Setting up Communication Channel between SAP Cloud Platform (Neo) and HANA XSA (on-premise)
Overview

- Let the db module define a simple table “Book”, and a calculation view on top of this table. The calculation view “BooksByCountry” has row-level authorization check to only return rows that matches the logged in user country. (Instance Based Authorization)
- The js module (xsjs compatibility – nodejs runtime) provides an odata service exposing the calculation view as an entity. The OData service also requires that user has the scope “books.read” to access the service. (Functional Authorization)
- The approuter module defines the routes in the xs-app.json along with the scopes required. As you know, this acts as the single entry point for the application, and also takes care of user authentication and authorization (partly, since the backend (js module) also needs to check the user has relevant scopes), and forwarding and caching of the JWT for the logged in user.
Let’s also define a xs-security.json file that would define the required scope, attributes and role template for the application described above. In your xs-app.json and in the odata definition, you can check the scope “read” for accessing the protected resource. And the attribute country will be used in the structured privilege on calculation view to filter rows based on the user accessing the calculation view.
{
"xsappname": "secure_helloworld",
"tenant-mode": "dedicated",
"scopes": [{
"name": "$XSAPPNAME.read",
"description": "Read access to the odata service"
}],
"attributes": [{
"name": "country",
"description": "country",
"valueType": "string"
}],
"role-templates": [{
"name": "BooksViewer",
"description": "View Books",
"scope-references": [
"$XSAPPNAME.read",
"uaa.user"
],
"attribute-references": ["country"]
}]
}
And there’s a simple UI5 application that’s display the data from the OData service.
Communication Channel & Security Configuration
- The user logs in to the HTML5 application authenticated by the external IdP.
- When accessing any protected service exposed from XSA on-premise, the backend service should be called with the JWT (JSON Web Token) that the backend service can use to verify that the user is authenticated and has the required authorizations
- The SCP destination configured of type “OAuth2SAMLBearerAssertion” using the configured Token Service URL exchanges the SAML bearer assertion for the JWT token. To explain the steps in detail
- The SAML attribute statement is created from the Principal attributes that’s assigned for this trust configuration (section 5). This is done in SCP Trust Configuration where we set the attributes that are to be mapped to the principal attributes from the SAML assertion
- The SAML assertion created is signed by the Service Provider Signing Key (in this case is the SCP Subaccount – Signing Key from Trust Configuration)
- HANA XSA is configured to trust the Local SP of the SCP Subaccount as an IdP by adding the SP’s metadata as an IdP in the XSA SAML Provider Configuration
- The destination service replaces the Signed SAML bearer assertion for JWT token with the Authorization Server (UAA). This is part of the OAuth2 Standard grant type urn:ietf:params:oauth:grant-type:saml2-bearer. For details on this refer to link. This is possible to exchange since the XSA already trusts the SP signing key as a valid IdP (from previous step)
- The JWT token holds the scope that has user been assigned, and the SAML attributes
- Since XSA is in the on-premise, all the interaction from SCP to XSA UAA and hence to the actual backend service is carried out via the Cloud Connector
- The JWT token fetched in the previous step is then sent in the header Authorization: Bearer <JWT_Token> to the backend service. Please note that here, we don’t invoke the App Router but then the actual service itself (js module).
- The backend service should check that user the required scope to the access the protected endpoint.
- As you already know access to DB in XSA is with single technical user. However, the application user is personified onto the technical user giving the JWT token. The user attributes are set at the global variables for the session and can be used in the instance based authorization in the database artifacts like Structured Privileges.
The steps that are explained above are taken care of implicitly by the destination configured in SCP. Since the XSUAA is running on-premise, it’s required to expose these endpoints as virtual mapping from the cloud connector. The destination service takes care of performing this complex flow, and fetching the service result to the browser client.

Configuration steps to setup the Communication Channel & Security
Overview of configuration steps
I’d explain in detail the steps in the following sections that are specific to the setup discussed in this blog.
- Configure Role and Role Collections (documentation)
- Establish trust between Identity Provider (IAS tenant) and the Service Provider (HANA XSA)
- Configure external IdP for the HANA XSA Application server (documentation)
- Assign Role Collections to users (federation through Groups attribute) – (documentation)
- Register the SP in the IdP as an application
- Setup the SAP Cloud Connector
- Expose XSUAA endpoints
- Expose the service endpoints of the nodejs application (js module of MTA)
- Setting up destinations on the SAP Cloud Platform
- Configure the SCP subaccount with an external IdP
- Configure SCP SubAccount Local Identity Provider as an additional IdP
1. Configure Role and Role Collections

Also, I’ve created a Role Collection BooksOrganizer containing the role BooksViewer
2. Configure the External IdP for XSA
2.1 Steps to configure an external IdP for XSA
I hope you have already configured an external IdP for authenticating business user to access the application in XSA. You can refer the documentation from the table above.
2.2 Assign Role Collections to users (federation through Groups attribute)

3. When a user logs in via IdP, the user gets federated to the role collections which matches to the Groups SAML assertion attribute that the logged user carries in his SAML Assertion attribute statement.
2.3 Register the SP in the IdP as an application

3. Configurations in SAP Cloud Connector for enabling the communication channel
In here, I’ll focus on setting up the Virtual that are specific to the consume the service from XSA On-premise. We’ll need to create two Virtual endpoints for the on-premise system, one to access the odata service, and the other access the UAA token service.
3.1 Expose the XSUAA endpoints
3. Create a mapping to the virtual system with the following details as shown in the snapshot below
Property | Value |
---|---|
Back-end Type | SAP HANA |
Protocol | HTTPS |
Virtual Host | <chosen host as per preference> |
Virtual Port | 39032 (Can be looked from the env of your application bound with XSUAA instance) |
Internal Host | <HANA XSA Host> (Can be looked from the env of your application bound with XSUAA instance) |
Internal Port | 39032 |
A sample configuration is shown below.

Property | Value |
---|---|
URL Path | /uaa-security/ |
Access Policy | Path and all sub-paths |
3.2 Expose the service endpoints for OData Service
Fetch the backend service endpoints (js module).

4. Setup the destinations on the SAP Cloud Platform
xs env <js_app_name>
"VCAP_SERVICES" : { "xsuaa" : [ { "name" : "uaa_books", "label" : "xsuaa", "tags" : [ "xsuaa" ], "plan" : "default", "credentials" : { "tenantmode" : "dedicated", "clientid" : "sb-secure_helloworld", "verificationkey" : "***", "xsappname" : "secure_helloworld", "identityzone" : "uaa", "identityzoneid" : "uaa", "clientsecret" : "***", "url" : "https://hxehost:39032/uaa-security" } } ] }
2. Create the destination with the following details.
Property | Mapping Attribute in Environment | Sample Value |
---|---|---|
Type | N/A | HTTP |
audience | <url>/oauth/token | https://hxehost:39032/uaa-security/oauth/token |
Authentication | NA | OAuth2SAMLBearerAssertion |
tokenServiceURL | <url>/oauth/token | https://hxehost:39032/uaa-security/oauth/token |
ProxyType | N/A | OnPremise |
URL | Backend (js module) Application URL on XSA | https://hxehost:51046 |
tokenServiceUser | <clientid> | sb-secure_helloworld |
tokenServicePassword | <clientsecret> | *** |
Property | Value |
---|---|
WebIDEUsage | odata_gen |
WebIDEEnabled | true |
WebIDESystem | HXE |
Sample Configuration

3. Test the connection to ensure that the system is reachable.
5. Configure SCP SubAccount with an external IdP
I assume that you have configured your Neo Subaccount with an external IdP. More details on this can be found here
- From the subaccount cockpit, Go to Security → Trust, and then open the Local Service Provider tab.
- Download the SP metadata by clicking on the “Get Metadata” link.
- Since the RoleCollection assignment to user is based on the Groups attribute passed, it’s important to send that as an Assertion attribute from SCP. This is achieved by setting the Assertion attribute.
- Go to Security → Trust → Application Identity Provider → click on the configured IdP link
- Go to Attributes tab, and then add the Groups attribute into the section Assertion-Based Attributes.
- If there are more attributes to be passed to XSA for row level access (instance based authorization), all of them has to be added to the list here. You can set all attributes passed from IdP as Principal attributes by just entering * in Assertion & Principal Attribute.
6. Configure SCP SubAccount Local Identity Provider as an additional IdP
- From the admin cockpit, navigate to SAML Identity Provider Configuration tile
- Add the metadata from got from the Local Service Provider (previous section)
- Save the configuration.
- Configure the role collections as we did while configuring an external IdP for XSA. (refer to section 2.2 – Assign Role Collections to users)
Testing the HTML5 application on SCP
For User with country attribute as “US”

SELECT KEY, VALUE from M_SESSION_CONTEXT WHERE KEY LIKE 'XS_%'

Good one Jamal. Keep em coming 🙂
Great Blog Jamal. I am trying something similar with SCP NEO UI5 > SCP CF HANA XSA. In my case if I start my app with CF-XSA/HTML5 the XSA session context is correct:
Call https://xxx-web-ekogu.cfapps.eu10.hana.ondemand.com/xsjs/session.xsjs
Result:
XS_FAMILY_NAME and XS_GIVEN_NAME are taken from IAS as expected. I have also an attribute XS_GROUP which is filled with IAS group. That one also looks fine.
But if enter from NEO/HTML5 using a NEO destination the identity forward works but XS info like FAMILY_NAME, GIVEN_NAME are not correct and XS_GROUP attributes are not listed anymore.
NEO Destination: https://xxx-xsjs-ekogu.cfapps.eu10.hana.ondemand.com/ (destination is called hana)
CALL: https://xxx-dispatcher.hana.ondemand.com/sap/fiori/koraytest/hana/xsjs/session.xsjs
Result:
Do you have any idea why NEO/HTML5 > destination > xsjs doesn't work as CF/HTML5 > xsjs works in my case?
Thanks a lot!
Regards,
Koray
Excellent blog. Thanks for sharing it with us!