All language subtitles for 006 Identity Federation_en

This lecture is an extension of the identity and access management concepts that were discussed in the

previous two lectures. In this lecture,

we are going to discuss Identity Federation, an interesting concept.

So when you go to a new website and you want to sign up, you are sometimes given two options.

You can either create a new account or you can use your existing Gmail or Facebook account to login.

Now that's powered by Identity Federation.

Identity Federation provides the framework under which two different entities can establish trust relationships

so that you don't have to create multiple redundant accounts.

Before we delve into details of how Identity Federation works, let's first see how traditional token

based authentication works.

So let's say you are a user, you want to log into a server, so you send your credentials and if your

login credentials are approved, the server creates an authentication success reply message and includes

a token along with that message.

So once the user has this token, he does not need to provide his credentials again and again.

He'll simply include this token in subsequent requests,

and based on this token, the server can authenticate whether it is the legitimate user or not.

So this is how, by using a token, we avoid exchanging credentials again and again.

An important concept, which we must understand is that tokens are short lived.

We cannot have a token which stays there for weeks and months from a security point of view.

This can create some serious problems. So, in order to avoid these problems,

tokens are short lived and they are regenerated by the server within the same session.

So every few minutes or every few hours, depending on the context, the server would simply generate

a new token, send it to the client again and the client would subsequently use the token.

Now, this is how traditional token based authentication works.

So as you see in the figure, sometimes when you visit a Web application or a site, you can either

provide their own customized account information or you can log in using your existing Facebook, Gmail

or LinkedIn account.

So this is all powered by Identity Federation, whose main idea is to use credentials from one account

to log on to multiple systems.

The key motivation is that, you know, if we have systems which trust each other, why should we create

multiple redundant accounts?

So this creates unnecessary burden on the user because they accumulate a lot of different credentials

for different accounts and this creates a higher possibility of leakage.

So if those systems, they trust each other, we can simply leverage one account to spin off on to other

systems.

This makes it easy for the user to simply remember the credentials for one single account.

Gmail is a popular example.

A lot of different Web applications around the world,

they allow you to log into the systems if you have an existing Gmail account,

because they have a trust relationship with Gmail.

The key motivation is, again, that we want to avoid creating multiple accounts and in order to avoid

managing multiple identity and access management systems.

Let's see how the identity federation flow works, so let's say you have an existing Gmail account

and you want to log into a new website.

So that new website is the service provider.

So you want to access a new service and you have an account on Gmail and since you will be using that

account.

So Gmail would be the identity provider in this example and the service provider and the identity provider

Gmail.

In this case, they have a trust relationship.

So what happens is that a user sends a login request.

But since the service provider is allowing you to use identity federation, so it is simply going to

forward your authentication request to the identity provider, which is Gmail.

Now, Gmail is going to redirect you to the login page of Gmail so that you can login. So once you login

and your login credentials are approved by Gmail, Gmail is going to create a token, which is the SAML

token (Security Assertion Markup Language).

We're going to discuss that later.

But the basic idea is still the same.

Instead of token generation by the service provider, as we discussed in traditional token based authentication

mechanisms,

this time, your identity provider, Gmail, is creating this token and sending it to the service provider.

So once this step is completed, the service provider now knows that you are a legitimate Gmail user

and since it trusts Gmail, that's why you're in.

So the login is considered successful on the service provider.

So single Sign-on is a subset of identity federation, but the difference is that we're not talking about

a single organization.

So within your organization, if you have multiple applications or systems running, you can use one

set of credentials or one login to access all those different applications or systems.

An example could be you can log in once and then access your e-mail system, your enterprise management

system and so on.

The basic idea is still the same, to leverage one account to access multiple services.

Now, this warrants a discussion on the difference between identity federation and single sign-on. To

start with,

both are similar concepts.

In fact, Single Sign-on is a subset of identity federation.

Now identity federation is more general in nature, and it is usually between organizations.

In contrast, when we discuss Single Sign-on, we are talking about one organisation.

So we're discussing access to multiple applications or systems within the same organization.

Another point to note is that Single Single Sign-on focuses exclusively on just signing and whereas Identity

Federation is more generic.

Let's have a look at some of the protocols used in identity federation, so the first is SAML(Security

Assertion Markup Language).

It's a standard for single sign on implementation.

And the basic service that it provides is authentication between two parties. Next is OAuth, which is

a standard for authorisation between two parties.

It authorizes service devices and space to run applications on behalf of others.

Finally, we have OIDC, which is again a standard for single sign on implementations.

The interesting point about it is that it is built on top of OAuth.

Let's have a look at some of the commercial products used for single sign on. So the two giants in this

category are Okta and AWS Cognito.

Both provide similar services to both provide single sign on.

Both support multifactor authentication.

They also support implementation and enforcing of organizational policies on AM.

The main difference is between how they structure their prices.

So, for example, for Okta, we have the first 7000 users who are free and then the single sign on

service costs two dollars per user per month.

With Cognito, we get up to 50000 free users, so that's substantially more than Okta.

And then the single sign on cost is two hundred seventy five dollars for every 50000 additional users

per month.

So both are well-known and stable solutions, and which one to prefer actually depends on the context

of your organization and business products.

That concludes our lecture.

I'll see you in the next one.