Skip to Content
Technical Articles

How to configure Azure AD for Principal Propagation with SAP Cloud Connector

Hello Everyone

This blog aims to assist anyone that is trying to configure Principal Propagation scenario between SAP Cloud Platform and a backend system, but uses Azure as the Identity Provider.

The Principal Propagation method is very popular among customers and several times they use a custom IdP, like Azure.
When this happens, there are some adjustments that need to be made in order to properly send the attributes in the SAML that the SAP Cloud Connector will be able to recognize and use it to generate the X.509 certificate, used to authenticate the user in the backend.

What you will need:

  • SAP Cloud Platform account
    • (Optional) SAP Cloud Platform Identity Authentication tenant
  • Microsoft Azure AD
  • SAP Cloud Connector
  • Backend system (in this case we are going to use an ABAP)

 

Before you start:

  1. Make sure that your SAP Cloud Platform account is configured to trust the Azure AD or the Identity Authentication tenant (that trusts the Azure AD)
  2. Make sure your SAP Cloud Connector is synchronized with your SAP Cloud Platform account and also is synchronized with the Azure AD.
    Configure Trusted Entities in the Cloud Connector

Configuration Steps:

  1. Add a new claim under User Attributes & Claims
  2. Test to see if the new parameter is now included on the SAML
  3. Follow the Principal Propagation configuration

1 – Add a new claim under User Attributes & Claims

As we can see in the help page (Configure a Subject Pattern for Principal Propagation), the SAP Cloud Connector expects four types of attributes when performing the Principal Propagation. They are the following:

  1. name
  2. mail
  3. display_name
  4. login_name

So, when we are configuring a scenario like this, we need to make sure that at least one of the attributes above will be present in the SAML sent by the IDP.

In order to make the Azure include this attribute in the SAML, you need to do the following:

  1. In your Azure account, go to Azure Active Directory -> Enterprise Applications
  2. All Applications -> SAP Cloud Platform Identity Authentication OR SAP Cloud Platform (depending if you are using the IAS tenant or the SCP directly)
  3. Single sign-on -> User Attributes & Claims
  4. Click on Add new claim
  5. Set the Name with one of the four values that the SAP Cloud Connector accepts (name, mail, display_name and login_name) and set the Source Attribute accordingly, then press Save

 

2 – Test to see if the new parameter is now included on the SAML

  1. Open your SAP Cloud Platform account
  2. Go to Services -> Web IDE Full-Stack
  3. Open the developer tools of the Chrome (F12)
  4. Select the SAML tab
  5. Click on Go to Service
  6. You will be redirected to the Azure login page.
    Login with your user and password from Azure
  7. You should be able to see the SAML traces recorded on the Chrome’s DevTools.
  8. The attribute you included on Azure AD(in this case, login_name) should now be visible in the SAML as follows:

3 – Follow the Principal Propagation configuration

Now you have everything you need to go through the Principal Propagation configuration.

There is a good blog about it already, check it out: How to Guide – Principal Propagation in an HTTPS Scenario

You can also follow our official documentation:
Configure Principal Propagation to an ABAP System for HTTPS

Just remember the following differences:

  1. When synchronizing the IdP for Principal Propagation, remember that you will need to syncronize with your custom IDP (Azure AD)
  2. When configuring the certificates on SAP Cloud Connector, in the Principal Propagation section, use the attribute created on step 1 (the one you customized on Azure AD to include in the SAML).

That is it!

Feel free to leave any comments or questions. I will be happy to answer.

 

Error messages for discoverability:

Unable to generate authorization token for user <user> on system <system>:<port>

Cheers,
Augusto Ferreira
Support Engineer, SAP Product Support

16 Comments
You must be Logged on to comment or reply to a post.
  • Thanks Augusto Ferreira – really nice blog but it is missing one of the major pieces – the groups/roles the user is assigned to then assert the security in SAP Cloud Platform. For me, this has been seriously tricky in MS Azure as compared to SCIAS (SAP Cloud Platform Identity Authentication Service) or MS ADFS so would be good if you could include this.

    If you could add this please then I would feel it is more complete. Thanks!

    • Hi Ravi

      There is a KBA about this issue. Look for the KBA 2727260 – SAP Cloud Connector – Principal propagation: “CN is not available in context”.

      Anyway, this error is caused because the SAML token coming from the identity provider does not contain the SAML assertion which is mapped in Cloud Connector to the client certificate common name field.

      The cloud connector only accepts mail, last_name, first_name and login_name.
      You need to verify which one you have set your cloud connector to use and validate if it is inside the SAML.

      In this blog post, I used the login_name as example, so in the cloud connector, you just need to use the login_name as parameter to generate the x.509.

      Thanks,
      Augusto

      • SAP Note https://launchpad.support.sap.com/#/notes/0002727260 highlights now we can use

        custom patterns.

        Since 2.12.0.1 version the attribute name can be adjusted in the subject pattern configuration, see the online help Configure a Subject Pattern for Principal Propagation.

        Tried mapping “uid” as per doc ${uid} custom pattern, in CC I was seeing below error

        The variable ‘uid’ needed for object CN is not available in context.

        it did not work me, I had to map in SCP cockpit -> Trust ->Assertion to Principal mapping to work.

        Again this only worked when I was accessing the app from FLP. 

        This did not work if I try to access my backed via Web IDE to get OData services ..(Try to create an App via Template)

         

  • Hi Augusto

    We want configure this same procedure between Azure AD and SCP.

    In step 3.1 BASIC CONFIGURATION XML ,,,, where can we find the correct paths for (Sign on url , identifier, and reply url f)ields?

     

    Thanks for your blogs

    Best Regards

  • Hi Augusto,

     

    Thank you for sharing this great blog. I am wondering if it is possible to setup two SAML in Azure AD. I am about to try it out but there is already SAML configured in our Azure AD but it is pointing to SAP Cloud Platform subaccount.

     

    Regards,

    Florence

    • Hi Florence

      I’m not sure I understand your question.
      The idea of this blog is to explain how to set the necessary user attributes in the SAML sent by the Azure to the SAP Cloud Platform.

      I’m not sure why you would need to configure another SAML for the SAP Cloud Platform… You can just add more parameters to the SAML you are already sending, if you need something different for another application running on SCP.

      Thanks,
      Augusto

  • Hi Augusto,

     

    I am configuring SSO for another SAP Cloud Platform subaccount. As I could see, on the current SAML the Sign On URL is pointing to another Cloud subaccount.

     

    Regards,

    Florence