SAP Cloud Platform Extension Factory Kyma Runtime - Open ID Connect Authentication

[jamie_cawley]

Open ID Connect (OIDC) provides a simple layer on top of oAuth 2.0 to support user authentication, providing login and profile information in the form of an encoded JSON Web Token(JWT).  Once a user logs in to an Identity Provider via OIDC this information can be used to securely access any other application or API that is implementing the same Identity Provider.  To learn more about OIDC visit https://openid.net/connect/.

OIDC supports a number of grant types that can be implemented to authenticate a user; with the preferred type being the authorization code flow that is supported by the SAP Cloud Platform Identify Authentication Service(IAS).  You can find related details, as well as documentation regarding the different grant types supported by SAP IAS here.

In this blog, we will explore a few scenarios using an OIDC application defined in SAP IAS.  Using this application we will secure an API running in the Kyma runtime and a Nodejs application that will be ran locally, or wherever you want, and within Kyma which will access the API.

Configure SAP IAS

Start by setting up an application in SAP IAS by choosing

Application & resource -> Applications -> Add

Provide a name and choose Save

Choose the Type option

and set it to OpenID Connect and Save the change.

Choose the OpenID Connect Configuration option

In the Configuration add a Name and the Redirect URIs. In this example we will run a sample app in two scenarios, at first locally and then in the Kyma runtime.  This requires a redirect URI defined for both.  To support running locally set an entry to

http://localhost:3000/oauth/callback

For the Kyma runtime the URI will be in the format of

https://oidc-sample-app.<cluster name>/oauth/callback

Save your entries.

Finally choose the option Client ID and Secrets

Choose the Add Secret button, Save it and make sure to copy the values for the Client ID and Client Secret.

 

Configuring the Sample App

You can find the sample app at

https://github.com/jcawley5/oidc-sample-app

In your command line interface clone the repository to your local machine, change into the app directory and and install the dependencies.

git clone https://github.com/jcawley5/oidc-sample-app



cd app



npm install

 

The sample app has a few environment variables required for it to run and expects these to be defined in a .env file.  Within the app directory you will find the file .env_sample with the variable names defined.  Rename this file to .env and set the values as follows:

idp_clientid= The value copied on the client credentials dialog of the SAP IDP app.
idp_clientsecret= The value copied on the client credentials dialog of the SAP IDP app.
idp_url= The url of the SAP IDP cluster
redirect_uri= http://localhost:3000/oauth/callback
api_endpoint= https://orders-list-api.<kyma cluster name>
token_endpoint_auth_method=client_secret_basic

 

Configuring the Sample API

Within the kyma directory of the app you will find the file orders-list-api.yaml which contains a deployment definition for a Kyma lambda function.  This lambda function returns a sample set of orders included the userid of the person who made the call.

Using the command line interface, configure the kubeconfig to the Kyma cluster, described here, create a namespace and deploy the function.

kubectl create namespace oidc-sample



kubectl apply -f orders-list-api.yaml -n oidc-sample

This will generate a lambda function and expose it as an unauthenticated API.  Once the deployment is complete the API will be available at

https://orders-list-api.<kyma cluster name>

which corresponds to the entry in the .env and viewable in the Kyma console within the menu option Configuration -> API of the oidc-sample namespace.

 

Scenario One - Unauthorized API

Start the node application locally by running the start command in the app directory

npm start

Within the console you should see some output describing the "Issuer" including a few endpoints, such as the "authorization_endpoint".  The app should be available at

http://localhost:3000

Opening the page should redirect you to the login page of your SAP IDP application.  After logging in you should be redirected to the orders listing page.

 

Scenario Two - Authorized API

In the Kyma console open your namespace and choose the API Ruless menu option and then choose the oidc-sample-app API.

Choose the edit option and then set the following properties under Access strategies and save the changes.

Auth Type = JWT

Method = Get

issuer = The url of the SAP IDP cluster

JWKS URI = <The url of the SAP IDP cluster>/oauth2/certs

After saving the changes it may take a minute for the changes to be applied.  You can test the API in the browser to verify, you should see the message Origin authentication failed.

The app is already configured to send the token to the API so upon refreshing the app within the browser, you shouldn't notice any difference.

Scenario Three - Using the Kubernetes Service

In the case where the app is deployed in Kyma, there is no need to expose the service to the internet.  With this in mind, configure the app to call the Kubernetes service directly.

Modify the the following values in the .env file

redirect_uri: https://oidc-sample-app.<cluster-name>/oauth/callback

api_endpoint: http://orders-list-api.<namespace>.svc.cluster.local

Please also make sure that one of the Redirect URIs entries in SAP IAS matches the value of the redirect_uri.

After setting the values create a config map from the values within the namespace and then apply the deployment.yaml found in the kyma folder of the sample app.

kubectl create configmap oidc-sample-app-config -n <namespace> --from-env-file=.env



kubectl apply -f deployment.yaml -n <namespace>

The deployment file will create the deployment for the sample app as well as a service and API Rule.  You should now see another entry being displayed in the menu option for the sample app.

Clicking on the link should result in the same experience.  At this point the app is calling the internal kubernetes service for the api so you could also delete the API Rule for the orders-list-api.