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.
- 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.
- Download the SAML metadata file from the Cloud Foundry subaccount
- Add Cloud Foundry as an Enterprise Application on Azure.
- Add Azure as Identity Provider in the Cloud Foundry account.
- Configure Role Collection mappings.
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.
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).
- 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:
Open a new browser window and enter the UAA tenant URL:
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:
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.