AWS Identity Management: The OneLogin Difference with Multi-Resource Provisioning

November 28th, 2016   /     /   smarter identity

Happy re:invent! With Amazon’s biggest conference kicking off today, I wanted to write about a long-awaited feature – it’s a game changer for AWS administrators.

The Situation

Simply put, OneLogin for AWS uses your organizational context to apply least privileged access on AWS accounts at scale.

So why is this significant? It means that you can now use your existing directory to maintain very granular permissions in AWS. No more going to each of your accounts and upgrading user access individually based on AWS account and IAM Role – instead, one action in your corporate directory combined with preset rules and mappings in OneLogin activates all of the desired permissions in AWS. And when somebody does not need permissions in one or more AWS accounts anymore, you can quickly evoke access instantly all at once.

After all, not every developer is the same. In every developer group, there are always members who require special permissions to complete their job, and handling those exceptions are some of the most challenging parts of the security cycle. The challenge is compounded when it extends to every group that uses something within your AWS infrastructure. For example, specific access for marketing may be requested during a project and granted by the AWS admin. This is great for collaboration and project flow, but when the project is complete, access should be revoked. Yet more often than not, AWS admins forget that the privilege had been granted and it isn’t revoked until many months later, or longer.

It’s a lot harder to hunt down rogue permissions months after they have been manually granted. When’s the last time anybody ever said to you “I have too many permissions, please remove some from my account”?

So How Do You Automate AWS Identity & Access Management Across Accounts?

Imagine if you had the tools to easily audit and manage your AWS user infrastructure while leveraging AWS IAM best practices, all without compromising end user productivity.

OneLogin has a solution that does just that, and it’s easier to set up that you’d think.

First, you need to setup my various policies in your AWS account(s) using the AWS Management Console and AWS IAM roles. This is the longest and hardest step – how granular do you want to make your permissions? With AWS, you can literally manage everything down to specific items within a module (S3, EC2, etc.) and you can have a theoretically infinite amount of permissions that could be assigned to users. The most effective teams keep permissions simple, but granular enough to allow for mixing and matching.

Second, you connect OneLogin to your AWS account(s). With AWS’ cross-account sharing, all policies across every account can be exposed in a single interface. From there, OneLogin’s mapping engine allows you to associate any of your directory groups or user attributes to specific AWS policies. For example, you may want all members of the “Web Development” group within your Active Directory to get write access to specific production S3 buckets for content while allowing for less strict measures for development S3 buckets.

Finally, you assign users, en masse, to the various directory groups. I’ve already set up the associations in OneLogin, so users can be instantly onboarded with specific permissions.

Simple, yet elegant — that’s OneLogin for AWS. Every single permission for each and every AWS account is accessible and manageable through a single OneLogin connection via mappings that automatically assign users to their respective least privilege permissions.

The OneLogin Difference

When a user signs in to AWS via OneLogin, they see only the specific permissions they are entitled to. No extra user accounts or inflated permissions, no extra fuss. Unlike other IAM solutions, there’s no extra icons in OneLogin either – a user may have access to 1 or 100 specific AWS policies across countless AWS accounts, but it still appears as a single application in the OneLogin portal.

In addition, permission mappings for AWS are separate from every other application. After all, a security model for AWS is different than a security model for Office 365 or the G Suite. By compartmentalizing permissions for different applications, administrators can have hundreds of different mappings and easily apply least privileged access across their application infrastructure.

Now you can see why I’ve been waiting for this feature – it strengthens your security structure without impacting user or administrator productivity!

Visit OneLogin’s AWS page to learn more, set up a personalized demo, or get a free OneLogin account.

About the Author

Nathan is a Solution Architect at OneLogin focusing on partnerships with global systems integrators and software vendors. A Berkeley graduate and a New Yorker, he is also an avid fan of the New York Yankees.

View all posts by Nathan Chan