----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: keycloak-dev(a)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