Now that you understand what claims are and how they're issued, let's talk about the different protocols
that are supported in ADF's for authentication because this will help you understand how applications
interact with the service.
In this clip, we'll talk about the two older protocols that are still supported, which are W's Federation
and SAML 2.0.
And in the next clip, we'll discuss the newer protocol used a lot on the web called OpenID Connect,
which Microsoft often refers to as modern authentication.
Double Federation and SAML 2.0 are often referred to in general as single sign on.
That's because that was really the purpose for them when they were first developed.
A user could sign into the identity provider, which in our case is ADF's, and if they visit another
application that's protected by the same identity provider, they don't need to authenticate again.
This works within your organisation and when organisations are federated together it allows users in
one organisation to access the applications of another organisation using single sign on also.
Let's look at these authentication flows in more detail, starting with the application within a user's
organisation.
You'll typically use open ID connect to protect modern applications, which we'll look at in the next
clip.
But this is still a valid use case and the process is the same at a high level.
A user uses a browser to attempt to access a web resource that's protected by ADF's.
The application has already been configured to use the ADF's server and the ADF's server knows about
this application and has claims rules configured for it.
The application picks up that the user isn't authenticated already, so the application redirects the
user's browser to the ADF's endpoint to authenticate the user.
The user authenticates with ad fs using whatever authentication method is configured as the primary
may be windows authentication forms based authentication, or even using the Azure MFA authenticator
on the user's device.
If the relying party configuration for the application requires that the user perform multi-factor authentication,
then the secondary authentication method is invoked for the user also.
If the user authenticates successfully, then ADF sends a redirect response to the user's browser along
with the security token containing the claims, and this causes the browser to redirect to the web resource
they were trying to access.
And that application can read the security token and extract the claims to have information about the
user as well as other claims that can be used to make authorization decisions in a federation scenario.
The process is similar, except when the user is redirected to the partner organization's identity server,
which could be an ad FS server or any product that supports the protocols.
The user enters their login information and the server picks up that their login relates to the user's
organization.
This is called Home Realm Discovery.
So the partner organization ADF's server redirects the user to the ADF's server of the user's organisation
where the user can authenticate.
In this scenario, the ADF's servers have been federated.
When the user authenticates successfully, they're redirected back to the first ADF's server with a
security token where the claims issued can be transformed by the partner organisation.
From here it's the same as the previous scenario.
Then the user is redirected back to the original application with claims issued by the organisation.
The flows you just saw are actually the same for both W's Federation and for SAML 2.0.
They just differ in the protocols that are used for sign in and the token type.
In order to understand where protocols fit, consider that there are three elements in an authentication
flow the sign in protocol, the authentication protocol and the token type.
The Signing Protocol for Federation and SAML 2.0 differ in the query string parameters that are sent
to the ADF's server when the resource server or relying party redirects the browser to ADF's.
We'll talk more about that shortly.
The authentication protocol relates to the different authentication methods that will be configuring
in the next module, like Windows Authentication Forms, based authentication or certificates.
And the token types are the format of the token data that's returned.
Both WC Federation and SAML 2.0 authentication flows.
Both return the tokens in a SAML format, which stands for Security Assertion Markup Language.
The difference is that US Federation uses the SAML 1.1 format and the SAML 2.0 authentication process
flow uses SAML 2.0 token format.
So as SAML is a token type.
And in the case of SAML 2.0, it's also an authentication protocol.
We'll look at these same three elements in the next clip when we examine OpenID Connect.
Let's look at how the sign in protocols differ.
When the user tries to access a protected resource, the middleware on that server, like ASP.NET Core,
for example, detects that the user isn't authenticated because the user doesn't have a valid authentication
cookie.
So because the application has been configured to use PDFs, the middleware formats, the URI from those
parameters in the configuration, the middleware knows to redirect the user's browser to the ad FS endpoint
that's been configured for Federation and the query string parameter of why is required and is set the
signal 1.0 to tell ADF's to invoke the login for the user.
The trial parameter matches the identifier for the application that's been configured for the relying
party trust in ADF's.
So this is what tells ADF's which relying party the user is trying to authenticate to.
So ADF FFS can prepare the right claims rules.
Optionally you can include information in the WCT parameter that you want sent back after authentication.
This essentially lets you pass around state information and another optional parameter WCT lets you
send the exact time authentication was attempted.
Now let's see an example of a SAML 2.0 sign in attempt.
This one isn't so obvious.
There's a parameter called SAML request that contains a base six four encoded XML document with the
information needed to complete the request.
And this is information similar to what was sent in the US Federation request, like the idea of the
application that access is being requested for.
There are also optional parameters like the ability to send data back after authentication similar to
the WCT parameter in the US Federation in parameters related to the digital signature used to sign the
request.
So when would you want to use.
Federation versus SAML 2.0.
It just depends on the application you're trying to access or the system you're federating your ADF's
server with.
If you're in the Microsoft world, for example, federating with another ADF's server in a partner organisation
you'd use was federation.
But saying 2.0 is supported by many third party applications, so it has better interoperability across
different vendors.
When you configure a relying party trust in ADF's, you have the option to configure it manually or
import data to do the configuration for you.
You can enter the location of the Federation metadata document for the third party identity server or
add FS server or in some cases the vendor will export that information to a file that you can import
here to do your configuration.
And all this is possible because products conform to the US Federation or SAML 2.0 standards.
So protocols for single sign on have given organisations a way to unify authentication systems and federate
across organizational boundaries.
Service oriented architectures and social media have created new needs for applications to use a wide
variety of APIs on the Internet and use them for many different platforms.
The technology that's now widely used for authorization in modern applications is off 2.0, and Open
ID Connect is an extension to off 2.0 that provides authentication.
Let's talk about how those are supported in ADF's 2019 in the next clip.