Automated Security Group & Role Assignment between SAP Cloud Platform and Microsoft Azure AD

There are a number of blogs that exist that cover how to map security groups in SAP Cloud Platform to either MS ADFS (Microsoft Active Directory Federated Services)  or to the SAP Cloud Identity Authentication Service (SCIAS) in order to automatically determine security groups and of course roles assigned to the groups. These blogs go through the mapping in the Trust section that allow for the automated determination of security roles on SAP Cloud Platform via groups defined in ADFS or SCIAS. The typical mapping of these attributes looks like this.

Figure:1 – Typical SAP Cloud Platform trust settings – Assertion Attributes

But what I have found when connecting to Microsoft Azure AD is that it is not as simple. In MS ADFS you can map English AD group names to the security groups in SAP Cloud Platform so the mapping is usually quite simple. This is not the case using Azure AD – instead we only have an objectid which is a fairly large number of mixed characters (see below) so more difficult to map directly without keeping some sort of spreadsheet to keep track of which ID’s related to which groups! As a comparison I would normally maintain a spreadsheet that covers which objects ID’s represent each SCP security group. For reference I have also maintained what a typical MS ADFS group name would look like and as you can see – the ADFS group name would be alot easier to maintain.

Figure:2 – Azure AD Object ID’s versus ADFS Group names

So this blog post seeks to cover how this can be set up. I was also mindful that my blogs for March were seriously low so need to get the numbers up in April to make up for it 🙂  Those who know me saw my 2020 goal of #2020YearofSAPBlogs! – 3 a month. So here goes….

Murali Shanmugham did produce a multi-part part series on how to integrate the Azure Active Directory and SAP Cloud Platform via SCIAS and definitely worth reading – very comprehensive. You can access all 5 from the below links so I’ve only included 2 here with the most relevant to this blog being the 2nd one.

https://blogs.sap.com/2019/04/28/integrating-identity-authentication-service-azure-active-directory-in-sap-cloud-platform-proxy-conditional-authentication-scenarios-part-1/

https://blogs.sap.com/2019/04/28/integrating-identity-authentication-service-azure-active-directory-in-sap-cloud-platform-proxy-conditional-authentication-scenarios-part-2/

This part 2 blog post in particular covers the direct integration option between the SCP subaccount and Azure (not via SCIAS) and describes how to map the user.department attribute in Azure through to the security group however this is quite a high level attribute to map to security groups. In my experience (like ADFS) the best attribute to map through to the SCP security groups is the AD groups themselves. So, this blog post carries on from the 2nd post from Murali.

So, how can this be done I hear you ask! OK…

There are multiple tasks involved in making this happen including:

• Setting up of the objectid claim in Azure
• Mapping of objectids to each SCP group

Each of these will now be covered in more detail.

Including Objectid claim in Azure

The first step in making this happen is to make sure Azure is sending the groups across to SCP – as an assertion attribute. To do this you need to choose the application (SCP subaccount identifier) and navigate to the User Attributes and Claims section.

Figure:3 – Azure application configuration – User Attributes & Claims

Notice that the claim identifier is different to the emailaddress, givenname and other claims which are typically identified with the 2005/05 prefix. The objectid is in the 2008/06 prefix range.

This claim needs to be assigned a value of user.groups however there needs to be additional settings made so click through to the claim’s detail settings page.

Users typically are assigned to multiple groups so it makes sense in these settings to send through [All groups]. Make sure that the Source attribute selected is Group ID. You can see some of these settings below.

Figure:4 – Azure application configuration – Objectid claim detailed settings

Once this is done the objectid’s will come through after the user has logged in. If you perform a SAML trace using various Chrome extensions you can see them coming through as the below diagram shows.

Figure:5 – SAML trace showing Objectids coming through

These still need to be mapped to SAP Cloud Platform groups, so this is what we will do now.

Mapping of ObjectIds to SCP Groups

The second step is to map these objectids to each SCP group. This takes place in the Groups tab of the Trust settings area in SAP Cloud Platform.

First navigate to the Trust settings, then click through to the Azure AD identity provider from within the Application identity provider tab as shown below.

Figure:6 – Identity Provider from Trust settings

When you click through you will arrive at the General tab typically but for the objectid mapping you will need to navigate to the Groups tab – as shown below.

Figure:7– Subaccount Trust Settings – Assertion Group Mappings

The above diagram shows the mapping of SCP groups -> field Group on left hand side to the objectid – on the right hand side. In between the full URL of the objectid mapping is maintained. Make sure you also select [regular expression] as the operator and of course make sure the mapping rules is maintained with the objectid URL.

http://schemas.microsoft.com/ws/2008/06/identity/claims/objectid

Once this is done hit the Save button and your mapping will be kept.

Notice though in the above table there are no English names being mapped they are specifically the objectids coming from Azure AD so it does make it more tricky than if a straight ADFS identity provider was connected.

When the users next log in they will be able to see the tiles connected to the SCP groups and have access to the roles as assigned to those groups.

Hopefully you have success in this space and thanks once again for reading. Feel free to Like or comment!