Re: [keycloak-user] Keycloak Groups vs. Roles vs. Composite Roles vs. Auth Scope?

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