英文:

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 even 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. Users are created from the application and invited (if local account) or already exist in their corresponding IdPs.

英文:

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.

答案1

得分: 2

这是另一个示例。

首先要求域，然后重定向到适当的IDP。

要添加IDP，请参考这个。

对于多因素身份验证（MFA），从多因素身份验证入门套件开始。

英文:

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.

答案2

得分: 1

以下是您要翻译的内容：

"The wording you should look into is "home realm discovery".
您应该查看的术语是“home realm discovery”。

There is a custom policy example on GitHub.
在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
编辑：rbrayb提到的示例更适合您的情况

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).
在此示例中，输入带有contoso.com后缀的电子邮件的用户将被重定向到其联合身份提供者以进行登录。在此情况下，是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).
输入带有facebook.com后缀的电子邮件的用户将被重定向到其联合身份提供者以进行登录。在此情况下，是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).
如果用户来自未知的电子邮件后缀，他们将被重定向到默认身份提供者，即Azure AD（OpenID）。

英文:

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).