AZURE AD B2C CUSTOM POLICIES (SERIES)

STARTER PACK RELYING PARTY FILES

TLDR;

The post shows how to configure ' Relying party files' such as SignUpOrSignin.xml and PasswordReset.xml with output claims that you've added to the 'Extensions file'. It also shows how to configure AADB2C for testing resulting user flows.

If you just want to see the code, check out the SignUpOrSignin.xml file and the PasswordReset.xml file in the source code repository.

Introduction

The custom policies starter pack (ref. 1) already comes with 'Relying party files' for the most common user interaction with the Azure AD B2C (AADB2C) identity management system . In this post I will show the minor changes I have made to the following files:

Prerequisites

If you haven't done so already, go read my other posts:

SIGNUPORSIGNIN.XML

One of the requirements for my application is to display a user's profile information after a successful login.

In the relying party file, I have added two output claims in addition to the ones already defined:

<OutputClaim ClaimTypeReferenceId="signInNames.emailAddress" PartnerClaimType="email" />
<OutputClaim ClaimTypeReferenceId="extension_CompanyCVR" PartnerClaimType="companyCVR" />

The whole relying party file ends up looking as follows:

<?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="__TenantId__" 
    PolicyId="B2C_1A_SignUpSignIn"
    PublicPolicyUri="http://__TenantId__/B2C_1A_SignUpSignIn">

    <BasePolicy>
        <TenantId>__TenantId__</TenantId>
        <PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId>
    </BasePolicy>

    <RelyingParty>
        <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
        <TechnicalProfile Id="PolicyProfile">
            <DisplayName>PolicyProfile</DisplayName>
            <Protocol Name="OpenIdConnect" />
            <OutputClaims>
                <OutputClaim ClaimTypeReferenceId="displayName" />
                <OutputClaim ClaimTypeReferenceId="givenName" />
                <OutputClaim ClaimTypeReferenceId="surname" />
                <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
                <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
                <OutputClaim ClaimTypeReferenceId="signInNames.emailAddress" PartnerClaimType="email" />
                <OutputClaim ClaimTypeReferenceId="extension_CompanyCVR" PartnerClaimType="companyCVR" />
            </OutputClaims>
            <SubjectNamingInfo ClaimType="sub" />
        </TechnicalProfile>
    </RelyingParty>
</TrustFrameworkPolicy>

PASSWORDRESET.XML

When based on the custom policies starter pack, a user is logged in after resetting their password. So the requirement of displaying a user's information after successful login, also applies to the custom policy resulting from the 'PasswordReset.xml' relying party file.

I have added the three following output claims to the relying party file:

<OutputClaim ClaimTypeReferenceId="givenName" />
<OutputClaim ClaimTypeReferenceId="surname" />
<OutputClaim ClaimTypeReferenceId="extension_CompanyCVR" PartnerClaimType="companyCVR" />

The whole relying party file ends up looking as follows:

<?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="__TenantId__"
    PolicyId="B2C_1A_PasswordReset"
    PublicPolicyUri="http://__TenantId__/B2C_1A_PasswordReset">

    <BasePolicy>
        <TenantId>__TenantId__</TenantId>
        <PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId>
    </BasePolicy>

    <RelyingParty>
        <DefaultUserJourney ReferenceId="PasswordReset" />
        <TechnicalProfile Id="PolicyProfile">
            <DisplayName>PolicyProfile</DisplayName>
            <Protocol Name="OpenIdConnect" />
            <OutputClaims>
                <OutputClaim ClaimTypeReferenceId="email" />
                <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
                <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
                <OutputClaim ClaimTypeReferenceId="givenName" />
                <OutputClaim ClaimTypeReferenceId="surname" />
                <OutputClaim ClaimTypeReferenceId="extension_CompanyCVR" PartnerClaimType="companyCVR" />
            </OutputClaims>
            <SubjectNamingInfo ClaimType="sub" />
        </TechnicalProfile>
    </RelyingParty>
</TrustFrameworkPolicy>

Testing the resulting user flows

In order to test the custom policies, I have updated some of the configuration under the 'Authentication' blade in AADB2C.

I have enabled issuing of Access tokens. Remember to disable this after testing, if it is not needed in order for your application to work with AADB2C.

I have then added https://jwt.ms as a reply URL in order to be able to see a decoded access token upon successfully logging in.

Fullscreen

After saving the changes, I have gone to the 'Identity Experience Framework' and uploaded the relying party file for SignUpOrSignin.xml. I will use its resulting user flow as an example.

I have then clicked on the resulting custom policy's corresponding link under the 'Custom policies' section and clicked the 'Run now' button.

After creating a user and logging in, I am able to see the output claims.

Fullscreen

The 'email' claim is there but the 'companyCVR' claim is not. It is like that by design, since 'extension_CompanyCVR' is not among the claims collected from the user upon signing up. Neither is it supposed to, as it is not an application requirement for the user to be an employee of a company, in order be a user.

I will later allow the user to fill in missing user attribute values, by implementing an application with read/write access, that can update the user via the Microsoft Graph API, if they fill the information in later on.

Alternatively, you can achieve something similar by configuring the 'ProfileEdit.xml' custom policy from the starter pack and redirecting the user to that flow.

That concludes the changes to the 'Relying party files', I wanted to show you in this post.

Next steps

For C# developers there's a post in the series called Azure AD B2C Custom Policies (Series): Basic User Operations With Microsoft Graph API

There's also a similar post in this series called Azure AD B2C Custom Policies (Series): SAML2 Sign-in Only.

References

https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack

ocano.net.