search

SAP / cloud-sdk-js

Use the SAP Cloud SDK for JavaScript / TypeScript to reduce development effort when building applications on SAP Business Technology Platform that communicate with SAP solutions and services such as SAP S/4HANA Cloud, SAP SuccessFactors, and many others.
Apache License 2.0
167 stars 57 forks source link

Using CloudSDK through CAP4 in Kubernetes context #940

Closed JohannesRu closed 3 years ago

JohannesRu commented 3 years ago

Hello colleagues,

We are building the SAP Graph. It allows customers to bring their heterogenous systems and APIs into one aligned API. The SAAS app runs in a Gardener provisioned Kubernetes cluster on Google Cloud Platform.

Authentication Use-case Token-Based Authentication with external systems (e.g. S4, C4C) through CAP4, which uses the CloudSDK.

Details Our application, running in our GCP K8 cluster, should retrieve destinations bound to a SAP CP account and uses the user_token/client_credentials flow to get access to the source Business system (S4, C4C).

Current State Authentication is working locally as a prototype with help of the app-router. Working source systems are S4 and C4C in DLAB.

For us to continue it'd be amazing if you can guide us through the remaining questions.

Open Questions

FrankEssenberger commented 3 years ago

Hello @JohannesRu,

before you start a disclaimer, that I do not know the K8s part of cloud foundry really well. It is on our agenda to provide a smooth developer experience also there. Especially since we see increasing demand from various people. So my knowledge is related to the classic cloud foundry but I hope this also applies to the situation you have.

I think these two go hand in hand (I am not 100% sure what you mean by handshake but I will write something about the general flow). The approuter is the central entry point for your application. From there all requests are redirected and the auth flow is started with the help of the XSUAA service by the approuter. The XSUAA service knows about the role templates and scopes and this information is added to issue a JWT by the identity provider to which the request is redirected by the approuter. Later the XSUAA is also used to issue service specific token, but more to this in the next section. In the end you have a JWT in your request. The issued JWT contains the tenant, user and scope information.

The second link does not work unfortunately. But I will explain the JWT thing a bit. Let's look at the destination case. We start with a JWT issued for the application. The application has a binding to the destination service. Hence the SDK can get an access token for the destination service (here I see a potential issue see below) via the XSUAA service. With this service token the destination is fetched. The destination service takes care of building the necessary tokens (OAuthSamlBearer, OAuthClient, Basic....) to access the target system. The SDK just takes this information and puts it in the request headers or destination object.

The way the SDK gets an access token for the destination service is based on the clientID and clientSecret of the bound destination service. These are available via some environment variables (VCAP_SERVICES). Here I do not know if these are present in your Kubernetes cluster.

If you have an approuter which triggers the auth flow and adds the JWT to your request AND the VCAP_SERVICES variables are present it does not matter if you are deployed on CF or local. The destination service is just in the internet and can be reached from everywhere. However, in most cases developers do not have an approuter locally and use some environment variables to have it working locally.

I hope this helps a bit.

Best Frank

ghost commented 3 years ago

The second link does not work unfortunately.

The external link to the CAP docs about authentication is here: https://cap.cloud.sap/docs/node.js/authentication#jwt

FrankEssenberger commented 3 years ago

One thing also just came to my mind:

Working source systems are S4 and C4C in DLAB.

I think the DLAB systems are only reachable from the intranet. You can test this if you exit the VPN and your local setup stops working. If this is the case you must use as source systems either proper cloud systems which are exposed in the internet or in case of onPremises systems a cloud connector should be attached.

Also keep in mind that this repo is publicly visible and no SAP internal landscape details should be exposed here e.g. that we have something called DLAB. Some mean people could use these information to get more credibility when they make some social engineering attempt.

Best Frank

FrankEssenberger commented 3 years ago

We had a meeting today but for the rest of the world I put some information here:

JohannesRu commented 3 years ago

Hey Frank,   thanks for the summary. Yes, we managed to identify the missing scope "uaa.user" as the missing piece. With that in place CAP+CloudSDK works as expected and we can happily skip AppRouter. Thanks again for helping us here.   Looking at the release notes for Java and reading the lates SAP guides "uaa.user" may be redundant, is there any plan to align accordingly in the JS version? Else we will simply incorporate the requirement into our documentation as well. https://sap.github.io/cloud-sdk/docs/java/release-notes-sap-cloud-sdk-for-java/#improvements-19   Regarding @sap/xsenv, we are currently evaluating the setup and will come back to you when we have figured it out.... Again, thanks for the speedy and efficient help. Hope we stay in touch on the subject ✌️

FrankEssenberger commented 3 years ago

I hope so too. Great that we could of help and that you also reminded us about the new token grant. I will make an issue in the backlog so that we remember to implement it. Seems like an easy change or additional method.