Add AD FS as a SAML identity provider using custom policies in Azure Active Directory B2C

Article
10/14/2024

Before you begin, use the Choose a policy type selector at the top of this page to choose the type of policy you’re setting up. Azure Active Directory B2C offers two methods to define how users interact with your applications: through predefined user flows or through fully configurable custom policies. The steps required in this article are different for each method.

This feature is available only for custom policies. For setup steps, select Custom policy in the preceding selector.

Note

In Azure Active Directory B2C, custom policies are designed primarily to address complex scenarios. For most scenarios, we recommend that you use built-in user flows. If you've not done so, learn about custom policy starter pack in Get started with custom policies in Active Directory B2C.

This article shows you how to enable sign-in for an AD FS user account by using custom policies in Azure Active Directory B2C (Azure AD B2C). You enable sign-in by adding a SAML identity provider to a custom policy.

Prerequisites

Complete the steps in Get started with custom policies in Active Directory B2C. This tutorial guides you how to update custom policy files to use your Azure AD B2C tenant configuration.
If you haven't registered a web app, register one by using the steps in register a web application.

Create a self-signed certificate

If you don't already have a certificate, you can use a self-signed certificate. A self-signed certificate is a security certificate that is not signed by a certificate authority (CA) and doesn't provide the security guarantees of a certificate signed by a CA.

Windows
macOS

On Windows, use the New-SelfSignedCertificate cmdlet in PowerShell to generate a certificate.

Run the following PowerShell command to generate a self-signed certificate. Modify the -Subject argument as appropriate for your application and Azure AD B2C tenant name such as contosowebapp.contoso.partner.onmschina.cn. You can also adjust the -NotAfter date to specify a different expiration for the certificate.
```
New-SelfSignedCertificate `
    -KeyExportPolicy Exportable `
    -Subject "CN=yourappname.yourtenant.partner.onmschina.cn" `
    -KeyAlgorithm RSA `
    -KeyLength 2048 `
    -KeyUsage DigitalSignature `
    -NotAfter (Get-Date).AddMonths(12) `
    -CertStoreLocation "Cert:\CurrentUser\My"
```
On Windows computer, search for and select Manage user certificates
Under Certificates - Current User, select Personal > Certificates>yourappname.yourtenant.partner.onmschina.cn.
Select the certificate, and then select Action > All Tasks > Export.
Select Next > Yes, export the private key > Next.
Accept the defaults for Export File Format, and then select Next.
Enable Password option, enter a password for the certificate, and then select Next.
To specify a location to save your certificate, select Browse and navigate to a directory of your choice.
On the Save As window, enter a File name, and then select Save.
Select Next>Finish.

For Azure AD B2C to accept the .pfx file password, the password must be encrypted with the TripleDES-SHA1 option in the Windows Certificate Store Export utility, as opposed to AES256-SHA256.

Create a policy key

You need to store your certificate in your Azure AD B2C tenant.

Sign in to the Azure portal.
If you have access to multiple tenants, select the Settings icon in the top menu to switch to your Azure AD B2C tenant from the Directories + subscriptions menu.
Choose All services in the top-left corner of the Azure portal, and then search for and select Azure AD B2C.
On the Overview page, select Identity Experience Framework.
Select Policy Keys and then select Add.
For Options, choose Upload.
Enter a Name for the policy key. For example, SAMLSigningCert. The prefix B2C_1A_ is added automatically to the name of your key.
Browse to and select your certificate .pfx file with the private key.
Click Create.

Add a claims provider

If you want users to sign in using an AD FS account, you need to define the account as a claims provider that Azure AD B2C can communicate with through an endpoint. The endpoint provides a set of claims that are used by Azure AD B2C to verify that a specific user has authenticated.

You can define an AD FS account as a claims provider by adding it to the ClaimsProviders element in the extension file of your policy. For more information, see define a SAML identity provider.

Open the TrustFrameworkExtensions.xml.
Find the ClaimsProviders element. If it does not exist, add it under the root element.

Add a new ClaimsProvider as follows:

<ClaimsProvider>
  <Domain>contoso.com</Domain>
  <DisplayName>Contoso</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="Contoso-SAML2">
      <DisplayName>Contoso</DisplayName>
      <Description>Login with your AD FS account</Description>
      <Protocol Name="SAML2"/>
      <Metadata>
        <Item Key="WantsEncryptedAssertions">false</Item>
        <Item Key="PartnerEntity">https://your-AD-FS-domain/federationmetadata/2007-06/federationmetadata.xml</Item>
      </Metadata>
      <CryptographicKeys>
        <Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_SAMLSigningCert"/>
      </CryptographicKeys>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="userPrincipalName" />
        <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name"/>
        <OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="family_name"/>
        <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email"/>
        <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name"/>
        <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="contoso.com" />
        <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication"/>
      </OutputClaims>
      <OutputClaimsTransformations>
        <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName"/>
        <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName"/>
        <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId"/>
        <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId"/>
      </OutputClaimsTransformations>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-idp"/>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Replace your-AD-FS-domain with the name of your AD FS domain and replace the value of the identityProvider output claim with your DNS (Arbitrary value that indicates your domain).

Locate the <ClaimsProviders> section and add the following XML snippet. If your policy already contains the SM-Saml-idp technical profile, skip to the next step. For more information, see single sign-on session management.

<ClaimsProvider>
  <DisplayName>Session Management</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="SM-Saml-idp">
      <DisplayName>Session Management Provider</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <Item Key="IncludeSessionIndex">false</Item>
        <Item Key="RegisterServiceProviders">false</Item>
      </Metadata>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Save the file.

Add a user journey

At this point, the identity provider has been set up, but it's not yet available in any of the sign-in pages. If you don't have your own custom user journey, create a duplicate of an existing template user journey, otherwise continue to the next step.

Open the TrustFrameworkBase.xml file from the starter pack.
Find and copy the entire contents of the UserJourney element that includes Id="SignUpOrSignIn".
Open the TrustFrameworkExtensions.xml and find the UserJourneys element. If the element doesn't exist, add one.
Paste the entire content of the UserJourney element that you copied as a child of the UserJourneys element.
Rename the Id of the user journey. For example, Id="CustomSignUpSignIn".

Add the identity provider to a user journey

Now that you have a user journey, add the new identity provider to the user journey. You first add a sign-in button, then link the button to an action. The action is the technical profile you created earlier.

Find the orchestration step element that includes Type="CombinedSignInAndSignUp", or Type="ClaimsProviderSelection" in the user journey. It's usually the first orchestration step. The ClaimsProviderSelections element contains a list of identity providers that a user can sign in with. The order of the elements controls the order of the sign-in buttons presented to the user. Add a ClaimsProviderSelection XML element. Set the value of TargetClaimsExchangeId to a friendly name.
In the next orchestration step, add a ClaimsExchange element. Set the Id to the value of the target claims exchange Id. Update the value of TechnicalProfileReferenceId to the Id of the technical profile you created earlier.

The following XML demonstrates the first two orchestration steps of a user journey with the identity provider:

<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
  <ClaimsProviderSelections>
    ...
    <ClaimsProviderSelection TargetClaimsExchangeId="ContosoExchange" />
  </ClaimsProviderSelections>
  ...
</OrchestrationStep>

<OrchestrationStep Order="2" Type="ClaimsExchange">
  ...
  <ClaimsExchanges>
    <ClaimsExchange Id="ContosoExchange" TechnicalProfileReferenceId="Contoso-SAML2" />
  </ClaimsExchanges>
</OrchestrationStep>

Configure the relying party policy

The relying party policy, for example SignUpSignIn.xml, specifies the user journey which Azure AD B2C will execute. Find the DefaultUserJourney element within relying party. Update the ReferenceId to match the user journey ID, in which you added the identity provider.

In the following example, for the CustomSignUpSignIn user journey, the ReferenceId is set to CustomSignUpSignIn:

<RelyingParty>
  <DefaultUserJourney ReferenceId="CustomSignUpSignIn" />
  ...
</RelyingParty>

Upload the custom policy

Sign in to the Azure portal.
Select the Directory + Subscription icon in the portal toolbar, and then select the directory that contains your Azure AD B2C tenant.
In the Azure portal, search for and select Azure AD B2C.
Under Policies, select Identity Experience Framework.
Select Upload Custom Policy, and then upload the two policy files that you changed, in the following order: the extension policy, for example TrustFrameworkExtensions.xml, then the relying party policy, such as SignUpSignIn.xml.

Configure an AD FS relying party trust

To use AD FS as an identity provider in Azure AD B2C, you need to create an AD FS Relying Party Trust with the Azure AD B2C SAML metadata. The following example shows a URL address to the SAML metadata of an Azure AD B2C technical profile:

https://your-tenant-name.b2clogin.cn/your-tenant-name.partner.onmschina.cn/your-policy/samlp/metadata?idptp=your-technical-profile

Replace the following values:

your-tenant-name with your tenant name, such as your-tenant.partner.onmschina.cn.
your-policy with your policy name. For example, B2C_1A_signup_signin_adfs.
your-technical-profile with the name of your SAML identity provider technical profile. For example, Contoso-SAML2.

Open a browser and navigate to the URL. Make sure you type the correct URL and that you have access to the XML metadata file. To add a new relying party trust by using the AD FS Management snap-in and manually configure the settings, perform the following procedure on a federation server. Membership in Administrators or equivalent on the local computer is the minimum required to complete this procedure.

In Server Manager, select Tools, and then select AD FS Management.
Select Add Relying Party Trust.
On the Welcome page, choose Claims aware, and then select Start.
On the Select Data Source page, select Import data about the relying party publish online or on a local network, provide your Azure AD B2C metadata URL, and then select Next.
On the Specify Display Name page, enter a Display name, under Notes, enter a description for this relying party trust, and then select Next.
On the Choose Access Control Policy page, select a policy, and then select Next.
On the Ready to Add Trust page, review the settings, and then select Next to save your relying party trust information.
On the Finish page, select Close, this action automatically displays the Edit Claim Rules dialog box.
Select Add Rule.
In Claim rule template, select Send LDAP attributes as claims.
Provide a Claim rule name. For the Attribute store, select Select Active Directory, add the following claims, then select Finish and OK.

LDAP attribute Outgoing claim type

User-Principal-Name userPrincipalName

Surname family_name

Given-Name given_name

E-Mail-Address email

Display-Name name

Note some of the names will not display in the outgoing claim type dropdown. You need to manually type them in. (The dropdown is editable).
Based on your certificate type, you may need to set the HASH algorithm. On the relying party trust (B2C Demo) properties window, select the Advanced tab and change the Secure hash algorithm to SHA-256, and select Ok.
In Server Manager, select Tools, and then select AD FS Management.
Select the relying party trust you created, select Update from Federation Metadata, and then select Update.

LDAP attribute	Outgoing claim type
User-Principal-Name	userPrincipalName
Surname	family_name
Given-Name	given_name
E-Mail-Address	email
Display-Name	name

Test your custom policy

Sign in to the Azure portal.
If you have access to multiple tenants, select the Settings icon in the top menu to switch to your Azure AD B2C tenant from the Directories + subscriptions menu.
In the Azure portal, search for and select Azure AD B2C.
Under Policies, select Identity Experience Framework
Select your relying party policy, for example B2C_1A_signup_signin.
For Application, select a web application that you previously registered. The Reply URL should show https://jwt.ms.
Select the Run now button.
From the sign-up or sign-in page, select Contoso AD FS to sign in with Contoso AD FS identity provider.

If the sign-in process is successful, your browser is redirected to https://jwt.ms, which displays the contents of the token returned by Azure AD B2C.

Troubleshooting AD FS service

AD FS is configured to use the Windows application log. If you experience challenges setting up AD FS as a SAML identity provider using custom policies in Azure AD B2C, you may want to check the AD FS event log:

On the Windows Search bar, type Event Viewer, and then select the Event Viewer desktop app.
To view the log of a different computer, right-click Event Viewer (local). Select Connect to another computer, and fill in the fields to complete the Select Computer dialog box.
In Event Viewer, open the Applications and Services Logs.
Select AD FS, then select Admin.
To view more information about an event, double-click the event.

SAML request is not signed with expected signature algorithm event

This error indicates that the SAML request sent by Azure AD B2C is not signed with the expected signature algorithm configured in AD FS. For example, the SAML request is signed with the signature algorithm rsa-sha256, but the expected signature algorithm is rsa-sha1. To fix this issue, make sure both Azure AD B2C and AD FS are configured with the same signature algorithm.

Option 1: Set the signature algorithm in Azure AD B2C

You can configure how to sign the SAML request in Azure AD B2C. The XmlSignatureAlgorithm metadata controls the value of the SigAlg parameter (query string or post parameter) in the SAML request. The following example configures Azure AD B2C to use the rsa-sha256 signature algorithm.

<Metadata>
  <Item Key="WantsEncryptedAssertions">false</Item>
  <Item Key="PartnerEntity">https://your-AD-FS-domain/federationmetadata/2007-06/federationmetadata.xml</Item>
  <Item Key="XmlSignatureAlgorithm">Sha256</Item>
</Metadata>

Option 2: Set the signature algorithm in AD FS

Alternatively, you can configure the expected SAML request signature algorithm in AD FS.

In Server Manager, select Tools, and then select AD FS Management.
Select the Relying Party Trust you created earlier.
Select Properties, then select Advance
Configure the Secure hash algorithm, and select OK to save the changes.

The HTTP-Redirect request does not contain the required parameter 'Signature' for a signed request (AADB2C90168)

Option 1: Set the ResponsesSigned to false in Azure AD B2C

You can disable the requirement of signed message in Azure AD B2C. The following example configures Azure AD B2C to not require 'Signature' parameter for the signed request.

<Metadata>
  <Item Key="WantsEncryptedAssertions">false</Item>
  <Item Key="PartnerEntity">https://your-AD-FS-domain/federationmetadata/2007-06/federationmetadata.xml</Item>
  <Item Key="ResponsesSigned">false</Item>
</Metadata>

Option 2: Set the relying party in AD FS to sign both Message and Assertion

Alternatively, you can configure the relying party in AD FS as mentioned below:

Open PowerShell as Administrator and run Set-AdfsRelyingPartyTrust -TargetName <RP Name> -SamlResponseSignature MessageAndAssertion cmdlet to sign both Message and Assertion.
Run Set-AdfsRelyingPartyTrust -TargetName <RP Name> and confirm the SamlResponseSignature property is set as MessageAndAssertion.