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._ 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