Hi, *Is it possible to explain the difference between "Keycloak Groups vs. Roles vs. Composite Roles vs. Auth Scope" more detail? * *I know there is the description here: * https://www.keycloak.org/docs/latest/server_admin/index.html#groups-vs-roles *From that I get * - Groups should focus on collections of users and their roles in your organization (Use groups to manage users. ). ☑

- Use composite roles to manage applications and services. ☑ - BUT previously said "Roles define a type of user and applications assign permission and access control to roles" & I don't see where you should maintain "access control to roles"

In other examples I see scopes being used for access control - album:view - album:delete Some more explanation on these different concepts would be greatly appreciated. Thank You in Advance Melissa _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

Hi Pedro Thank you for your reply - I understand that I can do programmatic vs externalized authorization. I want to use KC Authorisation Services(externalized authorization), BUT I am still trying to understand the Keyclaok concepts between - Groups vs. Roles vs. Composite Roles and most especially Roles vs. Composite Roles and how to get to the finer level of granularity. For example in a bug tracking tool I could have - Groups [eg: Audit, Contractors, Development, DevOps, QA, HODs, Help Desk] - Roles [eg: Manager, Developer, Tester, Audit, Owner] - Permissions/Functions which each have similar Access Control(privileged) [eg: Project: create, read, update, close/open, manage members, manage versions Issues: create, read, update, delete, move, Time: create, read, update, delete, manage activity types ] Generically I am thinking in terms of something like: Group --> Role --> Permission/Function --> Access Control (privileged) Development --> Manager --> Issues --> create/read/update/delete/move Development --> Tester --> Issues --> read/update/move Development --> Developer --> Issues --> read/update I am still not seeing how to do this in Keyclaok? The above example I have 4 levels (Group, Role, Permission, Privileged) where as in KC I only see 3 (Group, Composite Role, Role)

Thank you Melissa On Fri, 26 Oct 2018 at 14:18, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > You can achieve authorization using different approaches. I would group > these approaches in two main categories: programmatic vs externalized > authorization. > > When doing programmatic authorization, you are responsible to implement > the necessary logic to not only check if a subject is allowed to access > something but also to put some meaning on specific user attributes, such as > roles and groups, in order to decide whether or not access should be > granted. All that implemented in your application and subject to change in > case your security requirements change. At this category, roles, groups, > and even pure OAuth2 scopes, could be used to enforce access to your > resources. > > On the other hand, externalized authorization allows you to decouple your > application from the meaning you would normally put on your roles and > groups. Your application doesn't really care about the roles or groups that > a subject is associated with. It also doesn't care about which access > control mechanisms (role-based, group-based, context-based, *-based) was > used to grant access to a resource, giving you much more flexibility on how > you perform authorization in your application. What it does care is about > the permissions the subject has. When you are using our authorization > services you are basically abstracting from your application the different > access control mechanisms that govern access to the resources (and their > actions) and enforcing access based on permissions representing the actual > resources/scopes in your application. If your security requirements change > and you need to remove/add a new role and grant this role your users, you > won't need to change your application but the policies in Keycloak that > govern access to these resources. Your application would still enforce > access based on the resource: > > if (canAccess('album:read')) { > //read > } > > While the other approach would be: > > if (hasRole('X') and isMemberOf('Y')) { > // read > } > > Different from other solutions, Keycloak Authorization Services is based > on OAuth2, mainly. Thus, we include permissions inside tokens without force > applications to query the server every time for permissions. We also > support incremental authorization in order to allow permissions to be > included in tokens on-demand, reducing the size of tokens and more aligned > with the user experience. We also enable you to just query these > permissions without issuing tokens or just get a decision from the server > (grant/denied). > > Hope it helps. Take a look here for a little more details [1]. > > More answers inline. > > [1] > https://www.keycloak.org/docs/latest/authorization_services/index.html > > On Fri, Oct 26, 2018 at 6:23 AM Melissa Palmer <melissa.palmer(a)gmail.com&gt; > wrote: > >> Hi, >> >> *Is it possible to explain the difference between "Keycloak Groups vs. >> Roles vs. Composite Roles vs. Auth Scope" more detail? * >> >> *I know there is the description here: * >> >> https://www.keycloak.org/docs/latest/server_admin/index.html#groups-vs-roles >> >> >> *From that I get * >> - Groups should focus on collections of users and their roles in your >> organization (Use groups to manage users. ). ☑ >> > > Groups are repositories for users/personas. In Keycloak you can grant > *roles* to groups so users withing that groups are automatically granted > with these roles. > > >> - Use composite roles to manage applications and services. ☑ >> - BUT previously said "Roles define a type of user and applications >> assign >> permission and access control to roles" >> & I don't see where you should maintain "access control to roles" > > > Roles and composite roles are all about defining an access context in > your application. You may be a member of a "Sales" group representing a > business unit, but you are only a "Manager" if you have a "manager" role > assigned to you. > >> >> In other examples I see scopes being used for access control >> - album:view >> - album:delete >> >> Some more explanation on these different concepts would be greatly >> appreciated. >> >> Thank You in Advance >> Melissa >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > >

ok, so you saying for this example *Group --> Role --> Permission/Function --> Access Control (privileged)* Development --> Manager --> Issues --> create/read/update/delete/move Development --> Tester --> Issues --> read/update/move Development --> Developer --> Issues --> read/update in Keycloak model it as *Group --> Composite Role --> Role --> Scopes (of the "Authorization" tab)* Development --> Manager --> Issues --> create/read/update/delete/move Development --> Tester --> Issues --> read/update/move Development --> Developer --> Issues --> read/update On Fri, 26 Oct 2018 at 15:20, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > > > On Fri, Oct 26, 2018 at 10:15 AM Melissa Palmer <melissa.palmer(a)gmail.com&gt; > wrote: > >> Hi Pedro >> >> Thank you for your reply - I understand that I can do programmatic vs >> externalized authorization. >> >> I want to use KC Authorisation Services(externalized authorization), BUT >> I am still trying to understand the Keyclaok concepts between >> - Groups vs. Roles vs. Composite Roles and most especially Roles vs. >> Composite Roles >> and how to get to the finer level of granularity. >> >> For example in a bug tracking tool I could have >> - Groups [eg: Audit, Contractors, Development, DevOps, QA, HODs, Help >> Desk] >> - Roles [eg: Manager, Developer, Tester, Audit, Owner] >> - Permissions/Functions which each have similar Access >> Control(privileged) >> [eg: Project: create, read, update, close/open, manage members, manage >> versions >> Issues: create, read, update, delete, move, >> Time: create, read, update, delete, manage activity types >> ] >> >> Generically I am thinking in terms of something like: >> Group --> Role --> Permission/Function --> Access >> Control (privileged) >> Development --> Manager --> Issues --> >> create/read/update/delete/move >> Development --> Tester --> Issues --> >> read/update/move >> Development --> Developer --> Issues --> >> read/update >> >> I am still not seeing how to do this in Keyclaok? >> The above example I have 4 levels (Group, Role, Permission, Privileged) >> where as in KC I only see 3 (Group, Composite Role, Role) >> > > I don't get ... the missing level, "permission", would be the > resources/scopes you create for your client under the "Authorization" tab. > Where the permissions in the "authorization" tab will actually define > who/how/what can access things. For instances, I guess "Issues" and "CRUD" > are resources and scopes, respectively, right ? > > >> >> Thank you >> Melissa >> >> On Fri, 26 Oct 2018 at 14:18, Pedro Igor Silva <psilva(a)redhat.com&gt; >> wrote: >> >>> You can achieve authorization using different approaches. I would group >>> these approaches in two main categories: programmatic vs externalized >>> authorization. >>> >>> When doing programmatic authorization, you are responsible to implement >>> the necessary logic to not only check if a subject is allowed to access >>> something but also to put some meaning on specific user attributes, such as >>> roles and groups, in order to decide whether or not access should be >>> granted. All that implemented in your application and subject to change in >>> case your security requirements change. At this category, roles, groups, >>> and even pure OAuth2 scopes, could be used to enforce access to your >>> resources. >>> >>> On the other hand, externalized authorization allows you to decouple >>> your application from the meaning you would normally put on your roles and >>> groups. Your application doesn't really care about the roles or groups that >>> a subject is associated with. It also doesn't care about which access >>> control mechanisms (role-based, group-based, context-based, *-based) was >>> used to grant access to a resource, giving you much more flexibility on how >>> you perform authorization in your application. What it does care is about >>> the permissions the subject has. When you are using our authorization >>> services you are basically abstracting from your application the different >>> access control mechanisms that govern access to the resources (and their >>> actions) and enforcing access based on permissions representing the actual >>> resources/scopes in your application. If your security requirements change >>> and you need to remove/add a new role and grant this role your users, you >>> won't need to change your application but the policies in Keycloak that >>> govern access to these resources. Your application would still enforce >>> access based on the resource: >>> >>> if (canAccess('album:read')) { >>> //read >>> } >>> >>> While the other approach would be: >>> >>> if (hasRole('X') and isMemberOf('Y')) { >>> // read >>> } >>> >>> Different from other solutions, Keycloak Authorization Services is >>> based on OAuth2, mainly. Thus, we include permissions inside tokens without >>> force applications to query the server every time for permissions. We also >>> support incremental authorization in order to allow permissions to be >>> included in tokens on-demand, reducing the size of tokens and more aligned >>> with the user experience. We also enable you to just query these >>> permissions without issuing tokens or just get a decision from the server >>> (grant/denied). >>> >>> Hope it helps. Take a look here for a little more details [1]. >>> >>> More answers inline. >>> >>> [1] >>> https://www.keycloak.org/docs/latest/authorization_services/index.html >>> >>> On Fri, Oct 26, 2018 at 6:23 AM Melissa Palmer < >>> melissa.palmer(a)gmail.com&gt; wrote: >>> >>>> Hi, >>>> >>>> *Is it possible to explain the difference between "Keycloak Groups vs. >>>> Roles vs. Composite Roles vs. Auth Scope" more detail? * >>>> >>>> *I know there is the description here: * >>>> >>>> https://www.keycloak.org/docs/latest/server_admin/index.html#groups-vs-roles >>>> >>>> >>>> *From that I get * >>>> - Groups should focus on collections of users and their roles in your >>>> organization (Use groups to manage users. ). ☑ >>>> >>> >>> Groups are repositories for users/personas. In Keycloak you can grant >>> *roles* to groups so users withing that groups are automatically granted >>> with these roles. >>> >>> >>>> - Use composite roles to manage applications and services. ☑ >>>> - BUT previously said "Roles define a type of user and applications >>>> assign >>>> permission and access control to roles" >>>> & I don't see where you should maintain "access control to roles" >>> >>> >>> Roles and composite roles are all about defining an access context in >>> your application. You may be a member of a "Sales" group representing a >>> business unit, but you are only a "Manager" if you have a "manager" role >>> assigned to you. >>> >>>> >>>> In other examples I see scopes being used for access control >>>> - album:view >>>> - album:delete >>>> >>>> Some more explanation on these different concepts would be greatly >>>> appreciated. >>>> >>>> Thank You in Advance >>>> Melissa >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>>