Let's start this module by talking about claims in ADF's.
Claims are the key component that are used to determine the outcome of all web based authentication
and authorizations, claims or statements made about users.
Each claim has a type and a value.
That type can be a well known type ID or you can create your own if needed.
And claims are retrieved from an attribute store.
That attribute store is Active Directory by default.
But in ADF's you can also pull information about users from other attributes stores like a SQL Server
database or an LDAP store.
Claims are mainly used for authorizing access to claims based applications.
Typically that authorisation happens right within ADF's, but you can also send claims back to the application
the user is trying to access.
So authorisation decisions can be made there too.
Let's actually look at the list of claim descriptions right in ADF's 2019.
Each claim has a type and the value gets populated from the attribute store during the authentication
process.
These are the claims that ADF comes with by default, but you can add custom claims here or you can
return completely different custom clans using a claims rule in code.
But these are the claims that ADF's publishes in its Federation metadata XML file, which tells other
partner organisations that want to federate with the server just which claims the server can send and
accept.
And that's defined in these columns here, which you can edit.
You can see some expected claim types about the users being authenticated, like the user's name, email
address and group information.
But there are also claims here like information about the authentication method the user used in things
like the device OS version and device registration information if device registration is in use.
There are also claims here related to 6.509 certificates and whether the user is inside the corporate
network.
You can edit these clean descriptions, for example, if you want to change whether they're published
in the Federation metadata XML document and you can add your own plane descriptions here that can also
be issued by ADF's.
By default.
The values for many of these claims come from Active Directory.
But seeing as they're defined here using known claim types, the values could come from any attribute
store that's compatible with PDFs like an LDAP store or a SQL Server database.
And you'll see that in the next module.
Some claims are a product of the environment the user is logging in from, like the claim inside corporate
network or about the computer the user is accessing PDFs from like his known device or the claim could
be a byproduct of the authentication process itself, like the authentication method and timestamp.
And again, these claims could be evaluated while authenticating and authorizing the user in advance
and they could get sent back to the application the user is requesting access to or to the Federation
Partners server.
A really powerful feature of ADF's is that it contains a claims rule engine.
So besides allowing you to pass claims through that are retrieved from the attribute store, it can
also transform the claim to another value based on logic expressed in a rule.
For example, you might want any administrator within Active Directory to have admin access within your
application.
But there are several group names for administrators like domain admins, enterprise admins and security
admins.
And you don't want your application have to take that into account.
The app only needs to know if the user is an admin.
You could retrieve the user's groups from Active Directory as claims and evaluate them within a claim
rule and then pass back a single claim that indicates the user is an administrator.
That's a simple example of a single claim.
So keep in mind that all the user's claims are sent back inside a security token, and we'll talk more
about the different formats for those tokens in the next couple of clips.
When ADF retrieves claims for an authenticated user, they move through stages in advance where they're
evaluated and possibly transformed before being sent back to the calling application.
This is called the claims pipeline.
The three stages in the claims roll pipeline are acceptance of incoming claims, authorization of the
claims requester and issuance of outgoing claims.
The actual evaluation of claims that each point in the pipeline is done by the claims engine.
And when you need to control the flow of those claims, you use business logic called claims rules.
Claims rules allow you as the administrator to control the claims pipeline at the different stages.
They're evaluated in order so each rule can create or transform claims that are used by the next rule.
In the acceptance stage.
The claims rule engine accepts claims that are either coming from the attribute store that ADF's is
using, which is typically Active Directory or in the case of a federation scenario, the claims would
be coming from a federated partner's identity provider, which might be another ADF server.
Either way, in the acceptance stage, claims are extracted and any claims that aren't expected or trusted
are filtered out.
Then claims rules are run.
Let's take a look at these claims rules in advance for the default claims provider trust, which is
Active Directory.
Let's go to claims provider trusts and we only have the default configured which is Active Directory.
So I'll right click and edit claim rules when the user authenticates the claims for the user are retrieved
from the claims provider trust.
You can see the following claims rules are created by default and they involve passing through specific
claims retrieved from Active Directory.
Let's look at this first one.
Pass through all Windows account name claims.
This takes the incoming claim type, which is the Windows account name and just passes it through to
the next claim rule and ultimately to the next stage of the claims pipeline.
This rule is based on a template, though, and that template allows for filtering this claim.
So it's only passed through with the claim has a specific value if the claim value matches a specific
email suffix, or if the claim value starts with a specific value.
You can click this button to see the actual claim rule language that this template is creating underneath.
Now let's close this and let's look at adding a rule.
These are the claim rule templates that are available in advance, and these same templates are actually
available in the issuance stage of the claims roll pipeline also.
I won't go through them in detail, but you can see there's a template related to LDAP attributes one
related to group membership, a template that allows you to transform an incoming claim.
The template we just saw which lets you pass through or filter a claim and a template that lets you
write custom rules using claims rule language.
You'll see an example of this in the demos later in this module.
Once the acceptance transform rules are run, the claims are passed to the authorization stage where
more claims rules are run.
Let's examine these rules in a DFS.
In the authorization stage.
Access control policies are run on the individual relying party trust or a server resource in an application
group in the case of OAuth clients.
Authorization rules also have templates.
So let's take a look.
Here are the built in access control policies that come with ADF's, but you can create your own and
I'll show you that later in this module too.
These policies are evaluated after the user has authenticated with whatever credentials you've configured
as the primary credentials.
You can see there's a policy that allows access to every authenticated user, a policy that permits
access based on membership in a particular security group.
There's a policy that allows anyone to access the relying party if they're coming from the intranet
and policies that require multi-factor authentication to be invoked under specific circumstances, like
if the user is coming from the Internet, has an unauthenticated device, or if they belong to a certain
group.
The parameters for some of these templates, like the groups the user needs to be a member of are configured
when the template is applied to a specific relying party that's indicated by the parameter value in
the rule properties.
The authorisation stage of the claims pipeline results in a decision whether or not the token requester
is allowed to obtain a token for the relying party that they're trying to access.
In other words, if the user fails primary or multi-factor authentication, then the process stops here
and an error is returned to the caller.
If authentication was successful, then the claims are passed to the issuance stage of the pipeline
where again they could be filtered, transformed or pass through using the same claims templates we
saw in the acceptance stage.
And like the authorization stage, the rules here are configured specifically for the relying party
application the user is trying to access.
Now that you understand how claims are issued by ADF's, we'll talk next about the different security
protocols that those relying parties use to set up trusts with ADF's and exchange information over https.
Then you'll learn about application groups which allow you to group together the web clients, native
clients and APIs that typically make up a modern application that uses the OAuth 2.0 protocol.
Next, we'll create an ASP.NET Core Web application and Visual Studio to integrate with ADF's and display
the claims that are received.
You can just download the app from the course downloads if you prefer.
But walking through the steps of creating it will show you the middleware that supports show off 2.0
and open ID connect.
Then we'll configure an Add FS application group to authenticate users of the application and return
claims, and we'll examine some of the different claim rules.
After that, I'll show you how to use claims to perform authorization in the ASP.NET Core Web application.
Then we'll package up the application and see how to deploy it to IIS.
If you didn't create the application yourself in Visual Studio, you can just use the packaged application
in the course downloads.
Then you'll see custom access policies in advance which allow you to set up your own authorization rules.
And finally, we'll look at a feature that's new in ADF's 2019, which allows you to customize HTTP
security response headers.
So next, let's talk about how these claims get passed around in various authentication flows.
And in the process, we'll talk about the authentication protocols that ADF's supports.