This article was also contributed by Samantha Morgan, Senior Product Manager at JumpCloud
AWS is the largest cloud provider in the world. According to Synergy Research Group, AWS has a 32% market share of the cloud provider (IaaS or infrastructure as a service) industry. For organizations managing user and group permissions, access to accounts, and resources, AWS offers two services: AWS Identity and Access Management (IAM) and AWS Single Sign-On (SSO).
There are several similarities between the services: both oversee access management, ensure their users only have entry to the resources they need, and can be centrally managed with an external identity provider (IdP). Given the similarities, why would an organization choose one over the other?
The following provides an example scenario to identify the best use case for each service. Admin Bob must decide whether he should utilize AWS IAM or AWS SSO to manage his AWS resources. In this particular scenario, he manages a group of 20 engineers who are accessing 10 AWS accounts.
Before jumping in to decide which one Bob should choose, let’s first define a few key AWS terms that are vital to Bob’s decision. The definitions were taken directly from AWS and the diagrams below from cloudonaut.
An AWS account is a container of AWS resources. Using multiple AWS accounts is a best practice for scaling environments, as it provides a natural billing boundary for costs, isolates resources for security, gives flexibility for individuals and teams, in addition to being adaptable for new business processes.
An AWS Organization is a collection of AWS accounts that can be organized into a hierarchy and managed centrally. Organizations help to programmatically create new accounts and allocate resources, and simplify billing by setting up a single payment method for all accounts. In addition, AWS Organizations is integrated with other AWS services so admins can define central configurations, security mechanisms, and resource sharing across accounts.
An AWS user is an AWS identity created directly in the AWS IAM or AWS SSO admin console that consists of a name and credentials.
A federated user is a user identity that is created in and centrally managed and authenticated by an external identity provider. Federated users assume a role when accessing AWS accounts.
A group is a collection of users. Groups let admins specify permissions for multiple users, which can make it easier to manage the permissions. Any user in that group automatically has the permissions that are assigned to the group. Any user removed from the group will lose those permissions. For instance, if Bob places a new employee into the Engineering group, which has access to the Lambda and DynamoDB production account, then the new employee will also be granted access to the resources in that account.
A role is similar to a user in that it is an AWS identity with permissions and policies that determine what the identity can and cannot do in an AWS account. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. A role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when a user assumes a role, it provides them with a set of temporary security credentials for that session. Admins can use roles to delegate access to users, applications, or services that don’t normally have access to those AWS resources.
AWS SSO Permission Set
A permission set defines the level of access a user has to AWS resources within an AWS account. For Bob, once he provides access to the necessary accounts in AWS SSO, he can use predefined or custom permission sets to control the level of access.
What Is AWS IAM?
AWS Identity and Access Management enables admins to manage access to AWS services and resources within an AWS account securely for what it calls “entities” — IAM users created from the AWS IAM admin console, federated users, application code, or another AWS service. Admins can create and manage AWS users and groups directly, and use permissions to allow and deny their access to AWS resources. Admins create roles to manage access for all other entities.
For instance, if Bob wants to control who has access to a specific S3 Standard bucket, then he can create a role and add permissions to that role to control which users have access.
What Is AWS SSO?
AWS Single Sign-On (SSO) also manages access to AWS services and resources. The difference is that it manages access for all AWS accounts within an AWS Organization, as well as access to other cloud applications, e.g., Salesforce.
AWS SSO includes a user portal where end users can find and access their assigned AWS accounts, cloud applications, and custom applications in one place.
AWS IAM vs. AWS SSO
Bob now understands the specific AWS terminology and what each service offers. He is ready to explore the differences between using AWS IAM and AWS SSO for managing access to AWS resources. Bob will compare what he would need to do in each service to accomplish the task of adding new accounts and granting access to specific AWS resources within those accounts to his team of engineers. This comparison will allow Bob to make a final decision about which service can best meet his needs.
Bob has 10 AWS accounts. He needs to create two new AWS accounts, a test account and production account for Lambda and DynamoDB, to isolate his environments and ensure proper access.
Using AWS IAM, Bob will need to create two new accounts following the signup process.
Using AWS SSO, Bob will need to open the AWS Organizations service and add two new accounts from there.
Configuring Identity Providers
Bob is using JumpCloud as his single identity provider.
AWS IAM supports setting up multiple identity providers per account. Using AWS IAM, Bob will need to log in to each AWS account and configure JumpCloud as the identity provider.
AWS SSO only supports a single identity provider. Using AWS SSO, Bob configures JumpCloud as his identity provider once, and JumpCloud becomes the identity provider for all his new and existing AWS accounts.
Defining Permissions and Roles
Bob needs to define the permissions and policies that govern what his users can and cannot do within an AWS account and to which AWS resources they have access. He will need to do this from the admin console of the service he is using.
Using AWS IAM, Bob will need to log in to each AWS account and create a new role(s), or from one AWS account, Account A, create policies that allow a role to be assumed in another AWS account and to control the level of access to S3, Lambda, and/or CloudWatch in Account B, for example.
Using AWS SSO, Bob can reuse existing AWS SSO policies and permission sets. Policies and permission sets are defined at an organization level and are applied to groups or users at the account level. If the ones that are already defined are not applicable to these new accounts, then he can create new ones in the AWS SSO admin console.
User and Group Provisioning
Using AWS IAM, federated users log in as a role not as their specific user identity. Bob doesn’t need to create users or groups. If he has a specific need to create a user account that is not managed by an identity provider and can log in as a user identity, he will need to create a user in AWS IAM directly. If he has a use case for having several AWS users, he could create groups to organize these users and make assigning access to these users simpler.
Using AWS SSO, Bob can configure a SCIM integration and have users automatically created in AWS SSO when they are created in his identity provider. Otherwise, he would need to create users and groups manually within the AWS SSO admin console.
With the roles defined, Bob is ready to assign roles to his users and groups.
Using AWS IAM, roles are assigned to federated users using attributes in the SAML assertion for each AWS account. For each role, Bob will need to define a role attribute at the connector, group, or user level in JumpCloud. He will need to get the Amazon Resource Name (ARN) for each account and each of the roles he defined and construct the SAML attribute value from the role and account ARNs.
Using AWS SSO, roles are assigned through group membership or directly to the user for each AWS account. Once the groups are created, Bob will need to assign permissions to each group in each account. He is able to further refine who within the group gets the permissions using tags, which use specific user attributes such as department or role, to determine if the permission should be granted.
Those permissions will then be inherited by users who are members of the group and meet any additional conditions of the permission(s). If there are certain users who need specific privileges in addition to what they inherit from their group, he can assign permissions to those users directly within each account.
What’s Best for Bob?
Bob is ready to make his decision. Bob chooses AWS SSO over AWS IAM.
AWS SSO is ideal for managing multiple AWS accounts. With his Engineering group set up in AWS SSO, Bob can now grant his users access to the accounts they need at the user or group level.
Within the AWS SSO service, if Bob wants to grant his Engineering group access to the production account for Lambda and DynamoDB, then all that he would have to do is select AWS accounts, check the account box, and assign at either the group or user level. To further enhance the type of access his users or groups have, Bob will have to specify the permissions levels. This includes using existing permissions, i.e., Power User, or creating a custom permission set.
An added benefit of AWS SSO is that any new user added to the group will automatically be granted the same level of access as other members in the group. If Bob adds Mary Adams to the Engineering group, then she will also be granted Power User access to the production account for Lambda and DynamoDB.
Interestingly, AWS is also pushing their users to switch from AWS IAM to AWS SSO. Within the identity providers tab of AWS IAM, Amazon has a banner promoting AWS SSO.
How Can JumpCloud Help?
As the example above illustrates, for admins, such as Bob, they can easily manage their AWS IAM and AWS SSO users and groups from JumpCloud. All they have to do is declare JumpCloud as their identity provider and connect their IAM and/or SSO groups to their JumpCloud groups.
For AWS SSO, JumpCloud has group management integration that will simplify onboarding and user management. This will allow admins to manage their AWS SSO groups from JumpCloud. In the case of Bob, once he provides the account and application access at the group level in AWS SSO, then any user he adds to the Engineering group in JumpCloud will automatically be granted entry to the Engineering group in AWS SSO, with access to the same accounts and applications as the existing engineers. If Bob has a new engineer joining his company, then all he has to do is create their identity in JumpCloud and add them to the Engineering group in the Admin Portal. This will create their identity in AWS SSO and place them in the Engineering group, granting them similar access and permissions as their peers.
Evaluate JumpCloud Free Today
If you’re new to JumpCloud and interested in learning more about how the platform supports AWS, then evaluate JumpCloud today! JumpCloud Free grants admins 10 devices and 10 users free to help evaluate or use the entirety of the product. Once you’ve created your JumpCloud account, you’re also given 10 days of Premium 24×7 in-app chat support to help you with any questions or issues if they arise.