We’re in the last part of Configuring Federated SAML: Azure AD to the SAP HANA Cockpit series.
To recap, here’re what we’ve covered so far:

• 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 Enteprise Application
  • Assign Users to Azure Security Groups and the SSO Assignment
  • Test SAP SAML Single Sign On on Azure

In this part we’ll make the configuration in the HANA XSA and fit the puzzle together:

• Import SAML Metadata from IdP
• Map IdP Security Group to XSA Role Collections
• Add a SAML Certificate with HANA Cockpit
• Assign Database Group

BASIC CONFIGURATION

Change the signature algorithm for SAML on XSA to SHA256

If you’re still using SHA1 (the default value in the older version of HANA), consider updating it as it is deprecated.
Make sure you have XS RUNTIME 1 Patch Collection 37 (build 1.0.68 / PL 68) or higher.

1. Execute the following statement in the database:

   ALTER SYSTEM ALTER CONFIGURATION ('xsuaaserver.ini','SYSTEM') SET ('login.yml','login.saml.signatureAlgorithm')='sha256' WITH RECONFIGURE;​

2. Restart the XSUAA process via Eclipse/HANA Studio
   Goto Landscape view and right click stop the xsuaaserver

Change Service Provider Information

in XSA, we can’t provide as much information on Organization as its XS admin counterpart.
For example, we can’t define Organization Name, Organization Display Name or Organization URL.
The only detail we can customize is the Entity Name, and it is via SQL command:

alter system alter configuration ('xsuaaserver.ini','SYSTEM') set ('login.yml','login.entityid')='yourentityidname' with reconfigure;

XSA restart

Download the SAML metadata file from XSA

Once you’ve made a necessary change on signature algorithm and the SPI, you can download the metadata with this URL:

https://<uaa-server>:Authorization-end-point/saml/metadata

Note: Authorization end-point can be found by executing the command xs -v on the command line and looking for the key authorizationEndpoint.

e.g: https://sapzzzweb.internal.com:39632/uaa-security/saml/metadata

Provide the downloaded file to your federation team. They will import it into the IdP.
In case of Azure, we covered it on Configuring Federated SAML: Azure AD to the SAP HANA Cockpit Part II.

CONFIGURATION ON XSA

Importing SAML Metadata from IdP

I assume you have downloaded the IdP metadata or provided by you by IdP federation team. We covered it in the previous blog.

1. Access your XSA Cockpit page
   https://<uaa-server>:3<sys-nr>30/go/xsa-cockpit
2. Create New Trust Configuration
   
   Follow the sequences.
   The metadata will be parsed automatically.
   To give meaningful text for SAML login link, fill in “Link Text” field. If left blank, HANA will use the Origin Key name.
   Save it.

Map IdP Security Group to XSA Role Collections

While we’re in the Trust Configuration page, we may as well configure the mapping.
But before that, we need to know what roles are available, what functionality it covers, and how many job roles / functions should be defined based on that.

Standard Cockpit roles delivered by SAP:

To help with role mapping in a granular detail, we’ll use this authorization matrix.

Here’re important things to know:

• Every Cockpit user need object ‘cockpit!i1.landscape_view’ to be able to login successfully
• By default, only user with COCKPIT_RESOURCE_ADMIN role assigned will be able to view all database resources / groups. This means only admin user will be able to view databases without further configuration

Based on the matrix, an administrator will need following role collections to do all HANA Cockpit operations:

• COCKPIT_ADMIN
• COCKPIT_RESOURCE_ADMIN
• COCKPIT_USER_ADMIN
• COCKPIT_CONFIG_TEMPLATE_ADMIN

Now that you have clear understanding on the concept, let’s implement it.

Navigate to Role Collection Mappings and follow the sequences to define new mapping.

*Value in point no. 4 is the AD security group we defined earlier.

Repeat step 2-5 to define all mappings, both for admin and non-admin Cockpit users.

CONFIGURATION ON HANA COCKPIT

Adding a Certificate with HANA Cockpit

In our example, we’ll use HANA Cockpit. Other way is by using SQL command.

Prerequisites:

• You have downloaded SAML certificate / got it from IdP federation team.
  In case of Azure AD IdP, we covered it in Configuring Federated SAML: Azure AD to the SAP HANA Cockpit Part II of the series.
• You have added SAP HANA Cockpit Database to Database Directory with SAP HANA Cockpit Admin
• You have CATALOG READ, TRUST ADMIN, CERTIFICATE ADMIN, and USER ADMIN authorization

Importing Certificate

• Access “Certificate Store” from “Security Related Links” section in Database Overview of your HANA Cockpit database.
  
• On Certificate Store page, import your certificates.
  Highlighted red is the imported certificate.
  Also ensure that the entire certificate chain of the X.509 certificate is available.

Assign Certificate to Certificate Collection

A certificate collection is equivalent to internal personal security environment (PSE).
This is a secure location within a SAP HANA Database where public and private key certificates are stored. By default, standard installation will create a SAML PSE. We’ll import our certificate there.

• Access “Certificate Collections” from “Security Related Links” section in Database Overview of your HANA Cockpit database.
  
• On Certificate Collections page, filter the purpose of the PSE to “SAML”, and add the certificate
  

Add a SAML Identity Provider in SAP HANA Cockpit

• On the Database Overview page, with the Security and User Management or All view selected, navigate to Security Related Links and choose SAML Identity Providers.
  
• Choose “Add Identity Provider” and import your certificate from the certificate store
  

At this point, you should now have a working SSO.

TESTING THE SSO

• Goto your SAP HANA Cockpit login page.
  To login with SAML, click the SAML login link.
  Remember that the login link text depends on your configuration.
  
• Provide your IdP account
  
• You’re now logged in and able to see the Cockpit launch page
  

ASSIGN DATABASE GROUP TO NON-ADMIN USER

If you recall from our first blog series, there’s no HANA user defined locally in HANA Cockpit SAML setup. So how do we assign the groups if no user existed in the first place?

In HANA Cockpit SAML scenario, the system will populate Cockpit users locally after first time successful login with their IdP credentials. You cannot change anything on the user, but you can assign database groups to it.

To assign a group:

• Make sure user has login at least once with SAML
• Make sure you have created database groups
• From SAP HANA Cockpit Admin User Details, assign group(s) to each individual user
  

AUTOMATIC LOGIN

To redirect user automatically without login screen in HANA Cockpit page:

• Delete the other IdP, if you have several configured
• Set parameter uaa.oidc.enableoidc = false in the xsuaaserver.ini configuration file. If the issue persists and you are on XSA 1.0.99, remove the parameter uaa.oidc.providerlinktext.
• Execute the following statement in the database

  ALTER SYSTEM ALTER CONFIGURATION ('xsuaaserver.ini','SYSTEM') SET ('environment','saml_auto_redirect')='true';​

• Restart XSA

Now everytime you access the COCKPIT Admin page, you will automatically use your SAML assertion token.

Hint: if you have the auto redirect option enabled, but you would like to authenticate using the standard logon page with local HANA users, you can access the login endpoint of UAA with the URL parameter origin=uaa: https://<uaa-server>:3<sys-nr>32/uaa-security/login?origin=uaa. This feature was delivered with XSA 1.0.88

CONCLUSION

You should now have a basic understanding on how to setup SAML SSO for SAP HANA Cockpit in your organization. We use Azure AD as our example, but the overall configuration will apply to other IdP as well.

Another important point before we conclude the series is, although we do not cover SSL configuration it is highly recommended to implement one, as the token contains sensitive information of your organization.