- Alright, so let's take a look at federated users
within AWS.
In small organizations, when you have two or three,
maybe even a dozen users within your organization,
people that are actually using AWS,
creating and managing resources,
then it's really easy to just go in and create users
directly within the AWS identity
and access management service.
But in larger organizations,
where you have potentially dozens or hundreds or thousands
of employees all needing access to AWS,
it becomes really difficult and challenging
to manage those accounts, both on the corporate side,
in your own directory and in a separate directory
within AWS, and that's exactly what we don't want to do.
In those particular situations, we want to leverage
federated users.
In large organizations
where you have your existing directory,
perhaps you're using LDAP or Active Directory,
you already have a directory of users,
you already know who they are.
You can also determine what they're allowed to do
by using roles, as we've talked about.
So, federated users means that you are taking someone
who you already know and giving them temporary access
into AWS based on temporary credentials.
So, by doing this, we can create a single sign-on service,
where they sign in to one place,
such as your corporate network,
and then through that initial sign on,
they then have access into AWS.
We also have the ability to federate
web and mobile application users.
So, in the cases where we have a mobile application,
and that mobile application needs access to Amazon services,
such as Amazon S3 or Amazon DynamoDB,
then it's possible to federate millions
of mobile application users.
And through that, give them temporary credentials,
allow them to directly upload and download to Amazon S3.
And by doing that, we could potentially
even completely bypass a backend APIs and proxies
and allow those mobile applications
to go directly to AWS services.
So, let's take a look at a federated user's example.
Here, what we're talking about is authenticating
our corporate users against an existing directory.
In this case, it could be again LDAP,
it could be Active Directory, it could just be a data base,
a custom application looking to a database.
So, our users authenticate to our on-premises
identity broker.
That could be some custom application, an intranet,
whatever it is,
we're looking for their credentials,
and then we're going to authenticate them
against our directory, now we know who they are.
And part of that directory here says
that this particular user, at the time that they log on,
needs access to AWS.
And so once it sees that, our identity broker will then
come over to make a call to the AWS security token service,
and pass in certain information such as the name of a role
that we want that user to assume
or we could also just pass in SAML,
we could pass in a policy directly.
And then the security token service will
return again temporary credentials.
We can control the lifespan of those credentials,
they default to 15 minutes but we could push that out,
up to 36 hours.
Once we return those credentials,
we can do one of two things.
We can either just display those credentials here
to the user so that they can use them in their command line
as environment variables,
they can place them into the STK for local development,
or if they're just doing things within the AWS console,
we could just simply redirect their browser
to the AWS Console and have them already signed in
and start work right away.
So again, this is an example of federated users
leveraging an existing directory.
This is really powerful and useful
when you have existing users, dozens, hundreds, thousands
of existing users who need access into AWS
and you don't want to recreate their accounts
in a separate location.