[keycloak-dev] roles vs. groups

[Stan Silvert]

On 11/4/2015 9:15 AM, Bill Burke wrote:
> I've alread stated the reason for composite roles:
>
> Say you have a set of applications under the Sales and Marketing
> Department:  A Leads Application, Eloqua, and Salesforce.  Each of the
> applications has a set of roles that are used to manage access to
> various features of each application.  For example, each app might have
> an "admin" role.  You would then want to organize permissions into
> categories and assign coarser grain roles to individual users.  So, you
> would create a "Sales Admin" composite role that contains the "admin"
> role of each sales application.  Composite roles allow you to group
> together roles into role catagories that you can assign to a specific
> user or user group.
>
> User Groups are different as you want to assign a set of permissions to
> a group of users.
>
> So composite roles are used to group together roles of a set of
> applications.  User Groups are used to grant a set of perissions to a
> set of users.
Maybe it's just me, but I think of user groups as just a way to group 
users, and roles as a way to group permissions.  Roles are assigned to 
user groups.  Permissions are assigned to roles.

I don't see why you need anything more.  In your example, each 
application has an admin role that has a set of permissions for the 
application.  Each admin role can be assigned to a Sales Admin user 
group.   Sales Admin users are assigned to the Sales Admin user group.  
Done.

User Groups, Roles, and Permissions are common concepts.  Are there 
other systems that use composite roles?  I honestly don't know the 
answer, but I'm pressing on this point right now because I don't want us 
to be stuck with a concept that users don't readily understand and has 
not been found to be useful elsewhere.

>
> On 11/4/2015 8:43 AM, Stan Silvert wrote:
>> First, +1 to adding groups and permissions, because that's what our
>> users expect to see.
>>
>> I'm going to go ahead and say what I was hoping to say last night.  It's
>> hard to visualize this stuff without seeing diagrams, but I'm wondering
>> if we still need composites.  That is, once we have groups, roles, and
>> permissions, do composites really solve something that can't be done as
>> easily or better with the groups, roles, and permissions?
>>
>> Composites have been a point of confusion.  I can remember when I first
>> started working with Keycloak that it took awhile to get comfortable
>> with composites.  I think that's the reaction our users are having as
>> well.  From a technical standpoint, they are very powerful.  But that's
>> not readily apparent to a lot of people, which is why users are always
>> asking for groups.  Perhaps we should give up some technical elegance
>> for something that's easier to understand.
>>
>> If composites are only there for convenience, I'd say get rid of them.
>> IMO, we should favor something that's easy to understand and still gets
>> the job done.  (As a bonus, simpler data structures are easier to deal
>> with as we add new features!)
>>
>> On 11/4/2015 7:46 AM, Pedro Igor Silva wrote:
>>>> Let's supose, you have a group called "GroupA", that group have roles
>>>> "Create invoice" this has 13 permisions, "Remove invoice" this has 5
>>>> permisions, "Update invoice" this has 19 permisions...
>>>>
>>>> I asign 25 users to Group A, but 2 users, should not have 3 permisions
>>>> that are different in both users, should I need to create "GroupB" and
>>>> "GroupC" with the exact permissions, just to handle this 3 permisions
>>>> exclusions?
>>>>
>>>> It probably can be a little overkill, but IHMO is more flexible than
>>>> an all or nothing approach.
>>>>
>>> I see your point. However, IMO, when you start to use negatives you may end up with something more complicate and hard to follow.
>>>
>>> What I meant by positive logic is not an all or nothing approach, but use positives permissions and play with them to match your requirements.
>>>
>>> For instance, we are developing some additional authorization features to Keycloak. There you can define a set of policies that rule access to your resources based on different type of access control mechanisms: rbac, contextual/risk-based, abac, user-based, etc.
>>>
>>> Policies can be applied to a resource type, resource instance, a specific scope (eg.: create, remove, delete, etc) or a combination of them. Policies are also independent of each other and can be reused and combined in different ways to actually define and enforce authorization for a given resource/scope.
>>>
>>> Considering you scenario, you would have something like that:
>>>
>>>        - Only Group A Policy (defines that all members of Group A can *do something*)
>>>        - Resource X Policy (here we are telling what Group A can do. In this case, access Resource X and any of its scopes)
>>>          - Applies Only Group A Policy
>>>
>>> You can also have something like:
>>>
>>>        - Only Group A Policy (defines that all members of Group A can *do something*)
>>>        - Create Invoice Policy (here we're telling that Group A can access a specific scope.)
>>>          - Applies Only Group A Policy
>>>
>>> Now, if you want specific policies for some of your users, you can do something like:
>>>
>>>        - Exceptional Y Policy (which can define a specific user, role, group, any contextual information like current time or authentication method)
>>>        - Create Invoice Policy
>>>          - Applies Only Group A Policy
>>>          - Applies Exceptional Y Policy
>>>
>>> That will provide flexible policies, make them more meaningful and easy to follow/understand. We are considering protect resources as important assets within an organization, which should be ruled by a set of policies that must be applied before accessing them.
>>>
>>> I would appreciate if you could provide some more info about your use case. Right now I'm writing some examples and would be nice to check how your requirements can be addressed (or not :)) with what we did so far.
>>>
>>> Thanks.
>>> Pedro Igor
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>