[keycloak-user] How to implement access to resources based on resource roles
Alfonso Alba García
alfonso at alfonsoalba.com
Thu Apr 18 08:36:52 EDT 2019
As you mentioned, at the moment our "organisations" are more similar to
groups than to real organisational units. We have one realm that holds
all our users and a simple client to login users and implement the
authorisation.
However, you made an important remark about SaaS and realms... I have to
think again about your "random thought", I knew about user federation
but I was not aware that I can delegate authentication to other realms.
I guess it's similar to when you activate "login with facebook", right?
But instead of that I will have a "login with Eden". I have to dig
deeper in Identity Brokering and user federation. Thanks again, you have
been super-helpfull!! :-)
Pedro Igor Silva wrote:
> It really depends on how different the organization settings are.
>
> Without knowing your use case in details, I assume that an organization
> may have different client applications. A SaaS solution would have
> organizations mapping to realms and not clients. In this case, each
> organization has its own user database and security settings.
>
> It seems that your use case is more likely related with groups as
> organizations given that you have a shared user database.
>
> FYI, the identity broker feature set in Keycloak can help to solve the
> "shared user database" across realms problem if you want to keep a
> single realm as them the main repository of users and still have these
> users "federated" to other dependent realms. Suppose you have an "Eden"
> realm where you manage all your users. Then you have "Organization Foo"
> realm and "Organization Bar" realm. Each of these realms would be
> configured to delegate authentication to "Eden" realm and thus have
> users federated across all of them. Just a random thought :)
>
> On Thu, Apr 18, 2019 at 8:09 AM Alfonso Alba García
> <alfonso at alfonsoalba.com <mailto:alfonso at alfonsoalba.com>> wrote:
>
> Hi Pedro,
>
> Thanks a lot for your answer. I will have a look at the three things
> you
> are suggesting: groups, resource types and pushing claims.
>
> At the moment I'm having a deeper look at the Policy Enforcer
> documentation. I consider that I read that part of the documentation
> and
> did not get it right. As you suggest, pushing claims can simplify my
> policies. I had a look at the app-authz-rest-employee[1] and
> app-authz-rest-springboot[2] examples. I already have some ideas about
> it after going through them. I will post an update after trying a
> little
> more.
>
> Just one last question: in the first post I asked if using one client
> per organisation would be a good idea or not. Has anybody some advice
> about this? I don't know if I'm using the client to do something it's
> not supposed to do.
>
> Thanks again,
>
> Alfonso
>
> --------
> [1]
> https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-rest-employee
> [2]
> https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-rest-springboot
>
> Pedro Igor Silva wrote:
> > Hi,
> >
> > Some comments inline ...
> >
> > On Wed, Apr 17, 2019 at 2:16 PM Alfonso Alba García
> > <alfonso at alfonsoalba.com <mailto:alfonso at alfonsoalba.com>
> <mailto:alfonso at alfonsoalba.com <mailto:alfonso at alfonsoalba.com>>>
> wrote:
> >
> > I've installed keycloak locally and now I'm trying to
> implement these
> > requirements. I've started with the ones I think are the
> easiest: The
> > organisation Owner an Administrator. Following what's
> suggested in the
> > threads mentioned above, I implemented these resource roles
> as follows:
> >
> > * Create three scopes: organisation:edit, organisation:view,
> > organisation:billing
> >
> > * Create a resource "Organisation 1" with scopes
> organisation:edit,
> > organisation:view and organisation:billing
> >
> > * Create two client roles "Organisation 1 Owner" and
> "Organisation 1
> > Administrator"
> >
> > * Create two policies: "Organisation 1 Owner Policy" and
> > "Organisation 1
> > Administrator Policy"
> >
> > * Create one scope-permission "Organisation 1 Managers
> Permissions"
> > that
> > allows users with roles "Organisation 1 Owner" or "Organisation 1
> > Administrator" get permission for the scopes
> organisation:edit and
> > organisation:view
> >
> > * Create one scope-permission "Organisation 1 Owners
> Permissions" that
> > allows users with roles "Organisation 1 Owner" access the scope
> > organisation:billing
> >
> >
> > Your policy model is fine but I think you can make it simpler if you
> > just use groups to represent organization membership.
> >
> > By using groups, you can have a single "Organization Resource",
> > "Organization Managers Permissions" and "Organization Owner
> Permission".
> > Your policies could benefit from claims pushed by your
> application [1]
> > in order to make decisions based on whether or not the user is a
> member
> > of an organization plus the RBAC.
> >
> > For instance, if you have in Keycloak a group "organization-foo" and
> > your application provides a REST endpoint like
> "/api/organizations/foo",
> > you could send the request URI to your policies, extract the
> "foo" part
> > of it and check if the user is member of organization-foo. I
> think the
> > same logic could be applied to other resource types.
> >
> > You could check this example [2].
> >
> > [1]
> >
> https://www.keycloak.org/docs/latest/authorization_services/index.html#_enforcer_claim_information_point
> > [2]
> >
> https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-rest-employee
> >
> > I created these for three organisations and as well as
> several users.
> > I've been playing around with them using the Evaluate
> functionality of
> > the keycloak client and apparently everything is working
> fine. Now I'm
> > thinking about how I could implement the access to the packages I
> > mentioned above, the members, etc, but before I continue I
> have several
> > questions:
> >
> > * Since users can have different roles in different
> organisations, I'm
> > creating only one realm. I guess that's ok since different
> realms do
> > not
> > share users.
> >
> > * For every organisation that we create in our application we
> will need
> > to create all the policies, roles and permissions described
> above. Is
> > this supposed to be like that or am I missing something?
> >
> > * If this is the way to do it, I was wondering if it's a good
> idea to
> > create a Resource Server (i.e. a new client inside the realm)
> for each
> > organisation. This way I can create a client
> organisation-1-client with
> > all the resources, policies and permissions for "Organisation
> 1". I
> > think that this will make deleting an organisation quite easy
> after the
> > user deletes the organisation, I just need to delete de client
> > organisation-1-client. I don't know if this a good idea or
> not, has it
> > any negative impact in performance? will this make the
> application code
> > more difficult? or may be this not a good practice for any
> reason?
> >
> >
> > I would recommend you to try other approaches like that one I
> suggested.
> > I can think about another one using resource types.
> >
> > Considering your current design, I think the addition of a new
> > organization is pretty much related to a provisioning logic backed by
> > our REST APIs, so you can automatize this process. But I hope you can
> > find an alternative ...
> >
> >
> > Thanks for your time. Regards,
> >
> > Alfonso
> >
> >
> > -------
> > [1]
> >
> http://lists.jboss.org/pipermail/keycloak-user/2016-August/007309.html
> > [2]
> http://lists.jboss.org/pipermail/keycloak-user/2018-June/014347.html
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org>
> <mailto:keycloak-user at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org>>
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
>
More information about the keycloak-user
mailing list