7:39 a.m.
Dear Keycloak team,
Please find below :
• Use case description
• GOALS
• What I tried
• Question and Proposals
Is the approach described the good one?
Does-it exists another one?
What is your preferred proposal?
Do you have another ?
Use case description :
All applications and rest services secured by OpenID (Keycloak)
User (Realm A) → Web application Front end 1 (Realm A) --> Application Back End 1
(Realm A)→ Rest Service 1 (Realm B)
→ Rest Service 2 (Realm C)
GOALS:
The solution must permit to identify the user himself into each component.
The User in Realm B must be linked to the User in Realm A.
What I tried:
By using the "Internal Token to External Token Exchange" features of Keycloak
it works if the user is existing in all the realms and if the account(s) are linked
between them.
And it works, thank you for the job !
The current issue is that I want that the application back end 1 creates the account(s)
into the required realms when it try to use the Rest Service in the other realm.
I try to implement the following use case:
User (Realm A) → Web application Front end 1 (Realm A) --> Application Back End 1
(Realm A) -- Request account creation and linking → Keycloak Realm B
-- Internal Token to External Token Exchange → Keycloak Realm B
→ Rest Service 1 (Realm B)
-- Request account creation and linking → Keycloak Realm C
-- Internal Token to External Token Exchange → Keycloak Realm C
→ Rest Service 2 (Realm C)
I take a look into the chapter 5.2. Client Initiated Account Linking but it involve that
it must be the user browser that trigger the http request.
I take look into IdentityBrokerService.clientInitiatedAccountLinking and it seems that all
the secure mechanism used is related to the cookie and the Keycloak user session.
The approach that I try cannot work with the current implementation of
clientInitiatedAccountLinking.
Question and Proposals:
Is the call flow that I try the right approach for achieving the goals ?
If yes and assuming that:
1) the account creation and auto-linking must be included into the Keycloak solution in
standard for managing the use case described (think about micro services)
2) the OIDC Tokens are enough for securing the creation of new account into other realms,
if a trusted relation exists between the realms of course !
Proposal 1:
clientInitiatedAccountLinking proposes 2 mode of securization, the current one based on
the cookie and a new one based onto the Bearer token.
Proposal 2:
A complete new HTTP request using the bearer token can be used for the account creation
and linking.
Proposal 3:
Keycloak exposes a new Rest method permitting to create and link account by using the
Token Bearer only
Proposal 4:
Keycloak exposes a new Rest method permitting to create an account into a realm by using
the Token Bearer only.
Keycloak exposes a new Rest method permitting to link two accounts into a realm by using
the Token Bearer only.
Comment:
For being able to create an account into an other realm without entering in conflict with
an existing account we can propose to used the UUID of the account from the realm used for
original authentication.
From my point of view it could be a decision that must be done during
the design of the security policy of the IT system. For example the administrator can
decide to use the email like a common ID between the realms or the UUID or any value that
he can apply onto the preferred_username like currently implemented for the account
linking feature.