A Brief Overview

This blogpost discuss how one authenticates into the Development and Operations service provisioned within the SAP Cloud Platform and the various authentication and Single SignOn mechanisms available.

Gaining access to apps and related data via Mobile Services for Development and Operations (SAP CPms) is a two fold process. First one must authenticate into the platform and then to the datasource.

The SAP Cloud Platform which is the provider for core services to all the other services running within its scope is responsible for handling all the authentication into the platform and the services themselves are responsible for the second part of the flow where one implements what we call SSO (single sign-on) to the respective backend systems or data sources. Thus, one may see this setup as two distinct entities that need to work symbiotically to produce the desired end result.

Let us have a more in depth look at how this is set up.

The Identity Provider

The SAP Cloud Platform cockpit contains a Trust center (I actually have no idea what it is officially called but Trust center does sound nice Upon further inspection !! I can see it is actually called Trust Management 🙂 ) where one configures the various Identity providers. Normally this federation is done using SAML. By default the sap identity provider (accounts.sap.com) is available, meaning all users within your current scope will reside in this identity provider. Typically they will follow the S, P, D or I user naming nomenclature. It is also here in the trust center that one may configure 3^rd party Identity Providers like AD(FS) or indeed a tenant of SAP’s own Identity and Authentication Service.

The Configuration Nodes

But hold on, this is only about setting up where to look for the users when authenticating a call to a resource. Not how this is done. Well, the SAP Cloud Platform is also responsible for the “how” part of things (meaning various authentication mechanisms are provided which can either be called programmatically or set up as a part of the configuration tasks).

In the case of our service (SAP CPms), when an application is built, there are typically two configuration nodes that need addressing, namely Connectivity and Security.

While the connectivity node is left incomplete because there is no possibility to pre-populate the information required here, the Security node is provided with default settings which is SAML.

While the default security option for authenticating into the service is SAML, one also has other options available like

• OAuth
• Basic Authentication
• Certificate (X.509)
• And even NONE (so no authentication, can you guess why this may be relevant?)

While we are here, let us take a moment to crystalize the message.

“When creating an application in the Development & Operations Service, one can use Basic, Certificates, OAuth or SAML (default) to identify the user behind the request. In some cases it may be viable to allow anonymous  access (B2C scenarios for e.g. a webshop ) using the None option.”

Once we have decided on our Security mechanism, we are left with the simple (sic!) task of setting up SSO to the backend (or DataSource). This as you may have guessed is done in the Connectivity node.

As with the Security mechanisms we again have a few options to choose from.

• Application-to-Application SSO
  • This is an option typically used to pass the identity of the requester between services deployed within the cloud platform.
• SAPAssertion SSO
  • Use the assertion token option if the backend is configured accordingly. This option is typically used when working in a System-to-system scenario (user is identified with a logon ticket) where the recipient is singled out.
• OAuth2 SAML Bearer Assertion
  • As the name suggest, here one uses the SAML assertion to gain access to resources that are protected using OAuth.
• Basic Authentication
  • This option allows either using a preconfigured user (for e.g. technical user) or if the fields are left blank, then to respond to a challenge from the backend with an appropriate user & password combination.
• Client Certificate Authentication
  • Using certificates is viable when the backend is configured to accept trusted certificates (from a well known CA or one that is specifically trusted, typically enterprise internal CA’s).
• No Authentication
  • If the backend in question allows access to the requested resource without any form of authentication required, then one would use the NoAuth option.

One Last Thing

Did you pickup on the fact that the list above is missing one of the major topics we (Michael van Cutsem did sterling work on it while seconded to my team) worked on last year?  Yes, Principal Propagation is missing in this list. That is because the list is dynamic and will change based on what is a valid combination. See the matrix table in the appendix below for more insights into valid combinations. The screenshots below show you the difference in the options present when having chosen the Internet Proxy (for the destination / Connectivity) versus having chosen the On-Premise proxy and in the case of the latter, we can see the Principal Propagation option.

You’re Done

This done, one can safely say that the two components of the trinity that supports an authenticated and safe usage of applications via the SAP CPms have been configured and you have successfully joined the ranks of those who understand the basic tenants of Security and Authentication within the Development and Operations service on SAP Cloud Platform.

Appendix

The matrix below visualizes the various combinations and permutations between the Security configuration and the SSO options.

Find the official help documentation for Security Administration at this link.