BTP ABAP Environment: Inbound Communication with oAuth & JWT Support

[drvup]

Dear Community,

I have the following scenario:

> nodeJs UI5 app with approuter included, running on Cloud Foundry

> oData Service running on BTP ABAP Environment

I want to consume on the UI5 app the oData service, running on ABAP Environment, within a destination and forward principal propagation information within JWT via destination to ABAP Environment.

I know how to do this from app-to-app on Cloud Foundry (check out carlos.roggan's post).

Is there any way to do this? Can I use the JWT information, scopes, etc. on the ABAP Environment? How to realize principal propagation if I can't do that?

With basic auth, described here, I am able to set up this chain. But how does it look like with oAuth v2 and JWT?

Is that even supported or a gap within the BTP portfolio ?

Thanks for any suggestions and ideas,

Regards,

Cedric

[WolfgangJanzen]

Dear Cedric,

are you primarily interested in "principal propagation" or in using OAuth with scope restrictions?

If "only" principal propagation is required, then maybe "OpenID Connect (OIDC) Bearer Tokens" might be of interest for you. This authentication method (inbound communication) is available as of release 2111.
The option is provided in the "Communication System" configuration.

From your description it sounds like you are obtaining the JWT from an XSUAA service instance.
The screenshot above refers to an IAS instance (acting as OpenID Provider).

Before getting further into details, I'd first like to know whether my assumption (that you are primarily interested in Principal Propagation) and thus my recommendation (to use OIDC) is correct.

Regards, Wolfgang

[drvup]

Hi wolfgang.janzen,

thank you for your reply - I really appreciate your feedback and support.

I checked your approach and this is working. To use this approach, I am required to replicate all users from our IDP to the ABAP Environment. That's not state of the art and our IAS is only acting as proxy to the customers AzureAD. This would be overkill to replicate the users. But within your approach, this inbound communication configuration is "only" used to map the user by nameId claim. (To be honest: That's a good start, of course!)

The original idea of our architecture is following the best practices by the other BTP environments - so we're searching for a way where we can forward the claims via JWT to the backend application (like it's done if we're completely running on CF):

-> Add group to user on AzureAD -> IAS is acting as proxy -> UI5 app is running on CF and routes (xs-app.json) backend calls to -> REST Service, running on ABAP Environment

The only missing part of this chain is the JWT handshake, to be able to access the scopes (I hope these can be used within the AUTHORITY-CHECK function in ABAP Environment !?) and user claims.

Within this approach it's not necessary to replicate users, have SSO in place and be able to orchestrate the authority roles on AzureAD.

Thanks in advance for more details and information, I'll share our outcomes within a blog post if it does succeed 🙂

Regards,

Cedric

[gregorw]

I've asked in September 2020: Can I access Access SAML Assertion Attributes in ABAP unfortunately the SAP BTP ABAP Environment is still a special snowflake in regards to how users get access to it.

[WolfgangJanzen]

Hi Cedric,

thank you for your reply - and for the confirmation that my proposed approach is working.
Yes, ABAP still requires persisted users - it will not work with "virtual users" (in contrast to other environments).

The reason for that is simply that ABAP is offering a powerful authorization concept which goes far beyond the capabilities of what can be achieved with OAuth scopes: instance-based authorization checks, conjunctively combining up to 10 fields of an authorization object.

Therefore, we only evaluate the user-identifying attribute (subject name identifier) of a received security token to establish a user-specific session (aka "logon"). Inside that session all user-specific information is looked-up locally - and not retrieving information from a security token. In general it would be also not really feasible for the token issuer to know which kind of information (JWT: claims, SAML: attributes) are required/evaluated by some recipient system. Also: if you'd insert all (potentially relevant) information in one single token, the token would become fairly large (potentially causing functional or performance issues).

Therefore: yes, (local) users will be required - and thus identity provisioning is important.
Business Users are based on Business Partners (of type Person, exactly speaking: Employee).
Their attributes are typically fairly static; that's why it makes perfect sense not to transmit them with every request but to replicate them only when relevant (i.e. initially and after changes).

Well, my response became lengthy, again.
But I hope I was able to provide some insights, explaining why an ABAP system behaves that way.

Best regards, Wolfgang

[drvup]

Hi Wolfgang,

thanks again for your detailed reply and the clear communication and background information you did provide. I did understand it and also the reasons why SAP decided to not implement it like it's done with the other environment of BTP.

However, this breaks the chain of the BTP authority architecture and concepts I learned and used so far. Fine for the SSO within SAML, but bad with the requirement to replicate users again and the connected requirement to administer and orchestrate them again in an SAP environment. Thought we finally got rid of that 😕

Thanks for the support and clarification to you, wolfgang.janzen (and also thx to gregorw).

[WolfgangJanzen]

Hi Cedric,

most Business Applications (like Concur, Ariba, SuccessFactors, ...) are using their own Identity & Access Management. As I've tried to explain: with increasing number of user attributes and when using a more complex authorization concept you'll not be able to derive all required data just from a received security token.

That might be different for BTP (micro) service which are in general more tailored to a specific purpose.
In such a case it might be possible to operate with transient users - not requiring any persisted (local) users.

OAuth scopes only allow to perform simple (Boolean) checks ("has scope": yes/no).
That might be sufficient to decide whether certain actions are allowed.
But this approach will not allow to perform instance-based authorization checks (i.e. restrict access to subsets of data, e.g. only selected cost centers, regions, etc.).

Best regards, Wolfgang

[drvup · Accepted solution]

The answer was committed as comment replies on my question.

Short answer:

No, it is not possible to use the jwt of the user session within the ABAP environment.

You can create a SAML inbound connection, to at least have SSO in place.

However, you will need to replicate your business users to the ABAP environment and orchestrate them (and their roles) within the ABAP environment too.

This brakes the BTP authority chain so far and relies in additional workload. I recommend to SAP to think again about this solution and also I recommend to customers to overthink using ABAP environment for use-cases, where you wanna use the environment to provide REST APIs where it is necessary to have principal propagation and authorities in place. This small issue can be a gamechanger of your digital transformation (within ABAP environment).