[MUSIC]
Ramiro Calderon: Welcome to the Azure AD Architecture
Deep Dive Series. I am Ramiro Calderon. I’m a Program
Manager in the Azure AD Engineering team here at Microsoft.
Corissa Koopmans: Hello. My name is Corissa Koopmans and
I am also a Program Manager on the Azure AD Engineering
team.
Ramiro: So, in this video, we are going to cover four ways
to provision external identities using Azure Active Directory
B2B collaboration.
In this first scenario, we have Ann from Contoso over here.
And she wants to add Bob to work in Microsoft Teams. He
is an employee of Fabrikam, which is also an Azure Active
Directory tenant. In this context, we call Contoso the resource
tenant because that’s where the applications are and
Fabrikam is the account tenant because that’s where the
external identity is.
Creating external users has two parts. The part one is
invitation. The second part is what we call redemption.
The invitation phase of the flow starts when Ann adds Bob
to Microsoft Teams. Under the covers, Teams calls the
invitation back end service to create an invite request for
Bob. The invitation service validates that the request is not
in the allow/deny list of tenants, whether the external users
already created on other validations. So when the validations
pass, then the service creates a user object in the resource
tenant here in Step 2. The user then is marked as a pending
state until the flow is completed. A key thing to know here
is that the moment that Bob’s user object is created in the
resource tenant, then it can be added to groups. You can
change attributes, etc.
So in Step 3 over here, Bob needs to complete the provisioning
process. Again, and we’re transitioning to the redemption
phase of the invitation process. In our Teams example,
Bob will get an email with a link to access Teams. Bob also
could have gone straight to the resource if he knew the link
to it. It works for any other application the same way.
In Step 4, the authentication does the Home Realm Discovery.
So, this is exactly like the other flows that we did before.
The user needs to type in the UPN and, in this case, Bob is
going to type Bob@Fabrikam.com. Now, we have two pieces
of data. We know that the resource is in Contoso and the
user account is in Fabrikam. Since both of those things are
recognized by the authentication service as Azure AD
tenants, then the authentication systems can validate if
there is user in Contoso that represents Bob. In this case,
there’s a user, but it’s in pending state over here per the
Step 2 before. With this information, the authentication
service moves through Step 5 over here to figure out how
to authenticate Bob. The credential challenge kicks in here
in Step 6, depending upon the configuration of Fabrikam.
So, they’re use AD FS or password hash sync, etc.
In Step 6, Bob enters a credential per the configuration.
In Step 7, Azure AD validates the credentials where the
user account is coming from, in this case, the account tenant
Fabrikam. Since the authentication validated that Bob is in
Contoso and is in a pending redemption state, the authentication
service redirects the user to the invitation back end service
here in Step 8. That allows Bob to consent sharing information
with Contoso through our user experience. This consent
experience is in place to fulfill regulatory compliance such as
GDPR. And then after Bob consents, that triggers the last
step in the flow, where the invitation back end service
populates a special attribute and we call it alt-sec ID. That’s
short for alternative security identifier. The alt-sec ID is a
piece of metadata that indicates that Bob’s credentials are
not in the Contoso tenant but instead the credentials need to
be found in the Fabrikam tenant. At this point in time, the
provisioning flow is completed, and the user is no longer
marked as pending. Then Bob can go and access Microsoft
Teams and any other application or resource he has access to.
Corissa, would you like to walk us through the next scenario?
Corissa: Yes. Thanks, Ramiro. So, user objects can also be
provisioned with a social ID, for example, Gmail. The flow is
very similar except instead of having users from two
different tenants in Azure AD, you have Ann from Contoso,
the resource tenant, inviting Bob, who has a Gmail account.
For this to work, the Contoso administrator has to configure
Gmail as an identity provider.
So, Step 1 through 5 are exactly the same as the previous
diagram. Azure AD authentication services then has the ability
to go and talk to Gmail, redirecting the user to authenticate
with Gmail using OAuth.
In Step 6, Bob interacts with the social IDP through OAuth
and sends a token back to authentication services. And in
Step 7, the social IDB token is validated. After validation,
Step 8 and 9 are exactly the same. So, if this wasn’t exciting
enough, there is more.
Ramiro: In the next identity program, we have external
identity provisioning with direct federation. This is a good fit
for cases where Contoso needs to collaborate with an
organization that doesn’t have an Azure AD tenant but may
have a federation service that’s SAML or WS Federation
protocols. For this example, let’s say Bob is now in
Fabrikamagency.com and that’s a company that doesn’t have
an Azure AD tenant, but they have an AD FS somewhere. The
information about the federation service, the certificates, and
the domain, etc., that has to be configured ahead of time by
the Contoso administrator. The first five steps of the flow are
identical to the previous ones.
In Step 6, the authentication service redirects the user
to the federation service per the configuration. So, in this
case, it’s going to talk to AD FS. After Bob authenticates,
it will send a SAML assertion back to the authentication
service.
In Step 7, Azure AD authentication service will validate a
SAML assertion. And then after that, Steps 8 and 9 are
exactly the same as the previous cases.
Corissa: The last scenario that we’re going to cover is the
email one-time passcode or EOTP, which is a proof of
possession of an email address to authenticate the user.
This option allows customers to collaborate with anyone
who has an email address but can’t use any of the other
three options we discussed before. This flow also needs to
be enabled by the administrator.
So, referring to the diagram, Steps 1 through 5 are identical
to the previous flows. In Step 6, the authentication service
generates a one-time passcode and uses a high performing
messaging service to send the OTP to Bob’s email. Bob can
then retrieve the OTP from his email and we validate the
OTP in Step 7. Again, the last steps are the same; Bob
consents to sharing with Contoso and an alt-sec ID is
populated.
Ramiro: Here are some key takeaways for external
identity provisioning. Resource tenant owns the external
user object lifecycle. They can add him to groups, change
attributes or anything else that you can do with a user
object. The external user owns the credential. All four
techniques that we saw today allow you to collaborate
with pretty much anybody without creating local accounts
for external users.
The flow is exactly the same across all the scenarios. The
technique to authenticate external user is the only thing
that changes. Tenant to tenant invitation works by default,
but all the other three methods need to be configured by
the administrator ahead of time.
We want to thank you for joining us today. We hope you found
this video useful. We’ll be adding more videos on different
topics over time, so please see the description below for
additional information.
Corissa: Thank you.
[MUSIC]