Someone asked how to add group membership to the SAML 2.0 assertion from Azure AD to an application such as SAP Analytics Cloud. This would allow seamless single sign-on to SAP Analytics Cloud (SAC). This post documents the steps to sending group membership in the SAML 2.0 tokens from Azure AD to SAP Analytics Cloud (SAC).

Background:

You can pass group membership either as Application Roles or Security Group from Azure AD. Either gets translated into permissions during SAC’s authorization. See here to learn the Pros and Cons of Application Roles and Security Groups.

I chose to send group membership as Application Roles because I need to filter groups. In this case, Groups were sourced from an on-prem AD. Security Groups cannot yet be filtered. Security Groups are restricted. Instead it is much simpler and cleaner to use App Roles. Each user is already assigned to one or more Security Groups (sourced from on-prem). Each Security Group gets assigned to an App Role (in step 4 below). When a user logs in to SAC, Azure AD will emit all the App Roles that the user is indirectly assigned to via Security Groups. Neat! This capability requires Azure AD Premium. You can learn about this capability here

Note: If groups are to be synched from an on-prem AD, AD Connect should be version 1.1.649.0 & above.

I do not have access to SAC. I’m going to use a WS-Federation client application to mimic the SAC client interaction with Azure AD. See optional step 6 for how to setup and configure SAC client application.

Here are the steps:

Create the application in Azure AD

Configure the SAP Analytics Cloud Application in Azure AD

Create Roles for the Application in Azure AD

Assign Security Groups & App Roles to the Application

Customize the claims issued in the SAML tokens

Optional: Configure a sample client for testing

Test and verify

1. Create the application in Azure AD

The application object in Azure AD is a representation of SAP Analytics Cloud. This object is going to control authentication and issue SAML tokens. Azure AD provides a few options to register the application:

Now you have created a Service Principal and an Application Object. The Service Principal is accessible through: Portal > Enterprise Application. The Application Object is accessible through: Portal > App Registration. Be sure to not use the Application Object created under Portal > App Registration(Preview) because SAML 2.0 and WS-Federation protocols are not yet supported under the V2.0 endpoint (will be available soon). See here to learn more.

2. Configure the SAP Analytics Cloud Application in Azure AD

Now that you have an application object to represent SAP Analytics Cloud in Azure AD, lets configure it:

4. Assign Security Groups & App Roles to the Application

This is where we assign on-prem sourced Security Groups to the App Roles created for the Application. It allows us to filter and send only required Security Group names as App roles to SAC.

In this demo, I have two pre-existing Security Groups: SecurityGroup1 and SecurityGroup2 that are sourced from on-prem. We are going to assign these SecurityGroups to the Application and give them an App Role.

Go to: Portal > Enterprise Application
Select the application Object
Under Users and Groups, assign security groups to application roles
Set the Roles for those assignments to be App Roles. Note, there is a 1:1 mapping between Security Groups and Application Roles

5. Customize the claim name issued in the SAML tokens

SAP Analytic Cloud client looks for the name at the end of the URL formatted claim name, not the whole URL – so set the claim name to a friendly name. This example sets it to Name=“MyAppRoles”.

6.2 Clone the repo

6.3 Configure web.config

Configure the following in the application’s Web.config file:

ida:Wtrealm key set to the App ID URI.
App ID URI is auto generated in Step 1 when you register the application in Azure AD. The App ID URI is a URI that uniquely identifies the application.
Find the App ID URI under: Portal > App Registration > Settings > Properties > App ID URI and set it to the ida:Wtrealm key in web.config

6.3 Configure the token signature in startup.auth.cs

Sign in will fail if the token signature can’t be verified. That is because Enterprise App config creates an App specific signing key, but the App is picking up AAD’s global cert from the tenant metadata by default.

To solve for this look for this line in startup.auth.cs and add the ?appid= to the federationmetadata URL. That will enable it to find the app specific signing cert.