Welcome to the ITFreeTraining video on what are claims and the protocols that are used
with claims. By the end of this video you will have an excellent understanding of how
Federation based systems use claims to provide access to services and what protocols they use.
First of all, what is a claim? To put it in its simplest form, a claim is a statement
made by one party about another party. For example, suppose you have a user named Jane
Doe. Jane Doe may want to access another service on the network. This service however does
not know anything about Jane Doe. In order for Jane Doe to access this service, another
system called an Identity Provider is required.
The Identity provider knows who Jane Doe is and thus is willing to create a claim for
her. This claim contains information about Jane Doe, like her identity. If you have ever
used your Facebook login to access a non-face book site on the internet, this is the same
process. Facebook holds your identity. If you want to use your Facebook identity to
access another site, Facebook supplies you a claim that contains your identity.
Now that Jane Doe has a claim, she can use that claim to access the service. The next
point to consider is how claims are packaged.
A claim is placed inside a security token. So, when dealing with Federation Services,
you may hear the term claims and tokens used to describe the same thing. You may also hear
the phrase, 'the server consumes tokens'. To understand how this works, let's look at
a fictional example, first.
Consider that you have an employee who has done well. The company has decided to reward
the employee by giving them a voucher for a movie. In order to see the movie, the employee
would next need to present the voucher to a cinema. Once the voucher has been presented,
this is kept and a movie ticket is given to the employee. Once the employee has the movie
ticket, they can then use the movie ticket to see the movie.
You see how one item was exchanged for another. Federation Services will often be configured
in a simpler way.
Let's change this example to a typical Federation Service example. This time, the employee is
a computer requesting access to an application. In order to obtain this access, the computer
contacts a Federation Server in their company. This federation Server issues them a token
which contains a claim. This token may contain details, like the name of the person attempting
to get access.
The token is then presented to the server and it is consumed or destroyed. Next a second
token is created. This token contains details, like which server is running that application.
If you consider the previous example of the cinema, the voucher allows the employee to
see a movie, however once presented it was swapped for a movie ticket. The movie ticket
contains information on it like the number of the theater that the movie will be shown
in. In this case, the token contains information about which applications the computer may
access. Information like this was not available to the first server that created the first
token and is subject to change, just like which movie is showing in which theater.
Once the token has been created, it is transferred to the computer. This token can now be used
to access a claims aware application. You can see how a claim was incased inside a token
and used for authentication. A new token containing a claim was then created to determine what
they could access. Thus, when dealing with Federation Services, you may see the terms
security token and claims are used interchangeable but they are essentially referring to the
transfer of claims. I will now have a look at the protocols that are used to make this
process work.
Shown here are some of the protocols that may be used with Federation Services. Which
Federation System you use and how it is configured will determine which protocols are used. At
first it may look confusing, with so many protocols being used. To get a better understanding
I will have a look at some of them in more detail.
The first protocol that I will look at is WS-Trust. WS-Trust is the protocol that is
responsible for secure message exchange between different servers. This communication is used
to transfer tokens. This is important, as there are many different types of Federation
solutions. For example, if you have an Active Directory Federation Server and a Linux Based
Federation Server, there needs to be a common protocol between these systems to allow them
to communicate.
This protocol defines how a token will be exchanged between different parts of the Federation
system. The next question is what information is exchanged between the two parties?
The next protocol I will look at is SAML. SAML is an open standard for the exchange
of authentication between different parties. It is often used in Active Directory Federation
Services to create tokens.
So, essentially, what you have so far is this. You have the protocol WS-Trust which defines
how tokens are exchanged, their renewal, if required, and creation of a secure channel
for communication. SAML is used to create the token itself, although there are many
different protocols that could be used other than SAML. To think of it a different way.
Image you are using the postal system. The postal system defines how items are posted.
For example, they need to be in a box and they need to have an address and stamps on
them to be posted, but it is up to you to decide what to put in the box. In the example,
WS-Trust is used to define how communication will occur for tokens, however SAML is used
to define the token itself.
Federation Services can be used to communicate using many different methods. In most cases
certificates will be used; however, usernames and passwords could also be used. What can
be accepted is referred to as an 'end point'.
To better understand this concept, I will open Server Manager on this computer, which
is running Active Directory Federation Services. Once Server Manager is open, I will next open
Active Directory Federation Services Management from under the tools menu.
This server already has Active Directory Federation Services installed and configured. In later
videos I will have a look at how to do this; however, in this video I will have a quick
look at the configuration to better understanding of how end points work in Active
Directory Federation Services. This will also give us a better understanding of how the
protocols are used in a Federation Services.
From AD FS Management, I will expand down through services until I get to Endpoints.
This will show all the Endpoints this server currently accepts. If I select one, notice
this Endpoint uses "WS-Trust 2005". This means the other Federation servers will need to
support this as well.
Notice that under authentication this is listed as "Certificate". This means this Endpoint
will only accept "WS-Trust 2005" with certificates. If I select another Endpoint, notice that
this Endpoint is also "WS-Trust 2005" but this time the authentication type is SAML Token.
You can see how customizable Federation Services can be, allowing different protocols to be
used together. In a lot of cases, it is just a matter of making sure that both sides accept
the same protocols.
Notice further down, this Endpoint uses "WS-Trust 1.3" and the authentication type is Kerberos.
Kerberos is a ticket based system so, essentially, in an Active Directory environment, this means
a Kerberos token is created and presented to the server. This Endpoint would generally
be used inside a company.
If I scroll down, notice the end point under Metadata. This is an XML file that contains
the configuration information for the Federation Server. When setting up Trusts in Active Directory
Federation Services, which will be covered in later videos, this file is used in speeding
up that process. Without the XML file, when configuring a Federation Trust, the information
will need to be entered in manually for the trust.
The last two protocols that I will look at is WSDL and UDDI. Both of these protocols
are used to describe or advertise a web service. They are often used with other protocols,
so you may not come across them directly that much. For this reason, I simply will make
you aware of them at present but not go into detail about them.
Well, that covers it for claims and the protocols used for claims. I hope you have found this
video informative and hope that I see you in the other videos on this course and others.
Thanks for watching and see you next time.