Relying Party Trust Theory

Relying Party Trust Theory

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.

15 thoughts on “Relying Party Trust Theory

  1. can you please tell me which book to buy to read and get practice same as all this videos.It is very easy to understand for me.

  2. Honestly i keep re-playing your videos not because i don't understand absolutely not the reason is 'I love them, iam sure you know what i mean, very well done guys keep up the great work 🙂

  3. Fantastatic explanation, thank you so much! I've been struggling to understand this for a long time.

  4. Is there a good way to test that claims are being sent and received properly? It seems like a claims aware application is needed to actually put the trust to use.

  5. Thank you so much for such informative videos totally free of cost. Could you also please publish a video detailing "how the Claims Engine processes the claims?". There's a lot of text available on Microsoft websites but nothing beats a pictorial/video representation.

  6. Dear sir, these are the best of the best channel I've ever found in YouTube…. My heartful request is that please make a series on Azure… Pls pls pls

  7. You do make great videos. My teacher, and the text book we use, does not match up to how you and your group are able to explain this to people studying for their MCSA. Tried to go on your web site, but it does not seem like it is still in use. I hope you guys make more videos, and thanks for explaining ADFS.

  8. At 2:28, the first sub bullet is confusing. It's not clear if it's referring to the claim or the relying party trust configuration. If it's the latter, then I believe it shouldn't say "partner". If it's the former, then it should be "Used" (matching what the speaker says). In any case, what he says at the time that first sub bullet point is presented does not match what is shown.

Leave a Reply

Your email address will not be published. Required fields are marked *