Skip to Content

SAP Cloud Platform Single Sign-On: Application-to-Application SSO Authentication

User propagation between two applications deployed on SAP Cloud Platform

This blueprint provides common information, guidance, and direction for implementing principal propagation between two applications both deployed to the SAP Cloud Platform.


SAP Cloud Platform is an essential part of SAP’s digital strategy. It is the platform for our customers’ and partners’ transformation journey toward digital business models.This open platform as a service (PaaS) provides unique in-memory database and application services. It is the proven cloud platform that enables you to rapidly develop new applications or extend existing ones, all in the cloud.

While the authentication and authorization on the SAP Cloud platform is part of the security implementation, the challenge comes in how to integrate multiple applications running on the SAP Cloud Platform so that the user of an application only needs to authenticate once and the application can propagate their identity to other applications or services without the user having to constantly provide their identity.

SAP Cloud Platform offers many methods of user principal propagation so it is important to understand them and how they can be used in the destination configuration.

Authentication Type Description When to use…
Application-to-Application SSO

Enables services to propagate user identities to other applications which are consumed (deployed or subscribed) in the SAP Cloud Platform account. A user identity is propagated to the application that is specified in the URL.

Full identity is propagated.

If the service endpoint is running on an account in the SAP Cloud Platform

Configure the back-end system to accept SAP assertion tickets that are signed by a trusted X.509 DSA key pair. By default, all SAP systems accept SAP assertion tickets for principal propagation.

Only User ID is propagated.

If the backend service endpoint is a SAP NetWeaver AS system that can reside on the cloud or on-premise.
Principal Propagation

Allows destinations to forward the identity of an on-demand user to SAP cloud connector, which then forwards it to the back-end system of the relevant on-premise system. An on-demand user need not provide his or her identity for each connection to an on-premise system when using SAP Cloud Connector.

Full identity is propagated.

If the backend service endpoint accepts client certificate authentication for both SAP and non-SAP system.

This can be use with HTTPS protocol or RFC protocol with SNC.

Note: Cloud Connector is needed.


Enables applications to use SAML assertions to access OAuth-protected resources.

Full identity is propagated

If the backend service endpoint is a OAuth-protected resources that can reside on the cloud or on-premise (SAP and 3rd party backend system).

OAuth authorization server is needed.

This blueprint will focus on the Application to Application Single Sign-on (AppToAppSSO) method where both the front-end and back-end are running on the SAP Cloud Platform.

In this scenario Connectivity destinations are used for the outbound communication of a cloud application to a remote system. They contain the connection details for the remote communication of an application. Connectivity destinations are represented by symbolic names that are used by on-demand applications to refer to remote connections. The connectivity service resolves the destination at runtime based on the symbolic name provided. The result is an object that contains customer-specific configuration details, such as the URL of the remote system or service, the authentication type, and the relative credentials. In this scenario, the remote system is another application running on SAP Cloud Platform.

Technical Scenario

Just as many applications that a business runs consume services/data on premise and the identity of the user needs to be verified on the backend system, the same holds true for when the backend for the application is another application or service running on the cloud. Once the user has been verified against an Identity Provider (IdP), a SAML assertion token is passed to the backend application/service running on the cloud platform. The identity of the user between the two cloud platform applications should be the same in order to achieve SSO.


In this setup for AppToAppSSO, the principal propagation is configured using a destination allowing communication between two applications. If the two applications are running on different sub-accounts that could be on the same  global account or two different accounts, there needs to be a trust relationship between the two accounts, this is achieved by exchanging the Local Service Provider metadata to the destination account. Below are some of the possible scenarios:

Solution Benefits

AppToAppSSO is a specific for of principal propagation designed only for the simplified propagation of user identity between applications running on SAP Cloud Platform. Having AppToAppSSO enabled for the destination on SAP Cloud Platform would allow the user to access resources on the same or other sub-accounts seamlessly without needing to provide his/her identity every time he/she makes a connection to the other application. This is a one-time setup per application and requires minimal setup time; requiring on trust between two sub accounts and a configured destination. This setup leverages SAML 2.0 allowing propagation of the user identity plus additional attributes such as Email address, department, group membership etc, which can make the authorization setup much easier.

Reference Solution Diagram

SAP Cloud Platform is the extension platform for SAP. It enables developers to develop loosely coupled extension applications securely, thus implementing additional workflows or modules on top of the existing solution they already have.

SAP Cloud Platform supports application scenarios for consumers (B2C), for partners (B2B), and for employees (B2E). The solution provided in this blueprint is available for all three scenarios. All types scenarios users will be asked for authentication by the SAP Cloud Platform and the platform application configuration will propagate the user identity down to the backend system.

The following diagram of the solution illustrates a basic architectural pattern implementing Single sign-on using AppToAppSSO.   

  1. The user has already been authenticated against an IdP & authorized for SAP Cloud Platform.
  2. The destination in SAP Cloud Platform is configured to use App2AppSSO.
  3. A new SAML token will be generated base on the incoming authenticated user using the Local Service Provider information.
  4. The new SAML response for the authenticated user is forwarded to the target service/application resides on.

Note: In the landscape picture, the SAP Cloud Platform Identity Authentication Service is the IdP (this can be any 3rd party IdP) being used to authentication the user. The authentication IdP should already configured and trusted by the SAP Cloud Platform and authorization should be already configured.

Reference Solution Components

The following list describes the main components needed to implement this scenario and the role they play in the overall solution

User Network

Application – Organizations can choose to develop according to their needs, resources, and skills. Applications can be developed using SAP Mobile Platform SDK. The SAP Mobile Platform SDK provides developer tools to streamline the development, delivery, security and management of mobile applications. 

SAP Cloud Platform

SAP Cloud Platform Identity Authentication service – A cloud solution for secure authentication and single sign-on for SAP Cloud Platform applications, and for on premise applications.

Connectivity Service – The connectivity service allows SAP Cloud Platform applications to access securely remote services that run on the Internet or on premise.

Generic SAP Cloud Platform Service – To keep the blueprint simplified a generic icon is used since any SAP Cloud Platform Services requiring authentication will act the same way.

High Level Implementation Process

Overview of the steps needed to implement this blueprint:

  1. Establish trust between two sub-accounts by adding the Local Provider name from the first account to the second account
  2. Create a new destination to the application and set the Authentication to AppToAppSSO
  3. Add an additional property to your destination called saml2_audience this is a local SAML 2.0 provider name of the subaccount which consumes the target application.

Learn More

This blueprint highlights important considerations companies need to analyze when implementing authentication for cloud platform applications. It only provide a high level overview of the process. It is recommended to review further information to help you implement your single sign-on using principal propagation. The following resources are a starting point:

Back to top