Let's start a discussion on Active Directory Federation service Federation service allows identification
authentication and authorization across organizational and platform boundaries.
If you'd like to set it up it's going to require a federation trust relationship between two organizations
or two entities.
It's really a way to go with a trust relationship beyond the scope of our normal domain or forest environment
Federation service will allow an organization to retain control over who can access resources.
It will also allow the organization to retain control over their user group accounts.
So you can still have control and allow people outside of your organization to use your resources.
Let's see a little bit more about it.
So what is a DFS Active Directory that ration services.
It is a Microsoft identity Federation product that can be used with claims space authentication.
When we talk about claims space with indication we're talking about using a way to authenticate someone
other than using the traditional username and password.
Some of the features involved with it is that you can use it for single sign on for your web based apps.
You can also use that as a way to operate between web services on multiple platforms.
You'll also note that you can use it to support many clients in web browsers mobile devices and apps
that are available on the Internet and it's extendable with third party applications.
You can customize your own claims to be able to work with it.
One of the big benefits is it allows you to maintain your own account list in your own organization
without having to have another for an organization work with that account list.
I'll give you an example in just a moment.
OK.
So water claims based identity and claims based with indication.
The idea here is really a very old idea.
I would like to be able to use a resource in someone else's domain and we can do that very very easily
and Active Directory for part of the same forest.
And if we're not part of the same for us we can set up a forest trust I can access your resource.
But how do I do that.
If you don't have Active Directory and you don't have a forest maybe you're not even running a Microsoft
Network.
How could I do that.
That's where this comes into play Federation server.
So the idea here is that I need to use a resource in your network.
But the problem with it is I don't really want to tell you my username password to store it in your
system so that I can log into your system and access it.
Plus even better.
You don't want to have to maintain it.
So you want me to maintain my own users and groups and permissions and passwords and you maintain yours
and you don't want to have to go in and you know maintain each other's information so we can share resources.
So what we do is we take that old idea here of being able to trust a remote domain or in this case a
remote system with Federation services.
So what you can see here is I've used quite a number of names with this because you'll see it called
quite a number of things but essentially what we have is we have an account domain or a trusted domain
if we were to use Microsoft language here.
And this is where all the user accounts are.
So the user accounts are here and I would like to use a resource out here which is essentially a resource
domain a trusting domain an application provider.
It's also known as a resource provider.
So you'll hear the resource to Maine also known as a resource partner.
And then you'll hear the account Dumaine also known as account an account partner.
So as you can see this is really just taking the trusts that we would normally do within Microsoft and
expanding it out.
So I have my accounts that I maintain I want to use the resource on your site and you're not Microsoft
so we're going to do Federation services to make the connection.
So what happens is I'm going to have to set up trusts and the trust that I'm going to set up is going
to be related to the claims that I'm going to provide you.
So you tell me what you want me to tell you in order for me to use your resource and that could be anything
like maybe you want to know my e-mail address.
So maybe right now what's happening is we are doing a partnership and I need to use resources on your
side.
So you say everyone in the sales to everyone in the sales of you that has the a certain e-mail address
attached to them.
Those are the people that you want to have come in and use your resource.
We simply set up a claim to do that.
So that's where the claims come into place.
We're not used to using a traditional used in the password.
What we're doing is we're using attributes of you as a user and you maintain those attributes.
I don't want to maintain them but when you come in use my resource Well guess what you've got to tell
me some of those attributes maybe you belong to a certain group maybe you have a certain email address
maybe you have a certain location that you're working out of I can use all those claims to authenticate
you.
And that's how this works.
So it's the same domain model that we're used to but we're pulling it outside of a Microsoft Network
and then we're using these trusts to work with our claims.
Let's take a closer look at some of the ATF esque components if you'd like to set up a DFS.
We are going to talk about the different models that you can use but what you'll note here is that we
have an 80 FS server here out in our partner network.
So they're a foreign system I want to be able to use resources with them and I have my internal network
that also has an ATF ATF server.
So my federation server out here is going to need to be installed.
It's going to be installed just like we normally would do our installations.
As we've seen in the past through and rolls and features.
But my federation service here will also be a certain type of server.
We can have a server that will have accounts on it and it could use an attribute store to do that.
So I can store in my attributes store all of my user accounts and then the attributes that are associated
to them that I'm going to use his claims to get them authenticated.
Traditionally the attributes will probably be active directory.
So that's where I'm going to go in and figure out.
What about that user I need to use to figure out whether or not I can be allowed into a resource.
So you can see that you're also going to note here will have a relaying party server the relaying party
servers the server who has the application that we would like to access.
So this is our research server that we would like to access.
So they're going to say what they want.
For me who provides the accounts to be able to use their applications.
And so I just have to match those when we set up the trust relationship.
You might also note and this is an optional component.
You could have what's called a federation service proxy.
It is now known as a web application proxy and it's just an extra layer protection so that when we work
with external clients they don't have direct access to the Federation server.
They've got to go through the proxy and what the proxy will do is the proxy will determine who to connect
them to the proxy can actually pass them directly through to the application at the application to authenticate
them or the proxy can pass them off to the Federation server and let the Federation server use its attributes
or usually active directory to authenticate them.
So the proxy just kind of runs interference an extra layer of protection if you'd like to use it.
So as you can see all of this is going to run via these trusts and it really depends on what you're
trying to access.
We have a number of trust here that we can work with.
You'll see that we have a claims provider trust.
So this claims provider trust is going to be configured on the relay party.
This is for the relay party which is essentially the resource domain to say exactly what they want what
do they want to know about each of the users that would like to connect to the resource What do they
want to know what what are they going to require that you belong to a certain group that you're at a
certain location that you have a certain e-mail what are they going to require.
And that will be built into the claims provider trust relying partly trust is going to be configured
on our claims provider and it essentially has to match with whatever the resource wants.
So I'm going to make certain that I put in there what does the resource want.
I have to match that.
So the two have to match in order for us to get a connection.
So like I said this is kind of like the same model weve had for a while is just now were being able
to use claims to get someone authenticated and some of the authenticated possibly who you know is outside
of our organization.
So thats kind of the idea with this.
So we have certificates that this will use.
We have claims and claim rules that we set up so the claims being the the user with the attributes and
what attributes do we want to use.
With that we have rules here that you can configure.
So there is as you can see there's a lot of moving parts to this and this is kind of just scratching
the surface getting a little idea of what's what.
Let's take a closer look at some of the ATF s requirements for installation.
You will need a TCAP IP network the client computer will need to be able to communicate using HTP which
will require a certificate.
They'll need to be able to communicate to the web application proxy.
They'll also need to be able to communicate with the resource Federation server or the Federation server
proxy and they also need to be able communicate with the application Federation's server the Federation
server proxy must be able to communicate using HTP Yes with the Federation servers in the same organization.
And then the Federation servers an internal client computers must communicate with domain controllers
for authentication.
So there's a lot of connectivity here that will need to be set up.
You'll also want to work with active directory.
So the Federation's server must be joined to the active directory domain.
The proxy doesn't have to part of the domain.
A lot of times the proxy will be in the extranet network and then you will need an attribute store that
will usually be active directory there are some additional DFS requirements that involve DNS clients
must be able to resolve DNS names for all Federation servers and for any web apps that they plan on
connecting to external clients must resolve the DNS name for a web application proxy and not for an
internal Federation's server.
The web application proxy must resolve a name for the internal Federation's server.
You're going to need to configure different DNS records in internal and external DNS zones.
If the internal users have to directly access the internal Federation's server and if the external users
must connect through the Federation server proxy.
As you can see there's a lot of moving parts to active directory Federation server but as you'll work
through this you'll see that it becomes just really like a you know the domains that were used to back
an active directory.
So it's not that big of a stretch.
We just have to spend a little bit of time working extra with DNS and certificates to kind of bring
everything together.