-
Epic
-
Resolution: Done
-
Major
-
RH-SSO-7.1.3.GA, RH-SSO-7.2.0.CR1
-
None
Account details:
Name: Smals vzw-asbl
Oracle account no: 740644
TAM: Yes
SRM: No
Strategic: Yes
1. What is the nature and description of the request? (describe here what exact feature you need and why the existing functionality is not adequate for you to meet your current requirement).
We use the RH-SSO SAML client adapter to integrate web application authentication with a mandatory government non-Keycloak IdP. Applications are deployed in an OpenShift Enterprise v3 environment. Some of these applications have several routes defined to allow separating users based on their incoming access channel (internet, intranet, etc.). Users on a given access channel only have access to one and one only route.
We need the RH-SSO SAML client adapter to support setting the AssertionConsumerServiceURL from a dynamic source on outgoing AuthnRequest messages. Keycloak currently only supports setting this attribute statically in the keycloak-saml.xml descriptor.
2. Why do you need this feature? (List the business requirements here)
In the current state, the SAML client adapter only transmits the issuer (and, equivalently, a static AssertionConsumerServiceURL) to the IdP. The IdP is thus unable to tell which route the resulting SAML assertion should be sent back to. As such, we can only support one single access channel, which does not meet our business requirements.
3. How would you like to achieve this feature in RH-SSO ? (List the functional requirements here)
Following discussions with a Red Hat representative (support case 02010673), we've mutually come to the conclusion that the best way to support this feature would be to support multi-tenancy for the SAML client adapter, akin to what already exists for the OIDC adapter. This would involve the ability to implement a dynamic configuration resolver, which could then be suited to our purposes (i.e. setting the AssertionConsumerServiceURL based on incoming HTTP headers). Part of this issue has already been logged against Keycloak on issue KEYCLOAK-5214.
4. For each functional requirement listed, specify how Red Hat and you as our esteemed customer can test to confirm the requirement is successfully implemented.
We have test cases ready on our OpenShift environment which would allow us to verify successful login processes with the IdP.
In our case more specifically, setting up a web application protected by RH-SSO as an OpenShift service with two distinct routes, and showing that the AssertionConsumerServiceURL is set (according to incoming proxy headers) in outbound SAML AuthnRequests would be sufficient to validate the functionality.
5. Did you already file such feature request either in jboss community or through Red Hat bug tracking tools?
There are related issues:
KEYCLOAK-5214: SamlFilter - Allow KeycloakConfigResolver and SessionIdMapper to be configurable
KEYCLOAK-1925: SAML adapter multitenant support
6. Is the sales team involved in this request and do they have any additional input?
No.
7. List any affected packages or components. (For example: RH SSO Authentication, etc...)
RH-SSO SAML client adapter.
8. Would you be able to assist in testing this functionality if implemented?
Yes. We have test cases at the ready on our OpenShift environment.