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.