Skip to Content
Technical Articles
Author's profile photo Lucas Vaccaro

How to integrate Azure AD with SAP BTP, Cloud Foundry environment

UPDATE: We now recommend that you use SAP Cloud Identity Services – Identity Authentication as a hub, especially if your business users are stored in multiple corporate identity providers. For this scenario, connect Identity Authentication as single custom identity provider to SAP BTP. Then use Identity Authentication to integrate your corporate identity providers. For instructions, see Enable SSO Between Azure AD and SAP Cloud Platform Using Identity Authentication Service.


In this post, we are going to configure Microsoft Azure AD as the Identity Provider of applications running on an SAP BTP, Cloud Foundry subaccount. Furthermore, we are going to grant authorizations (scopes) to users by mapping Azure Groups to Role Collections.

Prerequisites

  • You have a Cloud Foundry subaccount (enterprise or trial), and you are a Security administrator of it (meaning that you can see the Security menu in the SAP BTP Cockpit).
  • You have a Microsoft Azure subscription.

Procedure

  1. Download the SAML metadata file from the Cloud Foundry subaccount
  2. Add Cloud Foundry as an Enterprise Application on Azure.
  3. Add Azure as Identity Provider in the Cloud Foundry account.
  4. Configure Role Collection mappings.
  5. Test.

1. Download the SAML metadata file from the Cloud Foundry subaccount

To download the metadata file of the subaccount, access your CF subaccount through the BTP Cockpit and go to Security > Trust Configuration.

Click on the SAML Metadata button to download it.

2. Add Cloud Foundry as an Enterprise Application on Azure

Go to the Azure Portal > Azure Active Directory > Enterprise applications, and click on New Application.

Search for the SAP Cloud Platform application in the gallery, give it a name and save it.

Access the newly created application, click on Single-sign on the left and select SAML.

Upload the metadata file downloaded from the Cloud Foundry account. The Basic SAML Configuration panel will open. Fill in the Sign On URL and save (the Sign On URL can be any CF application or the UAA URL, for example. It will not affect the configuration).

Under ‘2. User Attributes & Claims’, click on the pencil icon, and configure the name identifier, groups claim and user attributes as shown below (case sensitive). Make sure you remove the namespace from the attributes.

Hint: for e-mail addresses, either “email” or “mail” work.

For the Groups attribute (note the capital letter “G”), you will have to use the Advanced options as shown below. The groups attribute is used on Cloud Foundry to configure Role Collection mappings and grant authorizations to users in your applications. In this tutorial, we are going to use the value “All Groups”. The “Source attribute” is the value that the users’ groups will have in the SAML response. Here we chose the Group ID. These values will be used to define our Role Collection mappings in the step 4.

Note: there is a glitch in the UI where you save the attribute “Groups” and it is displayed as “groups” afterwards (lower case). If you refresh the screen or record a SAML trace, you will see the attribute with the correct name i.e. “Groups”.

UPDATE: Cloud Foundry is now more flexible and allows role collection mapping with arbitrary attributes. It is not strictly necessary to use “Groups” anymore.

Finally, download the Federation Metadata XML from Azure:

3. Add Azure as Identity Provider in the Cloud Foundry account.

Access your Cloud Foundry account and go to Security > Trust Configuration. Choose New Trust Configuration and import the metadata file downloaded from Azure. The ‘Link Text” is the text that will be displayed in the logon page of the UAA tenant for end users.

4. Configure Role Collection mappings

The final configuration step is to define Role Collection mappings in order to give authorizations to users for the CF applications. This will be done with the Groups attribute as explained in the step 2.

Go to Security > Trust Configurations > [Azure AD entry] > Role Collection Mappings, and configure it according to the Role Collections that you have for your applications.

Since we selected “Group ID” as the “Source attribute” for the groups claim in the step 2, Azure will send the “Object ID” of all groups assigned to the user. They can be seen in the Azure Portal > Azure Active Directory > Groups.

UPDATE: Cloud Foundry is now more flexible and allows role collection mapping with arbitrary attributes. Just make sure that the claims and mapping rules are correctly configured (consider case sensitive values).

Example:

  • There is a group on Azure AD with Object ID equals to “93461e34-6b54-47ae-bbec-c086a3385fa9”:
  • We want to map every user in this group to the “Manager” Role Collection in the CF subaccount:

5. Test

Open a new browser window and enter the UAA tenant URL:

https://<tenant_name>.authentication.<region>.hana.ondemand.com

You can find the <tenant_name> and the <region> in the Overview menu of the subaccount. Example:

You will still be able to logon with your S-user’s e-mail and password. You will see a link to Azure AD below the form. In the Trust Configuration, you can enable/disable the SAP ID Service or any other IdP you have configured. If you disable the SAP ID Service, you will only see the links to the external Identity Providers. If there is only one Identity Provider configured, you will be automatically redirected to it.

Click on the Azure link and logon with your Azure user. You will be redirected back to UAA afterwards.

Note: If you get a message similar to “AADSTS50105: The signed in user … is not assigned to a role for the application …” on Azure, you will have to either assign your user to the enterprise application, or disable the requirement for user assignment. More information in the Azure docs.

The screenshot below means that the authentication was successful. We see “Where to?” because we did not access a CF application, only the UAA tenant page. You can try to open any of your CF applications to verify whether the role mappings configured are working.

Hint: you can check the user’s details, including the groups that were mapped, by accessing the following URL:

https://<tenant_name>.authentication.<region>.hana.ondemand.com/config?action=who&details=true

For troubleshooting, you can use the SAML-tracer extension for Chrome and Firefox. You will be able to see the SAML assertions exchanged between CF and Azure.

Result

You have configured Azure AD as the SAML Identity Provider for your Cloud Foundry applications and delegated authorizations using Azure Groups! Feel free to leave any comment and to check our documentation.

Assigned tags

      28 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Marius Obert
      Marius Obert

      Great post and very easily and quickly comprehensible!

      I'm sure this will help a lot of people to leverage their existing Azure AD resources

      Author's profile photo Caroline Didriksson
      Caroline Didriksson

      Hi Lucas

      Thank you for a very good blog. I just have one little question. Under point 1 you mention downloading the metadata file. Where can I find this file to download?

      Regards,

      Caroline

      Author's profile photo Lucas Vaccaro
      Lucas Vaccaro
      Blog Post Author

      EDIT: now there is a button to download the metadata, so this is no longer required.

      ----------------

      Hi Caroline,

      Thanks for the feedback!

      To download the metadata file, you have to open a URL in the following format:

      https://<tenant_name&gt;.authentication.<region>.hana.ondemand.com/saml/metadata

      I’ve added some hints on how to find the <tenant_name> and <region> in the step 1.

      Best Regards,
      Lucas

      Author's profile photo Gregor Wolf
      Gregor Wolf

      Dear Lucas,

      with the help of your post I was able to configure the connection between my Azure AD and the SAP CF Cloud Foundry in just about 20 minutes. But I have some suggestions and comments.

      1. I've done several configurations of the Trusted Identity Provider on SAP CP Neo and never had to manually maintain the Sign On URL. I hope that can be included into the metadata download.
      2. Why isn't the metadata simply provided by a download link like it's done in SAP CP Neo?
      3. I don't think that editing the manifest to change the groupMembershipClaims is needed anymore. This can be done via the User Attributes & Claims UI.
      4. You've described and I found the details in Federation Attribute Settings of Any Identity Provider regarding the adjusted assertion attributes for first_name, last_name and mail. In SAP CP Neo there was also a mapping possibility for the attributes. That seems to not exist anymore or?

      Best regards
      Gregor

       

      Author's profile photo Lucas Vaccaro
      Lucas Vaccaro
      Blog Post Author

      Hi Gregor,

      Thanks for the comment.

      For 1 and 2, I will follow up with the responsible people.

      Regarding the point 3, it looks like the User Attributes & Claims configuration was changed after I wrote this blog, so thanks for letting me know. I've updated the respective section in the post.

      4. In Cloud Foundry, there is no such mapping for user attributes like there is on Neo. This whole architecture is based on the UAA project of the Cloud Foundry platform, so I'm not sure if the same feature can be implemented on CF. Another point to follow up.

      Best Regards,
      Lucas

      Author's profile photo Siddharth Jain
      Siddharth Jain

      Hi Lucas,

       

      I configured scenario with my CF App,but first name and last name are not coming in JWT ,instead of that first name is being taken as my email id first half and last name as my email address second half after @ ,this is weird ,i followed steps mentioned in blog,please suggest.

       

      Thanks,

      Siddharth

       

      PS: its resolved you can ignore 

      Author's profile photo Lucas Vaccaro
      Lucas Vaccaro
      Blog Post Author

      Hi Siddharth,

      would you share the resolution here? Just in case someone else faces it. I'd say it's because of the assertion attribute names.

      Best Regards,
      Lucas

      Author's profile photo Giovanni Degani
      Giovanni Degani

      Trying hard to find documentation on setting up CF apps that can do SSO all the way to the a SAP Gateway using SCC principal propagation. It is working fine for us on NEO, but not on CF. In our case samaccountname is an assertion attribute name we use in SCC to map the users, but on CF this seems not to be available. Any ideas ?

      Author's profile photo Lucas Vaccaro
      Lucas Vaccaro
      Blog Post Author

      Hi Giovanni,

      The general documentation is available here:
      https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US/e2cbb48def4342048362039cc157b12e.html

      The main difference in the PP scenario on CF is that the user’s JWT is forwarded to SCC instead of the SAML assertion.

      The UAA automatically maps the following attributes from the SAML assertion to the JWT when the user authenticates on CF:

      first_name -> given_name
      last_name -> family_name
      mail -> email

      In addition, the NameID attribute is mapped to “user_name”.

      Currently, it is only possible to configure one of the root attributes of the JWT as the Subject Pattern in the Cloud Connector (i.e. one of the 4 attributes above). It is not possible to use a custom attribute.

      Best Regards,
      Lucas

      Author's profile photo Giovanni Degani
      Giovanni Degani

      Ok. Thanks for the reply. So that basically means in my case I will need 2 separated cloud connectors to be able to have Principal Propagation for both Neo and CF.

       

       

      Author's profile photo Lucas Vaccaro
      Lucas Vaccaro
      Blog Post Author

      Yes, that's correct. Unless you can use one of these 4 attributes on Neo as well.

      Author's profile photo Wilfredo Barrantes
      Wilfredo Barrantes

      Dear Lucas,

      Excellent blog !!. and How to integrate Azure AD with SAP CP Neo.. be the same?

      Best regards
      Wilfredo

       

      Author's profile photo Lucas Vaccaro
      Lucas Vaccaro
      Blog Post Author

      Hi Wilfredo,

      For Neo, it's a bit different. You can check this guide:

      https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/sap-hana-cloud-platform-tutorial

      As I see, screenshots are outdated, but the menus, options, etc are still the same.

      Best regards,
      Lucas

      Author's profile photo Wilfredo Barrantes
      Wilfredo Barrantes

      Hi Lucas

      Thank's for you answer.

      The URL that I must put in the Sing on URL (Azure AD) is that of my global account or I do a configuration for a subaccount that I have.

      In my case I have three subaccounts in neo. each subaccount is an environment. (development, quality and production)

      What configuration would be optimal?

      thanks

      Wilfredo

      Author's profile photo Lucas Vaccaro
      Lucas Vaccaro
      Blog Post Author

      Hi Wilfredo,

      You can use the URL of the BTP Cockpit. The Sing on URL on Azure AD does not really affect the SSO flow. The Reply URL is the most important one.

      Best regards,
      Lucas

      Author's profile photo Jonas Meyer
      Jonas Meyer

      Dear Lucas

      Thank you for the great blog! As mentioned before, in NEO it was all crystal clear but in CF more of a struggle. Your blog confirmed what I had configured with a CF subaccount and Azure AD. But we also use IAS as proxy between AAD and BTP while some user-domains authenticate in IAS and others in AAD.

      But since I just forward the "Groups" claim in IAS to the trusted application / subaccount, this shouldn't be an issue really.

      Relevant AD Security Groups for Role collection mapping are synced to AAD. Then I use Groups claim with ID and ID is used in Role collection mapping as "Groups equals = ID".

      But the groups claim does not even get posted (SAML trace) to SAP IAS, so it never comes to even check the group membership for role assignment on BTP. Do you have any clue on that one?

       

      Best regards

      Jonas

      Author's profile photo Filip Szafarz
      Filip Szafarz

      Hi Jonas,

      You mention that for SCP Neo it was crystal clear. It is when you want to integrate AD Azure with Neo for specific service/application. Going through the help from Microsoft will do in this case:

      https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/sap-hana-cloud-platform-tutorial

      But how to integrate access to the subaccount(platform) and allow group of people set up in AD Azure access to specific subaccount. Below blog from Murali kind of show it but at the same time there is a need to have global accounts for every single user - which seems to be very odd.

      https://blogs.sap.com/2018/07/18/setup-a-platform-identity-provider-for-sap-cloud-platform/

      Do you have some better help how to set it up without creating every single user as global administrator for whole account?

      Appreciate any hint.

      Filip

      Author's profile photo Jonas Meyer
      Jonas Meyer

      Hi Filip

      Basically, you trust one of your subaccounts with an IdP (e.g. Azure AD). There are two options:

      • Application Identity Provider (services like Portal, Mobile, CPI...)
        • If you choose Azure AD as IdP and if you only want selected people to have access to certain services, you have to maintain groups in AD or AAD and make them part of the SAML assertion. Or you use SAP IAS and if the identities are maintained in there, you can also assign IAS based groups
      • Platform Identity Provider (subaccount members, administrators, developers in cockpit)
        • requires maintained Members with selected roles in subaccount
        • When you add new members, you can choose the identity source (SAP identity or custom IdP)

      Let's have a private talk on this, if you want!

       

      Author's profile photo Lucas Vaccaro
      Lucas Vaccaro
      Blog Post Author

      Hi Jonas,

      Unfortunately, I don't have any clue about that. If the groups claim is configured, it should be included in the SAML assertion. If you find the cause, let us know 😉

      Best regards,
      Lucas

      Author's profile photo Jonas Meyer
      Jonas Meyer

      I found out why...

      https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims

      "Azure Active Directory limits the number of groups it will emit in a token to 150 for SAML assertions, and 200 for JWT. If a user is a member of a larger number of groups, the groups are omitted and a link to the Graph endpoint to obtain group information is included instead."

      This is the case for most of our AD-accounts. So the only way with Azure AD is then to filter on the groups / explicitely assign AD-groups to the trusted enterprise application and then configure the group claim this way:

      Result is, that groups claim is part of the assertion and is delivered to BTP.

      But: It required a new second trust also between SAP IAS and Azure AD, because otherwise, all applications trusted to IAS would be limited to the selected groups above, which would make no sense!

      Author's profile photo Peter Benicky
      Peter Benicky

      Hi Lucas,
      Great post!
      Regards Peter

      Author's profile photo Jiani Zhang
      Jiani Zhang

      Hi Lucas,

      Thank you for the great post. I can configure the Role Collection mappings successfully.

      But the question is, once I uncheck the "Create Shadow Users During Logon" for the AzureAD IDP, the logon process cannot be performed properly. It will fall into a dead loop between the BTP subaccount login page and AzureAD login page.

      Is it necessary to have shadow users in the subaccount? We will have lots of application users in the future, having all these shadow users will increase maintenance efforts...

       

      Best Regards,

      Jiani

      Author's profile photo Lucas Vaccaro
      Lucas Vaccaro
      Blog Post Author

      Hi Jiani,

      Yes, shadow users are necessary. From our documentation:

      "the User Account and Authentication service always stores user-related data provided by the identity provider in the form of shadow users".

      The data is updated automatically at every login.

      Best regards,
      Lucas

      Author's profile photo Jiani Zhang
      Jiani Zhang

      Thank you Lucas!

      Best regards,
      Carol

      Author's profile photo Hannes Defloo
      Hannes Defloo

      Hi Lucas, good blog and very informative.

      One comment: I think the attribute should be email instead of mail ?

      https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/6d073332bc5743fdb7f7f06bde499ab7.html

       

      Thanks, Hannes

      Author's profile photo Lucas Vaccaro
      Lucas Vaccaro
      Blog Post Author

      Hi Hannes,
      Thanks for the feedback!

      In the past, only mail used to work, but currently, either mail or email work.

      Best regards,
      Lucas

      Author's profile photo Gokulraj Ramdass
      Gokulraj Ramdass

      Hi Lucas,

       

      great blog !! actually i am looking for the scenario in other way around. How can we use the SAP BTP CF access token to access the Azure Graph apis ? Is it possible to set up the trust in azure to allow our BTP accesss token ? thanks !!

      Regards

      Gokul

      Author's profile photo Lucas Vaccaro
      Lucas Vaccaro
      Blog Post Author

      Hi Gokul, thanks for the feedback.

      I don't think that this is possible as the tokens issued by XSUAA are tightly coupled to BTP, but I can't say for sure.