Identity federation and user management#
This page describes and evaluates the possibilities to setup identity federation between AWS accounts and the Caascad corp Keycloak.
We explore the following designs:
- Federation using "Hub and Spoke" model
- Direct Federation model
- AWS SSO using corp Keycloak as identity provider
Federation using "Hub and Spoke" model#
With 'Hub and Spoke' model, Keycloak corp would be defined as an external IDP in a single AWS account - "identity"
There is a "Double assume role" : - one assume role with SAML to get credentials in the "identity" AWS account - thereafter a second assume role to get credentials in a target AWS account to effectively perform actions
The "double assume role" drives complexity with
- Infra as code : Terraform or Cloud Formation needs to be configured with the sequence of role assumptions
- log auditing.
- role definition
- at the identity account level, a set of roles must be defined carefully to reflect the user segmentation
- at the target account level, the trust relationship between the local assumed IAM role and the requester role in the "identity" account must be restricted
Direct Federation model#
Conversely, direct federation will not use an "identity" account but provision the same external IDP to all the AWS accounts.
This supposes a good automation process.
This process looks simpler to setup, use and maintain. See this article.
AWS SSO using corp Keycloak as identity provider#
AWS SSO is the service used by Control Tower to manage user access in the case of multi-account organization.
By default, AWS SSO has its own user referential but it can support SAML external providers(DOC).
Automatic or manual user provisioning#
If the SAML external provider supports SCIM (System for Cross-domain Identity Management) v2, automatic provisioning of users can be setup.
If not, users must be manually created in both the external provider and AWS SSO then the email address and username association is the key link to map identities between AWS SSO and the external provider
Warning
Keycloak does not support SCIM yet!
Setting up corp Keycloak as an external provider to AWS SSO will require dual user provisioning in Keycloak and AWS SSO.
In addition, Terraform AWS provider does not manage aws_sso resources...
this seems very ugly and difficult.
→ user access for Caascad operators will be done without AWS SSO.
Conclusion#
We will setup Direct Federation with Terraform in conjunction with AWS SSO :
- AWS SSO will be kept to manage a recovery user with MFA. This user will have AdministratorAccess to all the AWS accounts. Its credentials will be hold by the security team.
- Corp Keycloak will manage the Caascad users.
- For each AWS account, an unique email address for the root user must provided.
