Fouad Matin

@fouadmatin

Once your team reaches a certain size, creating and managing AWS IAM users directly becomes a point of friction in getting people access on day one or cleaning up permissions during the offboarding process.

Thankfully, AWS has a service for single sign-on called AWS Identity Center (formerly known as AWS SSO) that can act as a standalone identity provider for logging into AWS accounts or connect to an existing provider like Okta and Google.

The great part about using Identity Center is that instead of coming up with usernames like jane-prod you can just have people sign in with their company email ([email protected]) and their role will be automatically provisioned.

Here's a quick demo video of what that would look like:

AWS IAM can get you and your team pretty far. It helps that it's the default way to set up authentication with AWS when you first set up your account.

Over time, you'll likely develop the need for multiple accounts. One for development where everyone has access, one for production that's "locked down"... and maybe one for staging? Oh, and the new infra engineer mentioned they might need an extra account for some load testing... Does the frontend team need to have full admin access to production?

Your AWS account must be managed by AWS Organizations. If you haven't set up an organization already, you can choose whether to have AWS create an organization for you.

It's recommended that you complete this process with standalone root AWS account that is only used for setting up the AWS Organization and SSO, for example [email protected] that is a Google Group or mailing list.

Before users can start using single sign-on, you need to first enable AWS IAM Identity Center:

1. Sign in to the AWS Management Console with your AWS account root user credentials.
2. Open the IAM Identity Center console.
3. Under Enable IAM Identity Center, choose Enable.
4. IAM Identity Center requires AWS Organizations. If you haven't set up an organization, you must choose whether to have AWS create one for you. Choose Create AWS organization to complete this process.
5. AWS Organizations automatically sends a verification email to the address that is associated with your management account. There might be a delay before you receive the verification email. Verify your email address within 24 hours.

Deciding if you want your users to be provisioned based on their Google Workspace or Okta accounts all depends on your situation.

There is no one right answer, but just tradeoffs given your situation.

If you have Okta, you should probably connect Okta as your identity provider.

Your IT and security teams will thank you later. You can follow AWS official documentation for setting up Okta.

If you use Google Workspace as your only identity provider, you may want to consider using Okta Developer which has a generous free tier of up to 7,000 users.

One of the primary tradeoffs between Okta and Google is support for System for Cross-domain Identity Management (SCIM) which Google generally does not have out-of-the-box. The difference between SAML support and SCIM support is that SAML handles the authentication ensuring you are who you say you are, but SCIM is the provisioning that creates your user profile or groups assignments in AWS.

You can still use Google, thanks to an open-source AWS Labs project called ssosync. You can read more about installation and configuration in the project README but the TLDR is that it works by syncing the data on a recurring schedule.

“

Caveat: when someone gets added to a Google Group that provisions their access, they won't be able to access it until the next scheduled sync - which can be anywhere up to 59 minutes if you sync hourly, which is the default. You can solve this issue by using solutions like Indent that can trigger a sync whenever access is granted or revoked.

Yep — AWS Identity Center also supports standalone usage, so you can just manage users and groups directly from the Identity Center section in the AWS admin console.

If you do this as part of your initial configuration, you can always migrate to a custom identity provider like Okta or Google, but your team's workflow and usernames (which would be their email address) doesn't change — which is awesome.

With AWS Identity Center, you can ensure that only the right people have access to the right resources, while still keeping your environment secure. Overall, setting up AWS Identity Center is an important part of managing your AWS environment.

If you have any issues or questions going through this process, feel free to reach out! We're happy to help even if you're still at the exploration phase for your access control structure.

Once you've set up single sign-on with AWS Identity Center, you might find it tedious to keep going into the admin console to grant someone access or setting reminders to revoke it the next day. That's where our product Indent can help — users can request and reviewers can grant without even leaving Slack.