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

[Melissa Palmer]

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 at redhat.com> 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 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
>
>