[keycloak-user] Keycloak Groups vs. Roles vs. Composite Roles vs. Auth Scope?
Pedro Igor Silva
psilva at redhat.com
Fri Oct 26 09:35:02 EDT 2018
Yes, "Resources/Scopes (of the Authorization tab). Where "Issue" is a
resource with CRUD scopes. You could define permissions for each individual
scope, for all of them, of a sub set of them, etc. Associating these
permissions to policies like "Only Manager", "Only Tester", etc.
For instance, consider the "delete" scope. You may have a scope-permission
as follows:
- Scopes: delete
- Policies: Only Manager
For the "move" scope:
- Scopes: move
- Policies: Only Manager, Only Tester
- Decision Strategy: AFFIRMATIVE (grants access if any policy gives a
grant).
On Fri, Oct 26, 2018 at 10:28 AM Melissa Palmer <melissa.palmer at gmail.com>
wrote:
> 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
>>>>
>>>>
More information about the keycloak-user
mailing list