[keycloak-user] Multi-tenant system: Using single /certs endpoint for all realms (spring-security-oauth2)

Ori Doolman Ori.Doolman at cyberark.com
Thu Nov 7 15:21:42 EST 2019


Hi,
I'm using spring-security-oauth2-autoconfigure package in my Spring boot Java service for securing my REST endpoints. I'm not using any Keycloak adapters. It's basically working, but there is a problem with multi-tenancy (multi realms).
I'm getting the Keycloak token in the Authorization header, and then the spring code is using a class named  JwkTokenStore (and other related ones) to verify the token signature.
For that, it is getting the public key from Keycloak by interrogating the /certs endpoint.

In keycloak, each realm has its own public key (represented by different KID) and also its own /certs endpoint.
For example, if I have 2 tenants on my system, then my service will have to interrogate 2 endpoints:

/auth/realms/{tenant1}/protocol/openid-connect/certs
/auth/realms/{tenant2}/protocol/openid-connect/certs


This poses an issue, since it means I will have to interrogate another endpoint each time I add another tenant to my system.
And unfortunately, spring-security-oauth2 does not support dynamic discovery of new public key endpoints. It can only use the ones provided upon startup.
It means I have no way to support dynamic on-boarding of new tenants.

My questions:

1) Is there any way to configure Keycloak to use a single /certs endpoint for all the realms (and return the KIDs of all realms)?
Or maybe have all realms share the same keys between them and then I will always use the master realm endpoint.

2) Why different realms must use different keys in Keycloak? I suppose the answer would involve the term "security"  : )
But still, when using Google APIs, all customers are using the same public key from this URL:  https://www.googleapis.com/oauth2/v3/certs .


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.


More information about the keycloak-user mailing list