[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.
