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

Pedro Igor Silva psilva at redhat.com
Thu May 23 11:58:41 EDT 2019


On Thu, May 23, 2019 at 12:21 PM Ori Doolman <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://aka.ms/ghei36>
>
> ------------------------------
> *From:* Pedro Igor Silva <psilva at redhat.com>
> *Sent:* Thursday, May 23, 2019 5:49:11 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
>
> 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>
> 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
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>> <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=>
>>
>


More information about the keycloak-user mailing list