[MUSIC]
Stuart Kwan: Hi. I’m Stuart Kwan and I’m a Program Manager
with the Azure Active Directory team and in this video, we’re
going to take look at federated web authentication.
In previous videos, we’ve been talking about how Alice, our
hero sitting here at her browser, is accessing a website.
And in this case, let’s actually use a real website now, say
SharePoint Online. And SharePoint Online trusts an identity
provider that we all know and love called Azure Active Directory.
And let’s do a scenario where Alice’s organization is actually
federated, so her credentials are not stored in Azure AD.
Her credentials are actually on-premise at a combination of
Active Directory and Active Directory Federation Services.
And let’s look at what happens when Alice comes to
authenticate to SharePoint Online. So as before, she
navigates her browser to SharePoint Online. And let’s assume
there’s no session set up. There’s no cookie in her browser
for SharePoint Online. She needs to authenticate. SharePoint
Online has a trust relationship with Azure Active Directory, so
what it’s going to do is it’s going to use Alice’s browser to
send an authentication request through her browser to
Azure Active Directory.
Now, here’s the difference between the earlier scenario,
where we looked at Alice just doing a normal web
authentication or an authentication using modern
authentication with a web application. Azure AD doesn’t
know Alice’s credentials, doesn’t know her password,
it doesn’t know how to authenticate her. It needs to
send her somewhere where she can be authenticated.
And the trick in federation is this one additional concept
that we need to understand that’s called home realm
discovery. And home realm discovery is the process of
sending Alice to the place where she can actually
authenticate. The way that Azure Active Directory does
this is actually pretty interesting.
When Alice is looking at the sign-in page of Azure Active
Directory—and you’ll have seen this before yourself—it
first asks her to enter her username. And she enters
Alice@Contoso.com let’s say. And then she presses next.
What Azure Active Directory does is it uses this bit of
information in her sign-in name as a hint. It takes
Contoso.com and it looks in the configuration in Azure
Active Directory. Is Contoso.com a federated directory?
And if it is, it knows that it now needs to issue a sign-in
request to the AD FS server or the federation server that
belongs to Contoso.com to get Alice to be signed in.
There’s a variety of different ways in these protocols for
either the user or even the application to provide this hint
that will allow home realm discovery to be completed so
that we can send Alice onto be authenticated. But we
now know we need to send her to that AD FS server and
what Azure AD does is it, again, issues a sign-in request
through Alice’s browser in the form of a redirect to get
her authenticated with her AD FS server. How that happens
is, again, a matter between Alice and her AD FS server. It
could be a name and password she enters in a form. If
she’s using a domain joined machine and she’s on the
corporate network and she’s signed in with her domain
account, then maybe that authentication with the AD FS
server can be a Kerberos authentication, in which case,
she doesn’t need to present any credentials; she’s
basically already signed in. Either way, the AD FS server
signs her in, makes sure it really is Alice and then it responds
to that sign-in request from Azure AD and it sends a token
back through to Azure AD. We’ll call it t1 that represents
Alice. Because of the trust relationship that Azure AD has
with Contoso’s AD FS server, it can validate the signature
on that token t1 and it can recognize that this is Alice. And
then, it can respond to that sign-in request that was sent
originally by SharePoint Online. And, of course, it does that
by sending a token through a post. We’ll call this token t2.
And SharePoint Online through knowing that it has a trust
relationship with Azure AD and knows where to find the
sign-in keys for Azure AD can validate the signature on
that token. It can know that it’s Alice and it can go on its
way. Now, there’s a couple of interesting things to look at
in this particular arrangement. For example, what’s the
relationship, if any, between token t1 and token t2.
And the answer there is, there is absolutely no necessary
relationship between these tokens and the claims that
are in them. Token t1 has the claims that AD FS knows
that Azure AD needs to have to be able to recognize Alice.
And token t2 has claims in it that are issued by Azure AD
that it knows SharePoint needs to have in order for it to
do its job.
Furthermore, we could actually have different protocols
happening here, say SharePoint Online could send its
sign-in request to Azure AD as an OpenID connect request
and Azure AD could send its request to AD FS as an SAML
2.0 request and everything still works. The identity
providers in this diagram allows this sort of impedance
matching to happen where we make sure the right protocols
are used for the relationship and the right claims are passed
in these various relationships.
Sometimes we look Azure AD in this particular setup and we
say that what it’s doing is it’s transforming the claims that
come from t1 into the claims needed by SharePoint in token t2.
But there we have it. Alice was able to sign in to SharePoint
through a federated authentication. And that’s the basics
of federated authentication for a web application.