You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a user is authenticated with several OPs, it should be possible to access his different identities and also its different access / ID tokens from the authorized client repository.
Current Behavior
Let's consider the following client configuration:
When the user authenticates on "Keycloak for A", he gets an OAuth2AuthenticationToken with an OidcUser principal which has among its properties: sub-a subject and an ID token with ${keycloak-realm-a-issuer} issuer. Also, an "authorized client" is added to the repository with keycloak-confidential-realm-a registration ID and sub-a.
Now, if after that he authenticates on "Keycloak for B" (additionally, without a logout from "Keycloak for A"), he gets a new OAuth2AuthenticationToken with a new OidcUser principal which has among its properties: sub-b subject and an ID token with ${keycloak-realm-b-issuer} issuer. Also, an additional "authorized client" is added to the repository with keycloak-confidential-realm-b registration ID and sub-b.
The main problem I have is that it is pretty difficult to retrieve the authorized client to issue request with tokens from ${keycloak-realm-a-issuer} as the Authentication in the security context knows about the sub-b only (and the repository expects sub-a as name to retrieve the authorized client for keycloak-confidential-realm-a registration).
Context
I am trying to migrate Angular applications configured as public OAuth2 client to the BFF pattern (Angular app secured with sessions on a middleware configured as OAuth2 confidential client, in my case: spring-cloud-gateway with TokenRelay filter) .
Some of this applications allow users to authenticate with several identity providers to query different set of services. For instance a doctor querying both health-care professionals and employers resource-servers. As the business required that resource servers and OP related to health-care were isolated from the rest of the information system, an OAuth2 client consuming the two set of services must acquire identities from the two OPs (the general purpose one and the health-care one) and send its REST queries to resource servers with the right access token.
The problem could be the same in applications proposing to add identities from social providers to activate optional features related to social graphs, Google APIs or whatever, with the client calling directly those APIs (each API provider trusts his own OP and would hardly accept access tokens issued by another one).
Work Arounds
I'm hacking a multi tenant client environment by using
some support code to store the various Authentication instances in session (one per client registration ID)
AOP to instrument OAuth2AuthorizedClientRepository / ServerOAuth2AuthorizedClientRepository and switching on the fly the Authentication to match the client registration.
Servlet
Store the several Authentication instances in session
Expected Behavior
When a user is authenticated with several OPs, it should be possible to access his different identities and also its different access / ID tokens from the authorized client repository.
Current Behavior
Let's consider the following client configuration:
When the user authenticates on "Keycloak for A", he gets an
OAuth2AuthenticationToken
with anOidcUser
principal which has among its properties:sub-a
subject and an ID token with${keycloak-realm-a-issuer}
issuer. Also, an "authorized client" is added to the repository withkeycloak-confidential-realm-a
registration ID andsub-a
.Now, if after that he authenticates on "Keycloak for B" (additionally, without a logout from "Keycloak for A"), he gets a new
OAuth2AuthenticationToken
with a newOidcUser
principal which has among its properties:sub-b
subject and an ID token with${keycloak-realm-b-issuer}
issuer. Also, an additional "authorized client" is added to the repository withkeycloak-confidential-realm-b
registration ID andsub-b
.The main problem I have is that it is pretty difficult to retrieve the authorized client to issue request with tokens from
${keycloak-realm-a-issuer}
as theAuthentication
in the security context knows about thesub-b
only (and the repository expectssub-a
as name to retrieve the authorized client forkeycloak-confidential-realm-a
registration).Context
I am trying to migrate Angular applications configured as public OAuth2 client to the BFF pattern (Angular app secured with sessions on a middleware configured as OAuth2 confidential client, in my case:
spring-cloud-gateway
withTokenRelay
filter) .Some of this applications allow users to authenticate with several identity providers to query different set of services. For instance a doctor querying both health-care professionals and employers resource-servers. As the business required that resource servers and OP related to health-care were isolated from the rest of the information system, an OAuth2 client consuming the two set of services must acquire identities from the two OPs (the general purpose one and the health-care one) and send its REST queries to resource servers with the right access token.
The problem could be the same in applications proposing to add identities from social providers to activate optional features related to social graphs, Google APIs or whatever, with the client calling directly those APIs (each API provider trusts his own OP and would hardly accept access tokens issued by another one).
Work Arounds
I'm hacking a multi tenant client environment by using
Authentication
instances in session (one per client registration ID)OAuth2AuthorizedClientRepository
/ServerOAuth2AuthorizedClientRepository
and switching on the fly theAuthentication
to match the client registration.Servlet
Store the several
Authentication
instances in sessionHack the authorized client repo
Reactive applications
Store the several
Authentication
instances in sessionHack the authorized client repo
The text was updated successfully, but these errors were encountered: