Identity federation between Azure AD B2C and SAP Cloud Identity Services using custom policies

SAP Cloud Identity Services, Identity Authentication (IAS), can act as an identity provider to authenticate users managed in its own local user store, or delegate authentication to an existing corporate identity provider and directory. Many companies choose the latter option to setup identity federation between their tenants in IAS and Microsoft Azure Active Directory (Azure AD) to offer single sign-on (SSO) to corporate users and allow them to authenticate with their known credentials. Detailled setup instructions for Azure AD are well covered by SAP‘s and Microsoft‘s product documentation and related blog posts on this topic.

Azure Active Directory B2C (Azure AD B2C) is Microsoft’s customer identity access management (CIAM) solution. Although it is built on the same underlying technology, Azure AD B2C is a seperate service from Azure AD with different capabilities enabling customers to use their preferred social identity, enterprise identity, or local accounts for single sign-on (SSO). With an Azure AD B2C tenant, the entire user experience for registration (sign-up), sign-in and profile editing can be highly customized with the Identity Experience Framework (IEF). IEF contains a set of predefined and configurable user flows for the most common customization tasks. For more advanced and detailed configuration, IEF offers custom policies. Custom policies are a set of XML files you upload to your Azure AD B2C tenant to define the behavior of your Azure AD B2C tenant.

To configure the federation scenario from this blog, start by following the steps described in Arpit’s blog post to create a setup similar as illustrated in figure 1:

Fig. 1: IAS Corporate Identity Provider scenario with Azure AD B2C

1. The user accesses a business application on SAP BTP that starts the authentication flow with the Open ID Connect (OIDC) protocol in the IAS tenant
2. Based on the application settings in IAS, the user is delegated to the Azure AD B2C tenant that is registered as a trusted corporated identity provider
3. The user can now choose to either login with their local user account credentials in the Azure AD B2C tenant, or to login with a social identity provider such as Facebook or LinkedIn. Upon successful authentication, Azure AD B2C issues an OAuth access token and id token and sends them back to the IAS tenant
4. The IAS tenant generates a new access token and id token based on the content of the tokens received from the Azure AD B2C tenant in the previous step, and sends them back to the business application. The user is now authenticated at the application.

Identity federation with built-in user flows

Let’s inspect the access token issued by Azure AD B2C in step 3 of figure 1 using the built-in Sign-up and sign-in user flow with the following exercise:

Step	Description	Screenshot
1.1	Login to your Azure AD B2C tenant and select User flows from the navigation menu. Select a flow of type Sign up and sign in from the list. Note: If the list is empty, click on + New User flow to create a new flow of type Sign up and sign in for your tenant.
1.2	Click on Run user flow to test it.
1.3	Select the IEF Test App application. This application has been registered with the IEF Setup App as described in Arpit’s blog. Click Run user flow.
1.4	Sign-in to your Azure AD B2C tenant with a local user account. Note: If you haven’t created a local user account yet, click on the Sign up now link.
1.5	Upon successful login, the IEF Test App redirects your browser to the jwt.ms test app which decodes the access token issued by the Azure AD B2C tenant.

With the built-in user flow, the emails attribute (or “claim“) is a multi-valued array of the email addresses registered for the user in the Azure AD B2C tenant. IAS is still able to login the user based on this token. It will use the unique identifier value (“3a4d...“) found in the subject claim (sub)  and transform the multi-valued emails claim into a single-valued field. The access token generated by IAS and returned in step 4 (fig. 1) to the business app looks as follows:

Fig. 2: Access token generated by IAS based on the access token from the Sign-up and sign-in user flow

The unique identifier in the sub claim is a pairwise subject identifier as defined by OpenID Connect Core specification. In Azure AD and Azure AD B2C, the subject identifier is always unique to a particular application in the tenant (here the IAS tenant’s application registration, see fig. 1). If a single user signs into two different applications using two different application (client) IDs, those applications will receive two different values for the sub claim. This may be problematic for business application that are not capable of managing multiple (subject) identifiers per user.

Identity federation with custom policies

Therefore we will take a look in the next step at the configuration options with custom policies from the Starter Pack to use a stable identifier (such as the user’s email address) for mapping the users from Azure AD B2C. Further samples of custom policies for several enhanced Azure AD B2C customizations can be found in this code repository on GitHub.

Step	Description	Screenshot
2.1	Select Identity Experience Framework from the navigation menu.
2.2	Select the B2C_1A_SIGNUP_SIGNIN custom policy from the list. Note: If the list is empty, install the custom policies from the Starter Pack using the IEF Setup App.
2.3	Select the IEF Test App application. This application has been registered with the IEF Setup App as described in Arpit’s blog. Click Run now.
2.4	Sign-in to your Azure AD B2C tenant with a local user account. Note: If you haven’t created a local user account yet, click on the Sign up now link.
2.5	Upon successful login, the IEF Test App redirects your browser to the jwt.ms test app which decodes and shows the access token issued by the Azure AD B2C tenant.

Using the Starter Pack’s custom policies as-is (i.e. without editing them) results in a token issued by IAS with the subject claim (“sub“) set to the same pairwise identifier (“3a4d...“) as before with the built-in user flow. The multi-valued emails claim is no longer present in the IAS token.

Fig. 3: Access token generated by IAS from the access token using the Starter Pack’s Sign-up and sign-in custom policy

Selecting a built-in user flow or a custom policy can be configured in the corporate identity provider settings of the IAS tenant. The Discovery URL field in the OpenID Connect Configuration contains the URL to the Azure AD B2C tenant’s metadata document (https://<tenantid>.b2clogin.com/<tenantid>.onmicrosoft.com/<policy-name>/v2.0/.well-known/openid-configuration) which has a policy-specific path (see figure 4).

Fig. 4: Policy-specific metadata URL for the Azure AD B2C corporate identity provider in IAS tenant

To federate the user’s local account in Azure AD B2C with the local account in IAS, a stable identifier such as the user’s email address can be used. IAS can be configured to use the email claim (not plural “emails“) from the token returned by the corporate identity provider as the subject identifier for the IAS-authenticated user.

If you have installed the Starter Pack policy files with the IEF Setup App and activated the Remove Facebook references checkbox (indicated by a missing Facebook button on the login screen), the following changes of the custom policy for sign-up and sign-in in the Azure AD B2C tenant are required:

Step	Description	Screenshot
2.6	Click Download on the selected B2C_1A_SIGNUP_SIGNIN custom policy.
2.7	Open the downloaded XML file in an editor of your choice. Add the OutputClaim element <OutputClaim ClaimTypeReferenceId="signInNames.emailAddress" PartnerClaimType="email"/> to the <OutputClaims> node between lines 15 and 22. This will add the email address found in the signInNames user attribute of the local user as a claim with the name email to the access token. Save the changes to the file. For more details on the XML elements please refer to the custom policy schema reference.
2.8	Upload the changed custom policy file to your Azure AD B2C tenant. Make sure to activate the checkbox to overwrite the custom policy if it already exists.
2.9	Test the changes to the custom policy file by selecting it from the list. Click Run now.
2.10	Upon successful login inspect the Azure AD B2C-issued token in the jwt.ms test app.It contains a single-valued email claim which can be further processed by the IAS tenant, e.g. to map the incoming token to a local user account.

However, without further changes in the IAS configuration in the corporate identity provider settings, the token issued and sent by IAS to the business application still contains the pairwise identifier in the sub claim (figure 5):

Fig. 5: IAS-issued access token after changing the output claims in the custom policy 

Configure federation and authentication settings in IAS

Step	Description	Screenshot
3.1	Login as the administrator to the IAS tenant’s admin console. Select the corporate identity provider for your Azure AD B2C tenant from the list and edit the Subject Name Identifier settings. Change from the default (None) to E-Mail. Click Save.

With this change in the corporate identity provider configuration, the sub claim in the token (see figure 6) issued by IAS for the business application has the user’s email address set as the value which can be used as a common identifier for the user across both tenants:

Fig. 6: IAS-issued access token after changing the subject identifier of the corporate identity provider 

If you manage your (multi-factor) authentication and access control settings for SAP applications in IAS (and not in your Azure AD B2C tenant), you can enable further federation settings in IAS for the users in your Azure AD B2C.

In this final federation exercise, users selecting a social identity provider (see figure 1) such as Facebook or Twitter to login to the Azure AD B2C tenant should be blocked from accessing any SAP applications in the IAS tenant. The fictitious company in this scenario considers social identity providers as a potential security risk for gaining unauthorized access to corporate data.

Note: The following steps assume that the custom policies from the Starter Pack were installed with the IEF Setup App without activating the Remove Facebook references option.If you did so you can simply re-install the custom policies with the option left disabled. In addition, you have to follow these steps to add Facebook as a social identity provider to your Azure AD B2C tenant for the next exercise.

Step	Description	Screenshot
3.2	Select the Identity Federation settings in IAS of your Azure AD B2C corporate identity provider
3.3	Enable all federation settings (Use Identity Authentication user store, Allow Identity Authentication users only, and Apply Application Configurations).
3.4	From your Azure AD B2C tenant, download the B2C_1A_SIGNUP_SIGNIN custom policy and add line <OutputClaim ClaimTypeReferenceId="authenticationSource" /> to it. This additional claim will inform IAS if the user has authenticated with her local or social account. If the user signed-in with a social identity provider, Azure AD B2C will set the value of this claim to socialIdpAuthentication. Otherwise it is set to localAccountAuthentication. Upload the updated policy file to the Azure AD B2C tenant.
3.5	If you start a test run with the IEF Test App for the updated B2C_1A_SIGNUP_SIGNIN custom policy and login with your social account, you will receive the addition claim with the value socialIdpAuthenticationin the access token issued by Azure AD B2C.
3.6	Select your business application’s registration in the IAS tenant and switch to the Authentication and Access tab. Click on Risk-Based Authentication.
3.7	Create a new rule to deny access based on the additional claim authenticationSource configured in the custom policy. Click Create Rule to add a new rule. Choose Deny for the Action and enter authenticationSource as the corporate attribute name. SetsocialIdpAuthentication for the value to compare against. Click Create, then Save.
3.8	If you now try to login to the business application with any of your social accounts, Azure AD B2C will propagate this authentication context information in the new authenticationSource claim to IAS, which will in turn deny access based on the rule above.

Conclusion

Custom policies in Azure AD B2C and the configuration settings for corporate identity providers in IAS offer a very rich toolset for almost any federation and security requirements. In addition, interoperability between SAP and Microsoft based on open security standards such as OAuth 2.0 and OIDC provide a solid foundation for this and many other scenarios.