In Enterprise(highly trusted) environment account auto linking when using token exchange mechanism

[Goran Sustek]

Hi, this discussion is sequel of this(https://github.com/keycloak/keycloak/pull/6995) Pull Request, at least part for autolinking of existing account in external token exchange scenario.

And i fully understand those reasons:

#1 The malicious application may have gained access to a users account in some social provider that the user doesn't care about all that much so they have used an unsafe password. The application can now link this social provider this user didn't care about to then gain full access of the user account.

#2 A user should control if they want to enable social login to their Keycloak account, not an application

But i found out that more and more people needs this feature, and i assume they using highly trusted environment like Enterprise on premise environment.

 In those environment KC can behave like STS(just issuing token with identity from incoming JWT  from trusted  issuer  - https://datatracker.ietf.org/doc/html/rfc8693).

Case study:
If closed Enterprise environment has one EntIdP(KC) which is connected to LDAP in read-only mode and they implement external solution which is a black box(with internal intIdP) from they perspective serially connected in they business process it make sense to have high trust between those two IdP's.

 Clerk adding new item in CRM system.  HTTP synchronous request pass multiple components in chain and one of link in chain is black box... but request/process is not finished, black box need to call more services in Enterprise environment.

Clerk is authenticated on EntIdP and some kind credentials is exchanged to JWT access token, every service verify EntJWT against EntIdP, when request hits black box, token exchange is made from EntJWT to IntJWT. Every service inside black box   verify IntJWT against IntIdP, on Egress of black box, one final token exchange happens, from IntJWT to EntJWT and call chain is continued... 

I hope that you can understand this business case..

So far i tested this feature (https://www.keycloak.org/docs/latest/server_admin/#automatically-link-existing-first-login-flow) and this feature(https://www.keycloak.org/docs/latest/server_admin/#_disabling_automatic_user_creation) on KC 13.0.0, with token_exchange: i created two bi.directionally trusted IdP-s intIpd and extIdP(only he has users) then adjust on extIdP IdP First loging flow to custom authenticator flow from above examples, ,but autolink is not working. I assume that this First login Flow do not even touch token_exchange, because in tcpdump i saw that during identity brokering process requests for  token_exchange was not used.

in this scenation: 

extIdP(EntIdp): is one and only IdP in Enterprise environment

intIdP: is idp in black box solution

extIdP <-> intIdp - in mutual trust

1. obtain ext JWT with
   curl -v --insecure --request POST \ --url http://192.168.168.211:8081/auth/realms/ext-idp/protocol/openid-connect/token \ --header 'content-type: application/x-www-form-urlencoded' \ --header 'x-csrf-token: 1' \ --data grant_type=password \ --data username=test \ --data password=test \ --data client_id=oidc-client-from-intIdp \ --data client_secret=3e5e4547-cd0d-49af-84cc-5c87981be7ef \ --data scope='openid email profile' \ | jq -r '.access_token'
2. ext to int on intIdp
   curl --request POST \ --url http://192.168.168.211:8080/auth/realms/int-idp/protocol/openid-connect/token \ --header 'content-type: application/x-www-form-urlencoded' \ --header 'x-csrf-token: 1' \ --data grant_type=urn:ietf:params:oauth:grant-type:token-exchange \ --data subject_token=eyJ<REDACTED>WGw \ --data client_id=oidc-client-from-extIdp \ --data client_secret=cb409d7b-7dc6-479d-84f8-45e8fc5189e8 \ --data subject_token_type=urn:ietf:params:oauth:token-type:jwt \ | jq -r '.access_token'
3. int to ext from extIdp
   curl --request POST \ --url http://192.168.168.211:8081/auth/realms/ext-idp/protocol/openid-connect/token \ --header 'content-type: application/x-www-form-urlencoded' \ --header 'x-csrf-token: 1' \ --data grant_type=urn:ietf:params:oauth:grant-type:token-exchange \ --data subject_token=eyJ<REDACTED>Mg \ --data client_id=oidc-client-from-intIdp \ --data client_secret=3e5e4547-cd0d-49af-84cc-5c87981be7ef \ --data subject_token_type=urn:ietf:params:oauth:token-type:jwt

end's up with error_
10:21:12,971 WARN [org.keycloak.events] (default task-73) type=TOKEN_EXCHANGE_ERROR, realmId=ext-idp, clientId=oidc-client-from-intIdp, userId=null, ipAddress=172.17.0.1, error=federated_identity_account_exists, auth_method=token_exchange, grant_type=urn:ietf:params:oauth:grant-type:token-exchange, subject_issuer=http://192.168.168.211:8080/auth/realms/int-idp, validation_method=signature, client_auth_method=client-secret