Let’s say you have an application that you want your vendors to access. If this application is Azure AD joined you could create a separate account, you could invite them as a guest using their email address, you can even add their domain name as a connected organization, or you could use external identities. That are a lot of options to choose from and the last one is new. What is different in external identities and why would you use them. This blogpost should answer that question and the next one provides a Logic App workflow implementation for you to use to onboard users with advanced workflows.

The whole idea of External Identities is to allow external people to sign-up to your application by themselves using an allowed Identity Provider (IdP). This provider can be a social provider, but also ‘trusted’ providers such as Okta, Ping, ADFS and others.

So, what would be the difference between External Identities and Guest invites, well first of all, Guest invites can’t use Facebook/or Other IdP’s to sign-up with (unless they create an MS LiveID) and the driver is someone in the organization inviting a guest.

With External Identities, we can control which applications allow users to self-sign-up to (instead of sending them an invitation email), we can ask for additional attributes to be provided by the user and finally, we can actually run (external) API’s prior to creating the user which isn’t available for guest invites.

Cross organizations are used to provide application packages to (all) external users of an organization, but again, no API’s although self-sign-up (from a trusted domain) is available.

So, lets dive into our scenario. We have an application (portal.contoso.com) that we want to make available to our partners. Each partner has a partner ID that needs to be provided during sign-up and then we will pickup the sign-up request in a Logic App in Azure to create a workflow. But let’s stick with the basics for now..

Creating a workflow

I’ve already created an application (portal.contoso.com) that allows my users to sign-in to. This application uses the PartnerID attribute (optionally) and is available to my users today. I know my partners use mostly their Facebook account and therefore I need to add Facebook as an Identity provider (https://docs.microsoft.com/en-us/azure/active-directory/b2b/facebook-federation). Next is enabling the self-sign-up in the External Identities blade:

Now don’t be alarmed nothing has changed at the moment. While this setting is enabled, there is still no application enabled for this and thus external people won’t be able to create a guest account in your system (yet). At which point we can begin with the User Flow. The user flow essentially defines the flow that users follow when signing up. It enables you to set a language for the sign-up experience, which attributes we will collect (from IdP and manual) and which applications this flow applies to. In our case I’ve named the flow B2X_1_PortalAccess and selected Facebook (Azure Active Directory is enabled by default for my own users), and I’ve chosen Display Name for the attributes to collect next to the e-mail address.

Finally, we need to assign this flow to an application. In my case the Contoso Portal application. For this, go to the newly created flow and select Applications from the left menu and add the Contoso Portal application. If desired you can also change the available languages, page layouts where we can select to have the additional attributes as mandatory or optional.

Now that this is done, lets see what the experience is for end-users. When they browse to the application, they will see the standard sign-in page from Azure AD:

I’ve changed the “Sign-in text” under the company branding blade in Azure to instruct partners to select the Sign-in options field which brings us to the following field:

As you can see, we now have the option to sign-in with a Facebook account. But what if the user was not yet invited?

The system will then ask if the user wants to create an account. Clicking this will send the user to Facebook for authentication and then back to Azure AD to provide their Display Name (which we copy from Facebook, but can be altered by the user in my configuration).

Now this is all nice and easy, but what if we don’t just want users to be able to sign-up? What if we need to ask the user for a “PartnerID” or other attribute and validate that attribute prior to account creation? For this the External Identities solution has API integration. You can call an API after signing with the external IDP or prior to creating the account. What’s the difference? Lets take a look at the following diagram:

The first API call can be queried prior to asking for additional attributes. This way we can add additional attributes from the IdP into the additional attribute question. For example, if we already have a customer/partner database, I can query that database based on e-mail address, retrieve additional information for the user (such as zip code, partner ID’s etc) prior to asking the user for this. Or for example we retrieve the phone number for the user, hide it in the attribute field and just ask for an MFA code the first API call sent out. The second API call is made prior to creating the user where those additional attributes are already known and can be used to validate or perform other logic with. Unfortunately there is no API after account creation but before sign-in so adding a user to a group can be tricky in this case (which we will see later in our API Logic App solution). As we cannot add users to specific groups, and dynamic groups are not that fast in populating new users, a regular sign-up/sign-in usually results in an error message for the user:

Which brings us to the Logic Apps in our next blogpost..

Conclusion

With External Identities and the introduction of user sign-up flows we can clearly see the merging of Azure B2C into the corporate B2B/B2E space. It allows highly distributed organizations or organizations depending on partners to provide applications to them in a secure manner. But similar to B2C, the default workflows of providing user access are not robust enough for advanced sign-up workflows. However, with the addition of the API calls we will see that we can extend on this with our own API’s or Logic Apps to provide a better user experience and incorporate this all into advanced workflows where we validate attributes, add users to groups and get approvals from application owners… let’s go to the next blogpost in this series!