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

Pedro Igor Silva psilva at redhat.com
Fri Oct 26 08:18:27 EDT 2018


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 at gmail.com>
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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


More information about the keycloak-user mailing list