[keycloak-user] How to get the role -> permissions for an authenticated user

Pedro Igor Silva psilva at redhat.com
Thu May 30 17:51:09 EDT 2019


Would be the account a resource and permissions their corresponding
scopes/actions that can be performed on an account ?

If a role implies access to some scopes/actions you can perform on an
account (which is a resource), you could write "scope-based policies" such
as:

* "Manager Permission" is defined for scopes A, B and C with a role-policy
that enforces "manager" role
* "Regular Permission" is defined for scopes X, Y and Z with a role-policy
that enforces "regular" role

With this setup, if the user has both manager and regular roles access
shall be granted to account and scopes A, B, C, X, Y, and Z. Otherwise, the
scopes granted will depend on the role assigned to the user.

On Thu, May 30, 2019 at 6:29 PM Ori Doolman <Ori.Doolman at cyberark.com>
wrote:

> Hi Pedro and all,
>
> I managed to use get an RPT given an access token.
>
> My problem is that I cannot find a good way to model my application's
> permission in Keycloak.
> Maybe you or someone else can help with that, since I think it is a pretty
> standard model:
>
> I have many "accounts" and many users.
> I have several roles in my application, each represents a set of allowed
> permissions.
> Each user is assigned a role *per account*.
> That means that one user can be a "manager" user for account 1 (with
> effective permissions a,b,c) and a "regular" user for account 2 (with
> effective permissions x, y, z).
> So as you see, my user roles (and permissions) is always in the context of
> an account.
> This is why I cannot just configure static client roles and use them for
> policies. My permissions always depend on the data, the account context.
>
> What is the best way (if any) to model this kind of permissions in
> Keycloak?
>
> Thanks,
> Ori.
>
>
> -----Original Message-----
> From: keycloak-user-bounces at lists.jboss.org <
> keycloak-user-bounces at lists.jboss.org> On Behalf Of Ori Doolman
> Sent: Thursday, May 23, 2019 9:35 PM
> To: Pedro Igor Silva <psilva at redhat.com>
> Cc: keycloak-user at lists.jboss.org
> Subject: Re: [keycloak-user] How to get the role -> permissions for an
> authenticated user
>
> Ok Pedro,
> I think I got it. Thanks a lot for thr clarification.
> My current plan is to make the exchange in API-GW.
> I get 2 advantages:
>
> 1) No change in client application and no need to involve client with
> server side authorization.
>
> 2) I need to make sure access token is still valid and user did not
> performed logout. API-GW seems the correct place to do that. So in a single
> call to KC I get both token validation and token exchange.
>
> I will try that and update the forum if succeeded. I think this is a
> typical classic deployment and such a documented solution can assist a lot
> of people.
>
> Ori.
>
> Get Outlook for Android<
> https://urldefense.proofpoint.com/v2/url?u=https-3A__aka.ms_ghei36&d=DwICAg&c=E55fojPA83XrPGfndbiaQQ&r=o_QF9VVN9H4LTRTYF8YMPkr6mGZ6BOo1SvoOkvu0tBw&m=5zurlkdmAWhsCMoYAVGUC1BNE8h1T4tFgpNVHb5eIr8&s=hiPvWoZ4YnB3lDZZxL_d8b-vGB5H0to2rJICMngePqY&e=
> >
>
> ________________________________
> From: Pedro Igor Silva <psilva at redhat.com>
> Sent: Thursday, May 23, 2019 6:58:41 PM
> To: Ori Doolman
> Cc: keycloak-user at lists.jboss.org
> Subject: Re: [keycloak-user] How to get the role -> permissions for an
> authenticated user
>
>
>
> On Thu, May 23, 2019 at 12:21 PM Ori Doolman <Ori.Doolman at cyberark.com
> <mailto:Ori.Doolman at cyberark.com>> wrote:
> Hi Pedro,
> Thanks for the prompt response :)
>
> Yes, I need RBAC only at the moment.
>
> When you said my web application should make the token exchange, do you
> mean client side (javascript ) or server side?
>
> Client-side
>
> I can also make it from API-GW which is even better I think. what is the
> common practice to send it to the server? I cannot use the Authorization
> header since it alteady contains the access token.
>
>
> Not sure if API-GW is better but you can replace the access token with
> permissions (sent by the client) in the authorization header. It is just an
> access token + permissions. Pretty much the original + permissions.
>
>
> Also, it means that I will have to make this call once per session (after
> login) rather than once in a process lifetime, since the roles->permissions
> mapping is pretty much static information.
> It doesn't sounds like the optimal approach.
>
> Yes, you would need a per session exchange.
>
>
> Ori.
>
> Get Outlook for Android<
> https://urldefense.proofpoint.com/v2/url?u=https-3A__aka.ms_ghei36&d=DwMFaQ&c=E55fojPA83XrPGfndbiaQQ&r=o_QF9VVN9H4LTRTYF8YMPkr6mGZ6BOo1SvoOkvu0tBw&m=kd7NLazIlAUReoX4xn1Isinku-QmPbxzujKjkg5CF78&s=kSulN2o1ygvKOHFKkrsYVnKZdGvuWpqYi8uwdhUudUc&e=
> >
>
> ________________________________
> From: Pedro Igor Silva <psilva at redhat.com<mailto:psilva at redhat.com>>
> Sent: Thursday, May 23, 2019 5:49:11 PM
> To: Ori Doolman
> Cc: keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
> Subject: Re: [keycloak-user] How to get the role -> permissions for an
> authenticated user
>
> There is no way to automatically set the permissions (from a client
> authorization settings) when an access token is issued. Like you said, you
> need another call to the token endpoint using the uma-grant-type.
>
> However, your web application will make that call only once in order to
> exchange the access token with another one with the permissions you need to
> access your backend. Your client should also be able to perform incremental
> authorization and limit the numbers of permissions within the token.
>
> Using a pure RBAC approach also works for your case, I think. Although you
> are limited to RBAC (thus tied with the roles you are using to protect
> resources) and not able to use resource-based authorization.
>
> On Thu, May 23, 2019 at 11:23 AM Ori Doolman <Ori.Doolman at cyberark.com
> <mailto:Ori.Doolman at cyberark.com>> wrote:
> Hi,
>
> I have a web application (Angular) which calls a REST API in a Java
> microservice.
>
> In my application, which manages books, I have a "regular" and "admin"
> roles.
> "regular" is allowed to execute API readBook.
> "admin" is allowed to execute APIs readBook, deleteBook, createBook.
>
> The mapping between the user roles to the permissions (book:read ,
> book:create, book:delete) is currently in my app DB. I guess I can migrate
> all roles and permissions into Keycloak using the
> resources/permissions/policies entities.
>
> I get an access token in the client (using code flow or implicit flow).
> The token contains the current user roles. But not the permissions.
> When I call my REST API I send the access token to my REST endpoint in the
> http header. The token contains the user roles, but not the user
> permissions. In fact, what I really need is the user permissions for
> checking authorization.
>
>
>
>   1.  What is the best practice of getting the user permissions in my REST
> service? Can I have them become part of the JWT access token when the token
> is created?
> Or is there any other recommended way to "map" the roles into the
> effective permissions at runtime?
> Maybe keep the role->permissions in my current DB and load them to service
> cache ?
>
>   2.  I want to avoid calling Keycloak for every REST API call because
> this will result bad performance. From what I read, if I want to use
> Keycloak authorization services I must call Keycloak for every API request
> and get the permissions (an RPT token). Is that the only way?
>
>
>
>   1.  Another alternative I thought of:
> have 2 user groups "Admins" and "Regulars". For "Admins" I will add roles
> "book:read" , "book:create", "book:delete" and for the "Regulars" group I
> will add only "book:read" role.
> This way, if a user belongs to the admins group, he will have all the
> permissions (roles) in the JWT access token.
>
>
> Thanks,
> Ori.
>
> ----------------------------------------------------------------------
> _______________________________________________
> This e-mail may contain information that is confidential, privileged or
> otherwise protected from disclosure.
> If you are not an intended recipient of this e-mail, do not duplicate or
> redistribute it by any means. Please delete it and any attachments and
> notify the sender that you have received it in error.
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_keycloak-2Duser&d=DwICAg&c=E55fojPA83XrPGfndbiaQQ&r=o_QF9VVN9H4LTRTYF8YMPkr6mGZ6BOo1SvoOkvu0tBw&m=5zurlkdmAWhsCMoYAVGUC1BNE8h1T4tFgpNVHb5eIr8&s=0rwHXNe4URgjDInU-A39bq3_yWW9rk_S713f0f0PvI8&e=
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_keycloak-2Duser&d=DwMFaQ&c=E55fojPA83XrPGfndbiaQQ&r=o_QF9VVN9H4LTRTYF8YMPkr6mGZ6BOo1SvoOkvu0tBw&m=C06JksmJ3-aEjipshrthQDy_e_8SFfiWTVg3xaAAi90&s=h3yWPfEVBy7AdTCBc2za37uwC0fzq34oyXd6IxbksNU&e=
> >
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_keycloak-2Duser&d=DwICAg&c=E55fojPA83XrPGfndbiaQQ&r=o_QF9VVN9H4LTRTYF8YMPkr6mGZ6BOo1SvoOkvu0tBw&m=5zurlkdmAWhsCMoYAVGUC1BNE8h1T4tFgpNVHb5eIr8&s=0rwHXNe4URgjDInU-A39bq3_yWW9rk_S713f0f0PvI8&e=
>


More information about the keycloak-user mailing list