So you have your shiny new AWS Organization. Maybe you’ve already built a best-practice Landing Zone. Your teams are now eager to get access to your brave, new, cloud-shaped world and start building Cool Stuff. Oh, and the small matter of actually moving the business forward.
AWS IAM Identity Centre (IAM IC) can help to streamline and simplify user access management in AWS to do just that. But, what should you be thinking about when getting set up?
Just one solution
Identity and access management good practice tells us we should be centralising identity. Simply put, avoid spreading accounts and credentials unnecessarily by tying access back to trusted identity providers (IdPs). The high-level question that IAM IC is answering is: How do I stop provisioning access manually across all of my AWS accounts? By default it provides a single way to manage user identities and their access.
Even better, it can (though sometimes imperfectly) integrate external IdPs. Your enterprise SSO then becomes exactly that for your AWS environment, a single point of authentication. Your SSO and MFA configuration enforced across the business is simply re-used for users in AWS as well. This also means your existing JML processes (Joiners, Movers, and Leavers) can ensure access is provisioned and removed as employees join, move and leave.
The power to do what you ought
The underlying mechanics of IAM IC are the tried and tested AWS IAM. That means when you configure your mappings of users to permission sets and accounts, what is happening under the hood is the provision of IAM roles to accounts that your SSO users can assume. Common IAM pitfalls still apply here. Are you assigning permissions to individuals or groups? Do you make use of administrator access permission policies instead of defining what a user needs? Are there wild-carded resources for convenience or action granted ‘just in case’?
Scope access to the job at hand. Use fine-grained policies to protect data where you can. Manage the assignment of user access automatically using SCIM-provisioned groups and the permissions themselves in code.
I would do anything for love, but I won’t (just) do RBAC
Assuming your role-based access control (RBAC) is in-hand, eliminating permanent access, particularly privileged access, is an easy way to refine your security posture. Because IAM IC can integrate with your existing IdP, you likely already have tooling in place to provide appropriate workflows. For example, Microsoft Entra ID PIM can be used to allow access between certain hours, or after specific approvals, only providing the appropriate claims to IAM IC when the conditions are satisfied. You can also apply context-aware controls from things like Google Workspace Context-Aware Access or Entra ID Conditional Access. You can use these to only allow your AWS access from trusted devices, countries or locations.
On the AWS side attribute-based access control (ABAC) helps to manage permissions dynamically. Instead of creating and maintaining separate roles or policies for every user or team, tags on resources and IAM identities like project, environment, or team can be used to define access. ABAC also integrates with SAML and OIDC, passing user attributes from your IdP as session tags. These claims can drive the same kind of fine-grained access decisions described above, granting access as and when needed without constant policy updates.
I commandeered a Chieftain tank without the permission of my immediate superiors
Permission needs evolve, and exceptions are inevitable. Users and teams are reluctant to ‘give up’ access. Regularly reviewing permission sets in AWS is critical to maintaining least-privilege access and reducing security risk. To stay on top of this, it’s important to audit IAM roles, groups, and policies on a routine basis. Look for excessive permissions, outdated rules, or inconsistencies across environments. Tools like IAM Access Analyzer and AWS Config help detect drift and highlight where actual usage doesn’t match intended access, making it easier to clean up and tighten policies proactively.
Events, dear boy, events
Once you’re up and running, use CloudTrail to see who’s doing what, and GuardDuty to alert on unusual API calls or activity. If there are roles that deserve special attention, ensure they alert when they’re used.
In case of emergency
Break-glass accounts are your fail-safe when misconfiguration or service outage render your SSO unusable. These should be highly protected unused roles or accounts with a path to access outside of SSO. There are several ways to accomplish this in AWS, such as by using role chaining (temporarily assuming roles) or OIDC trust relationships. The key thing here is that access should be severely restricted and use of the role should trigger a security response.
Wrapping up
Managing access in AWS can seem daunting, but IAM Identity Center and smart integration with your existing IdP make it much more manageable. With automation, regular audits, and a strong least-privilege mindset, you can empower teams without compromising on security.
Designing effective systems security for your SaaS business can feel like a distraction from delivering customer value. Book a security review today.
This blog is written exclusively by The Scale Factory team. We do not accept external contributions.
