How are you?
And welcome back.
Now, in today's video, we will be discussing about the concept of federation.
Now, before you go ahead and look into it in more detail, let's take a simple use case to understand
the challenge that many millions face and most of the large scale organization faces.
So let's assume that there are 500 users within your organization, and this organization is using three
primary services actively.
First one is aid, at least for infrastructure.
Second one is Jenkins, and the third one is the age related application.
And your role is basically to give users access to all the three services.
So let's assume that all the users, all the 500 users within the organization needs to have access
to all of these three systems.
Now, one of the challenges that we will see first one is that you will have to create individual users
in all of these three systems.
So in either list, you'll have to create a IAM user in the HIV management system.
Again, you'll have to create user and so on.
So now let's say that a new user has joined your organization or a new user is leaving your organization.
So essentially you will have to log in to all of these three applications to add or remove the users.
Now, let's assume that there are two new applications that are coming in the organization.
So essentially, again, you'll have to add all the 500 users to the upcoming new two system that is
being planned.
So this is not really a very efficient way of doing things.
So this is one of the challenges that you will really face in the medium to large scale organization.
Specifically, when you discuss about large scale organizations that have thousands of users in such
case are managing the users across each and every system is not recommended as well as the identity.
So in order to overcome this, basically what the system is used is to store the user center.
So let's say that you have a system.
So in this old app you have all of the users identities stored.
So all the user name and all the passwords are stored in this center directory.
And this single directory is connected with all of the systems in such a way that users from the center
directly can log in with the username and password to all of these three systems.
So this becomes a much more efficient architecture because there will only be a single set of username
and password that will be stored at the end up level and from the end up.
Since there will be a trust between all of these systems, the user can easily log in.
So anytime a new user joins the organization, all that the administrator needs to do, he needs to
add his user as part of the old app, and that's about it.
Will be able to log in to all of these three systems and maybe tomorrow a new system is planned to be
added in your organization.
All you'll have to do is you have to either trust between your old app and that new system and all of
the existing user will be able to log in to the new systems as well.
Now, there are a lot of solutions that allows us to store the user centrally.
One of the primary ones that you might have heard is the Microsoft Active Directory.
This is a very popular solution which allows you to store user center and also allows you to have an
orderly management.
The second popular one specifically for Linux is the Red Hat Identity Management also referred to as
a free app.
So if you look into the screenshot, this is associated with Active Directory and you see that there
are multiple users that have been added here and the order edition of user is very simple.
You see you can click on New and you can click on user and a new user will be added to your Active Directory.
So now let's say that you have Active Directory and you have these three systems.
What you need to do, you have to either trust between your Active Directory and these three systems
in such a way that the users that are part of your Active Directory will be able to log in to all of
these three systems depending upon the policy that you have set.
Great.
So with this, let's go ahead and understand the basics of federation from idealist perspective.
So basically, federation allows external identities also referred to as a federated users to have a
secured access inner eatables account without having to create any and users.
So we have already discussed that the identities are not stored in a place, these are stored in a central
server like Active Directory and all of these users will be able to log in to your account.
So this is what the Federation concept really comes into the picture.
So these external identities can come from various sources like corporate identity provider can be Active
Directory IPA, web identity provider.
Facebook.
Google.
Amazon.
Incognito or open ended, depending upon the use case you want to achieve.
Now let's quickly look into the high level workflow when we discuss about Federation.
So there are three primary entities that are involved.
The first one is the user.
Second one is the service provider, and the third one is the identity provider.
No service provider is basically these right hand side applications that we were discussing, like Jenkins
EAW is a data management system, etc..
Also, these are the providers that are providing some services.
Then you have an identity provider from the name itself.
We can identify what exactly this does.
This provides identity.
So that basically means the users are stored at the identity provider level and what the service provider
and the identity provider there is a trust relationship between both of them.
So this service provider is trusting the identity provider and hence the users that are coming from
this identity provider will be able to log in to the service provider depending among the policies that
you have state.
All right.
So if you look into the diagram, the user he first authenticates with the identity provider.
He does not authenticate with a service provider.
So this basically means that let's say that this workflow is that of EWR.
So it is a service provider and there is an identity provider like Okta.
So the users will be stored at the octane level.
Users will not be stored at a database level.
So the user will first authenticate with the identity provider.
Now, since there is a relationship, a trust relationship between the IDP and the service provider,
the user, once he successfully authenticates with the identity provider, he will be able to make a
successful request to the service provider of EWR.
So with this, let's go ahead and quickly understand things in more detail.
First, important concept here is the identity broker.
So identity broker is an intermediate service which connects multiple providers here.
So under identity, you have a idlis.
On the left hand side, you have an Active Directory which has all of the usernames and passwords for
all the employees of your organization.
So what do you want?
You want to intimidate service that can connect both of these.
So this is what is referred to as the identity broker.
So let's go ahead and look into the working vid.
On the right hand side, you have the place, on the left hand side you have the Active Directory and
yet in place.
So first the users will have to sign in to the identity broker.
So this identity broker is connected to the Microsoft Active Directory.
So basically what username and password the user supplied to the identity broker does that match to
that of the one that are stored in Active Directory?
So this is where the authentication really takes place.
First step is sign in.
Second step is authenticate the user with the Active Directory.
Once the authentication is successful, this identity broker will go ahead and call the A spear service
and it receives a specific token and then the identity broker sends the appropriate response back to
the client.
And this token is what declined again used to connect to the Amazon Web services.
So when we discuss about this author, this one's token.
This is nothing but a set of access and secret keys.
So access and secret keys are been provided to the users, and users can use that access secret keys
to connect to the EWG.
So this is the high level workflow on how things would work in a federated point of view, I think.
So let's go ahead and quickly revise the steps.
First one is the users log in with the username and password, and these credentials are given to the
identity broker.
Now Identity Broker validate these credentials against the Active Directory.
In this example, we have taken Active Directory.
If credentials are valid.
Basically, if the username and password is valid, the broker will contact the SDR service as this
will go ahead and give the access security back.
And this access secret key will be supplied from identity broker to the user and user will be able to
log in to the database console or securely using this set of access secret key along with the specific
token, which has a specific duration.
So if you can't remember when we discuss about identities, identities, nothing but the users.
So when we discuss our external identities, that basically means the users are stored in an external
system, not in IEM.
Second is identity broker, which is basically middleware that takes the user from point it and help
them connect to point B.
And third important concept is the identity stored, which is basically a place where the users are,
but as other users are stored.
So Active Directory or IP or maybe Facebook.
So these are basically the identity stored.
Now before we conclude, very important things that I wanted to share.
First one is that for the Federation to work, this service provider should also support that functionality
because ultimately we were discussing one.
Identity provider will store the identities and they will be a trust relationship between identity provided
and also that of the service provider.
Now, if the service provider does not really support that functionality at all, then you cannot really
have a federation.
So this is one important part to remember.
Now, when we discuss about Idlis, when you go to the IAM console, you have a specific option of that
of the identity provider.
So this is where you can go ahead and add multiple identity providers.
So menu Gordon identity provided you will have to basically specify a provider type as well as the metadata
document of that of your identity provider.
So for example, let's say that you have chosen the identity provider of OCTA.
So OCTA is a very popular identity provider platform.
So this metadata document that we were discussing, this comes from OCTA.
So after you have configured the request settings in OCTA, you can go ahead and upload this metadata
document after you have downloaded it from OCTA.
And this is how at a high level audit, the trust really happens between a service provider and that
of the identity provider.
So this is one part.
Second thing that we were also discussing, let's take an example of Jenkins.
Let's quickly go to Manager Jenkins and configure the global security.
So basically what we're discussing in these accounts laid on how the user's data is stored centrally
in a lab, should be able to log in to a specific application like Jenkins.
Now, if Jenkins does not release or put in that back then this entire concept will not really work.
So Jenkins will also need to support a LDAP specific point of view.
So if you'll go to the Jenkins settings under URI, you basically have two important options.
First one is Jenkins own user database.
So that basically means that whenever you go ahead and add a user, you add it to Jenkins database and
you also have option to allow user to say, no, this is one.
Now let's see, as we're discussing, you do not really want to create the user individually in individual
system.
What do you want?
You want end up?
So you also have an option for a dashboard here, and within it you'll have to provide the end episode
word details.
So once you have that server, you provide the details to that of Jenkins, and once you have necessary
configuration, the users that are part of a LDAP will be able to log into Jenkins audio.
Right.
So this is the high level overview.
In case if this is something that really interests you, then Okta is a popular platform that you can
try it out.
They also have multiple certifications associated with it, which are quite good.
So this is something that you can look forward to do.
So that's the high level overview about Federation.
And with this will conclude today's video.