Selecting an identity management solution is a critically important decision for any software organization. Identity management is a foundational component of good cloud security and can either be an enabler for scalability or a huge technical debt sink.
Many organizations start with AWS by quickly throwing together their IAM infrastructure: some users, a few roles, and some policies. This method might be sufficient for launching a minimum viable product (MVP), but when it comes time to scale, it’s going to be a major bottleneck for growth. This situation raises an important question for DevOps and security engineers: What enables developer productivity and speed now while providing a solid foundation for scalability and security later?
Understanding Identity Management
Identity management in AWS, or any cloud-based system, serves a variety of purposes. Primarily, it aims to provide secure authentication and least-privilege authorization that is appropriately scoped by both resource and time. It also aims to construct a scalable system that can grow in tandem with the infrastructure it supports while simultaneously empowering developers to remain productive and ship code securely.
Choosing the right identity management approach in AWS starts with understanding some of the core concepts that underpin identity and security.
Authentication
In any access request made by a system, user, or device, this initial step verifies the identity involved in making the request. It typically involves a username and password, but it may also entail other methods such as multi-factor authentication (MFA), where additional credentials are necessary to gain access.
Authorization
After an identity has been authenticated, authorization determines the resources the given identity can access and the operations it can perform. This process is typically managed through policies and roles that define the scope of an authenticated user's permissions.
Federation
Federation permits identities to be created, stored, and managed in one domain and recognized in others. This is particularly useful in hybrid cloud environments where you might be dealing with a mix of on-premises and cloud-based resources.
Identity Provider (IdP)
This is a system that is responsible for the lifecycle management of identity data within an organization or digital architecture. Principals, such as users or systems, derive their identity from this provider. It also offers verification services to applications that operate within a federated or distributed network. In the context of cloud services, an IdP is typically a service that stores and verifies a user’s identity.
Single Sign-On (SSO)
SSO improves security by consolidating and streamlining authentication by mitigating the requirement for users to recall numerous passwords. With single sign-on, users can authenticate themselves just once and subsequently access multiple systems or applications without the need for repeated sign-ins.
Multi-Factor Authentication (MFA)
MFA improves security because users are forced to present at least two methods of verification before being granted access to a protected system, resource, or location. These factors will typically be a password, ID, or even biometric data.
Identity Lifecycle Management
This encompasses the processes and technologies used to manage identities over time. It includes onboarding new users, managing changes to user status, and offboarding users who no longer require access.
Zero Trust
With this security framework, the default assumption is that neither any user nor any system is inherently trustworthy, regardless of their location relative to the network perimeter. Access is granted based on strict identity verification and only for the resources needed to perform a task.
The technical components of identity management in the cloud, such as authentication, authorization, federation, and lifecycle management, underscore the fundamental principle of identity: understanding, verifying, and controlling an identity's actions.
Authentication establishes what an identity represents, while authorization and federation ensure that this identity adheres to predefined rules to only access resources it is permitted to view/use. Meanwhile, lifecycle management ensures these rules evolve as the identity's status changes, reinforcing the concept that identity management is a dynamic, ongoing process.
Analyzing AWS Identity and Access Management (IAM)
AWS IAM is often the gateway service for organizations starting their journey with AWS-based identity management. All AWS services integrate with and depend on AWS IAM for authorization.
At its core, AWS IAM is a role-based access control (RBAC) service. Briefly, RBAC controls access to systems and resources based on the notion of roles and privileges. Certain roles have specific privileges within a given system. In the cloud, these privileges are typically defined via policy documents:
AWS IAM operates based on policies that define who or what is authenticated and authorized to perform which actions on which resources.
AWS IAM supports identity federation with Identity Center or other identity providers (IdPs), extending its identity management capabilities beyond the AWS ecosystem. This allows organizations to utilize existing identity solutions and seamlessly integrate them with their AWS resources.
AWS IAM features two main identities:
- IAM user: This aligns with the traditional model of a user, representing a logical user identity with hardcoded access credentials.
- IAM role: An identity that provides more flexibility of expression, roles can be used as a service account by non-interactive users (e.g., EC2 instances). IAM roles can also be “assumed” by other identities that have the correct authorization.
IAM roles are the building blocks of larger, more complex identity management implementations, such as organizations and cross-account access. As organizations grow and their engineering environments scale in both headcount and number of distinct applications, the complexity of their AWS environments invariably increases as well. Many IAM users are often employed for different application environments: security, billing, and top-level identity management. But implementing IAM users for these types of environments simply does not scale well. IAM roles, on the other hand, provide the necessary flexibility and scalability to manage access effectively.
Most engineering teams handling a cloud deployment in AWS initially choose vanilla IAM as their identity management platform. Typically, an organization would provision some IAM users for their engineers, assigning them role-specific permissions. Some of these might have admin permissions, while most would have limited, job-specific permissions. Applications and services are then assigned IAM roles, defining what actions they can perform on AWS resources.
As an organization expands, multiple accounts may come into play. IAM users might also be migrated to a separate identity account and granted cross-account role permissions. However, such a setup can be increasingly challenging to manage at scale, and over-permissioning becomes inevitable.
Diving into AWS IAM Identity Center (Previously Named SSO)
AWS IAM Identity Center, previously known as AWS SSO, is AWS's managed single sign-on offering. Comparable to services like Okta, Identity Center provides a platform for centrally managing SSO-enabled applications that encompass AWS accounts and organizations, as well as third-party applications.
Single sign-on is often thought of as a mechanism that provides an application portal: a variety of disparate applications and vendor-specific tools accessible through a single access point. While this is certainly a key feature of Identity Center, it also provides a single sign-on pivot for multiple AWS accounts. Amazon actually recommends this as the “front door” into an AWS environment.
Managing more than two or three AWS accounts in a modern, active software development environment is far too complex an exercise to be handled effectively via manual policy creation. To this end, Identify Center offers a feature known as “Permission sets,” templated collections of IAM policies that can be applied across multiple AWS accounts. One template can be used to define policies across a set of resources, such as compute or database, and then assigned to multiple AWS accounts.
The IAM user or group that was initially assigned in the permission set is included as a principal in the trust policy of the newly created roles. These roles are managed automatically by Identity Center; if the permission set is modified, the changes are propagated across accounts. Authorized users can assume these roles via the IAM Identity Center user portal or a standard interface like the AWS CLI.
Permission Sets
When creating permission sets, there are two primary types to choose from:
1. Predefined permission set: This uses an AWS-managed policy designed by AWS to provide a generic set of permissions for given resources or services. A permission set with the “IAMFullAccess” managed policy might be used for identity or security administrators throughout an organization.
2. Custom permission set: This type of permission set is more flexible and can use up to 10 AWS-managed or customer-managed policies, plus an inline policy. Custom permission sets can also take advantage of permission boundaries for additional granularity in policy control.
For anyone who has worked with AWS IAM at scale, the conventions of permission sets should be relatively familiar; they follow configuration conventions that are similar to individual IAM roles.
How Identity Center Works
For the actual mechanism of identity management, users have the option to manage identities directly inside Identity Center, or they can connect them to existing identity sources like Active Directory and Okta. For larger enterprises with an existing directory or identity platform, this is the ideal choice. Greenfield deployments can take advantage of managing identities directly within Identity Center if needed, although a separate IdP solution is likely the best long-term choice.
Identity Center can bolster authentication security by either integrating MFA directly or utilizing an external IdP that is SAML 2.0-compliant. Like most AWS services, Identity Center provides tight integration with AWS CloudTrail. This is important since logging events and actions taken against the management API of any identity management component is a must-have security feature regardless of implementation; a successful audit will almost certainly demand demonstrating this ability.
One point to highlight is that if you use Identity Center, you will need to sign up for AWS Organizations. This allows you to manage multiple AWS accounts from a centralized console interface, with consolidated billing, policy management, and fully automated account deployment and creation. Although having to use AWS Organizations can mean more management overhead up front, the centralization it brings can also simplify the management of large AWS environments, making it easier to maintain a secure and organized infrastructure.
A Comprehensive Look at AWS Federated Identity
Identity federation in AWS allows users to authenticate themselves via an external identity provider (IdP) and subsequently access AWS resources in a given account, all without needing to directly utilize an IAM user with hardcoded access credentials.
Using Okta as an example, the basic process to set up identity federation within AWS is as follows:
- Set up Okta as the identity provider: The first step in the process is configuring Okta as an IdP. In Okta, an app is created for AWS with the necessary details about the target account. This involves setting up a SAML (security assertion markup language) connection between Okta and AWS.
- Set up AWS to trust the IdP: Next, you’ll need to set up a trust relationship between the AWS account and the IdP. This is done in the AWS IAM console, where you create the configuration for the identity provider, including the SAML metadata generated in the previous step.
- Create IAM roles in AWS: IAM roles are created in the AWS accounts that federated users will assume. These give users the correct permissions to access AWS resources, so make sure to set them up with a trust policy that allows the IdP to assume the proper roles.
- Assign users to IAM roles in the IdP: In the IdP, users (or groups of users) are assigned to the IAM roles that have been created in AWS. This mapping tells the IdP which AWS role a user should assume when they request access to AWS.
- User authentication and access: When a user attempts to access AWS, they will be redirected to the IdP for authentication. Once they provide their SSO credentials and are authenticated, the IdP sends a SAML assertion to AWS indicating that the user is authenticated and specifying which IAM role they should assume. AWS then gives the user temporary security credentials that provide them with access to AWS resources based on the permissions of the IAM role they've assumed.
Considerations and Challenges
Manually creating IAM roles and establishing trust relationships between AWS and an IdP can become a significant hurdle when trying to scale. As an organization grows, the number of roles that need to be managed can increase dramatically, making the process of creating and maintaining them labor-intensive and prone to error.
Each new role must be individually configured in both AWS and the IdP, which can be time-consuming, especially if there are many AWS accounts or a large number of users with varying access requirements.
Moreover, defining and maintaining the trust relationships between these roles and the IdP, as well as managing the mapping of users to roles, can become increasingly complex and difficult to manage at scale. This can result in a high administrative burden and potential inconsistencies or errors in access control, which could pose security risks.
To help simplify the management of a large number of identities, most identity providers like Okta enable users to map user groups on the provider side to roles based on a simplified regex and filter matching. However, this process is still naive and does not account for changing needs and usage patterns.
Ideally, organizations should focus on moving away from the paradigm of thinking of identities as static groups; they need to be seen more as dynamic, fluid collections of permissions that change as staff duties and the underlying environment change and grow. Automated solutions driven by the principle of least privilege (PoLP) provide this functionality, reducing the administrative burden and improving your security posture by automatically scaling and managing the permission scopes of dynamic entities.
Identity Center, AWS Federated Identity, and AWS IAM: Making the Best Choice
Choosing between Identity Center (formerly SSO), AWS Federated Identity, and AWS IAM is less about a direct comparison and more about understanding an organization's current state and future roadmap for application infrastructure. The objective should be to minimize administrative overhead early on while still embedding flexibility and multi-account-friendly access patterns.
An implementation path that accommodates most organizations would look as follows:
- Start with AWS IAM: For a new organization or project, starting with AWS IAM provides the fundamental identity management capabilities you'll need. Create a separate account for identities, issuing no meaningful permissions for them. This will keep access management modular and scalable from the outset.
- Or… leverage existing identity providers (IdPs): Large enterprises often already have an IdP or user directory such as Active Directory (AD). Rather than reinventing the wheel, existing systems should be integrated with the AWS environment through IAM.
- Adopt AWS Organizations: AWS Organizations should be implemented as early as possible. This service not only lets you manage multiple AWS accounts easily but also opens the door to utilizing an Identity Center deployment in the future if needed.
- Create resource-specific roles and policies: As you start to develop and deploy applications, create resource-specific roles and policies in the relevant accounts (security, development, production, etc.). Automating permissions creation and management can simplify this process and ensure consistency.
- Entitle IAM user identities to assume roles: Assign permissions to IAM user identities that allow them to assume roles as needed with time-boxed access. This follows the principle of least privilege and enhances your security posture.
- Consider a separate IdP solution as you scale: When an organization or team scales past a certain threshold, a separate IdP solution is the logical next step. At this point, integrating Identity Center with an external IdP and third-party applications can centralize and streamline identity management.
- Use Cognito for external users: If there are a large number of external users, AWS Cognito and its federated identity pools can bridge access between these users and internal AWS resources and systems.
It's important to remember that identity management is not a one-size-fits-all solution. What works best for an organization will depend on its unique needs, the complexity of its environment, and the long-term vision for the overall application infrastructure.
You should also consider the maturity of engineering initiatives and staff: Trying to implement an enterprise-grade identity solution for a small startup with a single MVP is a recipe for expensive failure. The best choice is a solution that provides immediate ROI but one that can also grow alongside your engineering team.
Charting a Path Forward in AWS Identity Management
Getting identity management right is a critical step toward ensuring both security and scalability for a software organization. Understanding which AWS identity management solution makes the most sense is about understanding where your organization currently stands in its growth journey.
It's important not to force implementation patterns with tools that weren’t designed for a particular use case. Misalignment on this point, such as an over-reliance on an IdP for managing user groups and authorization, can lead to unnecessary complexity and potential security risks.
Third-party offerings can provide an alternative to or complement native AWS services. By automating much of the identity management process, these tools reduce the administrative burden on security and DevOps teams, freeing them to focus on building and securing application infrastructure.
AWS offers users several identity management tools that are flexible and powerful. By understanding these solutions and how they fit into your organization's unique context and growth path, you can design an identity management strategy that’s robust, scalable, and secure.
