It’s important to remember, that even when you use an external identity provider, users need to be able to sign up with your Azure AD B2C tenant the first time they sign in. The other sign-in policy, with the -o365 suffix, supports both signing in and signing up. This policy enables only the Local Account identity provider, as you see from the picture below. This means that only user accounts already existing can be used for signing in. The “standard” sign-in policy is only a sign-in type, which does not enable signing up. The picture below shows the list of user flows (a.k.a. So, we needed two sign-in policies where sign-up is enabled only for the other policy. They are going to be signing in with their Office 365 accounts, and they should be able to sign up for the Extranet the first time they sign in. The Office 365 sign-in is intended for employees of the company hosting the Extranet. Instead, we are creating all Extranet user accounts in advance from a list of known e-mail addresses. When signing in with local identities, we did not want to enable users to sign up. However, there was one thing that made this a bit different. And configure that identity provider for Office 365. Just add a generic OpenID Connect identity provider to the same sign-in policy with your local accounts. Supporting Multiple Sign-in MethodsĪs I wrote, one of our requirements was to support both local sign-in (accounts stored in Azure AD B2C) and Office 365 sign-in.
This article is about how we eventually met these requirements. We needed to mix both standard Azure AD B2C sign-in with Office 365 sign-in with different sign-in policies for these. Normally, that would be pretty trivial, but there were a few requirements that made it a little bit more tricky. I’m currently finishing up an Extranet project that is using Azure AD B2C for signing in.
0 kommentar(er)
