Skip to Content
Author's profile photo Prakalp Phadnis

Understanding Security & Authentication within Mobile Services for Development and Operations

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 ( 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.




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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Jyothi Krothapalli
      Jyothi Krothapalli

      One suggestion is to enhance the blog content with references to Basic Authentication flavors i.e., Cloud Platform SCIM vs Mobile Services SCIM

      Author's profile photo Prakalp Phadnis
      Prakalp Phadnis
      Blog Post Author

      Thanks Jyothi. Good Point that merits a follow up. Lets talk about it directly.

      Author's profile photo Jon Mijangos Bergara
      Jon Mijangos Bergara

      Hello Prakalp. Thanks for the blog. I'm also curious about the SCIM options for SCP Mobile Services Authentication.

      The SAP Help Portal indicates that "For applications that use basic authentication, you can configure SAP Cloud Platform Mobile Services to authenticate users with the default identity provider. The default identity provider is SAP ID service, and not the default Identity provider configured in Cloud Platform account trust settings."

      However, in "The Identity Provider" section of your blog, you indicate that the Identity Provider for the Mobile Services in maintained in the account Trust Management.

      The SAP Help and the blog don't seem aligned, unless I misunderstood something.

      Please, could you bring more light into this?

      Thank you!



      Author's profile photo Emiliano Orengo
      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 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!

      Author's profile photo Prakalp Phadnis
      Prakalp Phadnis
      Blog 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.


      Author's profile photo Santosh Chawala
      Santosh Chawala



      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?




      Author's profile photo Prakalp Phadnis
      Prakalp Phadnis
      Blog 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.

      Author's profile photo Prakalp Phadnis
      Prakalp Phadnis
      Blog 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.

      Author's profile photo Mahabaleshwar Hegde
      Mahabaleshwar Hegde

      Hi Prakalp,

      While creating a destination for one of my project, I have to use proxy type as “On Premise - Cloud Connector” and need to configure the https url, I guess which is not supported as I am below error while configuration url as https:
      “Invalid URL: Only http:// is allowed for OnPremise destination”

      Backend system has ABAP gateway and we are connecting it through Principal propagation. For Web IDE there is a provision to configure https url and we verified it is working as expected, but for mobile service I am not able configure the https url.

      Do you have some suggestion how to proceed to resolve this problem?



      Author's profile photo Prakalp Phadnis
      Prakalp Phadnis
      Blog Post Author

      Hi Mahabaleshwar,

      I normally do not maintain the comments section of my blogs. If you are looking for solutions, better reach out directly rather than the comments section.

      Did you find the solution? You simply need to present the same URL but remove the 's'.

      There is an explanation available in the documentation as to why this is the case but I don't have it at hand.

      Author's profile photo Vijay Sanjay Sonone
      Vijay Sanjay Sonone

      Hi Prakalp,

      Is there any possibilities of having a custom login screen with SAML on mobile services?



      Author's profile photo Prakalp Phadnis
      Prakalp Phadnis
      Blog Post Author

      Hi Vijay,


      The SAML screen presented by default is from ''. You as a consumer cannot influence this screen, but if you get an IAS tenant of your own, then you are able to brand the login pages.