I recently set up AWS SSO on an engagement. In this instance, I was setting it up using AWS Managed Active Directory as the identity provider. My first impression was how incredibly easy it was to set up the integration of SSO with the Managed AD. The SSO console basically prompts you for your Managed AD instance from a dropdown list. You connect it, and that’s it. AWS Managed AD comes with an OU already set up for you that SSO federates with. You add AD Groups (Domain or Global) in this OU along with users. Add users to those groups. From SSO, you pick from amongst these groups and map the AD Group to a permission set in an account from amongst those in your org. The SSO portal users log into is clean and provides a good user experience. You also have options to enforce (and manage) MFA at the SSO level. The SSO portal also provides copy-and-pasteable IAM credentials. Moreover, if your SSO users are using AWS CLI v2, the CLI will save you the hassle of copying and pasting credentials from the SSO portal to your credentials file, keeping them refreshed locally on your behalf. Overall, it’s a slick, easy-to-setup solution.
While all this is great, there are – from my perspective – a few flies in the ointment. First, the permission sets can only be managed from the SSO portal. You can define the permission set only from the SSO portal (which resides in the master account of your AWS Organization). It’s not possible to provision roles (what a permission set essentially amounts to when deployed to a target account) ahead of time in the target accounts. What would be highly preferential as a deployment mechanism would be the ability to use Stack Sets to push SSO service-linked roles out to spoke accounts that could be mapped as permission sets from the SSO console. This brings up the second fly: it would also be nice to do the AD Group to SSO permission set mappings through an API. At this point, the SSO API is quite limited in what it provides: essentially, it provides a mechanism to obtain STS credentials (the same type a user can retrieve from the SSO portal), as well as a few list operations. Third fly: the Managed AD has to be deployed in the master account in your Org (this is documented, but I didn’t discover it in the docs until after I had set it up initially – thankfully, this was all done with CloudFormation so remediating the issue was pretty easy).
So, there you have it. A quick rundown of the good, bad, and ugly of setting up AWS SSO with AWS Managed AD. Overall, it’s a pretty awesome solution that provides a solution to an ever-present enterprise need (federated login from a single identity “source of truth”) that is well integrated with the AWS console, AWS IAM, and for users who prefer to use the CLI. Hopefully soon we will see some additions to the SSO API to make programmatic management easier and reduce the dependency on console usage to manage permission set to AD to group association. Some integration allowing for ahead-of-time provisioning of roles that can be used with SSO would be great. Overall verdict: great solution, and I look forward to seeing improvements for administrators as time goes on. In a future post, I plan on documenting the process of setting this up in my own org – so stay tuned!