4:27 a.m.
Hello all,
I have a keycloak linked with two external idp, one
OIDC "IDP-A" and one SAML2 "IDP-B".
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:
level_1
I have three
keycloak clients, Client-01, Client-02, Client-03.
Client-01, is a OIDC
client and is about a web application secured with the keycloak oidc
TOMCAT adapter.
Client-02, is a SAML2 client and is about a web
application secured with the keycloak saml TOMCAT adapter.
Client-03,
is a OIDC client for a java web application (for test purpose only)
without a keycloak adapter.
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:
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 :
level_1
*
SAML2 TO SAML2 BROKERING. Client-02 adds
the parameter to samlp: AuthnRequest:
level_1
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:
level_1
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?_ Thanks to all,
Jcappaerre.
Con Tiscali Mobile Smart 30 hai minuti illimitati, 30 Giga e 100 SMS a soli 7,99€ al mese.
L'attivazione è gratis e disdici quando vuoi. http://tisca.li/smart30