feat: Improve Identity Documentation #665
Conversation
Co-authored-by: Andriy Knysh <[email protected]>
| user1_copy["User 1 Copy"] | ||
| user2_copy["User 2 Copy"] | ||
| user3_copy["User 3 Copy"] | ||
| group1_copy["Group 1 Copy"] | ||
| permissions["Permission Sets"] | ||
| user1_copy -.-> group1_copy | ||
| user2_copy -.-> group1_copy | ||
| user3_copy -.-> group1_copy |
There was a problem hiding this comment.
What are copies? Is this a term used by Identity Center?
|
|
||
| :::tip AWS IAM Identity Center or AWS SAML? Which do I choose? | ||
|
|
||
| The vast majority of our customers prefer AWS IAM Identity Center (SSO). The convenience of a web console login is hard to beat. However, some customers prefer SAML for its simplicity and compatibility with existing systems. We support both methods, and you can choose the one that best fits your needs. |
There was a problem hiding this comment.
I think the part we gloss over is that you always deploy aws-saml because it's how the identity architecture is implemented for automation. The option is whehter or not they also deploy AWS SSO.
There was a problem hiding this comment.
we dont need aws-saml for automation. GH uses OIDC to assume the team directly - saml isnt involved
There was a problem hiding this comment.
GH OIDC as a whole isnt explained in this layer. We should document somewhere specifically how it works - assuming a team from github, using a mixin, github-oidc-role, or something else, etc
We have this, but it's about OIDC as a process not for our architecture
https://docs.cloudposse.com/layers/github-actions/github-oidc-with-aws/
| @@ -60,8 +218,55 @@ Follow the Identity Providers documentation for adding a SAML login. | |||
|
|
|||
| With AWS SAML, we create a federated SAML login that connects to the "team" in the identity account, and then users can assume other roles from there. We use the [AWS Extend Switch Roles plugin](https://github.com/tilfinltd/aws-extend-switch-roles) that makes this much easier, but it's not as intuitive as Identity Center. | |||
There was a problem hiding this comment.
We should explain somewhere what we mean by federated
Federated login means that instead of managing separate credentials for each AWS account, users authenticate through a centralized identity provider (IdP). This allows them to access multiple AWS accounts or services using a single set of credentials, based on trust relationships established between the IdP and AWS.
what
why
references