[MUSIC]
Maria Lai: Welcome back. In the last video, I showed you
how Azure AD B2B is an easier and better way to collaborate
using the example of WoodGrove, a bakery chain needing to
share inventory information to their wheat wholesaler supplier,
AmazingWheat. Now, as a manager of a bakery chain, not
only did you need to collaborate with suppliers, you also
need to collaborate with photographers, marketing consultants,
and influencers in order to advertise their baked goods and
desserts. In this video, I will show you how B2B enables easy
sharing with any type of partner, whether or not they also
have an Azure AD account.
Let’s go over the types of organization you might be working
with. The first kind, they use Azure AD. The second kind,
they use an IT solution but not Azure AD. The third kind, they
do not have an IT solution. So, they could be using consumer
domain accounts to communicate with you. We have designed
features that will enable you to collaborate with any type of
partner organization. I will explain each capability.
Let’s go back to when you need to share inventory data with
Adrian at AmazingWheat, who resides in Azure Active Directory.
Recall this is how authentication happens in this scenario.
Adrian@AmazingWheat.com initiates access to shared
application. WoodGrove finds the user to see if the user has
been invited. WoodGrove sends the user to AmazingWheat
to sign in. AmazingWheat returns token to WoodGrove
and then Adrian gains access to share application.
Okay. Now, how does B2B enable you to collaborate with
Oaklyn, who has an Outlook account? In this scenario,
Oaklyn@outlook.com accesses shared application. WoodGrove
finds the user to see user has been invited and WoodGrove
sends user to Microsoft account to sign in. Microsoft returns
the token to WoodGrove and Oaklyn gains access to shared
application.
Let’s talk about sharing with non-Azure AD, non-native
Microsoft accounts. Take, for example, Grace, who has a Gmail
account, in a world before Google federation, Gmail accounts
sign up for a Microsoft accounts to share resources to
collaborate with people who have Gmail accounts even more
seamlessly. You can turn on Google federation, which enables
Grace@gmail.com to sign in with her Google account. In this
scenario, auth works by having the user goes to Google to
sign in in step 3 and then the user gets access after signing
in at Google.
For partner organizations who use AD FS or non-Azure AD
solutions, like OKTA, Ping, or G-Suite, you can enable direct
federation. For example, after you enable direct federation
with dairyspecial.com, which uses AD FS, then @dairyspecial.com
can sign into inventory apps. You share with him using
his dairyspecial account. In this scenario, dan@dairyspecial.com
initiates access to shared application. WoodGrove finds a
user to see if the user has been invited .WoodGrove sends
a user to AD FS to sign. AD FS returns token to WoodGrove.
WoodGrove validated token, issues new Azure AD token for
app access.
Phew. We can do so much already with Google federation and
direct federation. But what about guests who cannot sign in
through a federation? For non-Azure AD and non-Microsoft
account guests who cannot sign in through a B2B federation,
they can authenticate using the email one-time passcode.
No need for account sign-up. Email one-time passcode is
also a great solution for guests who are still not yet on a
cloud.
In this case, when Emma initiates access to shared application,
WoodGrove finds the user to see that she has been invited.
WoodGrove sends Emma an email with a one-time passcode.
Emma retrieves the code and then returns the code to WoodGrove
for sign-in. Then Emma gets access to application.
For both direct federation and one-time passcode, because
the user has to prove out the continued ownership of their
work account or email inbox, they no longer have access to
your shared corporate resources after they leave the company,
reducing headaches for IT admins.
Now, let me demo how to set up Google federation and
direct federation.
I am in Azure AD portal and I’m in organizational
relationships, identity providers. I click on Google here.
And I must have configured credentials already on Google
API side. You can go to documentation link in order to see
our steps on how to do that. Once I have configured it
successful on Google APIs, I can copy the client ID and a
client secret in order to finish configuration.
There you go. So now, after that you have successfully
configured Google federation, Grace@gmail.com will use
her Gmail account to sign in to your shared resources.
Next, I will do a demo of how to set up direct federation.
Here’s how you set up direct federation. And just simply
for your configuration Google federation, you click on new
enterprise identity provider. First, you must configure the
federating identity provider as well, and you select the
protocol, which is WS-FED in this case. And you click on
the name of your domain and scan.
And click save. There you go. Direct federation has been
successfully configured. Users from directfed01.nd will now
move to use their AD FS account in order to sign in.
For all of these types of accounts, the only different is in
the way the user authenticates, whether they are Google,
direct fed or one-time passcode guest, they appear like
any other guest in Azure AD and can have the same control
mechanisms like MFA and conditional access.
In summary, Google federation, direct federation, and one-
time passcodes make guests’ onboarding even more
seamless by having no account signup, enabling guests to
bring their own identities, thus, reducing the sets of
credentials they have to protect and gives admins lightweight
lifecycle management.
In the next video, I will cover some tools that will help you
to manage guest access even more.
[MUSIC]