AWS SSO has a naming problem. It’s going to quickly be the best way to enable access into AWS *using your own Single sign on identity provider for authentication.* Its capability to be an IdP or single sign on provider to other apps is not where its value lies for most people 1/
Today, you need your IdP to understand everything about access into AWS—the mapping of people to accounts and roles, because that information needs to get packaged up in a SAML assertion. Size limits on the SAML assertion make sensible multi-account setups hard. 2/
AWS SSO moves those mappings into AWS. Authentication uses your IdP—you sign into your own single sign on system, but the SAML that gets sent over is just your identity; the access you’re granted is maintained in AWS SSO. 3/
All the things related to you, attributes and groups, are separately sync’d via SCIM from your IdP. And that process is scalable, so we’ve left SAML size limit problems behind. 4/
Inside AWS SSO, with all the identity and membership pushed over from your IdP, you maintain assignments of users and groups to particular permissions on particular accounts. This is AWS-specific information, and it makes sense to me to maintain it here rather than in the IdP 5/
This *isn’t* about changing how you users authenticate with your IdP, nor about changing applications already using your IdP for single sign on. It’s about changing the system that your users use to gain AWS credentials for a better, more easily maintained and integrated one 6/
Besides the management advantages, AWS SSO has an API to authenticate against it (using your IdP) using the OAuth Device Flow. This is how the CLI v2 is able to have `aws sso login` 7/
The same logic, using the AWS SDKs, will enable AWS access, authenticated with your IdP, in any application you want to build. I’m looking forward to enabling access to data in S3 for robotics GUI tools we’ve got written in C++ 8/
People hear “AWS SSO” and understandably think it means changing their whole internal SSO setup, when it’s really not changing much from a user perspective and doesn’t impact the admin side outside of the IdP-AWS connection. 9/
Replacing sts:AssumeRoleWithSAML with AWS SSO has a narrow scope for your org, and is going to enable significantly better management and governance, *and user experience,* without changing your IdP or how you do single sign on in your org 10/10
