SAML IDP-Initiated Login
SAP Customer Data Cloud supports you as both the Service Provider (SP) and/or Identity Provider (IdP). If you're implementing a SAML 3rd party IDP-Initiated Login implementation, using the SAP CDC as SP, this article will help you understand the fundamental challenges and how to address them.
Table of Contents
SAML stands for Security Assertion Markup Language and is a protocol that allows Identity Providers (IDP) to pass authentication and authorization information to Service Providers (SP) between separate systems.
What it means is that you can,
- Use one set of credentials to login into multiple websites like CRM, Active Directory etc.,
- Provide Single Sign-on (SSO) and Single Logout (SLO) between security domains.
- Enable IT shops to use software as a service (SaaS) solution while maintaining a secure federated Identity Management System.
The SAML specification was developed and is maintained by the Security Services Technical Committee of OASIS.
Please note: The main goal of this article is to demonstrate implementation, troubleshooting tips, and caveats for “IDP-Initiated SSO Login”.
IDP-Initiated SSO Login
An IDP-Initiated SSO flow is a Federation SSO operation that was started from the IDP Security Domain, by the IDP Federation server creating a Federation SSO Response and redirecting the user to the SP with the response message and an optional operational state:
The SAP CDC supports SAML 2.0, which uses 1) SAMLResponse with Assertion and a 2) RelayState to track operation state. This will convey the URL where the user should be redirected after the Federation SSO is complete at the SP. If missing, the SP will need to determine where the user should be redirected.
Please follow this link to read more on SAML2.0 specifications
IDP-Initiated SSO is most commonly used when an Enterprise has numerous vendors/partners with users that need to access your (the SP) site or resources, who maintain their own User Databases.
Users would generally gain access to your (the SP) resources via a portal page from within their home Enterprise's domain (the IDP).
User clicks on a link on an IDP portal page referencing the protected resource at the SP, which would prompt the user to login via the IDP (if not already) and, upon successful authorization, the user would gain access to the requested resources on the SP (your site).
Below sequence diagram represents high level flow.
- User is logged-into the IDP already and then start a Federation request using current session by specifying, a) the SP to be used and b) optionally the URL where the user's browser should be redirected after the Federation SSO is complete
- After having identified the user, the IDP creates an SSO Response with a SAML 2.0 Assertion containing user information as well as authentication data, and redirects the user's browser to the SP with the message and the RelayState parameter
- The user's browser presents the SSO response to the SP server
- The SP validates the SAML 2.0 Assertion and creates an SSO session for the user. The SSO server will then redirect the user's browser back to the resource originally requested
- The user's browser requests access to the resource. This time the SSO Web Agent grants access to the resource
- The Web Application returns a response to the user's browser
- Existing user session
This flow is commonly used when IDP users need to access resources hosted by an SP, but it is not the best approach for Federation SSO, as it disregards any existing valid SAP CDC session at the SP the user could already have. In this case, some care could be taken to prompt a user when their session on the site is about to be discarded. It could even be an opportunity for better insight into clients user-base (for example, you've just logged in to a separate account using an external identity provider, you should go to [special page] to learn about merging your accounts into a single master account).
2. Performance impact - SAML vs OpenID Connect (OIDC)
SAML requires extra requests to avoid any direct Server-Server communication and a more efficient federation option which requires Server-Server communication is SAP OIDC, which is also SAP Customer Data Cloud (CDC)-supported.
3. User experience
The user's experience as the browser will be redirected across different domains resulting in a delay before the user can get access to the targeted protected resource.
4. Redirect Auth-flow
Since SAP CDC IDP-Initiated SSO uses a "redirect" authFlow mode to handle the login, it requires a canonical name (CNAME)or a customAPIDomainPrefix otherwise, the login will not work on the client side. When using a CNAME, the login will succeed only for domains that are under the main site domain. If a site also has other domains configured for it that are not related to the main site domain, IDP-Initiated login will not succeed there.
- RelayState HTTP 404.xx error -Not Found
Check length of operational state message (RelayState), operational state message should not be too long, as it might break the redirect flows with the redirect URL length exceeding the maximum length that browsers can handle for URLs.
2. Login is not working
If the site has a customAPIDomainPrefix configured for it, the SAP CDC first redirects to the correct domain prefix. The endpoint redirects back to itself under the domain prefix that correlates to the redirect URL.
For example: the ACS endpoint gets RelayState =, and the customAPIDomainPrefix for this site is "gigya". When getting the IDP-Initiated SSO request, the ACS endpoint first redirects to and continues from there. If the site does not have a custom domain prefix, but does have a CNAME, SAP CDC redirects to the CNAME.
3. Site has a CNAME, but still user is not logged in
Validate the redirect URL (RelayState), if the redirect URL is on one of the allowed domains for the site, redirect to the redirect URL using the "redirect" auth flow. If the URL is not an allowed domain, the flow terminates with an error response so white-list RelayState root domain.
4. Scan SAMLResponse
The SAMLResponse parameter that is posted to ACS end-point provides insights and the best debugging source. Depending on the settings, the assertions may be compressed, encrypted, or simply encoded (example base64). In most cases by decoding (example base64-decoding), and then decompressing (when needed?) the SAML response and inspecting the resulting XML will help troubleshooting.
As indicated previously, in an IDP-Initiated use case, the identity provider is configured with specialized links that refer to the desired service providers. These links actually refer to the local IDP's Single Sign-On Service and pass parameters to the service identifying the remote SP.
So instead of visiting the SP directly, the user accesses the IDP site and clicks on one of the links to gain access to the remote SP. This triggers the creation of a SAML assertion that, in this example, will be transported to the service provider using the HTTP POST binding.
- If the user does not have a valid local security context at the IDP, at some point the user will be challenged to supply their credentials to the IDP site, idp.example.org.
- The user provides valid credentials and a local logon security context is created for the user at the IDP.
- The user selects a menu option or link on the IDP to request access to an SP web site, sp.example.com. This causes the IDP's Single Sign-On Service to be called.
The Single Sign-On Service builds a SAML assertion representing the user's logon security context. Since a POST binding is going to be used, the assertion is digitally signed before it is placed within a SAML <Response> message. The <Response> message is then placed within an Hypertext Markup Language (HTML) FORM as a hidden form control named SAMLResponse. If the convention for identifying a specific application resource at the SP is supported at the IDP and SP, the resource URL at the SP can be encoded into the form using a hidden form control named RelayState. The Single Sign-On Service sends the HTML form back to the browser in the HTTP response. For ease-of-use purposes, the HTML FORM typically will contain script code that will automatically post the form to the destination site.
The value of the SAMLResponse parameter is the base64 encoding of a <samlp:Response> element
The browser, due either to a user action or execution of an “auto-submit” script, issues an HTTP POST request to send the form to the SP's Assertion Consumer Service (acs).
The service provider's Assertion Consumer Service obtains the <Response> message from the HTML FORM for processing. The digital signature on the SAML assertion must first be validated and then the assertion contents are processed in order to create a local logon security context for the user at the SP. Once this completes, the SP retrieves the RelayState data (if any) to determine the desired application resource URL and sends an HTTP redirect response to the browser directing it to access the requested resource.
- An access check is made to establish whether the user has the correct authorization to access the resource. If the access check passes, the resource is then returned to the browser.
This article introduced you to the fundamental challenges of SAML 3rd party IDP-Initiated Login using the SAP CDC as SP.
If you want to read more about the SAP CDC SAML in general and other possible implementations using the SAP CDC? please follow links mentioned below.