All right. So as I already introed, this is a crash course on identity and AWS and I'm John Leton, before we begin just these are, these opinions are my own, not anybody else's. And unless you've been living under Iraq for the last several years, odds are, you are familiar with AWS. And if you are an enterprise practitioner, odds are also that you have either been press gained into shoehorning your existing identity strategy into it, even after it had already seen wide use in the company or repeatedly consulted in an ad hoc fashion by several app teams about exposing identity information to AWS services for their urgent project or app launch, or completely cut out of any portion of the cloud identity management discussion, because it belongs to the cloud team. So when you get brought into an AWS identity project and start digging through the documentation, it is what I'd like to call thorough, but obtuse it is geared towards the developer audience and not necessarily towards solving for identity centric use cases.
Whereas the documentation becomes increasingly clear with experience on the platform. Enterprise practitioners usually must learn technologies in the context of solving for a specific business problem. Typically with very tight deadlines, they don't have the luxury of learning the platform first. So this brings us to the main thrust of this talk, or perhaps more importantly, what this talk is not, it is not necessarily a best practices session nor an implementation war story. Rather it is intended to be a crash court to bootstrap identity practitioners, to understand their identity landscape of AWS. So they can quickly get up to speeds on the lingo services, their purposes, so they can size step the pitfalls that will come with learning all by doing that on your own. So why is identity on AWS so complex at a Supai level? I'd say it's several things like services that offer the same functionality, but don't really, but there's absolutely nothing.
That's going to stop you from using the wrong service to the wrong use case. There are also plenty of what I speculate are the remnants of different access control philosophies scattered throughout the services. This manifests various one-off capabilities, depending on the service with the service, which make a centralized application of identity and access management more difficult. But most importantly, I think it's the confusion between which AWS services are best suited for IAM use cases. When AWS is acting as either infrastructures, a service versus when it is acting as a platform, as a service. Now, AWS does not bill itself as infrastructure as a service, but if it looks like a duck walks like a duck, quacks like a duck, then I feel pretty good about suggesting that it is not incorrect to say AWS could be considered infrastructure as a service. This is the typical AWS use case I've seen in enterprise environments.
So similarly, if we squint a bit, AWS can also start looking like a platform as a service where we only own run or manager applications and data with AWS running everything else. So let's think about an app that is literally built to run an AWS and couldn't be dropped easily into another cloud environment without significant retooling, like something riddled with Lambda functions or S3 buckets. If you start to interpret your AWS workloads into either of those two ways of using AWS, you'll find it gets easier to sort out what and which identity services should be used for which use case for the optimal AWS identity strategy. So in order to understand how AWS IAM governs identity on the entire platform, we will need to become familiar with some fundamental concepts that underpin identity and access management there. And to do that, we're gonna look at the most obvious identity service on the platform, which is AWS IAM.
This is the service you'll need to make your piece with no matter how you decide to solve for any identity challenges within AWS, every service, every action, every event is ultimately evaluated by AWS IAM before anything is done on the platform. So it's bad news that this one is so foundational because there are lots of moving parts to help you make wear through it. It's important to familiarize yourself with this taxonomy, these terms pop up everywhere. So you have resources. These are the things inside of AWS, like users, roles, policy, and groups, resources can also refer to the actual things like S3 buckets, or you see two instances on the platform. An identity is an AWS resource object. That's used to identify and group think user objects, groups, and roles. Entities are the AWS IM resource objects that AWS IAM authenticates as part of an identity transaction principles are the person or the application that uses an IM user or an IM role to sign in and make requests to AWS request is the full context.
What that a principal is asking AWS IM for, and the actions are what the principal gets to do on a resource after having been authenticated and authorized by AWS IAM. So from an identity services perspective, AWS IAM offers user and group object management, the authentication of entities. Those are the identity objects used during authentication. Again, credential management, including password management and policy multifactor authentication and token management and maintenance of programmatic credentials or API keys. It supports identity Federation inbound. And an important note about Federation is that there's never a corresponding user account in AWS IAM when federating into it from an external IDP, there there's only an assumed role and finally authorization and authorization policy management. So let's talk about authorization because if there's something that will make you look at a different cloud provider, this is it AWS's I's most important function is authorization.
Everything that goes through gets evaluated by AWS IAM. So even though there are overlapping identity services and AWS, they all ultimately engage with AWS IAM with us using one or more authorization policies to modify what the principles can do. So at a very high level, here are all the types of authorization policies that you get to mix and match to accomplish your authorization objectives. Using AWS, you have identity policies. These are managed policies that can be attached to identity objects like users or groups. They're either AWS managed, meaning created by AWS or customer managed, meaning you wrote them yourself. These policies are centrally managed and changes to a policy will apply to all the objects that that policy is attached to. Now. Inline policies are applied directly to the resource where they are written inline policies become an intrinsic characteristic of the resource that they're applied to, and they really make administration a pain in the butt because now you need to factor not just your centralized authorization policies, but also any inline policies which might manipulate the specific resource in question permissions boundaries that the maximum entitlements of a policy on an identity object, regardless of what competing policies say, service control policies are like permissions boundaries, but for subordinate accounts within an AWS organization, access control lists determine the conditions of allowing people outside of your account to access your resources, your resources from their own and session policies are policies created and applied on the fly during world assumption, usually by a federated principle, as part of receiving the temporary credentials that get issued during a federated transaction.
So all of these policies get evaluated for every event that happens in AWS. So naturally the evaluation logic is quite a site to behold. The important thing here is that there is no such thing as an implicit allow, a principal can only do something if allowed explicitly first, all applicable policies across all policy types are checked for any explicit denied logic that prohibits the action that the principal wants to take. Then it's evaluated for an explicit allow in organizational. Then in explicit allow in the inline policies, then in explicit allow in the permissions boundaries, then in explicit allow in the sessions policies, and finally in explicit allow in the identity based policies. If there's no explicit, allow the principals implicitly denied the action. If an explicit allow is found along that evaluation chain, the principal's suspended to take that action. So strictly speaking, we can service most of our use cases using AWS IM, but as we just saw that will require us thinking in terms of AWS level access for all of our enterprise identity use cases, while that's not unachievable, there are other services which provide identity capabilities that look much more familiar for identity practitioners.
So we already addressed AWS IM, but how about Cognito or AWS? Single sign-on as we already said, AWS IM provides the user management and controls access to AWS resources. Cognito provides user management and can control access to AWS resources. And that can is doing an awful lot of lifting in that sense, as we'll see, in a moment and AWS single sign-on provides user management and controls access to AWS accounts. So arguably these three services can provide similar capabilities though their implementation and capabilities do differ in significant ways that make selecting the raw one for your use case, a clunky experience. If we consider them through the lens of what kind of identity services do they offer, they start to converge even more with AWSs. So, and Amazon Cognito even offering fully featured IDP capabilities complete with their own user stores. Of course, once we toss in AWS directory services, which is AWS's managed active directory service, the things just get a little bit more confusing since AWS directory service can also become the user store for these services or even the authentication services provider for AWS IAM to figure out which service works best for each identity use case let's consider them individually first Cognito.
It has two main components. The first is user pools. A user pool is a managed directory for application accounts and offers a full suite of application, user management and security features, including new user sign up new user verification workflows with phone and email verification, prepackaged and customizable log forms, federated authentication using social identity providers, as well as support for any other standard space SAML or O I D C identity provider like your enterprise IDP strong authentication with support for multifactor credentials built in security tools, including checks for compromise credentials and account takeover protection. And unlike AWS IAM, where there's no corresponding user account object, and which only provides reference to an assumed role when delegating user authentication to a federated provider, every user within Amazon Cognito user pool has a user account object. Regardless if it is the Amazon Cognito user pool itself or an external Federation provider handling the authentication that authentication will map to a user account in the pool.
So here's a very simple use case diagram for Cognito user pools. Kognito user pools are designed to provide application identity services in a way that make identity simple for app developers. The app points to the user pool for all of this user sign up and authentication flows. And the user pool acts as a bog standard open ID connect provider for that application, the Amazon Cognito user pool may look to the locally, excuse me, the locally managed accounts within its directory or to a federated provider at user authentication time. The application continues to only respect Amazon Cognito as its source of identity. Though, federated users may delegate authentication to an identity provider. They will still exist as records within that pool. So user pools can also provide application authorization by following standard. Oof, two patterns. This model is similar to the previous one. We just saw with one key exception in this one, the application is using Amazon Cognito for its identity provider, and it's also acting as a resource server. So in addition to the user authentication and registration features, that app will look for scope tokens from the user pool to determine the resources that the user will have access to. We can map scopes to things like group membership within the pool to address access control.
The second component of Amazon Cognito is identity pools. Application developers can use identity pools to bridge application and user access to AWS resources. So why would we want the user of an application hosted on AWS to have access to the actual resources within our AWS account? So this is an example of Cognito being suited for the platforms as service use case. If you build applications on AWS and are deeply integrated into their services, it may be easier for you to permission the Cognito user to access a resource, think of an app where users upload photos to a bucket. And the, the S3 bucket is really just the interface on the website with Cognito identity pools. We can grant Cognito users permissions to write to that S3 bucket directly. So this is done using the AWS security token service to obtain temporary credentials, just like that.
Federated AWS, I user there's no corresponding AWS IAM user account for these Amazon Carto identity pool users. Access comes through an AWS IAM trust policy mediating the Amazon Carto identity pool users, access and identity pool requires a federated identity provider of some sort to provide those identities for that pool. That provider could be either Amazon Canto, user pools, social providers, or another Sam or O IDC based IDP provider or a mixture of them all. Whereas Canto user pools are a self-contained platform. Identity pools, assuming corporation into an application identity pools are a developer-centric offering and comes with lots of sample code and SDKs to facilitate adoption. So this is a very niche but powerful tool for bringing identity capabilities to your applications. If they're hosted all on AWS now, AWS single sign on is another IDAs capability available from AWS similar in some regards to Amazon Cognito. So where is Cognito provided application identity capabilities, AWS SSO facilitates centralized administration for federated access to AWS accounts, as well as general identity provider capabilities, AWS SSO offers, account management, authentication services and strong authentication capability for AWS accounts and applications managed under the AWS organization. So AWS SSO users can authenticate to one or more AWS accounts using either accounts and credentials managed by AWS SSO itself or through accounts synchronized from an external AU, excuse me, external authoritative source, such as an enterprise managed directory or identity provider.
So in addition to managing access to AWS accounts, AWS SSO also provides application identity services for AWS apps, which are AWS's own offerings for business services like instant messaging, email and document management. It also provides authentication capabilities for third party cloud SaaS providers and any other SAML, two compliance service provider. So like Cognito, the AWS SSO user store can be the source of truth for identity information, or those accounts can be synchronized from an existing enterprise directory. Unlike Amazon Cognito, the service is less developer focused in its consumption. There's no need to insert AWSs to so specific code into an application for that application to consume the Sam tokens and issues for its users. AWSs so behaves very similarly to any commercial on-prem or Ida's identity provider complete with preconfigured integrations for major SaaS applications. AWS's user star can be populated in various ways in organizations with an on-premise active directory.
The source of identity recommendation is to populate SSO user store via ad connector through Amazon directory services. As the name suggests that the ad connector bridges, the two user stores, alternatively accounts can be synced directly to the AWS SSO user store when using the AWS managed active directory also available in Amazon directory, AWS SSO also supports skim for federated provisioning from your authoritative source of identity. So finally, accounts groups and credentials may optionally be managed directly within AWS SSO itself, free of entanglement from an external authoritative source. However, if you connect AWS SSO to an external IDP, you give up the native group and credential management capabilities of the service since AWSs to so automatically configures the federated identity provider in the AWS IAM service of each managed AWS account inside of an AWS organization. We also get to define certain policies. These are called permission sets, which become the roles that are assumed by the federated principles upon authenticating into those downstream AWS accounts through AWS SSO.
So AWS SSO cannot be used without another AWS service called AWS organizations through AWS organizations, enterprises, or organizations with multiple AWS accounts can consolidate management of every account down to a single primary management account. This is great for simplifying some business processes like billing and resource utilization reports, but is also where those service control policies are implemented. Service control policies can be applied to organizational units within the AWS organization, and then they will then apply to all those accounts under the OU. You can also apply those STPs directly to AWS accounts. So that was an awful lot let's recap. So here's your cheat sheet for all the identity services available to us. And the recommended use case for enterprise practitioners. I am controls all is capable of offering user management, credential management and Federation it'll control access to AWS resource resources for authorization. It is not sufficient for AWS deployed apps for their authentication needs nor authorization within the context of those apps.
Cognito, similar story as IAM in terms of basic identity services offered, it is good for offering AWS resource authorization control for identity pools using AWS STS for resource access. It is great for AWS deployed application authentication and authorization specifically using identity pools for authorization. SSO also offers the full suite of basic enterprise capabilities. It is able to provide AWS resource authorization through AWS IM it's also able to be the authentication layer for AWS deployed applications. Once again, through AWS IAM, I think it's grow for application authentication for workforce and application authorization for workforce use cases as well. And then finally, directory services is much more directory oriented. It is very capable of being the AWS deployed app authentication as well as normal apps and application authorization broadly speaking, but it, it ultimately just serves as your credential and user store for any one of these services, unless you're using it as your main source of identity.
So, you know, in, in conclusion, so AWS IM will always control access to AWS resources. You're not going to escape it use AWSs. So to simplify the authorization constructs of AWS IM and bridge the platform centric mindset with a use case driven mindset, AWS SSO and organizations make administrative life cycle management and access to AWS accounts much easier. And you can refine authorization in that model by building additional policy within AWS IAM Cognito provides identity services for applications. It is good for enterprise developed applications. Assuming you connect your user pool to your enterprise IDP Coto identity pools, plus AWS STS allow Coto identities to access AWS resources like any other AWS principle. So this is good for app teams with a heavy dependency and deep AWS integration. Finally, AWS directory service is useful for organizations that use ads as their user store. AWS directory service can populate AWS. I am directly, but it's easier to use it as AWS SSOs user store directly. So that's it. Thank you for white knuckling through you with that, and feel free to reach out with any questions you may have and keep an eye out for my book being released on October 1st on this topic. Thank you.
