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

[Melissa Palmer]

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

>
>
> 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
>>>
>>>