Configuring Federated SAML: Azure AD to the SAP HANA Cockpit Part I
In these three parts of blog series, I’ll walk you through steps to configure SAML Access to HANA Cockpit, with Azure AD as the IdP. For a complete story, I included steps to configure Azure AD as well.
- In Configuring Federated SAML: Azure AD to the SAP HANA Cockpit Part I
We covered the facts and restrictions in HANA Cockpit such as mapping IdP to local HANA users and configuration area you need not touch.
- In Configuring Federated SAML: Azure AD to the SAP HANA Cockpit Part II
We cover these areas in details:
- Add SAP HANA Enterprise Application
- Configure SAP HANA SAML in Azure Enterprise Application
- Assign Users to Azure Security Groups and the SSO Assignment
- Test SAP SAML Single Sign On on Azure
- In Configuring Federated SAML: Azure AD to the SAP HANA Cockpit Part III
We’ll fit everything into place and make the solution work:
- Import SAML Metadata from IdP
- Map IdP Security Group to XSA Role Collections
- Add a SAML Certificate with HANA Cockpit
- Assign Database Group
Single sign-on (SSO) is a form of authentication that allows user access without requiring that the user to enter credentials every time.
The SAP HANA cockpit offers the option to configure SSO to access cockpit itself (including the cockpit manager), and to connect to a registered database.
Configuring SSO access to the cockpit itself means that you don’t need to provide cockpit user credentials in order to access the cockpit or the cockpit manager.
Unlike Kerberos, SAML has a much more decentralized architecture, hence referred to federated system. Instead of close-tight with specific IdP, such as Active Directory, SAML offers higher degree of flexibility. Any systems can act as an Identity Provider. As long as you’re authenticated with this IdP, either with LDAP or SSO, you can access data on any Service Provider, given a trust relationship is defined between the two systems.
For example, it is possible to use Kerberos token to authenticate yourself to company portal using SPNEGO, which provides a logon ticket to Business Objects, which acts as an Identity Provider for all of your SAP HANA landscapes with SAML assertions.
Notice from that example that you need to authenticate only once when login to Windows to get the solution working.
As of this writing, the most common supported methods for third-party authentication for SSO in HANA Cockpit are Kerberos and SAML.
Having implemented SAML in SAP HANA Enterprise for a few years now, my journey in replicating the solution in SAP HANA Cockpit hasn’t been so straightforward, as there’re some questions that can’t be found / answered in documentation, blog post, or incident. This is because most technical documents deal with SAML in SAP HANA Enterprise environment, which is quite different in SAP HANA Cockpit.
- SAP HANA COCKPIT is based on HANA express edition (HEX), a “streamlined version” of SAP HANA Standard / Enterprise that comes with certain limitations from a functional / authorizational perspective.
This means the configuration is a bit different from HANA Enterprise Platform (HEP). Don’t jump into “SAP HANA Administration Guide” even if the SAP HANA Cockpit Admin Guide refers it.
For example, in HEP, the SAML / SSL configuration is done with Web Dispatcher Administration, provided by SAP HANA internal Web Dispatcher, XS Classic which is accessible through http://<hana_host_name>:80<instance_number>/sap/hana/wdisp/admin/.
However, the XS classic engine is disabled by default in HEX. And even if you enable it from SYSTEMDB, you’ll face 404 page error when you try to access it, as the required standard role “sap.hana.xs.wdisp.admin::WebDispatcherAdmin” is not delivered in the installation.
It is also not possible to enrich the SP with organizational detail such as company name and URL.
- 2049971 – Web Dispatcher: wdisp/system_xx MSHOST is not allowed in the internal HANA Web Dispatcher
- 2107899 – HANA Web Dispatcher – Multi DB – Access to Administration UI is restricted to System DB users
- 2696800 – “503 Service not available” when using an External Web Dispatcher with HANA Multi-tenant Database Container
- 1990354 – Changes in internal HANA Web Dispatcher as of HANA SP9
- 2502174 – HANA Basic How-To Series – Securing HANA XS classic via SSL / HTTPS – using Web Dispatcher Administration and pse container (Microsoft CA edition) – SYSTEMDB
SAP HANA XS Advanced Cockpit
Replaces the old SAP HANA XS Advanced Administration Tools, which is announced as “Deprecated” in HANA 2.0 SPS03.
All features that were part of the SAP HANA XS Advanced Administration tools are now included with the SAP HANA XS Advanced Cockpit
- Certificates are saved in Database.
For ease of management, it’s possible to store certificates and configure their usage directly in the SAP HANA database. By doing that, administrator doesn’t need OS access to import the certificates.The following figure shows for which purposes in-database certificates stored in certificate collections can be used. In-database certificates and certificate collections can be fully managed in the SAP HANA cockpit.
If you still use filesystem PSE, consider migrating it as per SAP Note 2175664 – Migration of file system based X.509 certificate stores to in-database certificate stores.
However, there’s no CSR available yet in Cockpit, so OS access to sapgenpse tool is still required.
Benefits of in-database certs are as follows:
- Very easy administration of the certificates using SQL
- Certificates are included in the backups
- Changes in certificates take effect immediately and no restart is required
- Mapping SAML IdP users to local HANA users is not possible
2644845 – Map SAML to existing user in HANA
This is another difference between HEP and HANA Cockpit.
Whilst in HEP you need to create local users along with its respective roles and map it to ‘external identity’ of the IdP, in HANA Cockpit, authorization is maintained in your IdP, which in our case, Azure AD users via security group.
The pros is that no local user needs to be created in HANA database, which is the benefits of SAML: loose coupling of resources
The cons is an extra works in AD: maintaining groups for every user.
The cons outweighs the pros because depending on your company’s AD model, this may not be a supported approach. If this is the case, you may need to look at alternative method, e.g using the recently supported Kerberos authentication.
You now have a clear picture of restriction and tools required to configure SAML in HANA Cockpit.
In the next part of our series, we’ll touch configuration from Azure AD perspective:
Configuring Federated SAML: Azure AD to the SAP HANA Cockpit Part II
But before we start, please familiarize yourself with the overall configurations:
- Configuring SSO Access to the SAP HANA Cockpit
- 2569903 – How to configure SAML authentication on HANA XSA