In the old days before IAM Identity Center (AWS SSO), we used custom IAM Identity Providers with IAM Roles that had trust policies that allows users with certain claims (IdP groups) to assume them. This system was nice in that AWS/IAM didn't care about provisioning, syncing, or otherwise tracking the users themselves; it only cared that a user was able to get a valid SAML assertion or OIDC token.
Having the Identity Center internal user/group database just seems like an unnecessary security risk when you're using an IdP. For example, consider this scenario:
- I have a user in the
aws-adminsgroup in Active Directory, and this is synced to Identity Center via SCIM. - My provisioning (SCIM) tokens expire and the sync stops.
- I remove this user from the
aws-adminsgroup because they've been moved to a different job/department. - Because the sync has stopped, Identity Center isn't aware of this change.
- The user can still authenticate to Identity Center with Active Directory because they still have a valid user, but Identity Center thinks they're still in the
aws-adminsgroup and lets them assume an administrator permission set.
Is there any way to use Identity Center without having it internally store the users/groups? i.e. to have Identity Center use claims/assertions from the IdP to determine which permission sets can be assumed, instead of it using the IdP response to just identify the user, and then using its internal user/group database to determine which permission sets can be assumed?
What you described (AWS console access using SAML assertions alone) is still possible using AWS IAM.
AWS SSO seems to be for a different use case of centrally managing access to AWS and other applications, as seen in their product page. In this case, it makes sense that provisioning is required.