The security is paramount and the internet never forgets….

Assuming, your SAP Kyma workloads endpoints are exposed to the public internet via Kyma API rules with JWT access strategy.

Let’s see how to simplify the implementation burden of JWT access strategy with both SAP IAS and SAP BTP destinations.

From the previous blogpost we already know any SAP BTP subaccount is a de facto service provider.

In this, and following blogposts I shall demonstrate how to use a SAP Cloud Identity Service tenant custom OIDC application as a service provider for the benefit of SAP BTP Kyma API rules.

Last but not least, we shall follow the SAP BTP best practices and leverage the BTP destinations to help implement the many different authentication flows in a low-code/no-code style.

Let’s get started ..

1. SAP Cloud Identity and Authentication service as an OIDC service provider.

I shall be using SAP Cloud Identity and Authentication service. However, any other IDP, you may choose to have, can be used as well.

1.1 Create and configure SAP IAS OIDC application.

For the sake of this brief, we shall create a new SAP IAS OIDC application (=service provider) to act as a standalone OAuth2 client, as follows:

Good to know:

• if you define the scope attribute as an array of values this will backfire on ory oathkeeper side. The oathkeeper oauth2_introspection implementation expects the opaque tokens have the scopes defined as a string of values rather, for instance: "scope": "read openid write"

Good to know:

• In lieu of creating a custom application as a service provider, we could have decided to set up a trust between a SAP IAS IDP (identity provider) tenant and a BTP subaccount acting as a SP (service provider). Setting up such a trust would imply an exchange of the SP and the IDP metadata.

1.2 Configuring grant types

As aforementioned, you can configure your custom SAP IAS OIDC application to support a variety of grant types (=authentication flows) at a time, as depicted below:

1.3 Go low-code effort with SAP BTP destinations.

Let’s see how to apply the grant types listed below for use with Kyma API rules access strategies:

• Client Credentials,
• JWT bearer
• Authorization Code with PKCE

Of course, this can be done programmatically. And there are a number of libraries that can assist you with this task.

However, SAP BTP destinations can help alleviate the implementation burden of SAP IAS grant types (or of any other identity provider you may choose to have).

In most cases, the BTP destinations allow to eliminate the need to write any code at all.

Eventually, the resulting implementation effort is down to creating a destination definition that describes the desired method of access of an API rule. Let’s see how.

SAP Kyma API rules are kubernetes custom resource definitions provided by the kyma  API Gateway module.

At present, there are four different access strategies supported with Kyma API Rules, namely noop, allow, jwt and oauth2_introspection

The allow strategy is supported directly by istio and the three others are supported by ory oathkeeper identity and proxy component.

The ory oathkeeper jwt strategy requires a valid Json Web Token (JWT) to succeed.

Let’s see how to leverage OAuth2ClientCredentials destinations to help obtain such a token.

3.1 Retrieve bearer access JWT token for client credentials flow with OAuth2ClientCredentials destinations

Let’s create a destination definition according to the SAP IAS documentation: Configure the Client to Call Identity Authentication Token Endpoint for Client Credentials Flow

The above destination will yield a valid bearer access JWT token in its payload.

{
  "owner": {
    "SubaccountId": "<SubaccountId>",
    "InstanceId": null
  },
  "destinationConfiguration": {
    "Name": "poster-quovadis",
    "Type": "HTTP",
    "URL": "https://httpbin-anywhere.<custom domain>",
    "Authentication": "OAuth2ClientCredentials",
    "ProxyType": "Internet",
    "tokenServiceURLType": "Dedicated",
    "HTML5.DynamicDestination": "true",
    "clientId": "<clientId>",
    "Description": "poster-quovadis",
    "scope": "openid",
    "clientSecret": "<clientSecret>",
    "tokenServiceURL": "https://<sap ias tenant>.accounts400.ondemand.com/oauth2/token"
  },
  "authTokens": [
    {
      "type": "Bearer",
      "value": "eyJqa3UiOiJodHRwczovL2F0ZWFtLWlzdmVuZy5hY2NvdW50czQwMC5vbmRlbWFuZC5jb20vb2F1dGgyL2NlcnRzIiwia2lktF3PAieuL67S59apX9h_u47oY2XwdP5Ak7K8dwLeK-rysxTEuwjHUEevBoDaBS8g51HKWJFfA",
      "http_header": {
        "key": "Authorization",
        "value": "Bearer eyJqa3UiOiJodHRwczovL2F0ZWFtLWlzdmVuZy5hY2NvdW50czQwMC5vbmRlbWFuZC5jb20vb2F1dGgyL2NlcnRzIiwia2lkIKtF3PAieuL67S59apX9h_u47oY2XwdP5Ak7K8dwLeK-rysxTEuwjHUEevBoDaBS8g51HKWJFfA"
      },
      "expires_in": "3600",
      "scope": "read openid write"
    }
  ]
}

3.2 Configure JWT access strategy with an API rule

Let’s configure an API rule for the with the ory oathkeeper jwt access strategy, as follows:

apiVersion: gateway.kyma-project.io/v1beta1
kind: APIRule
metadata:
  labels:
    app.kubernetes.io/name: httpbin

  name: httpbin
  namespace: <namespace>
spec:
  gateway: quovadis-azure-dns-gateway.azure-dns.svc.cluster.local
  host: httpbin-anywhere.<custom domain>
  rules:
    - accessStrategies:
        - config:
            jwks_urls:
              - https://<sap ias tenant>.accounts400.ondemand.com/oauth2/certs
            required_scope:
              - openid
              - read
              - write
            token_from:
              header: Authorization
            trusted_issuers:
              - https://<sap ias tenant>.accounts400.ondemand.com
          handler: jwt
      methods:
        - GET
        - POST
        - HEAD
        - PUT
        - PATCH
        - DELETE
      path: /.*
      timeout: 300
  service:
    name: httpbin
    port: 8000

Good to know:

• When using the above destination with either approuter or using cloud sdk, the destination payload will be automatically transferred in the authorization header of the API rule.

Next blogpost will focus on the OAuth2-introspection access strategy.