Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 

Principal Propagation - Using a SAML Assertion Attribute as SAP Identifier



One of the most important requirement when implementing principal propagation is to ensure that we are able to map the identity from the Identity Provider (IdP) with the one from the User Repository of the SAP System.

We have already mentioned in this blog the possibility to perform a manual mapping between the internal and external user using EXTID_DN transaction.  This approach will always work but is quiet heavy to put in place compare to the other alternative.  The challenge is thus to make it automatic using CERTRULE in more complex situations.

In this blog I would like to share how to use an IdP property as a user id to authenticate in the SAP System through the setup of principal propagation described in this blog.

The only requirement in this context is to have the user id used to authenticate to the SAP System stored in the user's profile in the IdP.

Problem description

The SAP Cloud Platform (SCP) subaccount is configured to use a corporate IdP (not the default SAP ID Service).  This means that to access a service from SCP you can use your standard corporate credentials as defined in that IdP rather than an S/C/P/D/I user.  This can be many different things like an email address or a less intuitive employee id to only mention some examples.

On the other hand, to log into the SAP System, the user id format can be more restrictive.

Due to the multiplicity of user id associated to a single user it might be impossible to use one user id to authenticate to all systems.

Following the process of principal propagation, you will first authenticate while accessing the service or app running on the SCP using credentials, certificates,...  During the authentication process a bunch of (SAML) assertion attributes might be recuperated from the IdP for the SCP services to work properly.

This is what is configured here.  See more about this configuration in this blog.

Then you get to the SAP Cloud Connector (SCC) where a short lived certificate need to be built.  The creation of the certificate is done based on information also extracted from the user identity.

This config takes place here.  See more about this configuration in this blog.

But what might not be clear is from where exactly those information are obtained, ${name} here above for instance?  Does it come from the IdP directly or from the SCP user identity that was initially built based on the data retrieved from the IdP?

This part of the configuration is officially covered here.  In a nutshell the document says that the values that can be used for the configuration are the following:

You can assign values for the following parameters:

  • ${name}

  • ${mail}

  • ${display_name}

  • ${login_name} (as of cloud connector version

But what if it is not enough?  What if we would like to use another property that characterize the user?

Finding what is passed to the SCC

The solution to answer that question is to inspect the SCC logs (ljs_trace.log) at the moment where the service reaches the SCC to retrieve data from the backend.

2018-12-04 21:16:29,026 context in SAML2Assertion: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport|
2018-12-04 21:16:29,026 Name ID in SAML2Assertion: Subject NameID
Format: urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
Value: i******
Name Qualifier:
SP Name Qualifier:
SP Provided ID:
2018-12-04 21:16:29,027 Index in SAML2Assertion: _e93ed3d0-1a62-4205-81a9-ab4343cf8e1d|
2018-12-04 21:16:29,027 hash of value:********* is: d4489a876aff7e0456b0b8ae56cbb9fbe8e38b44|
2018-12-04 21:16:29,027 Cluster-wide Client ID: S-d4489a876aff7e0456b0b8ae56cbb9fbe8e38b44|
2018-12-04 21:16:29,027 in SAML2Assertion: null|
2018-12-04 21:16:29,027 authorities in SAML2Assertion: null|
2018-12-04 21:16:29,029 attributes received: Attributes
Format: urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified
Values: [Sarthak]
Encrypted: false
Format: urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified
Values: [Sharma]
Encrypted: false
Format: urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified
Values: [i******@******]
Encrypted: false
Format: urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified
Values: [Domain Users, WebIDEUsers]
Encrypted: false

We can see from the logs above that the information received by SCC to define the user is not created by the SCP subaccount using the info received from the IdP (we don't seen firstName, mail or lastName as attribute names) but it comes unchanged from the IdP.

To see those information in the logs you will need to increase their verbosity.

This means that instead of using ${Name} while defining the subject pattern details of the short-lived certificate or any of then variables given in the documentation, you can decide to use any other attribute assertion name from the SAML token, such as ${}.

This should offer you more flexibility when dealing with different credentials for different systems.


Thanks to sarthak0403 with who we figured this out.