In my scenario, when an application (Client-01, Client-02, Client-03) have to autenticate a user, keycloak shows the login page. In the keycloak login page the user can (in addition to authenticating directly with keycloak) choose an external idp between IDP-A and IDP-B. Here a representation:
The two external IDP have these constraints:
-
IDP-A wants an additional parameter called “acr_values” in the authentication request that can take one or more of these values "level_1", “level_2”, “level_3”
-
In a similar way IDP-B expect in the saml request the same information about “level_1”, “level_2”, “level_3 in an attribute like this:
<samlp:RequestedAuthnContext Comparison=“exact”>
<saml:AuthnContextClassRef xmlns:saml=“urn:oasis:names:tc:SAML:2.0:assertion”>level_1</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
Keycloak offers the possibility of defining mappers to manage the conversion of attributes from IDP-A and IDP-B, but it is a feature that concerns the “return path”, ie the mapping of attributes in the response from external IDPs to client through brokering.
What I need for is a mapping in the other direction, a mapping of the parameters in client requests, in particular this is what I would like to get:
-
oidc to oidc brokering . Client-01 adds to the Authentication Request the parameter “acl_values = level_1” (for example), if the user chooses IDP-A this parameter must be propagated as it is in the Authentication Request to IDP-A
-
oidc to saml2 brokering. Client-01 adds to the Authentication Request the parameter “acl_values = level_1” (for example), if the user chooses IDP-B this parameter must be propagated in samlp: AuthnRequest to IDP-B in the form :
<samlp:RequestedAuthnContext Comparison=“exact”>
<saml:AuthnContextClassRef xmlns:saml=“urn:oasis:names:tc:SAML:2.0:assertion”>level_1</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext> -
saml2 to saml2 brokering. Client-02 adds the parameter to samlp: AuthnRequest:
<samlp:RequestedAuthnContext Comparison=“exact”>
<saml:AuthnContextClassRef xmlns:saml=“urn:oasis:names:tc:SAML:2.0:assertion”>level_1</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
If the user chooses IDP-B, the parameter must be propagated as it is in samlp: AuthnRequest to IDP-B -
saml2 to oidc brokering. Client-02 adds the parameter to samlp: AuthnRequest:
<samlp:RequestedAuthnContext Comparison=“exact”>
<saml:AuthnContextClassRef xmlns:saml=“urn:oasis:names:tc:SAML:2.0:assertion”>level_1</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
If the user chooses IDP-A, the parameter must be converted to a parameter “acl_values =level_1” in the Authentication Request oidc to IDP-A
In Client-03, for test purpose, I wrote the code that makes the authentication call via oidc and then “manually” added the “acl_values =level_1” parameter in the Authentication Request. This is a piece of my code:
StringBuilder stringBuilder = new StringBuilder();
stringBuilder.append(this.authorizationUri);
stringBuilder.append(addFirstParam(“client_id”,client_id));
stringBuilder.append(addParam(“response_type”, “code”));
stringBuilder.append(addParam(“acr_values”,“level_1”));
stringBuilder.append(addParam(“redirect_uri”,redirect_uri));
stringBuilder.append(addParam(“scope”, “openid”));
loginUrl = stringBuilder.toString();
response.sendRedirect(loginUrl);
My first doubt is how to add these additional and arbitrary parameters through the adapters? I want do the same of this code but with the tomcat adapter or other.
From my tests the “acl_values = level_1” parameter added in the client-03 request is propagated as is in the request to IDP-A by KEYCLOAK. This is what I want for brokering oidc to oidc.
I have not yet tested a similar scenario for brokering saml to saml, but I suppose it works similarly by propagating the attribute as it is.
My second doubt: in the case of brokering oidc to saml or brokering saml to oidc, how can I map “acl_values = level_1” in its analogue in the request saml and vice versa?