Question 103520 in Azure Question posted in
The official documentation to get you started can be found here.

Azure – How to configure aad b2c custom policy to use local accounts + other clients

I need to configure a SignIn (no SignUp) custom policy on an AAD B2C tenant, but I’m lacking the experience of the IEF to design/develop and test it properly. The policy should read (logically) as follows:

  1. Present UI to user to enter email only (using a self-asserted TP?)
  2. Use custom logic to determine whether the user represents a local account or to any of the known clients of ours. A single client could have multiple possible domains to be authenticated in the same IdP. The only option I know for doing this step is an external REST service, but this is something I would like to avoid if there is any other option to include custom login running inside the custom policy engine, using C#, JS, or event a simple dictionary from email domain to IdP domain.
  3. Depending on the IdP automatically selected in step 2, branch to different journeys where the user will be sign-in
  4. For local-account sign-in journey, the user will need to use MFA if he/she belongs to admin group. Only email, DisplayName, FirstName, LastName and UserId are needed as final claims.
  5. For other IdPs I would have to add ClaimProviders and sub-journeys to allow for signing the users in
  6. Finally the JWT Token should be issued to the relying party.

No storing back to AAD storage is required because there is no sign-up process. User are created from the application and invited (if local account) or already exist in their corresponding IdPs.

Overview workflow for the required sign-in logic

Tags:

2

Answers


  1. 0

    The wording you should look into is "home realm discovery".

    There is a custom policy example on GitHub. However this example requires the application to provide the email hint. You need to extend it in a way that captures the email in a self-asserted step.

    Edit: Sample mentioned by rbrayb better suits your scenario

    For scenarios where you need to implement a sign in journey, where the user is automatically directed to their federated identity provider based off of their email domain. And for users who arrive with an unknown domain, they are redirected to a default identity provider.

    In this example, users who enter an email with the suffix contoso.com, they will be redirected directly to their federated identity provider to sign in. In this case that is Azure AD (SAML2).

    Users who enter an email with the suffix facebook.com, they will be redirected directly to their federated identity provider to sign in. In this case that is Facebook (OAuth).

    Where a user comes from an unknown email suffix, they will be redirected directly to a default identity provider, in this case that is Azure AD (OpenId).

    Login or Signup to reply.
  2. 0

    This is another sample.

    It first asks for the domain and then redirects to the appropriate IDP.

    To add IDP, refer to this.

    For MFA, start with the MFA starter pack.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search