Talk to an expert

Connect with a Ravenswood expert using the form below.

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.

Partner with Microsoft experts you can trust

If it’s time to take that first step toward leveling up your organization’s security, get in touch with Ravenswood to start the conversation. 

Get in Touch
Picture of Adam Zucker

Adam Zucker

Adam Zucker specializes in enterprise mobility and identity management. He works with customers to develop strategic and long-term solutions, planning and implementing projects using Microsoft IAM and enterprise mobility tools. Adam’s well-rounded skill set allows him to recommend solutions that meet both big picture and day-to-day needs for businesses.
View All Posts

[RELEVANT BLOG CONTENT]

How to Use Dynamic Membership Rules in Entra ID

Many organizations control access to internal systems by simply relying on whether or not an account is enabled. However, users often change roles throughout their careers within a single organization. [...]

Active Directory Design Overview

Active Directory (AD) is a cornerstone of IT infrastructure for many organizations, providing essential services for managing and securing resources. This guide will take you through the essentials of Active [...]

Is the Active Directory Red Forest dead? Time to Shift to the Enterprise Access Model?

A red forest is designed to increase the security of Windows Server Active Directory Domain Services (AD DS) by protecting privileged credentials from compromise. Privileged identities, such as members of [...]

Implementing Passwordless Authentication with Microsoft Authenticator Phone Sign-In

Since the introduction of passwords as the standard for computer authentication, there haven’t been many changes beyond enforcing password length and character complexity requirements and the introduction of two-factor authentication [...]

Active Directory Cleanup: Enhancing Security and Performance

Active Directory (AD) is a hierarchical directory service that enables you to manage users, groups, access control, and policy administration. AD is used to secure network resources, user accounts, and [...]

Boost Security and Transform Conditional Access with Entra ID’s Authentication Strengths

Microsoft Entra ID is a critical component of modern identity and access management. It acts as a front door to your applications and data by providing secure and auditable identity [...]

Ravenswood Technology Group is based in Chicago, IL but with customers around the world. We help companies, universities, and other organizations with less than 100 employees to over 500,000 build secure, hybrid infrastructure that enable their users to work from anywhere. 

[What we do]

[About Us]

[Recent Blog Posts]

[Expertise]

[Get in Touch]

Linkedin Twitter

© Ravenswood Technology Group, LLC

Privacy Settings