Implement user propagation flow when extending SAP...

gabbi · ‎2021 Apr 28

This blog provides details on how a user propagation flow can be achieved when extending SAP Cloud for Customer(C4C) using SAP Cloud Platform, Kyma runtime. A similar configuration is applicable when extending other SAP Solutions such as S4.

The flow uses SAP Cloud Platform Identity Authentication Service (IAS) as an external identity provider with user federation. However, any external identity provider would also work as long as it supports SAML 2.0.

The user propagation relies on the exchange of the JWT token received in Kyma for an OAuth2 token that can be authenticated by SAP Cloud for Customer. For this, the Destination Service is used.

Trust is established between SAP Cloud for Customer and Destination Service. The extension deployed in Kyma runtime makes an API call to the destination service passing the JWT token. Destination Service after validating the token responds along with other details an opaque OAuth2 token for the logged-in user. This OAuth2 token is then used to make calls to the SAP Cloud for Customer ODATA APIs.

Below is an example setup of such a flow. Here the web application (example frontend) uses auto-login to get a JWT token using OIDC. The sample and all the related code is available on SAP-Samples at User propagation sample

Flow

User signs in to C4C with a single ID and password (SSO).

C4C redirects the user to IAS for authentication.

User signs in to IAS.

The user is signed in to C4C with SAML bearer assertion.

User accesses the front end. The front end can be a mesh inside C4C or a standalone app hosted on Kyma or somewhere else. The front end redirects the user to IAS for automatic login. Along with the autologin request, the frontend receives the bearer token.

The front end makes an API call to Kyma with the bearer token.

Kyma API Gateway verifies the token with IAS.

API Gateway forwards calls to a Function/microservice along with the bearer token. Token forwarding is made possible by adding an attribute to the Kyma API rule.

Microservice/Function does the token exchange via the Destination Service. The Destination Service calls C4C and performs the OAuth2 SAML bearer assertion flow.

Microservice/Function makes a call to C4C with the OAuth2 token it got from the Destination Service, preserving the logged-in user's identity.

NOTE: The flow does not use Application Gateway when calling C4C from the Kyma runtime. Instead, it calls the APIs directly.

Prerequisites

SAP Cloud Platform, Kyma runtime instance

SAP Cloud for Customer tenant

SAP Cloud Platform Identity Authentication Service tenant

OAuth 2.0-based authentication between IAS, SAP Cloud Platform, and C4C requires the same user ID to exist in both IAS and C4C.

Configuration

Single sign-on

Set up single sign-on (SSO) using IAS with C4C. Refer to the official documentation for details.

User propagation

Configure user propagation between C4C and Kyma runtime.

This blog was used as a reference. It was written for Neo, but some steps are also applicable for Kyma runtime.

You will end up creating a Destination Service in SAP Cloud Platform. It will be later on used by the microservice to do the token exchange.

Download the Trust certificate from Subaccount --> Destinations --> Download Trust.

Log on to your C4C system as an administrator. Go to ADMINISTRATOR --> Common Tasks. Choose Configure OAuth 2.0 Identity Provider and select New OAuth2.0 Provider.
- Get the issuing entity name from the certificate. You can use OpenSSL to view certificate details.
```
openssl x509 -in {cert path} -text -noout
```
- Upload the certificate.

Register an Oauth2 Client in C4C.

Create a destination in SAP Cloud Platform. Under your subaccount, go to Connectivity --> Destinations.

Configure these additional properties:
scope : UIWC:CC_HOME
x_user_token.jwks_uri : Provide URI of the JSON web key set

The identifier used by the Destination Service to get the token

The Destination Service uses whatever is specified in the userIdSource property. If not specified, it would require either user_name or email depending upon the nameIdFormat
In this example, user_name is mapped to the Login name attribute.

Components for the sample

httpbin

httpbin is a service that returns all the request headers to the /headers endpoint.

It is used for demonstrating and verifying that the token is forwarded from the API Gateway to the microservice.

Deploy httpbin.

kubectl -n identity-propagation apply -f https://raw.githubusercontent.com/istio/istio/master/samples/httpbin/httpbin.yaml

Expose it with an API rule. The API rule is configured to forward headers, such as Bearer Token, to the microservice.

Update jwks_urls and trusted_issuers with the IAS tenant.

Deploy the API rule.

kubectl -n identity-propagation apply -f https://raw.githubusercontent.com/SAP-samples/kyma-runtime-extension-samples/master/user-propagation...

Extension

The second microservice is the one that implements the extension logic as well as the user propagation.

It receives the JWT token that is forwarded from the API Gateway.

The token is used to do a token exchange by making an API Call to the Destination Service.

A call is made to C4C to create a task with the exchanged token that contains the user context.

The task is created with the logged-in user as the processor, not a static user.

Setup

Create a Destination Service instance in the Kyma Service Catalog. This will be used to get the credentials to make the call to the Destination Service.

Create credentials for the instance.

Deploy the extension with user propagation.
- Update DESTINATION_NAME in deployment.yaml with the name of the destination created in SAP Cloud Platform.
- Deploy the extension.
```
  kubectl apply -f https://raw.githubusercontent.com/SAP-samples/kyma-runtime-extension-samples/master/user-propagation...
```

Bind the extension to the Destination Service instance.

Expose it with an API rule. Similarly to httpbin, the API rule is configured to forward headers, such as Bearer Token, to the microservice.
- Update jwks_urls and trusted_issuers with the SAP Cloud Identity tenant.
- Deploy the API rule.
```
  kubectl -n identity-propagation apply -f https://raw.githubusercontent.com/SAP-samples/kyma-runtime-extension-samples/master/user-propagation...
```

Angular app

It simulates the SSO flow and makes API calls to the extensions deployed to the Kyma runtime.

The app automatically logs the user in after they have been signed into C4C through SSO. It is registered in the IAS as an application.

The app makes a call to the httpbin service to the /headers URI path. The httpbin service replies with all the HTTP headers received.

It makes another call to create a C4C task for the logged-in user.

Set up the angular app

Follow these steps:

Update the deployment file. Provide values for HTTP_BIN, OIDC_URL, OIDC_CLIENT_ID and C4C_EXT_URL.
- OIDC_CLIENT_ID is the Client Id for the registered application in SAP Cloud Platform Identity Authentication Service tenant.

Deploy the app:

kubectl -n identity-propagation apply -f https://raw.githubusercontent.com/SAP-samples/kyma-runtime-extension-samples/master/user-propagation...

Expose the app using an API Rule:

kubectl -n identity-propagation apply -f https://raw.githubusercontent.com/SAP-samples/kyma-runtime-extension-samples/master/user-propagation...

Access the app at https://sample-angular-app.{kyma-cluster-domain}.` and create a C4C Task.

Takeaways

It is possible to build in the Kyma runtime the extensions and flows that require user propagation. This feature has been requested by various customers.

Although the sample is built for SAP Cloud for Customer, a similar approach can be applied to other SAP solutions, such as SuccessFactors.

The approach requires an extension to build the logic required to fetch the token.

The flow does not make the call via Application Gateway but directly calls the SAP Cloud For Customer APIs with the token it got from the Destination Service.

premroshanmadhusudhan_nai · ‎2021 May 07

Is the API Gateway in Kyma based on the Istio component?

gabbi · ‎2021 May 07

Hi Prem,

Partially yes.

Istio ingress gateway is used as the ingress. Then we use ORY Oathkeeper for authentication mechanisms such as OAuth2/ JWT (custom IDP).

You can see more details here

https://kyma-project.io/docs/components/api-gateway/#architecture-architecture