Skip to Content

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 3rd 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.

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Emiliano Orengo

    Hi there!

    I wondering if you could help me to understand the proper setting for SAML authentication and propagation (I could make it work the first part following https://blogs.sap.com/2017/02/02/appendix-d-saml/) but I need to propagate it, a.k.a. SSO, to my SCP Destination. Not sure how to configure and test this. So far, I have this hardcoded with basic auth. I need to fix it.

    Thanks a lot!

    (0) 
    1. Prakalp Phadnis Post author

      Hi Emiliano,

      Normally, I dont follow up the comments so apologies for the late response. Perhaps I should change my routine.

      Now, to your query, paraphrasing your request (which it is rather more than it is a question),

      ** You are following Daniel’s blog on the Kapsel SDK and its capabilities and now you are at a stage where you wish to propagate that user to the back-end. **

      My suggestion is for your to follow the How-to-Guide on Principal Propagation found here. If you do so, I am certain you should be able to propagate the  identity all the way to your datasource.

       

      (0) 
  2. Santosh Chawala

    Prakalp,

     

    I’m missing a few things in this blog but before i go there, let me ask your help for me to understand how best we can handle our scenario.

     

    We have an offline mobile application which works well with Principal propagation but there is one scenario where functional accounts (from shared industrial devices) authenticates to IDP but corresponding id does not exist on backend system and we would like that exception to be handled and user be presented with backend credentials popup.

     

    Scenario above does not work same application i.e. exception/conditions handling is not possible on security or connectivity configuration and we may be forced to deploy 2 apps , one handling PP and other handling Basic auth which is a support nightmare.

     

    Can you please suggest possibilities to handle conditions/exceptions i.e. say try PP first and if that fails use basic with SCIM path for authentication?

     

    Sant

     

    (0) 
    1. Prakalp Phadnis Post author

      Hi Santosh,

      In this blog, I have captured the existing options to handle Authentication from the device to the platform and the SSO mechanisms / options from the platform to the back-end.

      What is it that you perceive to be missing? I will be happy to enhance the blog if necessary.

      The scenario you describe is specific and I would rather discuss this over email or in a call thank in the comments section, so please reach out if the questions are still relevant.

      (0) 
    2. Prakalp Phadnis Post author

      and btw, RE.

      “Can you please suggest possibilities to handle conditions/exceptions i.e. say try PP first and if that fails use basic with SCIM path for authentication?”

      This is exactly how it works, if the preferred authentication mechanism fails, then the next viable option is presented.

      (0) 

Leave a Reply