As elaborated in a number of my blog articles, SAML 2 Single Sign-On (SSO) is usually a must-have for live HANA connections in SAP Analytics Cloud (SAC). In such a setup, the InA service, which is a HANA XS artifact, is configured with a SAML 2 Identity Provider (IdP), typically the same IdP as the one used by SAC. This IdP is often the corporate SAML 2 Identity Provider.
However, in the on-premise deployment of SAP BusinessObjects Business Intelligence Platform (BIP), the HANA InA service is typically configured to authenticate against the built-in SAML 2 IdP within BIP. This brings up a challenge for customers who have both SAC and BIP: as HANA allows only one IdP configured on a given XS artifact, how can they use both SAML 2 Identity Providers for the HANA InA service?
My colleague Vishal Mour created an amazing wiki document with detailed steps to solve the problem. However, the wiki document does not explain what happens under the hood that makes this seemingly impossible solution work. In this blog article, I will try to walk you through the internal working mechanism of this "magic".
How SAML 2 SSO works between regular IdP and HANA
First of all, regular SAML 2 SSO process flow with the central SAML 2 IdP (for both HANA and SAC) works as illustrated in the below diagram. Technically speaking, this is called SP-initiated Web SSO with front channel, where the front channel means that the web browser is passing the SAML 2 requests and responses between the SAML 2 IdP and SP. This is the most typical way that SAML 2 SSO works, and it complies with the SAML 2 specification.
Note that in this setup, a SAML 2 Identity Provider has to be added via HANA's XS admin tool, and the InA artifact must be configured explicitly to use this particular SAML 2 IdP for authentication.
How SAML 2 SSO works between BIP and HANA
In the SAML 2 SSO scenario between BIP and HANA, things work completely differently. BIP does not come with a full-blown SAML 2 Identity Provider, and there is no Web Browser in the landscape to perform front-channel SAML 2 process flow.
First, BIP is able to generate a certificate that serves as the IdP's certificate. This certificate is then imported to HANA via HANA Studio to generate an IdP entry. However, as this IdP doesn't come with an IdP metadata file, it is not listed in the XS Admin tool. What really happens behind the scene is that HANA establishes the trust in the IdP certificate.
Without SAML 2 IdP metadata, this IdP is really just a pseudo IdP. However it does allow HANA to maintain SAML 2 user mapping against it.
Secondly, note that unlike regular SAML 2 setup, the HANA SAML 2 Service Provider (SP)'s metadata or certificate is not uploaded to the BIP system. Instead, only the HANA SAML SP's name is maintained on BIP. I will explain the reason a little later.
Thirdly, this pseudo IdP is not configured at the InA artifact level. The InA service will continue to use the central IdP for SAML authentication. I am sure this would make any SAML expert curious how SAML 2 SSO would work between BIP and HANA.
The magic is that the BIP IdP doesn't make use of the standard SAML2 process flow. Instead, it injects the unsolicited SAML 2 authentication response into the HTTP Authorization header! See the below diagram that illustrates this process.
The HTTP Authorization header looks like this:
The SAML 2.0 response is base64-encoded, and the actual content looks like the below screenshot. Note that the Audience of this SAML response is the previously configured HANA SAML2 SP name.
With this proprietary protocol, HANA is able to trust the unsolicited SAML 2 authentication response from BIP carried in the HTTP Authorization header, and this works even on HANA XS artifacts that are not configured to use this particular IdP!
Now hopefully you understand the entire "magic". It solves complex SAML 2 SSO issues with a simple trick, and both of your SAP Analytics Cloud user and BIP users will be happy. You can also think of more creative ways beyond the SAC use case to make use of this SSO mechanism in HANA to fulfill complex SAML 2 SSO requirements.
I hope you have enjoyed reading this blog post. Till next time:).
However, in the on-premise deployment of SAP BusinessObjects Business Intelligence Platform (BIP), the HANA InA service is typically configured to authenticate against the built-in SAML 2 IdP within BIP. This brings up a challenge for customers who have both SAC and BIP: as HANA allows only one IdP configured on a given XS artifact, how can they use both SAML 2 Identity Providers for the HANA InA service?
My colleague Vishal Mour created an amazing wiki document with detailed steps to solve the problem. However, the wiki document does not explain what happens under the hood that makes this seemingly impossible solution work. In this blog article, I will try to walk you through the internal working mechanism of this "magic".
How SAML 2 SSO works between regular IdP and HANA
First of all, regular SAML 2 SSO process flow with the central SAML 2 IdP (for both HANA and SAC) works as illustrated in the below diagram. Technically speaking, this is called SP-initiated Web SSO with front channel, where the front channel means that the web browser is passing the SAML 2 requests and responses between the SAML 2 IdP and SP. This is the most typical way that SAML 2 SSO works, and it complies with the SAML 2 specification.
Note that in this setup, a SAML 2 Identity Provider has to be added via HANA's XS admin tool, and the InA artifact must be configured explicitly to use this particular SAML 2 IdP for authentication.
How SAML 2 SSO works between BIP and HANA
In the SAML 2 SSO scenario between BIP and HANA, things work completely differently. BIP does not come with a full-blown SAML 2 Identity Provider, and there is no Web Browser in the landscape to perform front-channel SAML 2 process flow.
First, BIP is able to generate a certificate that serves as the IdP's certificate. This certificate is then imported to HANA via HANA Studio to generate an IdP entry. However, as this IdP doesn't come with an IdP metadata file, it is not listed in the XS Admin tool. What really happens behind the scene is that HANA establishes the trust in the IdP certificate.
Without SAML 2 IdP metadata, this IdP is really just a pseudo IdP. However it does allow HANA to maintain SAML 2 user mapping against it.
Secondly, note that unlike regular SAML 2 setup, the HANA SAML 2 Service Provider (SP)'s metadata or certificate is not uploaded to the BIP system. Instead, only the HANA SAML SP's name is maintained on BIP. I will explain the reason a little later.
Thirdly, this pseudo IdP is not configured at the InA artifact level. The InA service will continue to use the central IdP for SAML authentication. I am sure this would make any SAML expert curious how SAML 2 SSO would work between BIP and HANA.
The magic is that the BIP IdP doesn't make use of the standard SAML2 process flow. Instead, it injects the unsolicited SAML 2 authentication response into the HTTP Authorization header! See the below diagram that illustrates this process.
The HTTP Authorization header looks like this:
The SAML 2.0 response is base64-encoded, and the actual content looks like the below screenshot. Note that the Audience of this SAML response is the previously configured HANA SAML2 SP name.
With this proprietary protocol, HANA is able to trust the unsolicited SAML 2 authentication response from BIP carried in the HTTP Authorization header, and this works even on HANA XS artifacts that are not configured to use this particular IdP!
Now hopefully you understand the entire "magic". It solves complex SAML 2 SSO issues with a simple trick, and both of your SAP Analytics Cloud user and BIP users will be happy. You can also think of more creative ways beyond the SAC use case to make use of this SSO mechanism in HANA to fulfill complex SAML 2 SSO requirements.
I hope you have enjoyed reading this blog post. Till next time:).
- SAP Managed Tags:
3 Comments
