idps-filter

Azure AD B2C: Dynamic identity provider selection

This sample policy demonstrates how to dynamically filter the list of social identity providers render to the user based on a custom query string parameter idps. In the following screenshot user can select from the list of identity providers, such as Facebook, Google+ and Twitter. With Azure AD B2C custom policies, you can configure the technical profiles to be displayed based a claim's value. The claim value contains the list of identity provider to be rendered.

By default Azure AD B2C displays every identity provider that appears in the ClaimsProviderSelections element of the first orchestration step of your user journey. To filter the list of identity providers dynamically, you send a custom query string parameter idps, in a comma delimiter format. The following URL illustrates how to display only Facebook and Google sign-in buttons:

Solution building blocks

1. The IdentityProviders string collection claim contains the list of identity providers to be displayed.
2. The idps string claim contains incoming query string parameter idps.
3. To convert the idps comma delimiter value to a string collection, we use the StringSplit claims transformation.
4. The first orchestration step invokes the Get-IdentityProvidersList claims transofmation technical profile. This technical profile reads the idps query string parameter, using claims resolvers , then call the ConvertIDPsToStringCollection claims transformation (to convert the comma delimiter string to a string collection).
5. In each technical profile:
   1. The EnabledForUserJourneys element set to OnItemExistenceInStringCollectionClaim. This element controls if the technical profile is executed in a user journey. The value of the tels B2C to execute only when an item exists in a string collection claim.
   2. You also need to add two metadata elements: ClaimTypeOnWhichToEnable specifies the claim's type that is to be evaluated. In this case the string collection claim identityProviders. ClaimValueOnWhichToEnable specifies the value that is to be compared. The name of the identity provider, for example facebook.

<ClaimsProvider>
  <DisplayName>Facebook</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="Facebook-OAUTH">
      <Metadata>
        ...
        <Item Key="ClaimTypeOnWhichToEnable">identityProviders</Item>
        <Item Key="ClaimValueOnWhichToEnable">facebook</Item>
      </Metadata>
      ...
      <EnabledForUserJourneys>OnItemExistenceInStringCollectionClaim</EnabledForUserJourneys>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

<ClaimsProvider>
  <DisplayName>Google</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="Google-OAUTH">
      <Metadata>
        ...
        <Item Key="ClaimTypeOnWhichToEnable">identityProviders</Item>
        <Item Key="ClaimValueOnWhichToEnable">google</Item>
      </Metadata>
      ...
      <EnabledForUserJourneys>OnItemExistenceInStringCollectionClaim</EnabledForUserJourneys>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Community Help and Support

Use Stack Overflow to get support from the community. Ask your questions on Stack Overflow first and browse existing issues to see if someone has asked your question before. Make sure that your questions or comments are tagged with [azure-ad-b2c]. If you find a bug in the sample, please raise the issue on GitHub Issues. To provide product feedback, visit the Azure Active Directory B2C Feedback page.

Note: This sample policy is based on SocialAndLocalAccounts starter pack. All changes are marked with Demo: comment inside the policy XML files. Make the necessary changes in the Demo action required sections.