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

[Pedro Igor Silva]

On Fri, Oct 26, 2018 at 10:15 AM Melissa Palmer <melissa.palmer at gmail.com>
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 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
>>
>>