azure-samples / active-directory-b2c-custom-policy-starterpack

Azure AD B2C now allows uploading of a Custom Policy which allows full control and customization of the Identity Experience Framework

Contributing

This project has adopted the Microsoft Open Source Code of Conduct. For more information, see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Change log

09 August 2022

With this version the starter pack now contains a Refresh Token user journey. This journey will be executed any time an application refreshes a token. It will check the user still exists and is enabled in the Azure AD B2C directory. It also checks that the refresh token is not expired. It compiles any claims that are not persisted in the user profile, including claims from Identity Provider's and REST API calls. A new set of refreshed tokens is then issued.

This fix allows for refresh token to be revoked from users and prevents directory deleted users from getting continued access.Change affects all starterpack samples.

Policy	Notes
B2C_1A_TrustFrameworkBase	Added Refresh Token claims, Refresh Token ClaimsTransformations, Refresh Token Technical Profiles and Refresh Token User Journey
B2C_1A_SignUpOrSignIn	Added Refresh Token Endpoint to Relying Party

Migrate existing policy to this version

Your custom policy can invoke a custom refresh token journey. Add the following user journey to your TrustFrameworkExtensions.xml file to get started.

1. Open the extensions file of your policy. For example, SocialAndLocalAccounts/TrustFrameworkExtensions.xml.
2. Locate the UserJourneys element. If the element doesn't exist, add it.
3. Add the following UserJourney to the UserJourneys element.

<!--
<UserJourneys>-->
  <UserJourney Id="RedeemRefreshToken">
    <PreserveOriginalAssertion>false</PreserveOriginalAssertion>
    <OrchestrationSteps>
      <OrchestrationStep Order="1" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="RefreshTokenSetupExchange" TechnicalProfileReferenceId="RefreshTokenReadAndSetup" />
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="2" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="CheckRefreshTokenDateFromAadExchange" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId-CheckRefreshTokenDate" />
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="3" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
    </OrchestrationSteps>
  </UserJourney>
<!--
</UserJourneys>-->

This user journey will validate that the refresh token has not been revoked. You can revoke refresh tokens in Azure AD B2C following the Microsoft Graph API Revoke sign in sessions guidance.

You can add additional steps into this journey to call any other technical profiles, such as to your REST API technical profiles or Azure AD read/write technical profiles.

Configure the relying party policy

The relying party file must be configured to point to your custom refresh token journey. This allows Azure AD B2C to reference your refresh token journey when your app makes a refresh token request.

Add an Endpoint with Id set to token and provide a UserJourneyReferenceId referencing the UserJourney Id from the prior section. Merge the following XML snippet into your SignUpOrSignin.xml file.

<RelyingParty> 
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" /> 
    <Endpoints> 
      <Endpoint Id="Token" UserJourneyReferenceId="RedeemRefreshToken" /> 
    </Endpoints>
    ...    
</RelyingParty> 

Repeat this for all Relying party files your application may invoke, such as ProfileEdit.xml and PasswordReset.xml.

Configure refresh token revocation evaluation

The custom refresh token journey can be used to evaluate whether the current refresh token being presented has been revoked. To implement this logic, Azure AD B2C must compare the refreshTokenIssuedOnDateTime and the refreshTokensValidFromDateTime. Create the claims schema definitions as shown in the below XML snippet in your TrustFrameworkExtensions.xml.

1. Open the extensions file of your policy. For example, SocialAndLocalAccounts/TrustFrameworkExtensions.xml.
2. Locate the BuildingBlocks element. If the element doesn't exist, add it.
3. Locate the ClaimsSchema element. If the element doesn't exist, add it.
4. Add the following claims to the ClaimsSchema element.

<!--
<BuildingBlocks>
  <ClaimsSchema> -->
    <ClaimType Id="refreshTokenIssuedOnDateTime">
      <DisplayName>refreshTokenIssuedOnDateTime</DisplayName>
      <DataType>string</DataType>
      <AdminHelpText>Used to determine if the user should be permitted to reauthenticate silently via their existing refresh token.</AdminHelpText>
      <UserHelpText>Used to determine if the user should be permitted to reauthenticate silently via their existing refresh token.</UserHelpText>
    </ClaimType>
    <ClaimType Id="refreshTokensValidFromDateTime">
      <DisplayName>refreshTokensValidFromDateTime</DisplayName>
      <DataType>string</DataType>
      <AdminHelpText>Used to determine if the user should be permitted to reauthenticate silently via their existing refresh token.</AdminHelpText>
      <UserHelpText>Used to determine if the user should be permitted to reauthenticate silently via their existing refresh token.</UserHelpText>
    </ClaimType>
  <!--
  </ClaimsSchema>
</BuildingBlocks> -->

To check whether the refresh token has been revoked, the refreshTokenIssuedOnDateTime and the refreshTokensValidFromDateTime must be compared. Add the following AssertDateTimeIsGreaterThan ClaimsTransformation to your TrustFrameworkExtensions.xml.

1. Open the extensions file of your policy. For example, SocialAndLocalAccounts/TrustFrameworkExtensions.xml.
2. Locate the BuildingBlocks element. If the element doesn't exist, add it.
3. Locate the ClaimsTransformations element. If the element doesn't exist, add it.
4. Add the following ClaimsTransformation to the ClaimsTransformations element.

<!--
<BuildingBlocks>
  <ClaimsTransformations> -->
    <ClaimsTransformation Id="AssertRefreshTokenIssuedLaterThanValidFromDate" TransformationMethod="AssertDateTimeIsGreaterThan">
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="refreshTokenIssuedOnDateTime" TransformationClaimType="leftOperand" />
        <InputClaim ClaimTypeReferenceId="refreshTokensValidFromDateTime" TransformationClaimType="rightOperand" />
      </InputClaims>
      <InputParameters>
        <InputParameter Id="AssertIfEqualTo" DataType="boolean" Value="false" />
        <InputParameter Id="AssertIfRightOperandIsNotPresent" DataType="boolean" Value="true" />
        <InputParameter Id="TreatAsEqualIfWithinMillseconds" DataType="int" Value="300000" />
      </InputParameters>
    </ClaimsTransformation>
  <!--
  </ClaimsTransformations>
</BuildingBlocks> -->

To invoke the process to evaluate whether the refresh token has been revoked, add the following technical profile to your TrustFrameworkExtensions.xml.

1. Open the extensions file of your policy. For example, SocialAndLocalAccounts/TrustFrameworkExtensions.xml.
2. Locate the ClaimsProviders element. If the element doesn't exist, add it.
3. Add the following ClaimsProvider to the ClaimsProviders element.
4. Add extra claims collected from previous REST API's and Federated IDP's that have not been persisted in the directory as OutputClaims under the RefreshTokenReadAndSetup technical profile

<!--
<ClaimsProviders> -->
  <ClaimsProvider>
    <DisplayName>Refresh token journey</DisplayName>
    <TechnicalProfiles>
      <TechnicalProfile Id="RefreshTokenReadAndSetup">
        <DisplayName>Trustframework Policy Engine Refresh Token Setup Technical Profile</DisplayName>
        <Protocol Name="None" />
        <OutputClaims>
          <OutputClaim ClaimTypeReferenceId="objectId" />
          <OutputClaim ClaimTypeReferenceId="refreshTokenIssuedOnDateTime" />
              <!--additional claims from REST API or Federated IDP-->
            <OutputClaim ClaimTypeReferenceId="ExtraClaim1" />
            <OutputClaim ClaimTypeReferenceId="ExtraClaim2" />
        </OutputClaims>
      </TechnicalProfile>
      <TechnicalProfile Id="AAD-UserReadUsingObjectId-CheckRefreshTokenDate">
        <OutputClaims>
          <OutputClaim ClaimTypeReferenceId="refreshTokensValidFromDateTime" />
        </OutputClaims>
        <OutputClaimsTransformations>
          <OutputClaimsTransformation ReferenceId="AssertRefreshTokenIssuedLaterThanValidFromDate" />
        </OutputClaimsTransformations>
        <IncludeTechnicalProfile ReferenceId="AAD-UserReadUsingObjectId" />
      </TechnicalProfile>
    </TechnicalProfiles>
  </ClaimsProvider>
<!--
</ClaimsProviders> -->

Upload the policies

1. Select the Identity Experience Framework menu item in your B2C tenant in the Azure portal.
2. Select Upload custom policy
3. Select Overwrite the custom policy if it already exists
4. In this order, upload the policy files:
   1. TrustFrameworkExtensions.xml
   2. SignUpOrSignin.xml

11 October 2021

With this version the starter pack now contains localization policy file TrustFrameworkLocalization.xml. The localization policy allows your policy to accommodate different languages to suit your customer needs. For more information, check the PR #107.

The new localization policy is located between the base and the extension policies:

Policy	Base policy	Notes
B2C_1A_TrustFrameworkBase		Contains most of the definitions. To help with troubleshooting and long-term maintenance of your policies, try to minimize the number of changes you make to this file.
B2C_1A_TrustFrameworkLocalization	B2C_1A_TrustFrameworkBase	Holds the localization strings.
B2C_1A_TrustFrameworkExtensions	B2C_1A_TrustFrameworkLocalization	Holds the unique configuration changes for your tenant.
Relying Parties (RP)	B2C_1A_TrustFrameworkExtensions	For example: sign-up, sign-in, password reset, or profile edit.

Migrate exiting policy to this version

To migrate from the older version of the starter pack to this version:

1. Download the starter pack and update the tenant name.

2. Upload the newer version of TrustFrameworkBase.xml file.

3. Upload the new TrustFrameworkLocalization.xml file.

4. Update your existing TrustFrameworkExtension.xml with the new base policy B2C_1A_TrustFrameworkLocalization. The following XML snippet demonstrates the base policy before the change:

   <!-- file: TrustFrameworkExtensions.xml -->
   <BasePolicy>
     <TenantId>yourtenant.onmicrosoft.com</TenantId>
     <PolicyId>B2C_1A_TrustFrameworkBase</PolicyId>
   </BasePolicy>

   The following XML snippet demonstrates the base policy after the change:

   <!-- file: TrustFrameworkExtensions.xml -->
   <BasePolicy>
     <TenantId>yourtenant.onmicrosoft.com</TenantId>
     <PolicyId>B2C_1A_TrustFrameworkLocalization</PolicyId>
   </BasePolicy>

5. Upload the TrustFrameworkExtension.xml policy.

15 September 2021

Update to the content definition page version. With the new version the starter pack uses the page contract. For more information, see Migrating to page layout.

20 July 2019

Updated policies to use the new Ocean Blue template

29 January 2019

A collection of bugfixes, improvements to code, and additional feature support is included in this starterpack. It is not necessary or encouraged for developers to change policies currently in production or in testing. We do encourage the use of these new versions for all new projects.

10 May 2017

Public Preview Release

5 May 2017

Added Key definition to the metadata element in all four TrustframeworkBase.xml versions. When this Item Key is set to TRUE, the expiration dates on the token issued by B2C will be presented as JSON Numbers. When set to False (default) they will be presented as strings.

<Item Key="SendTokenResponseBodyWithJsonNumbers">true</Item> 

---

Important notes

The following Change is incorporated into the latest version of starterpack (01/29/2019) - It remains here for historical purposes. 06/26/2017 - Correction to SocialAndLocalAccountswMFA in TrustFrameworkBase.xml file.

A change to fix a data loss issue related to SSO, the profile edit policy, and MFA. This issue was due to the MFA SSO technical profile not outputting the below claim in the same format that the regular MFA provider does

<TechnicalProfile Id="SM-MFA">
  <DisplayName>Session Mananagement Provider</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.DefaultSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <PersistedClaims>
***OLD:  <PersistedClaim ClaimTypeReferenceId="strongAuthenticationPhoneNumber" />
***CORRECTED:  <PersistedClaim ClaimTypeReferenceId="Verified.strongAuthenticationPhoneNumber" />
    <PersistedClaim ClaimTypeReferenceId="executed-PhoneFactor-Input" />
  </PersistedClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="isActiveMFASession" DefaultValue="true" />
  </OutputClaims>
</TechnicalProfile>

active-directory-b2c-custom-policy-starterpack's Issues

Are clientdefinitions node still in use in TrustFrameworkBasePolicy.Xml ?

BuildingBlocks node in schema contains ClientDefinitions node which is not described here. Does it mean that this node is not supported/obsolete? Document Reference

If it is not used in the policy anymore. can we remove that Clientdefinition node from the TrustFramwork starterPack policy xml's.
Here is the link for TrustFrameworkBase.xml where client definitions node exists.

Same Issue reported in Documentation page

Missing nodes in TrustFrameworkPolicy_0.3.0.0.xsd

Following this issue azure-docs/#6299, we noted that TrustFrameworkPolicy_0.3.0.0.xsd is missing some nodes.

For instance, this doc mentions InputValidations and Predicates, which are not currently present on the XSD.

The XSD needs to be updated to reflect all available nodes.

How do the IdentityExperienceFrameworkApps connect to AAD without secrets?

In LocalAccounts/TrustFrameworkExtensions.xml we have:

<TechnicalProfiles>
   <TechnicalProfile Id="login-NonInteractive">
    <Metadata>
      <Item Key="client_id">ProxyIdentityExperienceFrameworkAppId</Item>
      <Item Key="IdTokenAudience">IdentityExperienceFrameworkAppId</Item>
    </Metadata>
    <InputClaims>
      <InputClaim ClaimTypeReferenceId="client_id" DefaultValue="ProxyIdentityExperienceFrameworkAppID" />
      <InputClaim ClaimTypeReferenceId="resource_id" PartnerClaimType="resource" DefaultValue="IdentityExperienceFrameworkAppID" />
    </InputClaims>
  </TechnicalProfile>
</TechnicalProfiles>

Can someone explain why two applications are required to make these custom policies work?
How does the IEF use each of them?

Besides, I don't see any secret or application key being passed to IEF in these files. How can IEF connect to AAD using Application Ids only?

Read Application information by Object ID from the token received with client_credentials.

There's plenty of information how to read users' data from the directory. However, there's a way to use client_credentials flow to receive a valid AAD token which can be used as a id_token_hint for custom policies. Nonetheless, if I'm trying to read app data using AAD-UserReadUsingObjectId it fails into the error.

How to get the base-v1 policy

We're using Azure AD B2C for a client app. I configured many custom claim properties and several user journeys through the Azure portal.
However, now we need some special functionality that can only be achieved by directly editing the policy xml files because Azure Portal doesn't support these features.

But I don't want to start from scratch with the xml templates as it seems to be very difficult.

Now my question is:
Is it possble to get the current working base policy as xml file? It's not possible to derive my own custom policy from the default base-v1 policy.

multitenant template?

is there one template for multitenants?

What happened to the user migration app?

Trying to create users in B2C. Can't find the VS migration app project. How to add users into B2C then? I need to use custom usernames (Social Security Numbers).

Phone signup without email recovery step

I uploaded phone-number-passwordless custom policy and features are working as expected.
But I wanted to remove email recovery step when a user signup using phone number.

As per the SignUpOrSignInWithPhone.xml or SignUpOrSignInWithPhoneOrEmail.xml, a user need to verify email id as well, even when doing a phone number based sign up.

Any help will be really appreciated.

Add JourneyInsights to XSD

I've integrated the XSD file into VS Code and it complaining about JourneyInsights.

I'm happy to submit PR to fix... just want to check first that it is weclomed... thanks 🙏

<UserJourneyBehaviors>
    <JourneyInsights TelemetryEngine="ApplicationInsights" InstrumentationKey="[some-guid]" DeveloperMode="true" ClientEnabled="false" ServerEnabled="true" TelemetryVersion="1.0.0" />
</UserJourneyBehaviors>

SignUpOrSignIn Intermittent Exception

This issue is not reproducible on demand. Intermittently you will see errors logged stating "A claim could not be found for lookup claim with id "alternativeSecurityId" defined in technical profile with id "AAD-UserReadUsingAlternativeSecurityId-NoError""

It looks to me there is an unhandled case in the SignUpOrSignIn user journey. The journey assumes that if the authenticationSource is not localAccountAuthentication then the alternativeSecurityId claim will exist. This seems not to be true in practice. Step 2 in the user journey acknowledges that an objectId could already exist and if it does then it skips that step. That step is where the alternativeSecurityId gets created so if it is skipped and authenticationSource is social then you can get the error reported above. Looking further into the logs there is a field called objectIdFromSession which is set to true. So it seems that when the objectId is populated from a session it does not create a alternativeSecurityId from that session, it skips the step 2 that creates alternativeSecurityId, and because authenticationSource is set to social it goes into step 3 and we get the above error.

        <!-- Check if the user has selected to sign in using one of the social providers -->
        <OrchestrationStep Order="2" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="FacebookExchange" TechnicalProfileReferenceId="Facebook-OAUTH" />
            <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <!-- For social IDP authentication, attempt to find the user account in the directory. -->
        <OrchestrationStep Order="3" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>authenticationSource</Value>
              <Value>localAccountAuthentication</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />
          </ClaimsExchanges>
        </OrchestrationStep>

Default error message in case of a wrong password in login-NonInteractive tech profile

Hi,
I've noticed that in the base policy below (but I think it's the same for other base policies) there's a default message displayed to the user when a wrong password is entered. I'm wondering whether this might be the best default message in terms of security, especially for a new developer that still doesn't know really well everything is in the policies. Maybe for the default message provided by the starter pack something like "Your username and/or password is/are incorrect" would be more appropriate.
Thanks.

active-directory-b2c-custom-policy-starterpack/LocalAccounts/TrustFrameworkBase.xml

Line 414 in ee4832d

<Item Key="UserMessageIfInvalidPassword">Your password is incorrect</Item>

Update "Enable Keep me signed" sample to latest 2.0 version of layout

This sample using 1.1.0 version. https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/blob/master/scenarios/keep%20me%20signed%20in/TrustFrameworkExtensions.xml

Microsoft updated b2c layouts to use 1.2.0 https://docs.microsoft.com/en-us/azure/active-directory-b2c/contentdefinitions#migrating-to-page-layout

Please update it this sample to use latest/greatest versions

Add Username based Local Accounts

The starter pack for local accounts assumes email address will be used. Please add the username approach for local accounts! 😄

SO Post

V2.0 token configurations

What are the configuration parameters for OpenIdConnect technical profile for v2.0 endpoints?
I tried v2.0 endpoints from my B2C tenant and it throws userid and password invalid error.

< Item Key="ProviderName">https://sts.windows.net/< /Item>

< Item Key="METADATA">https://.b2clogin.com/{tenant}//v2.0/.well-known/openid-configuration</ Item>

< Item Key="authorization_endpoint">https://.b2clogin.com/{tenant}//oauth2/v2.0/token< /Item>

Also, the sample should be updated to get v2.0 token using b2clogin.com.

TrustFrameworkPolicy XSD seems outdated

Where can I find the XSD for the TrustFrameworkPolicy XML?
I found one in some Azure Samples github repository (https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack), but it obviously does not fully match the description in the Azure Documentation.
Just one example out of many: The XSD does not have an "Enabled" attribute on the "Localization" element, whereas the documentation lists it.

Ref: GitHub Issue

Define "ESTS" or change to a well-known term

Many of the policy files use the term "ESTS" in comments. However, I can find no definition for this term in the starter pack or in any B2C documentation. One example of such comments:

        <!-- Show self-asserted page only if the directory does not have the user account already (i.e. we do not have an objectId). 
          This can only happen when authentication happened using a social IDP. If local account was created or authentication done
          using ESTS in step 2, then an user account must exist in the directory by this time. -->

Custom Policy B2C_1A_signup_signin Upload error

Hi,
when I try to upload to azure B2C the custom policy B2C_1A_signup_signin i get this error:

Validation failed: 1 validation error(s) found in policy "B2C_1A_SIGNUP_SIGNIN" of tenant "tenantName.onmicrosoft.com".TechnicalProfile "login-NonInteractive" in policy "B2C_1A_signup_signin" of tenant "tenantName.onmicrosoft.com" defines an invalid value "" for the metadata item "client_id."

This is my XML file:

<?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="tenantName.onmicrosoft.com"
        PolicyId="B2C_1A_signup_signin"
        PublicPolicyUri="http://tenantName.onmicrosoft.com/B2C_1A_signup_signin">

  <BasePolicy>
    <TenantId>tenantName.onmicrosoft.com</TenantId>
    <PolicyId>B2C_1A_DisplayControl_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="email" />
        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
        <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
      </OutputClaims>
      <SubjectNamingInfo ClaimType="sub" />
    </TechnicalProfile>
  </RelyingParty>
</TrustFrameworkPolicy>

How do I disable MFA? Removing steps 5, 6 and 7 as said in comments breaks the policy.

TrustFrameworkPolicy_0.3.0.0.xsd - XML Validation errors

I have set up VSCode to validate my Custom Policies against the provided TrustFrameworkPolicy_0.3.0.0.xsd file but have found there are numerous validation errors.

• There is a Namespace issue with the XML vs the XSD document: "TargetNamespace.2: Expecting no namespace, but the schema document has a target namespace of 'http://schemas.microsoft.com/online/cpim/schemas/2013/06'.xml(TargetNamespace.2)"
  I have fixed this by adding the xsd file name to the xsi:schemaLocation portion of the TrustFrameworkPolicy element, however I'm not sure if that is the correct fix:
  xsi:schemaLocation="http://schemas.microsoft.com/online/cpim/schemas/2013/06 TrustFrameworkPolicy_0.3.0.0.xsd

• Long is a valid DataType for ClaimsSchema ClaimType, however they are not in the XSD

• Paragraph is a valid UserInputType for ClaimsSchema ClaimType, same problem

• When using the LinkedIn sign in CustomPolicy with the Optional Email claim, the second OutputClaim throws this error 'cvc-complex-type.2.4.d: Invalid content was found starting with element 'OutputClaim'. No child element is expected at this point.xml(cvc-complex-type.2.4.d)'

• Using AlwaysUseDefaultValue="true" in an OutputClaim throws this error: 'cvc-complex-type.3.2.2: Attribute 'AlwaysUseDefaultValue' is not allowed to appear in element 'OutputClaim'.xml(cvc-complex-type.3.2.2)'

alternativeSecurityId case sensitivity issue?

active-directory-b2c-custom-policy-starterpack/SocialAndLocalAccounts/TrustFrameworkBase.xml

Line 575 in d20bb35

<InputClaim ClaimTypeReferenceId="AlternativeSecurityId" PartnerClaimType="alternativeSecurityId" Required="true" />

active-directory-b2c-custom-policy-starterpack/SocialAndLocalAccounts/TrustFrameworkBase.xml

Line 579 in d20bb35

<PersistedClaim ClaimTypeReferenceId="alternativeSecurityId" />

Why are the cases different in the 2 lines? Does this work as is?

Minor issue - Phone number passwordless has a spelling mistake

"Standard messsage and data rates"

Generate OTP either doesn't work or fails into the error.

Hi,
I copied technical profiles examples from the ms docs site to my policy and it fails into the error:

Unable to cast object of type 'Web.TPEngine.Providers.OneTimePasswordProtocolProvider' to type 'Web.TPEngine.Providers.IProtocolProvider'.

Correlation ID: 94f61d59-81c7-4416-8f11-dddf21b9b557
Timestamp: 2021-01-13 11:05:30Z
AADB2C: An exception has occurred.

UserJourney used:

        <OrchestrationStep
            Order="3"
            Type="ClaimsExchange">
          <ClaimsExchanges>
            <ClaimsExchange
                Id="GenerateOtpFromEmail"
                TechnicalProfileReferenceId="GenerateOtp" />
          </ClaimsExchanges>
        </OrchestrationStep>

However, if I'm using it as a validation profile of another profile - it doesn't generate a code. Otp claim is empty.

This is an example of the UserJourney:

        <TechnicalProfile Id="GenerateOtpProfile">
          <DisplayName>Generate OTP</DisplayName>
          <Protocol
              Name="Proprietary"
              Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
          <InputClaims>
            <InputClaim ClaimTypeReferenceId="email" />
          </InputClaims>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="Otp" />
          </OutputClaims>
          <ValidationTechnicalProfiles>
            <ValidationTechnicalProfile ReferenceId="GenerateOtp" />
          </ValidationTechnicalProfiles>
        </TechnicalProfile>

.....

        <OrchestrationStep
            Order="3"
            Type="ClaimsExchange">
          <ClaimsExchanges>
            <ClaimsExchange
                Id="GenerateOtpFromEmail"
                TechnicalProfileReferenceId="GenerateOtpProfile" />
          </ClaimsExchanges>
        </OrchestrationStep>

CorrelationId for this event is 576334b2-5432-4498-9033-567617514196.

For both cases I used the same example from the docs:

    <ClaimsProvider>
      <DisplayName>One time password technical profiles</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="GenerateOtp">
          <DisplayName>Generate one time password</DisplayName>
          <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.OneTimePasswordProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
          <Metadata>
            <Item Key="Operation">GenerateCode</Item>
            <Item Key="CodeExpirationInSeconds">1200</Item>
            <Item Key="CodeLength">6</Item>
            <Item Key="CharacterSet">0-9</Item>
            <Item Key="ReuseSameCode">true</Item>
            <Item Key="MaxNumAttempts">5</Item>
          </Metadata>
          <InputClaims>
            <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="identifier" />
          </InputClaims>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="otp" PartnerClaimType="otpGenerated" />
          </OutputClaims>
        </TechnicalProfile>
    
        <TechnicalProfile Id="VerifyOtp">
          <DisplayName>Verify one time password</DisplayName>
          <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.OneTimePasswordProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
          <Metadata>
            <Item Key="Operation">VerifyCode</Item>
          </Metadata>
          <InputClaims>
            <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="identifier" />
            <InputClaim ClaimTypeReferenceId="verificationCode" PartnerClaimType="otpToVerify" />
          </InputClaims>
        </TechnicalProfile>
       </TechnicalProfiles>
    </ClaimsProvider>

Poor code quality in samples

The code samples have poor quality, Visual Studio warns about "Naming rule violations" for instance.

I believe Official Microsoft samples should follow the C# programming guide.

Add TFP Claim to the Base Policy

According to this documentation -> Setting claim representing policy ID, TFP is the preferred approach but that claim is not included in the starter pack.

This issue was raised on Stack Overflow.

Sample ClaimType that works:

<ClaimType Id="trustFrameworkPolicy">
    <DisplayName>Trust Framework Policy</DisplayName>
    <DataType>string</DataType>
    <DefaultPartnerClaimTypes>
        <Protocol Name="OAuth2" PartnerClaimType="tfp" />
        <Protocol Name="OpenIdConnect" PartnerClaimType="tfp" />
    </DefaultPartnerClaimTypes>
</ClaimType>

Related SO post: Should ACR or TFP have the policy name?.

Terms of use consent page giving errors

Hi,

For a new user I am trying to show the user consent form but the link below is giving some errors
https://cs4585b26274a94x484fx966.blob.core.windows.net/b2ccontainer/index.htm

Uncaught TypeError: element.attachEvent is not a function
at observe (prototype.forms.js:578)
at HTMLDocument._methodized [as observe] (prototype.forms.js:60)
at scroll.js:1
at scroll.js:1
prototype.forms.js:594 Uncaught TypeError: element.dispatchEvent is not a function
at fire (prototype.forms.js:594)
at HTMLDocument._methodized [as fire] (prototype.forms.js:60)
at HTMLDocument.fireContentLoadedEvent (prototype.forms.js:598)

I am not able to get the continue and cancel button

SignUpSignIn does not render correctly for Email operatingMode

In my TrustFrameworkExtensions I added the following:

<ContentDefinition Id="api.signuporsignin">
        <LoadUri>https://{Settings:BlobStorageAccount}.blob.core.windows.net/{Settings:BlobContainer}/html/sign_in.html</LoadUri>
        <RecoveryUri>~/common/default_page_error.html</RecoveryUri>
        <DataUri>urn:com:microsoft:aad:b2c:elements:contract:unifiedssp:2.1.0</DataUri>
        <Metadata>
          <Item Key="DisplayName">Signin and Signup</Item>
        </Metadata>
      </ContentDefinition>

However, with version 2.1.0 the sign in name field is not an Email Address field. Based on the TrustFrameworkBase I would expect the behavior to have Email Address as the placeholder and label and to validate the input as a valid email address. The actual behavior is that the placeholder/label says "Sign In Name" and there is no email address validation. The input is also always throwing a format mismatch for whatever text is entered into that field. Perhaps the TrustFrameworkBase is out of date for this new version?

The Country code list from the `Phone_Email_Base` policy has invalid values

In this policy, there is a list of country code (claim countryCode).

Ukraine and United Arab Emirates have the same ISO country code: UA.
The ISO country code for United Arab Emirates is wrong, it should be AE.

Also it is missing the kosovo cuntry code. A new item should be added:
<Item Text="Kosovo(+383)" Value="XK" />

I'm happy to push a PR if needed.

Support focus on the first attribute (HTML input element) - urn:com:microsoft:aad:b2c:elements:selfasserted:1.1.0

Content definitions (TrustFrameworkPolicy element "ContentDefinition") with DataUri="urn:com:microsoft:aad:b2c:elements:selfasserted:1.1.0" do not set the focus on the first attribute (HTML input element for claim).

Only the content definiton with DataUri="urn:com:microsoft:aad:b2c:elements:unifiedssp:1.0.0" contains a useful focus setting.

Because own JavaScript is filtered out, this should be fixed rapidly. Otherwise we have to inform the users that they must press TAB or use mouse.

Please fix this problem asap. It is one line JavaScript/jQuery

$(document).ready(function() {
    $('form:first *:input[type!=hidden]:first').focus();
});

OR (much easier)

A line similar to the following (marked with "/* FIX HERE */") for all attributes:

Handlebars.registerHelper('buildTextInput', function (id, type, placeholder, value, pattern, patternDesc, title, required, readonly, index, options) {
        var input = '<input id="' + id + '" class="textInput" type="' + type + '" ';
        var ariaLabel = "";
        var passwordErrorMsgsStr = "";
		
	/* FIX HERE */ input += 'autofocus '; // New line inserted

        if (placeholder) {
            input += 'placeholder="' + placeholder + '" ';
        }

P. S.: Twice posted (other entry: Azure-Samples/active-directory-b2c-advanced-policies#30) - please decide which repo is the right one.

Split the signup screen into 2 screens

The signup page on AD B2C shows the email verification controls followed by user First name Last name and other fields.

I would like to split this into 2 separate screens where the users only see the email verification box and send the verification code. When they comeback they should be able to go to the next screen which asks for more details.

For multiple projects here, we do not like having it all on one screen, basically it doesn't make sense to show controls that are not relevant to what we are trying to do, i.e. just email verification before anything else.

So the question is, is that possible. Has anyone tried it? Can you share any customization samples, pointers?

Use descriptive parameters instead of numeric.

The sample is used in official MS documentation https://docs.microsoft.com/en-gb/azure/active-directory-b2c/active-directory-b2c-user-migration.
It looks unprofessional to see instruction like
“When you run the pre-migration process with the command-line parameter 2 ...”
It will be much better to have meaningful parameters, like
MigrateWithPassword, MigrateWithRandomPassword etc.

Compatibility with NET Core 3

This sample now doesn't work since NET was updated

IHttpActionResult has been deprecated, so the prescribed return type isn't possible

 return Content(HttpStatusCode.Conflict, new B2CResponseContent("Request content is empty", HttpStatusCode.Conflict));

As per guidelines I have ported it to ActionResult but now the sign up process says "The claims exchange 'REST-API-SignUp' specified in step '2' returned HTTP error response that could not be parsed"

Rejects some valid e-mails

When doing development, it is often useful to use emails of the form:

my_email+1234@my_domain.com

E-mails of this form are rejected by the regular expression in TrustFrameworkBase.xml

AADB2C90068: The provided application with ID is not valid against this service. Please use an application created via the B2C portal and try again.\

I have configured a custom policy that just perform signin (I have removed any other custom step I will use just to make sure the issue is not with policy).

I have followed all instructions for creating IdentityExperienceFramework and ProxyIdentityExperienceFramework. When I run the user flow, it shows the UI screen, posts the request and does not redirect and does not show any errors. Since I enabled application insights, I could see this exception is being thrown.

I am sure I configured the apps as B2C apps and not AD apps, which seems to be a common cause for this issue but this is not the case.

The odd thing is that I have another directory with the same custom policy and with the exactly same configurations and it is working. The only difference is that this directory was created a month ago.

Any thoughts on this issue?

Wrong ISO code for United Arab Emirates

It should be AE, not UA. When UA, a user does not receive the MFA code.

Can I use two email addresses for MFA using custom policies?

I would just like to know, can we use two email addresses for Multi-factor authentication in custom policies just like two phone numbers. Is it possible to do that?

Any help would be appreciated in this regard.

Phone-number-passwordless scenario does not issue newUser claim

Signup implementation in this scenario does not result in the newUser=true claim being included in the issued token, unlike in all (most) other scenarios doing signup. Therefore, applications using the signup/signin journeys do not get notified whether the received token represents a new B2C user or signin by an existing one.

Unable to validate the information provided

I have followed this documentation and added REST API call back.

https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-custom-rest-api-netfw

The API gets executed and returns response.
Response: {"extension_CompanyGUID":"ABC"}

But validation fails with this error on signup. "
Unable to validate the information provided.
--"
I have created this user attribute(extension_CompanyGUID) from UI and using it here. I have mentioned details of " b2c-extensions-app. Do not modify. Used by AADB2C for storing user data." app in "AAD-Common" profile metadata section.

Technical profile details.

On Boarding callback https://turindevbranch.azurewebsites.net/api/beta None Body true

			<!-- Change LocalAccountSignUpWithLogonEmail technical profile to support your validation technical profile -->
			<TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
			  <OutputClaims>
				<OutputClaim ClaimTypeReferenceId="extension_CompanyGUID" PartnerClaimType="extension_CompanyGUID" />
			  </OutputClaims>
			  <ValidationTechnicalProfiles>
				<ValidationTechnicalProfile ReferenceId="REST-API-SignUp" />
			  </ValidationTechnicalProfiles>
			</TechnicalProfile>

Generic exception "server_error, AADB2C: An exception has occured"

Using custom SignUp_SignIn policy for SocialAndLocalAccounts, I am getting below exception each time I try to authenticate with a social account (Facebook)

ErrorMessage: server_error
ErrorDescription:
AADB2C: An exception has occured.
Correlation ID: 9f92fe54-31e6-4ff8-8145-399311128ef8
Timestamp: 2017-08-14 06:24:34Z

The exception only occurs when I use custom policies in the AD B2C Identity Experience Framework. When tried with default Sign-up or sign-in policy with Facebook Identity provider, it works perfectly well.

Issue with social and MFA

There is an issue in the SocialAndLocalAccountsWithMfa, sign up work perfectly, but when signing in it will ask for a phone number to send the verification, you can put a different number than the one used during the sign up procedure.

To correct this you need to add the following line:
<OutputClaim ClaimTypeReferenceId="strongAuthenticationPhoneNumber" />
in the technical profile AAD-UserReadUsingAlternativeSecurityId (which is the azure AD claimsprovider) in the base file.

Deprecation of login.microsoftonline.com

As indicated on https://docs.microsoft.com/en-us/azure/active-directory-b2c/b2clogin login.microsoftonline.com is deprecated on 04 december 2020. The templates should be updated with the new b2clogin.com url

EnforceEmailVerification=false not working

all
I want to disable email validation at sign-up.

Following the tutorials at
https://docs.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-get-started?tabs=applications
and
https://docs.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-disable-email-verification
my custom B2C_1A_signup_signin policy keeps on showing the "Send verification code" button and requires to validate the code.

Any hint on what could be wrong?

My policy files seem to be correct because:

• Facebook integration works
• when fiddling around with various other settings I either get an error message on the UI or an validation error when uploading the xml.

Unable to create users through migration process

When i run the usermigration.exe 1 i do not see users appear on the screen as being created, it just says users migrated successfully. When i do usermigration.exe 2 i receive this error after 60 seconds The remote name could not be resolved: 'azueb2cdemob.table.core.windows.net'

i have checked the URL to make sure that it is correct but am unable to use this sample.

Thanks.

Localization documentation

Hi guys,

I've been able to piece together quite a bit from just looking over the samples, but I'm struggling to localize messages like this: https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/blob/master/LocalAccounts/TrustFrameworkBase.xml#L487

Im able to localize several fields that appear on the page (like the labels, username, etc), but I'm not sure how to localize the error messages that come back if the user doesnt exist/password is wrong/etc.

Where is the actual documentation on all of this?

Sign in gives 'Your password is incorrect' with Custom policy.

Hi,

First, thanks for the custom policy starter pack.

I have followed the steps as given in documentation, but somehow am not able to sign in with correct username and password.

The only change I made is instead of making ProxyIdentityExperienceFramework as Native APP I have made it as Web App/API.

Note: I made ProxyIdentityExperienceFramework as Web App/API.

For my POC, am trying to have the custom policy for TaskWebApp and TaskService.

https://azure.microsoft.com/en-in/resources/samples/active-directory-b2c-dotnet-webapp-and-webapi/

Regards,
Venkatesh

SocialAndLocalAccountsWithMfa

When you load the Policies for SocialAndLocalAccountsWithMfa everything seems to work correct with the exception of "Forgot your Password". The link is Broken. Any ideas??

Is there any method to get MAC address of the user's system using custom policies?

Hi,

I want to uniquely identify the user's machine other than IP addresses and want to store it into the claims as well. Is there any method to get MAC address of the user's machine using the custom policies flow or is there any other way to uniquely identify the user's machine. The reason behind why I don't want to go with the IP address is that this approach cannot uniquely identify the user's machine if all the machines are on the same network let's say on an organisational network. In that case it will give me the public IP address which I don't want because public IP address will be same for all the machines inside that network.

How to find out what and why return 500 error "There is a problem with the resource you are looking for, and it cannot be displayed."

I have Azure B2C Custom Policies. (They are based on active-directory-b2c-custom-policy-starterpack, but have some differences)
I try to sign up with new user. During registration I get 500 error "There is a problem with the resource you are looking for, and it cannot be displayed.".

POST /slhb2cuat.onmicrosoft.com/B2C_1A_signup_signin/SelfAsserted?tx=StateProperties=eyJUSUQiOiI1MmJmNzJhYi0xYTIwLTQzODgtYTgzOS1kZjBhNTUzYTVlNmEifQ&p=B2C_1A_signup_signin

I have configured Application Insights according to
https://docs.microsoft.com/en-us/azure/active-directory-b2c/troubleshoot-with-application-insights article.

But there is nothing useful(or I didn't noticed something):
AI_logs.txt

Could you point me out in what direction should I look?

B2Clogin.com replacing login.microsoftonline.com?

Should these URLS be updated given this update?

Cannot get Email from user when authenticating against AD

Hi, I've already tried several solutions, when i login from azure ad, I cannot get the email of the user.

I'm trying to transform the upn to the other emails property as mentioned here: https://stackoverflow.com/questions/55227279/get-email-username-in-claims-azure-ad-b2c-signed-in-with-azuread-like-a-social

Do you have any suggestions?

Azure B2C custom policies can't integrate with API Management

I tried to config Azure B2C using custom policies and API Management Identities but it was not success.

1. When i used Azure B2C built-in policies, it worked perfectly.

2. When i used Azure B2C custom policies (with xml files), the Azure B2C provider appeared on APIM login page. After login success, i got an error message "Authentication has failed."

Does Azure B2C custom polices support APIM identities?