Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
quovadis
Product and Topic Expert
Product and Topic Expert
















The security is paramount and the internet never forgets....all public API endpoints must be secured. Good news! With Kyma API Gateway and Istio modules it is fairly easy to protect the API endpoints. 

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 a JWT access strategy with both SAP IAS and SAP BTP destinations.

(the sibling oauth2-introspection access strategy is just one blog away...)

Putting it all together


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 [SAP IAS] authentication flows in a low-code/no-code style.

Let's get started ..










Table of Contents

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

    1. Create and configure an OIDC application.

    2. Configuring grant types.

    3. Go low-code effort with SAP BTP destinations.



  2. SAP Kyma API rules access strategies easy with SAP BTP destinations.

  3. JWT access strategy (preferred choice)

    1. Retrieve bearer access JWT token for client credentials flow with OAuth2ClientCredentials destinatio...

    2. Configure JWT access strategy with an API rule





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:












1. Create an application



2. Configure the OAuth2 client authentication


We need to secure access to the SAP IAS token issuance endpoint. We have a choice of using client credentials, x509 client certificate or a JWT token.

For the sake of simplicity let's go for client credentials.


Good to know

  • a SAP IAS OIDC application is essentially an OAuth2 client supporting a variety of authentication flows, namely authorization code, client credentials, jwt bearer etc.



3. Add a secret




After saving please take note of the secret and its hint. You may create several secrets if need be.

4. Create OAuth2 scopes (self-defined attributes) for your OAuth2 client


As OAuth2 scopes are again called the attributes in the SAP IAS parlance, here goes a screenshot that explains where to go to define your OAuth2 client scopes if need be:



The above syntax will be reflected in jwt tokens as an array of scopes, namely:

"scope": [ "read", "openid", "write" ]

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, you could have decided to set up a trust between a SAP IAS IDP (identity provider) tenant and a BTP sub-account 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:

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.

2. SAP Kyma API rules access strategies easy with SAP BTP destinations.


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.

Good to know:

  • you should not  be mixing istio-based allow strategy with any of the noop, jwt and oaut2_introspection ory oathekeeper-based strategies in the same API rule.


3. JWT access strategy (preferred choice)


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 SAP approuter or if using SAP cloud sdk, the destination payload will be automatically transferred in the authorization header of the API rule.


 




The next instalment will focus on the oauth2-introspection access strategy.