Skip to Content
Technical Articles
Author's profile photo Phil Cooley

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!

Assigned tags

      7 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Murali Shanmugham
      Murali Shanmugham

      Thanks for sharing.

      Author's profile photo Tobias Harmes
      Tobias Harmes

      Hi Phil, thanks for sharing this. Is there a specific reason, why you changed the name of the group claim for Azure AD to objectID? If I select as source "Groups ID" without changing the defaults, a groups-claim of namespace "http://schemas.microsoft.com/ws/2008/06/identity/claims/groups" is added to the saml response including all the object IDs of the groups of the user.

       

      Author's profile photo Phil Cooley
      Phil Cooley
      Blog Post Author

      Hi Tobias Harmes I was not really responsible for the Azure configuration nor had access to it however the default settings did not seem to work for me. Good to know though that the default settings work. Maybe you could add in some screenshots to show others what alternative configuration would look like?

      Thanks

      Phil

      Author's profile photo Carsten Olt
      Carsten Olt

       

      Yes, I can confirm it works with the default namespace as mentioned by Tobi 😉

      Cheers Colt

      Author's profile photo Phil Cooley
      Phil Cooley
      Blog Post Author

      Thanks for confirming this Carsten Olt – looks good however overall it would be better if a name descriptor could be used instead of the object ID. This would make support and maintenance alot easier. I still don’t understand why these names cannot be sent through rather than the meaningless object ID.

      Holger Bruchelt – is there any update on this? I recall we discussed this last year on whether this was possible.

      thanks

      Phil

      Author's profile photo Carsten Olt
      Carsten Olt

      Agreed

      Author's profile photo Carsten Olt
      Carsten Olt

      UPDATE:

      It is possible to use a name descriptor instead of the object ID for group claims. However, there are some things to consider:

      • Groups identified by their Azure Active Directory object identifier (OID) attribute
      • Groups identified by sAMAccountName or GroupSID attributes for Active Directory (AD) synchronized groups and users

      Limitation: sAMAccountName group names are available on Group objects synced from Active Directory (AD Connect). They aren't available on groups created in Azure Active Directory (!)

      • When using group membership for in-application authorization purposes it is preferable to use the Group ObjectID. The Group ObjectID is immutable and unique in Azure Active Directory and available for all groups.
      • If using the on-premises group sAMAccountName for authorization, use domain qualified names; there’s less chance of names clashing. sAMAccountName may be unique within an Active Directory domain, but if more than one Active Directory domain is synchronized with an Azure Active Directory tenant there is a possibility for more than one group to have the same name.

      More Information can be found here

      Cheers Colt