(=the authentication authority) and who is the SAML Service Provider (=the application).
It is overwhelmingly important as more than often a SAML SP can also act as an SAML IDP;
Security Assertion Markup Language (SAML) is an open-standard data format for exchanging authentication and authorisation data between parties.
We can see the three parties involved and a very simplified exchange flow in the following picture:
SAP Analytics Cloud is the service provider (SP).
The browser will attempt to get access to the SAC application (=the service)  and will be redirected  to a third party Identity Provider that will be responsible to authenticate the user.
When you get your SAC tenant URL and logon to SAP Analytics Cloud, you get redirected to SAP Cloud Platform Identity Authentication service. every time to SAML token is no longer valid in the browser cache
The SAP Cloud Identity Provider is used as the default SAML IDP as depicted in the picture below:
Understanding SAML with SAP HANA
However, what I am about to show deviates in some ways from the official documentation, especially with regard to the requirement of having a custom SAML IDP for both your SAC tenant and HANA database tenant.
[Please bear in mind that in order to be able to override the default SAC IDP you must be the system owner.]
And in that we shall be using the SAP HANA Express tenant database with the HDI views rather rather than relying on the classic _SYS_BIC schema.
We shall be using the HTTPS INA protocol leveraging the XS classic engine with the web-dispatcher still part of any SAP HANA 2.x on premise image.
There is still many partners and customers out there using HANA 2.x without XSA/HDI at all and anyway this method is officially supported on HANA Platform for the tenant databases.
On the other hand one of the fantastic features of HANA 2.x is the containerization support implemented through the HANA Deployment Infrastructure (HDI) paradigm.
So what. Can’t we take advantage of the HDI views?
Yes we can. I will be showing how easy and convenient it is to be using your HDI container based HANA views through the XS classic INA router for your analytical reporting with SAP Analytics Cloud.
All the below links are to a vanilla SAP HANA Express image where the self-signed SSL certificate was replaced by a trusted certificate signed with a CA (Certificate Authority) of your choice (it could be even your own CA).
To help you with this exercise let me show the full view of the XS classic stack folders in HANA Express tenant database (HXE):
From what I recall in the initial HANA Express 2.0 SP03 rev31 image certain of these folders were missing. Thus I needed to upload a couple of delivery units into the tenant database using Eclipse;
SAP HANA Web based Development Workbench
Please make sure your tenant database user can access the below editor URL:
SAP HANA XS Classic Admin Console:
As you can see the INA service is part of the HCO_INA_SERVICE delivery unit.
From what I recall the CORS settings came pre-configured in the SAPCAL HXE image as depicted below.
If your HANA image is different this is what you will need to see in here:
As aforementioned I will show how to implement SAML SSO to HANA database on a HANA Live connection level (or HANA user level) without the need of having a custom SAML IDP provider;
This means you are free to put whatever SAML IDP you want including not having any;
HTTPS INA protocol:
Your HANA tenant database user must be granted the relevant roles for the INA access
and you need to be able to see the answer to the GetServerInfo verb
CORS AUTHorization response
You will need to add the following auth.html CORS response file under the cors folder as depicted below using the workbench editor:
and the .xaccess file as well
Putting this all together
Because we have provided the trusted SSL certificate for the secured (HTTPS) INA connection we will no longer be getting the following type of errors when trying to establish a HANA Live Connection with SAP Analytics Cloud. Please take note as of SAC wave 2019.01 the self-signed SSL certificates are no longer accepted.
Deploying SAP HANA Shine XSA application to the HXE tenant database.
I find SAP HANA Shine a fantastic truly educational application. It has many features. For instance it provides a consistent set of cubes (HANA views) implemented in an HDI container; It also features a data generator. I have been using its cubes as a reliable test data that anyone can replicate.
I was a little surprised after I had deployed the SAPCAL HANA Express image to discover the HANA Shine XSA application was deployed on the system database. I would rather expect it to be deployed on the tenant database because the index server is only running on the tenant database;
The system db can leverage to some extent the name server in lieu of the index server but after all I decided to deploy it on the HXE tenant database. Moreover the HTTPS INA protocol can only reach the tenant database.
This is the central SAP note on SAP HANA Shine releases : 2239095 – SAP HANA XS ADVANCED DEMO MODEL – SHINE XSA Release & Information Note
And this is the SAP HANA Shine for XSA link to SMP
For convenience this is the direct link to the HANA Shine for XSA documentation
in the PDF format.
So you know I opted for the XSA CLI command line deployment method.
Finally let’s go to our SAC tenant:
My SAC tenant version is 2019.02 as follows:
By clicking the OK button you will be validating the connection against the source system;
The below pop-up window is the result of the end user browser issuing the logon authentication request, namely https://vhcalhxedb.sap.corp:4390/sap/bc/ina/service/v2/cors/auth.html
As we are not connected to any custom SAML IDP the authentication request defaults to user and password request that we of course satisfy.
This happens only the first time we define the connection and then every time the connection cookie gets invalidated in the browser cache;
One important thing: even if we had set up a custom SAML IDP for both SAC and HXE tenants the auth.autml window would be furtively displayed and seen as well;
the only different being the authentication token would come from the IDP itself and not through the user/password credentials validation.
With the live connection to HANA set we can create models and stories based on these models
I provide the below screenshots on purpose as still may people get confused when they get in here.
and one of the stories: