- Now, let's talk about federated users.
Earlier, we talked about creating users
within the identity and access management service,
and for small teams, that works really well.
But, for larger teams when you're in especially
an enterprise that has perhaps hundreds
or maybe even thousands of users that already exist
that also need access to AWS,
then we want to ideally leverage our existing directories.
There are plenty of existing directories available.
A lot of organizations already use things like LDAP
or Microsoft Active Directory or some other type
of directory, and we want to enable the ability
to essentially reuse those accounts.
We don't want to have to duplicate those accounts
between an on-premise directory
and within the identity and access management service
because there's a lot of issues with that.
One, it's kind of a pain to do.
And two, if they leave the company, we have to remember
to remove them from two places,
and so by leveraging a federation, we can leverage
that existing user base that we already have.
Of course, the same thing applies
to web and mobile application users.
We have users out there that want to authenticate
against our web or mobile application,
but we don't want to necessarily force them
to go through the process of account creation.
They already have an account somewhere,
and we can leverage that existing account
by allowing them to log in with Facebook,
log in with Google or Twitter
or basically any other OpenID provider.
And so in terms of federation, we have a lot of options
that are available to us.
First, we have the SAML, and SAML 2.0 allows us
to grant access to the AWS Management Console.
It allows us to gain access to temporary access keys
that can be used to configure the CLI and other API access.
With SAML, the nice benefit of SAML is that we can enable
this kind of federation with no coding whatsoever.
We simply configure our on-premises directories
and the AWS Identity and Access Management Service
to communicate to one another using SAML,
and when our enterprise users authenticate
against that on-premises directory,
through the communication of SAML, they're able to retrieve
those temporary credentials that they can use to access AWS.
We also have the AWS Directory Service.
This allows AWS Management Console access
by allowing the user, the on-premises user,
to authenticate against Active Directory using
their Active Directory username and password.
We also have Cognito, Amazon Cognito gives us
a programmatic access to the API that allows our web
and mobile applications to create user pools.
We create a user pool within Cognito
and using OpenID Connect, such as log in with Facebook
or Twitter or so on, our web and mobile application users
can authenticate against that existing account,
and that can be correlated and stored
within a Cognito User Identity Pool, and from there,
we can use that to grant temporary credentials
that can be used to communicate with other Amazon services.
So through authenticating with Cognito,
we can create a system that allows our web
or mobile applications to communicate
with Amazon services directly,
and we'll see some examples of that later on.
The last option that I wanna talk about here
would be the AWS Single Sign-On.
Single Sign-On gives us access to multiple AWS accounts
and business applications.
We've talked about earlier how it's common
for organizations to leverage multiple accounts
for their different environments, right?
You may have an account for production,
an account for development,
or account for different business units,
and so that's a very powerful pattern in order to
create isolation between different types of resources,
and AWS Single Sign-On allows you
to essentially create one place for users to authenticate
and gain access into multiple accounts.
So, keep that in mind when you, for those of us
who are a part of larger organizations,
for teams that may have hundreds or even thousands of users
that already exist, keep these federation options in mind.