SAP Analytics Cloud App Integration with OAuth2SAMLBearerAssertion flow.

[quovadis]

Sky is the limit! The OAuth2SAMLBearerAssertion flow is the mechanism for propagation of a user's identity and authorisations (scopes) from a client application deployed anywhere all the way through to the asset management service (such as Analytics Cloud in this instance). A truly end to end Single Sign On!

Business value Let's have a look at the business value proposition of SAP Analytics Cloud (SAC) App2App Integration capabilities. In a nutshell, SAP Analytics Cloud App Integration is all about asset management. Analytics Cloud becomes an asset management tool offering out-of-the-box content integration capabilities... that you can monetise. For instance, you could leverage SAP Integration Suite's API Management, to create proxied APIs to help both monetise and monitor access to these SAC hosted assets to 3rd party applications.

proposition.

SAP Analytics Cloud App Integration.

SAP Analytics Cloud (Cloud Foundry edition) App Integration with OAuth2SAMLBearerAssertion flow with and without the SAP BTP Destination service:

1. SAP Analytics Cloud App Integration with SAP BTP Destination service:	This is the most straightforward way of achieving the end to end user SSO. However this implies using a SAP BTP Destination service. OAuth2SAMLBearerAssertion Flow with the SAP BTP Destination Service. SAP Analytics Cloud CF edition.
2. SAP Analytics Cloud App Integration without additional SAP BTP tie-in:	Disclaimer: this is the hardest way of doing things as it implies creating and signing a SAML assertion that will be passed to the SAC’s OAuth service provider for user identity validation. How to generate SAML bearer assertion token for OAuth2SAMLBearerAssertion flow?

 

Conclusion.

In either case the working assumption is that your client application is deployed outside of SAP BTP. That means you will need to cater somehow for all the functionality that the SAP BTP application router (bound to an xsuaa service) provides, especially the mapping of an external SAML user's identity to a user JWT token.

On the other hand, if your application were deployed to SAP BTP you would etablish the SAML trust with your BTP sub-account as the ServiceProvider and would seamlessly benefit from the intrinsic user JWT identity provider mechanism.

As SAC is both single tenant and can support only one single SAML WebSSO IDP provider at a time, it makes sense to have SAC configured with the same SAML Identity Provider as your client application.

But what if your client application is not designed to support 

SAML SSO and is for instance designed to support only 

an Open ID Connect (OIDC) provider?

 

For the sake of the OAuth2SAMLAssertion flow this is not such a strict requirement to have one same [WebSSO] IDP hooked to either client app and SAC (especially if the client app does not have the built-in support for a SAML provider). When you generate a SAML bearer assertion the user's identity it is supposed to help propagate must match a user's identity in SAC. A concept called 'user isolation'. (And having the same IDP hooked to both client application and SAC tenant makes it simple to achieve the user isolation.)

But in the end the same identity might have 2 different origins: OIDC on the client side and SAML on SAC side. This is why with OAuth2SAMLBearerAssertion flow the SAML assertion must be signed with the private key of the x509 certificate. (This x509 certificate is often called a trusted identity provider but has nothing to do with the webSSO IDP of the SAC tenant). Thus you must own the keypair == the private key and the x509 certificate. (Again when using the SAP BTP Destination service this is out-of-the-box.)

Last but not least, you could also imagine having (a) technical user or users to get access to the SAC tenant assets with OAuth2SAMLBearerAssertion flow. In that case you might end up manually creating these technical users in SAC tenant. Thus ultimately your SAC tenant might be hooked to a different IDP that your client app's provider. The technical users are not recommended for production landscapes  but you may find them handy for proof of concepts and sandboxing.

 

__________

 

Additional reading and resources.

1. There is a very good SAP sample that describes how to map an external SAML user identity into a user JWT token here (steps 1 - 5).

SAP Analytics Cloud REST API.

SAP Analytics Cloud, Embedded Edition: Development | SAP Help

SAP Analytics Cloud URL API

Enable Iframe embedding notes:

This is one of the most important help pages when it comes to enabling iframe embedding of SAC assets (stories, applications). Please read it carefully.

You must enable third party cookies in the browser you are using for story embedding.

When SAP Analytics Cloud is running in an iframe, and it redirects to an IdP, this will happen in the same iframe. Clickjacking protection must be disabled for the IdP or you may not be able to login to the IdP within the iframe.

Alternatively, you can create an active session with the SAP Analytics Cloud tenant in a different browser tab prior to loading SAP Analytics Cloud in the iframe.

So this is exactly what is happening for instance in Chrome. If you create an active session with the SAP Analytics Cloud tenant prior to loading SAP Analytics Cloud in the iframe the subsequent iframe embedding works properly regardless whether it is with WebSSO or OAuth2SAMLBearerAssertion.

Additionally, in Safari, you may need to uncheck "Prevent cross-site tracking" https://support.apple.com/en-in/guide/safari/sfri11471/mac