In my previous blogs (What's Changed - Setup Remote HANA Connection with SAML SSO in SAP BusinessObjects Cloud and Single Sign-On from BusinessObject Cloud to HANA - Reverse Proxy Rules for SAP Cloud Identity) on setting up Single Sign-On (SSO) for SAP BusinessObjects Cloud (BOC) and HANA, I have focused on the SAML 2 SSO process among BOC, HANA and the SAML 2 Identity Provider (IdP). While that addresses the SSO requirement from BOC to HANA, end users still have to authenticate against the SAML 2 IdP in the first place; often times, this is a user ID and password logon by default with most SAML 2 IdPs. Nowadays, who wants to remember yet another pair of user ID and password? Users just want to open the BOC URL in their browser's bookmarks, and immediately see the home screen or the story board.
How can we make that happen? Well, technically this means that the user needs to be able to log in to the SAML 2 IdP automatically from their Web browser. Mainstream Web browsers offer three ways to do this without installing any native add-ons: X.509 Client Certificate authentication, Kerberos/SPNego authentication, and NTLM. Due to the security concerns on NTLM, the only feasible solutions currently are Client Certificate authentication and Kerberos/SPNego. This is often referred to as Windows Integrated Authentication, but it also works on other OS platforms such as MacOS.
In this article, I would like to walk you through the concepts and configuration of end-to-end SSO with Kerberos/SPNego and SAML. If you are interested in setting up end-to-end SSO with X.509 Client Certificate authentication and SAML, check out the other blog: Creating an End-to-end SSO Experience to SAP BusinessObjects Cloud and HANA with Client Certificate ....
The following diagram shows how it works. The diagram is self-explanatory, but one important thing to point out is that Kerberos authentication is an intranet solution, as the Web browser needs access to the Active Directory's domain controller, which is almost never exposed to the Internet. Having said that, Kerberos/SPNego authentication is still the preferred authentication method if your end users are in intranet only, as Kerberos yields excellent authentication performance.
In addition to the SAML 2 setup I elaborated in previous blogs, the following has to be performed to implement the design above for Kerberos/SPNego to work:
1. The SAML 2 IdP needs to be configured with Kerberos/SPNego. This step varies from IdP to IdP, but in general this means:
1) Create a service user on the Active Directory Domain Controller that represent the SAML 2 IdP's service.
2) Provide the service user's credential to the SAML 2 IdP and configure it for Kerberos.
3) On the domain controller, create a Service Principal Name (SPN) for the SAML 2 IdP web server.
2. As the SAML 2 IdP is exposed to the Web browser via the reverse proxy, an additional SPN needs to be created for the reverse proxy.
As just mentioned, the actual steps vary based on the type of SAML 2 IdP you use, but take a look at how it can be done with SAP NetWeaver SSO SAML 2 IdP and SAP Cloud Identity as references.
1. SAP NetWeaver SSO SAML 2 IdP
1) Configure Kerberos/SPNego on Active Directory and NetWeaver AS Java: Using Kerberos Authentication on SAP NetWeaver AS for Java
2) Once Kerberos/SPNego is configured on the IdP's underlying AS Java, add Kerberos to the authentication context of the IdP service: Adding Custom Authentication Contexts
2. SAP Cloud Identity
Refer to this document on how to configure SAP Cloud Identity to support Kerberos/SPNego: Configure Kerberos Authentication.
If you have finished the above steps, you can now relax and enjoy the end-to-end SSO experience...well, not quite if your Active Directory user belongs to a large number of groups. In those cases, the SPNego token may become as big as 12392 bytes, which exceeds Apache reverse proxy's default maximum header length (8190 bytes); and consequently, all HTTP requests with SPNego tokens will be blocked. To resolve this issue, add the following line to your Apache reverse proxy's configuration file to lift the limit to 12392 bytes:
LimitRequestFieldSize 12392
Now you can sit back, just click the BOC URL in your browser's bookmarks, and log straight into BOC and view remote HANA-based stories without typing in user credentials at all. Isn't that cool:)?
Till next time.
How can we make that happen? Well, technically this means that the user needs to be able to log in to the SAML 2 IdP automatically from their Web browser. Mainstream Web browsers offer three ways to do this without installing any native add-ons: X.509 Client Certificate authentication, Kerberos/SPNego authentication, and NTLM. Due to the security concerns on NTLM, the only feasible solutions currently are Client Certificate authentication and Kerberos/SPNego. This is often referred to as Windows Integrated Authentication, but it also works on other OS platforms such as MacOS.
In this article, I would like to walk you through the concepts and configuration of end-to-end SSO with Kerberos/SPNego and SAML. If you are interested in setting up end-to-end SSO with X.509 Client Certificate authentication and SAML, check out the other blog: Creating an End-to-end SSO Experience to SAP BusinessObjects Cloud and HANA with Client Certificate ....
The following diagram shows how it works. The diagram is self-explanatory, but one important thing to point out is that Kerberos authentication is an intranet solution, as the Web browser needs access to the Active Directory's domain controller, which is almost never exposed to the Internet. Having said that, Kerberos/SPNego authentication is still the preferred authentication method if your end users are in intranet only, as Kerberos yields excellent authentication performance.
In addition to the SAML 2 setup I elaborated in previous blogs, the following has to be performed to implement the design above for Kerberos/SPNego to work:
1. The SAML 2 IdP needs to be configured with Kerberos/SPNego. This step varies from IdP to IdP, but in general this means:
1) Create a service user on the Active Directory Domain Controller that represent the SAML 2 IdP's service.
2) Provide the service user's credential to the SAML 2 IdP and configure it for Kerberos.
3) On the domain controller, create a Service Principal Name (SPN) for the SAML 2 IdP web server.
2. As the SAML 2 IdP is exposed to the Web browser via the reverse proxy, an additional SPN needs to be created for the reverse proxy.
As just mentioned, the actual steps vary based on the type of SAML 2 IdP you use, but take a look at how it can be done with SAP NetWeaver SSO SAML 2 IdP and SAP Cloud Identity as references.
1. SAP NetWeaver SSO SAML 2 IdP
1) Configure Kerberos/SPNego on Active Directory and NetWeaver AS Java: Using Kerberos Authentication on SAP NetWeaver AS for Java
2) Once Kerberos/SPNego is configured on the IdP's underlying AS Java, add Kerberos to the authentication context of the IdP service: Adding Custom Authentication Contexts
2. SAP Cloud Identity
Refer to this document on how to configure SAP Cloud Identity to support Kerberos/SPNego: Configure Kerberos Authentication.
If you have finished the above steps, you can now relax and enjoy the end-to-end SSO experience...well, not quite if your Active Directory user belongs to a large number of groups. In those cases, the SPNego token may become as big as 12392 bytes, which exceeds Apache reverse proxy's default maximum header length (8190 bytes); and consequently, all HTTP requests with SPNego tokens will be blocked. To resolve this issue, add the following line to your Apache reverse proxy's configuration file to lift the limit to 12392 bytes:
LimitRequestFieldSize 12392
Now you can sit back, just click the BOC URL in your browser's bookmarks, and log straight into BOC and view remote HANA-based stories without typing in user credentials at all. Isn't that cool:)?
Till next time.
- SAP Managed Tags:
