----- Original Message ----- > From: "Jorge Solórzano" <jorsol(a)gmail.com&gt; > To: "Bill Burke" <bburke(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Tuesday, November 3, 2015 7:33:07 PM > Subject: Re: [keycloak-dev] roles vs. groups > > I think the concepts should be standardized: > > Permissions: are the most atomic level of a security policy and they > are statements of functionality. Can you open a door? Can you read a > file? Can you delete a customer record? Can you push a button? > > Roles: are effectively a collection of permissions used to simplify > the management of permissions and users. So users can be assigned > roles instead of being assigned permissions directly, which can get > complicated with larger user bases and more complex applications. So, > for example, a bank application might have an administrator role or a > bank teller role. > > Users: A user is the "who" of an application. > > Groups: Is a collection of users and define a set of roles/permisions, > users are members of groups. > > The asociation for me is something like this: > Groups can have Roles and/or Permisions asociated to it. > User can have Roles and Permisions and can be members of Groups, by > inheritance users that are members of groups have all the permisions > asociated to the groups. > Roles can have one ore more permissions, this are explicit permisions. > > There should be deny permisions too. Don't you think that positive logic is enough ? > > > Jorge Solórzano > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev

> 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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.

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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

On 11/4/2015 10:26 AM, Stan Silvert wrote: > 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. > We dont' have the concept of a permission, so, assigning roles to a composite role is equivalent right now of assigning permissions to a role.

> 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. > App developers focus on designing the roles/permission model for the applications and would deal with roles, composite roles, and clients. User admins would focus on managing users and defining groups and assigning permissions/roles to groups and users. Instead of dealing with fine-grain roles/permissions for each and every application, user admins just deal with coarse grain composite roles.

On 11/4/2015 11:21 AM, Stan Silvert wrote: > On 11/4/2015 10:37 AM, Bill Burke wrote: >> On 11/4/2015 10:26 AM, Stan Silvert wrote: >>> 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. >>> >> We dont' have the concept of a permission, so, assigning roles to a >> composite role is equivalent right now of assigning permissions to a role. > Isn't that what Pedro is working on right now? No. His is like: user in this group as write access to this document. This is just roles and sets of roles.

> > 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

From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Tuesday, November 3, 2015 7:04:43 PM Subject: [keycloak-dev] roles vs. groups Stian and I were having a conversation about roles, keycloak composite roles, vs. groups. It seems that groups and roles are often confused and one can be equivalent to the other. One common thread is the following: Groups are user centric. Roles are permission centric. "A group is a means of organising users, whereas a role is usually a means of organising rights."

So, keycloak composite roles would be a way to organise rights for a set of applications. For example, you might have a set of sales services, each sales service has an "admin" and "user" role. You'd define a "sales user" and "sales admin" role which would be a composite containing the "admin" and/or "user" role of each sales service. Conversely, a keycloak group would provide a way to organize a set of users. You would create a group called "sales associates" add members to it and then assign the roles members of the group can partake. Really, in Keycloak with composite roles, you can have a role act as a group. So, while groups and roles are logically the sameAdding the concept of a group though provides distinction and clarity without overloading the concept of a composite.

So, given that, Role mapping tab for Groups and Users would be named "Permissions" instead of "Role Mappings". Each role would have a "Rights" tab instead of the "Composite Role" concept we have now. That might bring more clarity? Or will it just confuse concepts that are going to be introduced by Pedro and his Authz stuff?

I'm also thinking that a Groups and Role Namespaces could be combined. So a group would have a set of "Permissions" (role mappings) that are automatically granted to user members. The group could also define a set of "Roles" that apply to this group. So "Sales" could have a "Manager" role. This "Manager" role would be a composite role that assigns additional permissions. This would also allow us to define default roles for

Whoops, I didn't finish.... Combining Groups and Role Namespaces would allow us to define built in roles for the Group that when assigned would allow management of the members of the group.

-- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

On 11/3/2015 5:01 PM, Pedro Igor Silva wrote: > ----- Original Message ----- >> From: "Bill Burke" <bburke(a)redhat.com&gt; >> To: keycloak-dev(a)lists.jboss.org >> Sent: Tuesday, November 3, 2015 7:04:43 PM >> Subject: [keycloak-dev] roles vs. groups >> >> Stian and I were having a conversation about roles, keycloak composite >> roles, vs. groups. It seems that groups and roles are often confused >> and one can be equivalent to the other. One common thread is the following: >> >> Groups are user centric. Roles are permission centric. >> >> "A group is a means of organising users, whereas a role is usually a >> means of organising rights." > IMO, groups can also be used to organize rights. It is quite common to only check if an user is member of a group or any of its parents. Despite any role ... > > In any case, handle groups and roles separately is the best way to go ... > >> So, keycloak composite roles would be a way to organise rights for a set >> of applications. For example, you might have a set of sales services, >> each sales service has an "admin" and "user" role. You'd define a >> "sales user" and "sales admin" role which would be a composite >> containing the "admin" and/or "user" role of each sales service. >> >> Conversely, a keycloak group would provide a way to organize a set of >> users. You would create a group called "sales associates" add members >> to it and then assign the roles members of the group can partake. >> >> Really, in Keycloak with composite roles, you can have a role act as a >> group. So, while groups and roles are logically the sameAdding the >> concept of a group though provides distinction and clarity without >> overloading the concept of a composite. > +1 > > Regarding "role act as a group". Yes, you can. And that is what JEE gives you and it is not enough when you really need to support the group concept, specially when you need to consider group hierarchies, permission inherited to members, etc. You need some role mapping hack to get all that working. > > IMO, Role (or composite role) != Group ... > >> So, given that, Role mapping tab for Groups and Users would be named >> "Permissions" instead of "Role Mappings". Each role would have a >> "Rights" tab instead of the "Composite Role" concept we have now. That >> might bring more clarity? Or will it just confuse concepts that are >> going to be introduced by Pedro and his Authz stuff? > Basically, what you are doing is group and role mapping in the end. Where you can add "permissions" to an group or an user. > > The Authz stuff will just use whatever you define in order to write policies for your protected resources. For instance, we can now define a Group-Based Policy, so you can say that all members of a group (or any of its parents) can access a resource or perform some operation on it. > > Or even say that any member with a role X within a group can do something. > >> I'm also thinking that a Groups and Role Namespaces could be combined. >> So a group would have a set of "Permissions" (role mappings) that are >> automatically granted to user members. The group could also define a >> set of "Roles" that apply to this group. So "Sales" could have a >> "Manager" role. This "Manager" role would be a composite role that >> assigns additional permissions. This would also allow us to define >> default roles for >> Whoops, I didn't finish.... >> Combining Groups and Role Namespaces would allow us to define built in >> roles for the Group that when assigned would allow management of the >> members of the group. > If I got this properly, what you mean is support "GroupRole" relationships. Where you may say that Bill is Manager in Group A. > > IIRC, Hawkular requires that. > I'm just proposing a role namespace. i.e. Group A defines a role called "Manager". Bill has role mapping A.Manager. I want to avoid overlapping with what you are doing. Each group would have some built in declared roles: i.e. add-user, manage-user, manage-group, etc...So that a user can be permitted to manage the members of the group. A few people have been asking for this.

> > I'm just proposing a role namespace. i.e. Group A defines a role called > "Manager". Bill has role mapping A.Manager. I want to avoid > overlapping with what you are doing. Each group would have some built > in declared roles: i.e. add-user, manage-user, manage-group, etc...So > that a user can be permitted to manage the members of the group. A few > people have been asking for this. > So my understanding is correct. This is what I meant by "GroupRole" relationships, which is also supported in PL. However, there we don't have roles within a group. But you can just assign any existing role to an user in the scope of a specific group.

Regarding the overlap, there is no overlap with what I'm doing. What I'm doing is permission, what an user is actually allowed to do, considering the resources and the actions that can be performed on them (plus other things related authz). Like I said, we are going to use all the stuff you are doing to actually define permissions/policies for protected resources. Maybe the names "Permission" and "Rights" are not the best ones for what you are doing ? Maybe you should keep "Role Mapping" instead ? Conceptually, what you are doing is not permissions ...

> 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.