Keycloak sping boot authorisation with multi tenancy

261 views

Skip to first unread message

Karthik Narahari

unread,

Oct 6, 2021, 3:53:52 PM10/6/21

to keyclo...@googlegroups.com

Hi,

We are using Keycloak spring boot starter on our Rest API for authentication and authorisation. We do support multi tenant also (which means we can get requests with tokens generated from different realms). So to handle this we and add extended/overided KeycloakSpringBootConfigResolver and added our logic to evaluate and pass in the specific keycloakdeployment object for the realm where we want to validate the token.

All this works fine, But the concern that we have is, we see the adapter is doing too many api calls to keycloak both for token validation(calls for open id config, certs, token validation) and authorisation (fetch resource details etc). we traced the requests and roughly below are the calls that go to keycloak for each request that comes to our api which is increasing the latency of our apis to a lot

GET <host>/auth/realms/<realm>/.well-known/openid-configuration
GET <host>/auth/realms/<realm>/protocol/openid-connect/certs
GET <host>/auth/realms/<realm>/.well-known/uma2-configuration (3 times)
POST <host>/auth/realms/<realm>/protocol/openid-connect/token
GET  <host>/auth/realms/<realm>/authz/protection/resource_set?owner=client1&matchingUri=false&deep=true&max=-1&name=users&exactName=true (multiple times, we feel it is based on no of scopes this particular resource is mapped with)
GET <host>/auth/realms/<realm>/authz/protection/resource_set?owner=client1&matchingUri=false&deep=true&max=-1&name=lookups&exactName=true (multiple times, we feel it is based on no of scopes this particular resource is mapped with)
POST <host>/auth/realms/<realm>/protocol/openid-connect/token
GET <host>/auth/realms/<realm>/.well-known/openid-configuration

Can someone help if we are doing this wrong, is this expected or is there anything that we can add to the adapter settings to just use introspect api (which we understand validates the token and return the scopes allowed for a token in a single call) and enforce the authorisation.

BTW, we tried using settings like path cache, lazy loading etc. nothing seems to reduce these requests.