[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