Principal Propagation to SAP CPI using OAuth2SAMLBearerAssertion

Introduction

SAP supports various Authentication methods (SAML, OAUTH, Certificate etc) to enable user authentication to its Cloud Platform Application. SAP Cloud Platform Integration an application on SAP Cloud Platform commonly uses FORM (implemented over SAML) authentication to login users to WebUI and Role / Certificate authentication to IFlow Runtime Endpoints.

The Role based authentication to runtime endpoints can be achieved using Basic Auth or OAUTH access token. While no explanation is needed for Basic Auth you can read this blog “Secure connectivity (OAuth) to SAP Cloud Platform Integration” by Divya Mary to understand using OAUTH – Client Credentials flow to send message to runtime endpoints.

In this blog I will explain how to implement OAUTH2 – SAML Bearer Assertion flow to SAP Cloud Applications and thus achieve Identity propagation from the sender.

Note: I’m using SAP CPI as a use case here but the flow implementation is same for any SAP Cloud Application resource protected using OAUTH.

OAUTH2SAMLBearer Assertion Flow

The Security Assertion Markup Language (SAML) 2.0 is an XML-based framework that allows identity and security information to be shared across security domains for SSO. RFC7522 defines how a SAML Assertion can be used to request an access token when a client wishes to utilize an existing trust relationship without a direct user approval step at the authorization server. This flow at a high level constitute below steps.

• Establishing Trust between Sender and Receiver.
• Sender Generate a Short living SAML Assertion and post to Receiver Application Token Endpoint.
• Receiver Validates the SAML Assertion using existing trust and issue an Access Token with requested Scope.
• Sender make Resource Call with the received Bearer Token.

Scenario

The principal propagation between the sender and SAP CPI are based on Open Standard Protocol and hence it’s vendor neutral. So the Identity propagation can be achieved from any APPs deployed on Private / Public Cloud or On-premise and SaaS Applications (mostly with Development effort).

In this blog I will explain how to implement Trust set-up between sender and SAP Cloud Platform, OAUTH SAML Bearer (1) and OAUTH protected resource call (2) implementation.

Note: Principal Propagation between SAP Cloud Apps are supported out-of-the-box using OAUTH2 – SAML Bearer. Hence it’s out of scope for this blog.

1. Trust Set-up

Trust set-up is achieved in two step i.e. adding an IDP and Registering an OAUTH Client in SAP Cloud Platform.

This however is a single step in most Apps like Salesforce, Successfactor etc i.e. by creating an OAUTH Client and associating the signing certificate and role assignment. Hope SAP simplify it in future.

1.1 Pre-requisite

• A Key Pair is generated (Self / CA Signed) or an Existing Keypair used by the sender application.
• Sender Application Implement logic to generate a short living SAML Assertion and sign it with Private key.
• The X.509 Certificate a.k.a. Public Key or Signing Key is shared.

1.2 SAP Cloud Platform – IDP Set-up

1. From SAP Cloud Platform Cockpit Navigate to Security –> Trust –> Application Identity Provider and choose “Add Trusted Identity Provider”
2. Add the sender application as a Trusted IDP like shown below.
   

   Field	Value
   Name	Unique Name to Identity Sender Application
   Assertion Consumer Service	Application Root (default)
   Single Sign-On URL	A dummy URL (No significance)
   Single Sign-On Binding	HTTP-POST (No significance)
   Signature Algorithm	Same as the algorithm used by Sender SHA-1 / SHA256
   Signing Certificate	X.509 Certificate of the Key Pair
   User ID Source	XML element from SAML assertion containing User ID.

   

3. Define the Default and Assertion Based attribute to be propagated.
4. Define Default or Assertion Based Groups Assignment.Note: I have assigned a default Group containing the required Role, however you could choose to assign Assertion- Based Groups by evaluating certain condition. Eg. Assign Group ‘X’ only if the user a member of ‘Y’ Department etc.

1.3 SAP Cloud Platform – OAuth Client

1. From SAP Cloud Platform Cockpit Navigate to Security –> Trust –> OAUTH –> Clients and choose “Register New Client“
2. Register a New Client to represent Sender Application as show below.In Subscription drop-down choose your Application. In this case I have choose SAP CPI runtime.

2 SAML Assertion

The Sender Application should implement code to generate an SAML Response containing logged on user principal and sign the assertion using the Private Key.

2.1 SAML 2.0 bearer assertion Generation

The sender application generate a SAML Bearer Assertion in the below format.

<Assertion
	xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="pfx41c65b86-321a-8659-eb60-07535d31b02b" IssueInstant="2019-05-27T07:04:51.852Z" Version="2.0">
	<Issuer>{ApplicationIDPName}</Issuer>
	<ds:Signature
		xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
		<ds:SignedInfo>
			<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
			<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
			<ds:Reference URI="#pfx41c65b86-321a-8659-eb60-07535d31b02b">
				<ds:Transforms>
					<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
					<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
				</ds:Transforms>
				<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
				<ds:DigestValue>IYdHJoZChCgA60prp6utKwtYCj8=</ds:DigestValue>
			</ds:Reference>
		</ds:SignedInfo>
		<ds:SignatureValue>{AssertionSignatureValue}</ds:SignatureValue>
		<ds:KeyInfo>
			<ds:X509Data>
				<ds:X509Certificate>{SigningKey}</ds:X509Certificate>
			</ds:X509Data>
		</ds:KeyInfo>
	</ds:Signature>
	<Subject>
		<NameID>{UserID}</NameID>
		<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
			<SubjectConfirmationData NotOnOrAfter="2019-05-27T09:04:51.868Z" Recipient="https://oauthasservices-{tenantID}.hana.ondemand.com/oauth2/api/v1/token"/>
		</SubjectConfirmation>
	</Subject>
	<Conditions>
		<AudienceRestriction>
			<Audience>https://hana.ondemand.com/{tenantID}</Audience>
		</AudienceRestriction>
	</Conditions>
	<AuthnStatement AuthnInstant="2019-05-27T07:04:51.870Z">
		<AuthnContext>
			<AuthnContextClassRef>urn:none</AuthnContextClassRef>
		</AuthnContext>
	</AuthnStatement>
	<AttributeStatement>
		<Attribute Name="mail">
			<AttributeValue
				xmlns:xs="http://www.w3.org/2001/XMLSchema"
				xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">{emailAddress}				
			</AttributeValue>
		</Attribute>
	</AttributeStatement>
</Assertion>

3. OAUTH2 SAML  Bearer Assertion Flow

Sender Application Post Base64 encoded SAML Bearer Assertion to SAP Cloud Platform Token Endpoint.

Note: RFC7522 define using base64url encoded assertion however SAP implementation uses base64. Make a note of it and implement the Client accordingly.

Below is a sample request/response using Postman.

SAP Cloud Platform Validates the Client Credentials and SAML Assertion before issuing a Bearer access token.

4. Invoke SAP CPI Endpoint

The Sender Application Invoke SAP CPI IFlow Runtime Endpoint using the retrieved Bearer Token.

Below is an Postman example.

5. Retrieve User Principal in SAP CPI IFlow

The user Principal from the Sender Application is populated in “SAP_AuthHeaderValue” Exchange Property.

Decode it to retrieve the propagated user identity which look similar to below.

{
  "name": "UserID",
  "attributes": {
    "IDP": "CustomIDP",
    "name": "NameID",
    "CustEmail": "{Mapped from SAML mail attribute}",
    "com.sap.security.oauth2.clientId": "f2787804-416c-36fe-8614-d2756765ad71"
  }
}

You can notice that

• Name attribute is populated as configured in Section 1.2 Step-2 “User ID Source”.
• IDP and CustEmail populated as configured in Section 1.2 Step-3 “Default and Assertion Based attribute”
• com.sap.security.oauth2.clientId populated with OAUTH Client created in Section 1.3

6. Propagate Identity to Target Application

The common principle to implement end-to-end SSO is to break down the flow into two i.e. Sender to SAP CPI and SAP CPI to Receiver and choose the principal propagation mechanism supported by receiver of each leg. While the former supports OAUTH – SAML Bearer Assertion as shown in this blog the latter can be achieved using OAUTH – JWT, OAUTH – SAML, SAML etc.

So to achieve the Last-mile security and Principal Propagation

• Retrieve the Unique User Identifier as required by the Target Application i.e. User ID or Email from SAP CPI Principal Propagation Exchange property.
• Implement SSO mechanism supported by Target Application using the user principal retrieved in SAP CPI.

In my scenario I used OAUTH – JWT Bearer Flow to propagate Identity to Salesforce as shown in this blog series  “SAP CPI – Salesforce Rest API Integration using OAUTH JWT Bearer Flow“. This is reference solution and can be implemented for any Target Apps supporting OAUTH – JWT Bearer flow.

Additionally read “SAP Cloud Platform Integration – Principal Propagation with SuccessFactors OData V2” blog to know how to implement Identity Propagation to Success factors using OAUTH – SAML Bearer Assertion.

Unfortunately at this point of time SAP CPI does not support OAUTH – JWT Bearer out the box and supports OAUTH – SAML Bearer only in Successfactors ODATA Adapter. So we have to workaround this limitation for Last-mile Principal Propagation.