How to Federate a SAML Application with Azure AD B2C

User flows in Azure Active Directory (AD) B2C don’t currently support SAML applications. Therefore, you must use custom policies for those integrations. This makes the configuration more complex for those who are unfamiliar with custom policy configurations. In this blog, I’ll show you how to configure a service provider-initiated SAML application to integrate with Azure AD B2C.

SAML Configuration

Configuring a SAML application requires the use of a custom policy. While custom policies are more complex to configure compared to user flows, they can be customized to provide functionality that’s otherwise not possible. If you haven’t worked with custom policies in Azure AD B2C or you need a refresher, check out our blog post on them.

Creation of a Policy Key

Each SAML application to be integrated requires certificates for signing and, optionally, encrypting the assertion. Azure AD B2C makes this process more hands-on and requires you to upload a certificate manually. Once created, the certificate must be exported—including the private key—and uploaded into a policy key within the Azure AD B2C Identity Experience Framework (IEF).

  1. On the Overview page, select Identity Experience Framework.
  2. Select Policy Keys and then select Add.
  3. For Options, choose Upload.
  4. Enter a Name for the policy key. The prefix B2C_1A_ is added automatically to the key name when it’s created.
  5. Select your certificate .pfx file that includes the private key.
  6. Click Create.

Creation of the Technical Profile

The technical profile generally gets added to the TrustFrameworkExtensions.xml file in a simple Azure AD B2C implementation; however, it can be located elsewhere in a highly complex architecture. Follow the steps below to begin customizing the sample to issue SAML assertions.

  1. Update the DisplayName to modify the name of the application.
  2. Update the TechnicalProfile Id to modify the name of the application.
  3. Update the DisplayName under TechnicalProfile to modify the name of the application.
  4. Update the SamlAssertionSigning and SamlMessageSigning StorageReferenceIds to match the names used when creating the policy keys earlier.
    <ClaimsProvider>
      <DisplayName>SPSAMLApp</DisplayName>
      <TechnicalProfiles>

        <!-- SAML Token Issuer technical profile -->
        <TechnicalProfile Id="SPSAMLApp">
          <DisplayName>Sales Application</DisplayName>
          <Protocol Name="SAML2"/>
          <OutputTokenFormat>SAML2</OutputTokenFormat>
          <CryptographicKeys>
            <Key Id="SamlAssertionSigning" StorageReferenceId="B2C_1A_SPSAMLApp"/>
            <Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_SPSAMLApp"/>
          </CryptographicKeys>
          <InputClaims/>
          <OutputClaims/>
          <UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-issuer"/>
        </TechnicalProfile>
        
<!-- Session management technical profile for SAML based tokens -->
        <TechnicalProfile Id="SM-Saml-issuer">
          <DisplayName>Session Management Provider</DisplayName>
          <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
Code language: HTML, XML (xml)

Creation of a New Relying Party Profile for the Application

The next step is creating the relying party profile dedicated for this application. Below is a sample that can be modified to your needs, which I’ll call SPSAMLApp.xml.

  1. Update the TenantId to the correct Azure B2C directory domain name.
  2. Update the PolicyId to a unique name for the specific application.
  3. Update the PublicPolicyUri to include the correct Azure B2C directory domain name.
  4. Update the TenantId element under BasePolicy with the same tenant domain name.
  5. Update the PolicyID element under BasePolicy with the name of the policy to inherit from; this is usually the TrustFrameworkExtensions policy.
  6. Update the UserJourney Id to the UserJourney being used from the TrustFrameworkExtensions.xml file.
  7. Update the value of Order and CpimIssuerTechnicalProfileReferenceId under OrchestrationStep #8 to match the values used in the TrustFrameworkExtensions.xml file.
  8. Update the ReferenceID for the DefaultUserJourney under the RelyingParty and Metadata elements to the UserJourney being used from the TrustFrameworkExtensions.xml file.
  9. Update the IssuerUri to substitute your directory name and PolicyId for this application.
  10. Lastly, you may need to adjust the OutputClaims and SubjectNaming format type to match the requirements of the SAML application you are federating with.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TrustFrameworkPolicy
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06"
  PolicySchemaVersion="0.3.0.0"
  TenantId="myB2Cdirectory.onmicrosoft.com"
  PolicyId="B2C_1A_SPSAMLApp"
  PublicPolicyUri="http://myB2Cdirectory.onmicrosoft.com/B2C_1A_SPSAMLApp">

  <BasePolicy>
    <TenantId>myB2Cdirectory.onmicrosoft.com</TenantId>
    <PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId>
  </BasePolicy>

  <UserJourneys>
    <UserJourney Id="SAMLSignin">
      <OrchestrationSteps>
        <OrchestrationStep Order="8" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="SPSAMLApp">
        </OrchestrationStep>
      </OrchestrationSteps>
    </UserJourney>
  </UserJourneys>

  <RelyingParty>
    <DefaultUserJourney ReferenceId="SAMLSignin" />
    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2"/>
      <Metadata>
        <Item Key="IssuerUri">https://myB2Cdirectory.b2clogin.com/myB2Cdirectory.onmicrosoft.com/B2C_1A_SPSAMLApp</Item>
      </Metadata>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="displayName" />
        <OutputClaim ClaimTypeReferenceId="givenName" />
        <OutputClaim ClaimTypeReferenceId="surname" />
        <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="" />
        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/>
        <OutputClaim ClaimTypeReferenceId="email" />
      </OutputClaims>
      <SubjectNamingInfo ClaimType="email" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" ExcludeAsClaim="true"/>
    </TechnicalProfile>
  </RelyingParty>

</TrustFrameworkPolicy>Code language: HTML, XML (xml)

Upload the New Policies

The last step is to upload the modified or new policies. From the Azure AD B2C directory, perform the following tasks:

  1. Under Policies, select Identity Experience Framework
  2. Select Upload Custom Policy in the following order:
    • TrustFrameworkBase.xml
    • TrustFrameworkExtensions.xml
    • SPSAMLApp.xml

View the SAML Application’s Metadata

After policies have been uploaded, Azure B2C generates the IdP SAML metadata document. This can be accessed at https://<directory-name>.b2clogin.com/<directory-name>.onmicrosoft.com/<policy-name>/samlp/metadata.

  1. Replace <tenant-name> with your B2C directory name.
  2. Replace <policy-name> with the name of the policy.
https://myB2Cdirectory.b2clogin.com/myB2Cdirectory.onmicrosoft.com/B2C_1A_SPSAMLApp/samlp/metadataCode language: JavaScript (javascript)

Verify that you can access the SAML metadata before continuing; this is also what you can provide to the application vendor for their configuration.

Register the SAML Application in Azure AD B2C

  1. Under App registrations, select New registration
  2. Enter a Name for the application: SPSAMLApp in this case
  3. Under Supported account types, select Accounts in this organizational directory only
  4. Under Redirect URI, select Web and then enter https://localhost
  5. Allow Grant admin consent to openid and offline_access permissions
  6. Select Register
  7. Select Manifest
    • Edit identifierUris, adding the application’s entity ID / issuerURI
    • If the application provides a publicly accessible URL for their metadata, edit samlMetadataUrl to add their URL
    • If the application does not provide a URL for their metadata, edit replyUrlsWithType and add the AssertionConsumerServiceUrl (ACS) for the application
  8. Save the Manifest

Test with the SAML Test App

Microsoft has a SAML test application (https://samltestapp2.azurewebsites.net/SP) that you can use to test your configuration. When you go to the SAML test application, you will need your B2C tenant name, custom policy name, and issuerURI (use https://samltestapp2.azurewebsites.net). Once those values are entered, click Login. If configured properly, you’ll be redirected to your Azure AD B2C login page to authenticate.

Conclusion

Configuring Azure AD B2C with custom policies can be very complicated, and clients often call us to assist with modifications. The experts at Ravenswood Technology Group are available to help. Contact our team to see how we can assist with your project.

[RELEVANT BLOG CONTENT]

6 Tips to Harden Your Windows LAPS Deployment

In a previous blog post, we covered how to migrate to Windows Local Administrator Password Solution (LAPS). With Windows LAPS deployments gaining traction, it’s important

Migrating to Windows LAPS

Windows Local Administrator Password Solution (LAPS), now integrated into the OS, is the replacement for Microsoft LAPS, which was a separate installation. Windows LAPS is

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.