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

[Dmitry Telegin]

Just a followup - if your IdP is able to 1) redirect back to a specific Keycloak URL upon successful login, 2) provide verifiable (e.g. signed) assertion of successful login, then you can use the approach demonstrated in this quickstart [1].

Unfortunately, you will lose the benefits of IdP brokering like first broker login flow, token storage etc., but this might be easier to implement.

[1] https://github.com/keycloak/keycloak-quickstarts/tree/latest/action-token-authenticator

Good luck,
Dmitry Telegin

Carretti Consulting OÜ | Keycloak Consulting and Training
Sepapaja 6, Tallinn 15551, Estonia | info at carretti.pro

On Fri, 2019-05-24 at 17:39 +0300, Dmitry Telegin wrote:
> Hello Cécile, answers inline,
> 
> On Thu, 2019-05-09 at 16:11 +0200, Cécile Radix Saint-Martin wrote:
> > Hi,
> > 
> > We wish to use Keycloak as our IDP for our application (frontend + REST
> > micro services).
> > We want to give users the possibility to authenticate using their
> > credentials of another application (login + password).
> > In the same time, our application needs to call this other application APIs
> > and for this, needs the custom token returned by the application during
> > authentication (this application is not OIDC compliant).
> > 
> > First I wanted to implement a custom identity provider for Keycloak, as it
> > enables to store token of external IDP. But there is very few documentation
> > about that and only examples I found are for OIDC providers.
> 
> 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.
> 
> > So finally I decided to implement a custom authenticator
> > (org.keycloak.authentication.Authenticator).
> > 
> > I want to be sure that with a custom authenticator, I will be able to :
> > - Store custom tokens of the other application
> 
> 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.
> 
> > provide it to a client API
> 
> 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.
> 
> > and refresh it if expired
> 
> 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.
> 
> > - Create user in Keycloak if it does not exist (if authentication with the
> > other application succeed)
> 
> 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 at carretti.pro
> 
> > Anyone can confirm ?
> > 
> > *Cécile RADIX SAINT-MARTIN*
> > *mailto:cecile.saintmartin at gmail.com <cecile.saintmartin at gmail.com>*
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user