Skip to Content
Technical Articles

Principal Propagation – Using a SAML Assertion Attribute as SAP Identifier

Principal Propagation – Using a SAML Assertion Attribute as SAP Identifier

 


Introduction

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 2.8.1.1)

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 +0100#DEBUG#com.sap.security.saml2.sp.sso.AssertionValidationService#tunnel-client-10-1#0x9ad39e45#Authentication context in SAML2Assertion: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport|
2018-12-04 21:16:29,026 +0100#DEBUG#com.sap.security.saml2.sp.sso.AssertionValidationService#tunnel-client-10-1#0x9ad39e45#Subject 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 +0100#DEBUG#com.sap.security.saml2.sp.sso.AssertionValidationService#tunnel-client-10-1#0x9ad39e45#Session Index in SAML2Assertion: _e93ed3d0-1a62-4205-81a9-ab4343cf8e1d|
2018-12-04 21:16:29,027 +0100#DEBUG#com.sap.security.saml2.lib.common.SAML2Utils#tunnel-client-10-1#0x9ad39e45#SHA-1 hash of value: https://hana.ondemand.com/oo7hb0xmpj@http://*********.wdf.sap.corp/adfs/services/trust@_e93ed3d0-1a62-4205-81a9-ab4343cf8e1d is: d4489a876aff7e0456b0b8ae56cbb9fbe8e38b44|
2018-12-04 21:16:29,027 +0100#DEBUG#com.sap.security.saml2.sp.sso.AssertionValidationService#tunnel-client-10-1#0x9ad39e45#Generated Cluster-wide Client ID: S-d4489a876aff7e0456b0b8ae56cbb9fbe8e38b44|
2018-12-04 21:16:29,027 +0100#DEBUG#com.sap.security.saml2.sp.sso.AssertionValidationService#tunnel-client-10-1#0x9ad39e45#SessionNotOnOrAfter in SAML2Assertion: null|
2018-12-04 21:16:29,027 +0100#DEBUG#com.sap.security.saml2.sp.sso.AssertionValidationService#tunnel-client-10-1#0x9ad39e45#Authenticating authorities in SAML2Assertion: null|
2018-12-04 21:16:29,029 +0100#DEBUG#com.sap.security.saml2.sp.sso.AssertionValidationService#tunnel-client-10-1#0x9ad39e45#SAML2Assertion attributes received: Attributes
Name: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
Format: urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified
Values: [Sarthak]
Encrypted: false
Name: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
Format: urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified
Values: [Sharma]
Encrypted: false
Name: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
Format: urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified
Values: [i******@******.dev-wdf.sap.corp]
Encrypted: false
Name: http://schemas.microsoft.com/ws/2008/06/identity/claims/role
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 ${http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname}.

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


Acknowledgement

Thanks to Sarthak Sharma with who we figured this out.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.