Welcome to the ITFreeTraining video on how claim-based Federation identity systems work.
There are many different examples of these kinds of systems on the internet. Whenever
you login to a web site using your google or Facebook login, this is an example of a
Federation Identity system. In this particular video, I will use Active Directory Federation
Services as the example system; however, the same theories apply to many of the other Federation
systems.
Before I look at how a claim-based federation system would work, let us consider a fictional
example to get an idea of the principals involved. Consider an employee who is working for a
business called business A.
There is another business called business B that this employee wants to get some information
from. So the employee asks business B for this information. Typically, this kind of
request would go to their information desk.
The information the employee is asking for is kept in the main office. The business is
not going to allow people, who they do not know, into the main office. So, the employee
will need to go through the information desk in order to get this information. Also it
is up to the business if they want to release this information or not. At this stage, the
answer they give back is no, because they do not know who the employee is and they do
not want to give someone who they do not know any information.
There is an arrangement between business A and business B to provide this information,
but business B will not release this information without the person proving who they are and
that they are sure company A wants them to have this information.
So how does the employee prove who he is to the second company? In order to do this, the
employee contacts his information desk. The company is quite big so the information desk
does not know who he is, so they contact someone in the main office to confirm his identity.
The office will do their own kind of checks, and once they are happy, will give the green
light indicating that they believe that he is one of their employees and he is entitled
to ask for that information. Now that the information desk is happy, what they do is
create a letter that they give to the employee.
This letter indicates that this person works for their company and indicates the information
that they are asking for. This letter is then given to the information desk for business
B. The problem is that business B does not necessarily believe that the letter came from
business A so they want to be able to check if the letter is authentic.
In order to do this, business A creates a rule book explaining how to check a letter
issued by them to make sure it is authentic. Business A provides business B with this rule
book so they can now check any letters they are given to make sure they are authentic.
Now that the information desk has the rule book, the information desk can check the letter
to ensure that it is authentic. Now that the information desk knows the letter is authentic,
they can give the employee the information, However, notice that business B could still,
if they wanted to, decline to give out this information, but in this case they will release
this information to the employee.
Even though this is a fictional example, it shows the key points of a federation identity
service. These are, Business B being able to check that the employee is who he says
he is without having to contact Business A. Business B is able to do this because they
can verify that the letter given to them is authentic.
So how does all this relate to Federation services? Let's consider this example again;
but this time using Active Directory Federation Services.
First of all, in this example the employee is instead a mobile user using a laptop. To
obtain the information they want, they will contact a web server in business B asking
for the data. This web server will of course be behind a firewall.
The web server does not know who the user is and thus will reject the request saying
'I need authorization first'. The user will then contact business B's federation server
asking for permission. The federation server will also reject this request saying that
'I want proof you are who you say you are'.
In order to get this proof, the user will contact the federation server in business
A, where they work. Like the other federation server, this will be on a perimeter or DMZ
network and, thus, will be separated from the internet by a firewall.
To verify the user is who they say they are, the user will give the federation server their
username and password. The user could be authenticated in any way that you choose, for example they
could be authenticated using smart cards.
The federation server will not know if the username and password given is correct so
it will pass the user name and password to a domain controller on the internal network.
Since the domain controller is on an internal network, there is a firewall between the two
networks. You can see how this kind of system helps keep the network secure, as the user
is not contacting the Domain Controller directly from the internet.
The domain controller is able to check if the username and password are correct and
then responds back to the Federation server that the user is valid and the password given
is correct. Now that the user has been verified, the federation server creates what is referred
to as a 'claim' which is given to the user.
A claim contains information about who the user is and what they would like access to.
The claim is signed using the server's certificate. In order for it to be checked by another server,
the certificate needs to be exported from that federation server and imported into the
other federation server. In this case, Business A will export a certificate containing its
public key and send it to Business B. Transferring this certificate could be done using any media,
for example using e-mail. This process only needs to be completed once. If the company
were to purchase a certificate from a public CA, the public CA certificate may already
be in the local certificate store and thus the certificate may not need to be exported.
The user now has a claim which has been given to the Federation server in business B. Since
the federation server in business B has the certificate from the other federation server,
it can check the digital signature in the claim to make sure that it came from business
A's federation server. If the federation server is happy to allow the user access, remember
it is still up to the federation server to decide if they want the user to have access,
the federation server will approve the access.
Now that the user has been approved to access the data, that user can once again contact
the web server asking for the data. The web server does not have the data, the data is
stored on the internal network which is separated from the main network by a firewall. The web
server will have access to the file server on the internal network so it can request
the file. Since the web server is on a company network, the file server allows the file to
be transferred to the web server. The web server can then transfer the data to the user.
It may look like there is a lot to this process and in fact there is, but there are a number
of advantages to doing it this way. To show this, I will have a quick look at what would
be required using an Active Directory solution without federation services.
In order for a file to be accessed between the domains, a trust needs to be created.
This will allow business B to access Business A in order to check the username and password
of users requesting access to files. This requires changes to firewalls on both networks.
Since a trust relationship is being used, this requires a connection between both networks
in order to operate. If the connection is broken, the trust will stop working.
In order for a file transfer to occur, additional changes to the firewall rules need to be made.
So without going into too much detail about the requirements, you already need a trust
relationship to be established and firewall changes to be made. The average business is
not going to want to make these changes and if the businesses do not trust each other,
you can forget about the management approving a trust relationship between the two businesses.
So now that you understand what is involved with an Active Directory solution, let's consider
the advantage of using Federation services.
Federation services do not require a connection-style trust to be created. We saw before that a
certificate needs to exported from one federation server and used on the other. However, this
is only required once and does not require a connection in order to work once set up.
Federation services use standard web ports. There is a good chance these ports are already
open on the firewall and most businesses would have fewer issues opening these ports rather
than opening nonstandard ports.
Access is determined by using a claim. Claims are file-based and issued by the authenticating
company. This means the other company supplying the data does not need to worry about authenticating
users. Claims use standard web protocols. This makes them compatible with other systems.
In a later video I will have a closer look at the protocols that claims use.
This should give you a good idea of how claim-based federation services work. However, I will
look at one more example of how it works.
Let's consider the following example. It is becoming more common for businesses to outsource
some of their applications to external companies - like cloud based services. For example,
Microsoft offers Exchange and Office services in the cloud. In this example, I will consider
Exchange is being run on an outsourced company and a mobile user is attempting to access
the Exchange server. With users becoming more mobile, it makes more sense for a company
to outsource software like Exchange as this means the business no longer has the administrative
overhead of running, backing up and hiring staff for this purpose.
In order for the user to access Exchange, they first contact an outlook web server.
The web server will not know who they are so will respond back with, "I need authorization
first". In order to get this authorization, the user will then contact the federation
server. The Federation server will also respond back saying it does not know who the user
is, "you need to give me a claim stating who you are and what you would like access to".
In order to get this claim, the user will then contact their federation server. The
Federation server will require the user to be authenticated so the user will contact
a Domain Controller in order to be authenticated.
Now this is the important point to take away with Federation Services. Notice that the
company that is supplying the Exchange Services has no control over authentication; this is
completely controlled by the company using the service. This means the company keeps
control over who can access the Exchange services. If a new employee was hired, the company can
give them access to Exchange services. If an employee was to leave the company, the
company can also remove that user's access. The company also controls how the user authenticates.
For example, using usernames and passwords, smart cards or perhaps requiring them only
to supply a valid e-mail address depending on what the company requirements are. The
important point to take away is the authentication happens here and not by the company supplying
the service.
Once the Domain Controller has authenticated the user, it informs the Active Directory
Federation Server that the user has been authenticated. The Federation server then issues the user
a claim. The user is then able to give this claim to the federation server. The Federation
server looks at the claim and is able to determine who the user is, what they want access to
and verify the claim is real using the digital signature in the claim.
You may be wondering how a service like this would charge the business when it has no control
over authentication. The charging will depend on who is providing the service but it may
be as simple as counting the number of users that access the service during a monthly period
or charging for the number of users that are currently active on the system (for example
50 to 60 users). It is up to the company to make sure that they are in that range or upgrade
to a higher plan if they need more users.
If the federation server is happy with the claim, it will allow it. The user can then
contact the outlook web server and gain access to their e-mail. You can see how using a claim-based
system like this allows separation of a service and authentication using standard web ports.
There has been a lot covered in this video so let's have a quick look at the main points.
Systems that use Federation services, use standard web protocols and do not require
connection style trusts. For this reason, the big advantage of this is that it is generally
easier to get management approval since one does not need to make firewall changes or
have a trust that requires a connection to work.
The point to remember with any Identity system is that it requires many different systems
to work together. This is not always an easy thing to achieve. If you are using any of
the Microsoft cloud services with Active Directory Federation Services, these will work together
quite well and are well documented. Of course, Microsoft is going to take the time to make
this process as simple as possible to ensure the success of these products. If you are
using other systems, it may work quite easily or, then again, you may need to put a lot
of effort into getting the systems to work with each other and the documentation may
be poor. Federation Services, although good and saves you from having to get some management
approvals to change settings like firewall settings or create trusts, is not always the
silver bullet for your infrastructure and, thus, you should be prepared to take time
to set it up and get it working.
The last point to remember is that it uses claims. I will covers claims in a later video
but, essentially, a claim contains user information and what the user would like access to. In
order for a user to gain access, they must present a claim to a claim-aware application
in order to access the data or service. Claims are signed with a digital signature ensuring
that they are from a trusted source.
I hope you have found this video informative. This is just one of the free videos that
are part of the Federation services course. For more videos please see our Youtube channel
or web page. Thanks for watching and see you next time.