Instructor: Okay so let's talk about identity federation.
You may have heard identity federation many, many times
in AWS and to be honest for me, it was quite
a cryptic topic, it's really hard to understand.
So I'm doing my best here to explain to you
how identity federation works, with the SAML
and Cognito, how it is integrated with all these things.
So let's take it step by step and hopefully
you'll have a clearer view of it after this lecture.
So federation means that will let users that
are outside of AWS to assume temporary roles
to access our AWS resources.
What does that mean?
That means that our users don't need to have a user
in AWS to access AWS.
How does this dark magic works?
Well basically the users will assume an identity
provided access role.
So that's a lot of information already.
Let's go through a diagram to understand better
how this works.
So we are a user and we're in our company
or we are a mobile app user, whatever it is,
we are a user and we don't have an account in AWS
but what we do have is access to a third
party servers for login.
It could be our company's, it could be whatever
and this third party is trusted by AWS so we have
define preempt beforehand, a trust between
the third party and AWS.
What happens that our users will connect to this third party
and through some complicated process
that we'll see in a second, the third party will
give back credentials, they will be temporary
to our AWS, to our, sorry, to our user, to us.
Then as a user what can we do with these credentials,
well we can directly access AWS through
the console or the API.
So this is how federation works, identity federation.
That's because the identity is stored somewhere else
or stored on a third party.
If you understand this, you very clear understood
identity federation.
Now identity federation, what is this third party
authentication that we're talking about?
It could be LDAP, it could be Microsoft Active Directory,
which is also a similarity to being SAML,
SAML's the standard but Active Directory
is an implementation of it, could be single sign on,
it could be open ID, it could be Cognito.
So all these things can be third party authentication.
And so using federation, the thing you have to remember
is that we don't need to create individual IAM users,
the user management is done outside of AWS.
So for the exam, they may ask you about some very specific
form of identity federation, namely SAML,
custom broker and Cognito so we're going to see
these three in details right now.
The first one is SAML federation and that's for enterprises,
basically if you're a large enterprise,
you most likely have a Microsoft Active Directory
or you have something SAML 2.0 compliance,
where you already manage your users through this
and you basically want to integrate this with AWS.
What this gives you is that now all your users
automatically have access to the AWS Console or the CLI
through the temporary credentials so you don't
need to create a new IAM users for each of your employees,
which is quite nice.
So how does it look like?
This is a diagram.
Now, this may be a very complicated diagram,
it comes straight from the AWS documentation
but it is very clear so let's walk through it
one step at a time to understand what happens.
We are the client app and we are within our organization
so a large organization.
What we'll do is that we'll go to the identity provider
or IDP, which is SAML compliance so it could be
Microsoft Active Directory and it will authenticate
the user based on the user database.
Then when we are authenticated to this IDP,
the IDP will send back a SAML assertion,
it's basically a token, a SAML assertion
is basically a token.
Now we get some SAML assertion and what we'll
do is that automatically, we'll call assume
a role with SAML to SDS, which is a special API
on SDS and SDS recognizes this SAML assertion
and we'll give this back, we'll trade this SAML
assertion for temporary security credentials
so now we've basically logged in,
got a SAML assertion, traded that SAML assertion
from SDS to security credentials and now with
the security credentials, we can for example,
access AWS just normally, for example on this S3 bucket.
That's if you want to have CLI based access.
If you want to have a console based access,
there is also a nice diagram by AWS,
the idea is the exact same.
From our browser, we'll access the portal
of our identity provider so it's like a web based thing,
we'll get it authenticated, same thing
then the IDP will return a SAML assertion and now
we can use that SAML assertion very quick to sign in
into the AWS SSO endpoints, which behind the scenes
talks to SDS and then once it's all validated,
once your SAML is traded for SDS then we'll
validate the whole thing and you get redirected
to the AWS management console right here.
So the idea is the same, right?
If you look again, we trade our identity internally
for some AWS credentials and basically there
is just a bunch of back and forth that happens.
So if you understood this, then you understood
SAML federations, it's actually not that complicated.
Now if you don't have a SAML 2.0 way of identifying
your users then you need to use custom identity broker.
So that's only if you don't have a SAML 2.0
and that's a bit more complicated.
Basically you have to program what's called
an identity broker application and you have to
program it and this identity broker must be used
to determine the appropriate IAM policy you apply.
So what's the change?
Well here it is, again, we have our users, browser,
application, we'll access our identity broker
and the identity broker is something that we have
to program, okay, this whole thing in the green dot
circle is something that we have to program
and the identity broker will validate our identity
with maybe a corporate identity store, authenticated
and then if it's happy, it has super powers,
it has super user superpowers and it can ask
from SDS any security credentials for any policy.
So it's up to the identity broker to really tailor
a policy just for the user that was connected
so it's a bit more work to do and that's why
it's called custom identity broker application.
So we have to create this, it goes to SDS,
makes a request for a security credentials,
the security credentials come back,
they're given to our users and then they can
either access AWS with the API's or get redirected
to the AWS management console and we can access AWS.
So it is the exact same principles as SAML
but it's not SAML and therefore we have to do
a lot more manual work, we have to do a lot more work
to implement that identity broker so if you see
custom identity broker, that means enterprises
but not SAML 2.0, whereas before,
if you see SAML 2.0, that means identity federation
directly integrated with AWS.
And finally this is, this was for our corporate users
so anytime you are basically sitting at a desk
at your corporation, but what if you have an app
and an app, your users need to basically
put files into an S3 bucket.
How do we do this?
Do we create a user per app?
No, that doesn't sound scalable, right?
So the goal is to provide AWS resources access
directly to our users of our app.
How do we do this?
Well, we login through a federated identity provider
or we can remain anonymous then we get AWS credentials
back from what's called a federated identity pool
and that comes straight from Cognito
and then these credentials will come with pre-defined
IAM policy that basically allow users to do what
they need to do.
Don't worry, there's a graph.
So an example is anytime you want to provide
temporary access to write S3 bucket,
maybe using a Facebook login, you should use
AWS Cognito and federated identity pools.
Note there is something in the documentation
called Web Identity Federation, you may have
heard of it before and it is an alternative
to Cognito but now in the documentation
AWS recommends against it and it says
you should just use Cognito because it does
the exact same thing.
So for this reason I'm not teaching Web Identity Federation
because it's not on the exam anymore.
Cognito is going to be the way to have public
applications access AWS resources.
Now quickly, how does that work?
We have our app and our app is directly connected
to our identity provider.
It could be commuter user pool, Google, Facebook, Twitter,
SAML, open ID, whatever you want, right,
but it's an app, it's at on the web, it's public
so our app logs in to our identity provider
and gets a token back from it.
Then the app will talk to the federated identity provider,
in Cognito, and we'll basically trading that token
that will be verified by the identity provider
and then the identity provider will get credentials
from SDS and then same pattern as before,
the identity, the federated identity on Cognito
will send us back temporary credentials
and now using these credentials, we can directly
talk to our S3 bucket and make some calls
and see if we're authorized to do what we need to do.
So that's the idea.
Here the difference is that now we connect
to public identity providers, such as Cognito User Pool,
Google and Facebook but the idea is exactly the same.
We're trading a token, we retrieve from a third party
to a service on AWS to get back some temporary
AWS credentials.
So if you understood this, you understood federation,
take your time, review the graphs,
look at the documentation, review this lecture,
I promise it will make sense after a little bit,
just write it down on a piece of paper.
It's quite hard sometimes to understand how these
things are orchestrated, it takes a lot of time for me
to get to understand this but once you understand it,
it makes total sense and any question at the exam
that talks about federation, you will not be afraid of it,
you will be embracing it and happy that you know
the answer right away.
So hope you enjoyed this lecture,
I will see you in the next one.