In this video from ITFreeTraining, I will look at the Relying Party Trust found in Active
Directory Federation Services. The Relying Party Trust determines what data is included
in a claim. The terminology for trusts in Active Directory Federation Services may seem
backward, so I will first have a quick look at how the Active Directory Federation Trusts
work before I look at the Relying Party Trust.
In our example, ITFreeTraining has a server running Active Directory Federation Services,
and so does HighCostTraining. In order for ITFreeTraining to create claims and send them
to HighCostTraining, there needs to be a relying party trust configured on the ITFreeTraining
side and a Claims Provider Trust configured on the HighCostTraining side.
This may seem different to what you would expect for the following reasons. If a claim
is created in ITFreeTraining, this claim contains information, for example it could contain
a user name, e-mail and other data. Once the claim is created, it is transferred to the
server. Typically the claim will go to the user, who will present this to a server. But
you get the idea that the claim is created and then transferred. So what does this mean?
It means that in order for ITFreeTraining to create a claim, it needs to know what to
put in the claim. So in order to do this, it needs some configuration information. So
another way to look at it is, on the ITFreeTraining side you are creating the relying party trust
configuration. This configuration determines what will go into the claim. If you were to
create the relying party trust on the HighCostTraining side… well, the claim has already been created
and cannot be changed afterwards. When HighCostTraining is given a claim, it has to make use of what
has been included in it. It cannot ask for additional information afterwards. Any information
it needs must be put into the claim. If you are a bit confused by this, it should all
start making sense soon.
If you look at what a relying party trust achieves, it essentially is the configuration
that is used to create claims. A relying party trust is used in the accounts partner organization.
In the previous example, ITFreeTraining would create a claim that could be used in HighCostTraining.
Relying Party Trusts can also be created in between the Federation Server and the Claim
aware application. In a moment, I will have a look at how that one works.
Once you configure a Relying Party Trust it is divided into 3 sets of rules as shown.
These are, Issuance Transform Rules, Issuance Authorization Rules and Delegation Authorization
Rules. To get a better idea how these work, let’s look at an example.
First let’s consider the Active Directory Federation Server in the ITFreeTraining domain.
This server needs to be configured to create claims to send to the HighCostTraining domain,
so how would you do this? First, you would create a Relying Party Trust on the ITFreeTraining
Federation server. The relying party trust defines the relationship with HighCostTraining.
This contains information like what encryption is to be used and defines what functionality
is available on the server. But the next point to consider is who will be allowed to use
this server to create claims?
In a typical environment you may have authorization determined by a Domain Controller. In order
for this to occur, you need a rule to define it. These rules are called “Issuance Authorization
Rules” and these rules define authorization.
In this example, I have used Active Directory to define who can use the server to create
claims; however, a rule could be created for just about anything. For example, the rule
may state that the user only requires a valid e-mail address. The rule could also query
a SQL server to allow access. Multiple rules could also be defined. For example, you could
define one rule which allows access only to domain users. However, you could also create
a second rule which denies users the ability to connect from a particular IP Address. For
example, perhaps you only want external users using the server and internal users to be blocked.
Now that the user has been authorized, the next step is to determine what information
will be sent to the other party in the claim. This is the part where you can see how customizable
Active Directory Federation Services can be.
In this example, a SQL server is used to store data that will be used in the claim. Once
the data is obtained, Active Directory Federation Services needs to know how this data should
be put into the claim. To do this, an issuance transform rule is used. An issuance transform
rule essentially converts the data to the form required in the claim; however, it can
also be used to change data as required.
The authorization rule is pretty straight forward, it defines who has access. Since
the issuance transform rule is a little more complex, let’s look at an example.
To start with, consider what happens when a claim is being created. When a request to
create a claim is created, the Issuance Transform rules are run. In this example, the first
rule that is run is “Get the user’s job title”. In order to get this information,
the attribute store is contacted which contains the job title which that user performs in
the company. AD FS uses this information to create the claim.
You can see how the issuance transform rule is used to tell AD FS what information should
be put into the claim. However, later on, you find out that a user obtained a claim
from the Federation Server but was not able to access the claims based application. When
you investigate the problem, you determine that no job title has been entered in, for
that user. When you contact HighCostTraining they tell you the application is hard coded
to expect a job title in the claim and it cannot be changed. They also tell you that
they do not use this information so you can set the value to whatever you like.
It is a lot of effort to make sure all the employees’ job titles are set correctly
and the problem needs to be fixed quickly. So to fix the problem, a second rule is created.
This rule states that if the job title is blank set it to ITFreeTraining Employee. This
way a value is always set in the claim for the value of job title.
You can see how Issuance Transform rules can be used to determine what information is used
in a claim, but also put it in the format that is required. It can take the raw data
and transform it to the required state. This is a very powerful feature of Active Directory
Federation Services.
The last rule I will look at is delegation authorization rules. This rule allows a user
to be impersonated. To understand why this is important, consider this example. A user
wants to access a claims aware application, so they contact an Active Directory Federation
Server to obtain a claim.
Once they have this token, they contact a web server using this claim, in order to get
the information that they want. Notice that because the user uses that claim to access
the application, this can be logged showing that they used the application.
The problem occurs in that the information they are after is on a secure SQL server that
only accepts claims for access through a claim aware application. The problem is that the
user does not have access to this server. So in order to get this information, the Web
Server obtains a claim using its access and obtains the information for that user on their
behalf using impersonation. So essentially delegation authorization rules is pretending
to be someone else in order to access another system. To better understand this, consider
a real world example.
Consider that you have a library. The library purchases an online subscription to a journal.
The library is now able to access the online journal. The problem is, how does the library
allow the users to access the online journal? If they had direct access, the library would
no longer have control over who has access. For example, the users could give the access
to other people or they could use it even if they stopped being members of the library.
To solve this, the users access the library server, which will then access the online
journal for them. You can see how impersonation works, it’s about pretending to be someone
else or accessing something on their behalf. You will notice with a system like this, although
the online journal would not know who is accessing the journal, the library could keep records
of this access.
There has been a lot covered in this video so I will now perform a quick summary of the
major points.
In order to have a trust relationship in Active Directory Federation Services, you require
a relying party trust and a claims provider trust. In this video I have looked at the
relying party trust. The easiest way to remember where this goes is to think of it as configured
on the side that creates claims.
If you consider this example, the ITFreeTraining Active Directory Federation Server creates
claims that are used by the HighCostTraining Federation Server. For this reason, the relying
Party Trust is configured on the ITFreeTraining side. Although this may seem opposite of what
you expect, remember that the server is creating the claim and is sending it to the other party.
For this reason, since it is creating the claim, it needs to know what it is creating.
Now also consider that, on the HighCostTraning side is a claims aware application. This server
uses claims, as well; however, it does not use the claims that are created by ITFreeTraining.
It only accepts claims from HighCostTraining. Typically, what happens is, when the user
presents the claim to the HighCostTraining Federation Server, the server will create
a new claim and give that to the user. The user can use this claim to access the claims
aware application. This is the same sort of principal as when you go to a store and purchase
an item, but rather than them giving you the item, they give you a token. You then use
that token to get the product you were after. The important point to remember is that since
the server is creating a claim, a relying party trust is required and defines how the
claim will be created. Once the claim is created, the claims aware application can use it.
The next point to remember is that a relying party trust has 3 sets of rules associated
with it. The Issuance Authorization Rules defines who can creates claims. For example,
you could have all users with a particular e-mail address or all users in a particular
group.
The Issuance Transform rules defines what data is put into the claim. This can be data
obtained from a number of different stores like Active Directory, SQL Server and Active
Directory Light Weight Directory Services, to name a few. Remember, also, that this data
can be changed if required. For example, if your usernames ended in dot local, you may
change the claim to have usernames that end in dot com.
Lastly you have delegation authorization rules. These rules allow a user to be impersonated.
This will generally be done so data can be fetched for the user that they do not have
access to while protecting the initial access. This is normally done so the user does not
have direct access and thus improves security.
That covers it for Relying Party Trusts. In the next video I will look at creating a relying
party trust. Till that video, thanks for watching and see you.