[keycloak-dev] roles vs. groups

[Pedro Igor Silva]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, November 5, 2015 11:43:25 AM
> Subject: Re: [keycloak-dev] roles vs. groups
> 
> 
> 
> On 11/4/2015 9:36 AM, Pedro Igor Silva wrote:
> >> There really is no equivalent in Java EE for leveraging a
> >> User/Role/Group relationship.  We'd have to add it to our adapters.
> >> Isn't "users of Group A have the manager role" enough?
> >
> > For most cases yes. But if you want to be more flexible you can support
> > that as well. IIRC, Hawkular wants group role. And it might be useful for
> > others as well.
> >
> 
> Doesn't User/Role/Group start to overlap with what you're doing?  I
> thought Hawkular wanted a permission model so that you could assign
> permissions to resources based on group membership.  If I added a
> user/role/group relationship mapping, wouldn't people start using that
> to implement similar permission model to what you are doing?

Not really. What I'm doing is completely different and is related with permissions and fine-grained authorization.

One thing is say that User A has Role B. Or User A has Role B in Group C. Or User A is member of Group C. You are not assigning permissions, but defining a baseline to actually define them. Let's say you are logically separating permissions but not defining what, how and when can be accessed.

Like I said in other emails, whatever you define for roles and groups would be used to create policies, covering fine-grained permissions and considering different types of access control mechanisms such as role-based, group-based, user-based, context-based, attribute-based, etc.

Let's use the following example. You have defined that User A has Role B in Group C. From this statement you don't know what that means from a access control perspectice. You only know that User A has Role B in Group C. What that means from a access control mechanism is implicit and will probably be used to actually *enforce* a policy when accessing some resource. 

Usually, what people do is obtain that statement somewhere (eg.: from a token) and write a if statement around the code the will access a resource. 

Now, in the case of the Authz Server, you would not use ifs or enforce these policies by your self. You will use a rich and powerful policy engine to say if a resource can be accessed or not. Where you can use not only that statement (user/group/role) but mix other statements such as: user must have authenticated with OTP, time must be XX:XX:XX, the authenticated user must be the resource owner, only the Action X can be performed, etc.

Or you can even just ask the authorization server for all the *entitlements* for an user. And the server will give you which resources and what actions can be accessed/performed by a given user.

Regarding Hawkular, they need a permission model, yes. But they also need a permission model that can also support policies/permissions based on User/Role/Group relationship.

> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>