Welcome to the ITFreeTraining video on Federation Services Terminology. This video will look
at all the terminology you need to understand in order to start using Federation Services
effectively.
As you can see, there are 17 different terms that I will look at in this video. Federation
Services has its fair share of Terminology but don't worry, I have sorted them into
a logical order to make it easy to understand. So let's get started.
The first term that I will look at is the Account Partner Organization. This is simply
the organization that contains the users that will be used with federation services. In
this example, these are users in the domain ITFreeTraining. These users will be the users
that will access resources using federation services. The important point to remember
is the account partner organization contains the users, their passwords and other relevant
information about those users. So this brings up the next question, what are these users
accessing?
These users access resources in the Resource Partner Organization. A resource partner organization
is simply an organization that hosts federated applications. For example, these could be
held in a child domain, an external business domain or services in a cloud. The important
point to remember is that a resource partner organization allows users from an account
partner to access services using web services. For example, a resource partner may have services
like e-mail or applications like Office that the user can access using web protocols. The
next point to consider is how the account partner organization and resource partner
organization are connected.
In order to connect both, a Federation trust is created. If you are familiar with an Active
Directory trust, you will know that it is connection-based trust means data is required
to travel over it, otherwise the trust is not useable. A Federation trust is different
in that it is a non-connection style trust. This means no communication happens over the
trust, unlike an Active Directory trust. It is possible to setup the trust by accessing
the other company's Federation Service, however it is also possible to set up the
trust manually without access to the other server. The important point is that a certificate
is required in the resource partner organization so this will need to be transferred and imported
into the resource organization.
Effectively the resource partner organization is saying that I trust the users in the account
partner organization and will allow them access. But how does the user request this access.
In order to grant access, the federation server in the accounts partner organization creates
a claim. A claim contains identification details of the user asking for the access and also
which service they would like access to.
Essentially a claim is just a file. In other videos from this course I go into more detail
about how the claim file works and how it is used in federation services. In this example,
notice that the user and e-mail service is added to the claim. The claim is signed by
the server and presented to the other Federation Server in the resource Partner Organization.
This is a simplification of the process, but you should get the idea that a claim is essentially
a statement about who the user is and what they would like access to.
This brings us to the next term, Claims Provider Trust. Now we already know that a Federation
Trust is required for Active Directory Federation Services to work; however, Active Directory
Federation Services supports two kinds of trusts, the first one being the Claims Provider
Trust.
A claims provider trust is normally created in the resource partner organization and essentially
defines how the other organization will access the resources. So this includes the basic
rules for the trusts, what it can access and who can use this trust. Or in simple terms,
defines who and how the trust is used. Personally I think the name is misleading. You would
think that a Claims Provider Trust would create claims; however it does the opposite and
accepts them.
Normally a file will be provided to the resource partner organization with this information,
but if it is not, the information can be entered in manually. Once created, this defines the
rules the resource partner organization will use to provide access to resources.
The next trust that I will look at is the relying party trust. It is a simple thing
to say I trust another organization's users to access Active Directory Federation Services.
However, for the whole system to work, Active Directory Federation Services needs to access
non Federation Services. For example, when a user requests access, they must be authenticated,
and this means the Federation Server must contact a service like Active Directory Domain
Services. This requires a relying party trust. The relying party trust in this case is essentially
the configuration created on Active Directory Federation Services that describes how it
will access other resources. In this example, how it will access Active Directory.
The relying Party Trust is also used in the resource partner organization. For example,
to access a Claim Aware Application. In order for this to occur, the Federation Server must
trust the server running the Claim Aware Application. Once again, the relying party trust is created
on Active Directory Federation Services and defines the trust relationship between it
and the claim aware application.
So essentially a relying party trust is used by Active Directory Federation Services to
issue claims. If you get confused, remember claims provided trusts accept claims. Relying
parting trust create claims. In later videos I will look at how to create these trusts.
A claims provider trust will be on one side and relying part trust on the other. If you
not sure which ask yourself which side is accepting claims and this will be the claims
provider trust. In later videos, when I set up Active Directory Federation Services, this
will make more sense.
The next term I will look at is Claims Provider. The claims provider is the organization that
provides a claim to its users. In most cases, this is the Account Partner Organization.
The claims are used by claims-aware applications and this can happen in a number of different
ways.
Let's consider a domain that is holding the Active Directory Federation Services which
creates claims for its users. These claims are used to access claim-aware applications.
These will normally be in an external domain; however, could also be in the cloud or, in
some cases, in the same domain as the Active Directory Federation Server. You can see how
there is a lot of flexibility in how these claims can be used by an organization. Why
would you use Active Directory Federation Services in the same domain? If a user was
mobile, some organizations will place the Claims-aware application in their perimeter
network for the mobile users to access. This is one way a company can choose to keep their
network secure.
The next term I will look at is Federation Server. This is simply a server that is configured
to run Active Directory Federation Services. In other words, the Active Directory Federation
Services role has been added and configured.
The next term is Account Federation Server. This is an Active Directory Federation Server
that issues security tokens to a user. To understand what a security token is, consider
that you have an Active Directory Federation Server and a user.
The Active Directory Federation Server will create a security token. Inside this security
token is placed a claim. The security token is then given to the user. Thus an account
federation Server provides security tokens to the user. So the question is, where does the
federation server obtain the information to put inside this security token and the claim?
To obtain information to create a token, information is obtained from an attribute store. This
is essentially a database. Common databases that are used are Active Directory Domain
Services and SQL Server.
So, essentially, this database contains details about the users. It should be pointed out
that this is different from authentication. For example, a user could be authenticated
by a Domain Controller and then additional attributes obtained from an SQL Server. Having
said this, the user could also be authenticate by a Domain Controller and then details (like
their first and last name) could be obtained from the Domain Controller. You can see the
attribute store simply contains information that is used to create the claim.
For example, perhaps there is a requirement that all claims have a picture of the user
in them. Active Directory does include this ability by default. It could be added, but
most administrators do not like adding features like this as it involves changing the schema
which cannot be reversed once done.
To get around this, after the user is authenticated, a claim is created with information like the
user name obtained from Active Directory. However, the picture is obtained from an SQL
Server. You can see how an attribute store is used to hold information to be used in
the claim. You can see that even though Active Directory can be used as an attribute store,
this is separate from authentication. Essentially the attribute store is a database that is
used to obtain information to store in a claim.
The next point to consider is how configuration information is transferred between different
Active Directory Federation Services. If you consider an account and resource organization,
a trust needs to be created between these two. This can be done manually but this involves
some extra work.
Rather than performing the step manually, the configuration data can be exported. This
can then be transferred to the other server using any method. For example, via the network,
e-mail or through the postal service. This data is then imported into the other server.
Thus, essentially, the Federation Metadata is the data format used for configuration.
It uses Security Assertion Markup Language for the data format. It is not important that
you understand how this works at present, as it will be covered in more detail in a
later video.
Each Active Directory Federation Service instance stores its data in a database. This is referred
to as AD FS Configuration Database. If you have SQL Server on your network, you can use
this to store that configuration in. If you do not, you can use the internal Windows Database
to store the data in. The important point to remember is that an AD FS Configuration
Database is required in order to run Active Directory Federation Services.
The next term I would like to look at is the Primary Federation Server. When you create
a farm of Active Directory Federation Servers, the first server added to the farm is the
Primary Federation Server. This server has a read/write copy of the configuration database.
If you add additional Federation Servers to the farm, these Federation Servers will have
a read-only copy of the database. These Federation Servers will need to replicate any changes
made to the configuration database to the Primary Federation Server holding a read/write
copy of the database.
The next term I will look at is Federated Users. A federated user is a user that has
been provided with a claim. This claim allows them to access an application or resource.
For example, if a Federation Server were to issue a claim to a user, this user would now
be a federated user.
The next term is relying party. This is simply the organization that receives and processes
the claim. Essentially this is the resource partner so if you see this term you know it
is referring to the resource partner organization.
The next term I will look at is Resource Federation Server. This is a federation server in the
resource partner organization. What a resource Federation server will typically do is this.
A user will obtain a security token from their account federation server. This will have
the claim information inside it, but does not give them access to anything.
This security token is presented to the resource federation server. The security token is checked
to make sure it is valid and then the claim removed from inside. This claim is used to
create a new claim and then the old claim is destroyed. The point to remember here is
that this new claim is based off the old claim. This new claim defines what the user can have
access to. It is then placed inside a security token and given to the user. The user is free
then to use this security tokens to access services or resources.
If this is confusing, think of it like this. It's like getting a letter telling you your
driver's license has been approved. If you head off to collect your driver's license.
The person at the counter looks at the letter and sees it is legitimate. They then say I
cannot issue you a driver's license, you need to go see this person. The person behind
the counter keeps the letter but they give you another document so you can claim your
driver�s license. All you need to do now is see that person, give them the document
that you were given and you will be able to collect your driver's license. A resource
federation server works off the same principle: you give a claim to the resource server, they
look at what you are asking for and then give you a different claim back so that you can
access what you asked for. These claims are stored in a security token so that they can
be checked to make sure they are legitimate.
The last term I will look at is Claims Aware Application. This is any application that
can accept claims. For example, a user that is given a security token from a resource
federation server can then give this security token to a claims aware application. The claims
aware application will then provide the user with the resource or service that they are
requesting. For example, Microsoft Office is an example of a claim aware application.
There has been a lot covered in this video, but unfortunately it is necessary to get the
building blocks in place before looking at how to use Federation Services.
I would like to thank you for watching this video and hope you have found it useful. I
also hope to see you in the other free Federation Service videos from us. Thanks and see you
next time.