Hello Cécile, answers inline,
On Thu, 2019-05-09 at 16:11 +0200, Cécile Radix Saint-Martin wrote:
We wish to use Keycloak as our IDP for our application (frontend + REST
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
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:
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
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
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
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,
Carretti Consulting OÜ | Keycloak Consulting and Training
Sepapaja 6, Tallinn 15551, Estonia | info(a)carretti.pro
Anyone can confirm ?
*Cécile RADIX SAINT-MARTIN*
keycloak-user mailing list