Consume SAP HANA Cloud HDI containers with HAA and eSAC/SAC

Quovadis.md

Quovadis. Building a destination definition.

By design, a BTP sub-account is a service provider (SP).

In order to build the destination definition we need to retrieve two very important saml assertion attributes, namely the audience (EntityID) and the recipient (ACS - Assertion Consumer Service) from the service provider (SP) metadata.

The audience attribute designates the service provider itself - the BTP sub-account - and the recipient is the value of the AssertionConsumerService URL which, in turn, will be used by the destination service to call into the XSUAA to retrieve a bearer access token.

These attributes can be looked up in the BTP's sub-account (SP) metadata. However, we had already downloaded the BTP’s sub-account SP metadata and uploaded it into the external IDP SAML Application. Thus we can simply look up both the audience and recipient values from the IDP's SAML Application.

As we are using an external IDP with our own trust the saml assertion issuer value is not necessarily equal the CN value of the signing x509 certificate.

We need to look it up and assign it to the assertionIssuer property in the destination definition. Failure to do so will result in the destination service picking the CN value of the uploaded keypair and a metadata contract mismatch error.

 

The tokenServicePassword is the client secret from the XSUAA service instance service key.

The clientKey and tokenServiceUser are the client id from the XSUAA instance service key.

Test quovadis destination

  {
    "Name": "Quovadis-HAA",
    "Type": "HTTP",
    "URL": "<backend haa-ina-service service URL>",
    "Authentication": "OAuth2SAMLBearerAssertion",
    "ProxyType": "Internet",
    "KeyStorePassword": "<KeyStorePassword>",
    "tokenServiceURLType": "Dedicated",
    "audience": "<entityID from your BTP subaccount SP metadata>",
    "Description": "Quovadis-HAA on a BTP subaccount subscription level. client_id/client_secret must be the backend service app router's xsuaa credentials",
    "authnContextClassRef": "urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession",
    "assertionIssuer": "https://auth.pingone.eu/<env>",
    "tokenServiceUser": "<xsuaa client_id>",
    "HTML5.ForwardAuthToken": "false",
    "tokenServiceURL": "<AssertionConsumerService URL from BTP's subaccount SP metadata>",
    "tokenServicePassword": "<xsuaa client_secret>",
    "HTML5.DynamicDestination": "true",
    "clientKey": "<xsuaa client_id>",
    "KeyStoreLocation": "quovadis_ateam-isveng.p12",
    "nameIdFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
    "scope": "openid",
    "SystemUser": "haa-ina@quovadis-haa.com"
  }

  The above destination can be used for development and testing purposed. However, in a productive scenario the user' identity should rather be provided as a digitally encoded user-JWT token as follows:

Productive quovadis destination

  {
    "Name": "Quovadis-HAA-JWT",
    "Type": "HTTP",
    "URL": "<backend haa-ina-service service URL>",
    "Authentication": "OAuth2SAMLBearerAssertion",
    "ProxyType": "Internet",
    "KeyStorePassword": "<KeyStorePassword>",
    "tokenServiceURLType": "Dedicated",
    "audience": "<entityID from your BTP subaccount SP metadata>",
    "Description": "Quovadis-HAA on a BTP subaccount subscription level. client_id/client_secret must be the backend service app router's xsuaa credentials",
    "authnContextClassRef": "urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession",
    "assertionIssuer": "https://auth.pingone.eu/<env>",
    "x_user_token.jwks_uri": "https://auth.pingone.eu/<env>/as/jwks",
    "tokenServiceUser": "<xsuaa client_id>",
    "HTML5.ForwardAuthToken": "false",
    "tokenServiceURL": "<AssertionConsumerService URL from BTP's subaccount SP metadata>",
    "tokenServicePassword": "<xsuaa client_secret>",
    "HTML5.DynamicDestination": "true",
    "clientKey": "<xsuaa client_id>",
    "KeyStoreLocation": "quovadis_ateam-isveng.p12",
    "nameIdFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
    "scope": "openid",
    "userIdSource": "email"
  }

trusted IDP.md

In order to establish the IDP-initiated flow, a dedicated trusted IDP will have to be created in the BTP sub-account where the java backend service is hosted.

For the sake of simplicity the destination service trust may be used as the Trusted IDP as explained in the following gist.

However, any other trust could be used instead provided the keypair to be used to sign the saml assertion is uploaded to the destination service vault (for saml assertion signing).

As to make things a bit more spicy and tasty, this time I have not used the destination service trust to build this trusted IDP but used a trust from an external identity provider as depicted below