Re: [keycloak-user] Configure Keycloak to be able to delegate authentication to other application

Hello Cécile, answers inline, On Thu, 2019-05-09 at 16:11 +0200, Cécile Radix Saint-Martin wrote: The overall approach should depend on the semantics of the protocol used by your external IdP ("another application"). If the protocol is redirect-based, like OIDC and SAML, then yes, custom identity provider is definitely the way to go. This is also beneficial because IdP infrastructure in Keycloak already provides facilities for token storage, user creation upon first login etc. As for documentation - I personally don't like the mantra "code is the best documentation", but seems like this is just the case here. Here is the hierarchy of IdPs currently implemented in Keycloak: AbstractIdentityProvider AbstractOAuth2IdentityProvider BitbucketIdentityProvider FacebookIdentityProvider GitHubIdentityProvider InstagramIdentityProvider LinkedInIdentityProvider MicrosoftIdentityProvider OIDCIdentityProvider GitLabIdentityProvider GoogleIdentityProvider KeycloakOIDCIdentityProvider OpenshiftV3IdentityProvider PayPalIdentityProvider StackoverflowIdentityProvider SAMLIdentityProvider TwitterIdentityProvider When solving a similar problem, I used SAMLIdentityProvider as a reference, since I found it to be more understandable (but that's personal of course). But if your IdP's protocol is not redirect based (like e.g. it uses REST or even TCP socket API that consumes login/password and returns a token), then the only option would be custom authenticator. IdPs (including custom) have that out ouf the box, via FederatedIdentityModel::token. OTOH, custom authenticator will need to take care of it itself. If you're ok with transient tokens, then you can simply attach them to user sessions (using so called "user session notes"). If you need persistent tokens, you'll also need to implement a custom JPA entity for that. In both cases (custom IdP and custom auth), you'll need a client mapper to push external token from the user session to the target OIDC token, as a custom claim. Is it correct that your client side will always need a valid external token, and you want to delegate the refresh process to Keycloak? If so, you will need another client mapper to handle this. Each time the client asks Keycloak to refresh main (OIDC) token, the mapper will kick in and perform external refresh too, if needed, thus ensuring that both tokens (OIDC and external) are valid. Again, if using custom IdP, this will be out of the box via First Broker Login flow. In the case of custom authenticator, you should be also able to invoke the same flow when needed. But you will also need to implement internal-to-external user mapping; that should be easy if the username could be unambiguously derived from the external token. Otherwise, you will have to implement something similar to FederatedIdentity mechanism used by IdPs. Feel free to ask any further questions, Dmitry Telegin Carretti Consulting OÜ | Keycloak Consulting and Training Sepapaja 6, Tallinn 15551, Estonia | info(a)carretti.pro