AWS

https://aws.amazon.com/blogs/security/how-to-establish-federated-access-to-your-aws-resources-by-using-active-directory-user-attributes/

In the preceding diagram:

1. An AD user (let’s call him Bob) browses to the AD FS sample site (https://Fully.Qualified.Domain.Name.Here/adfs/ls/IdpInitiatedSignOn.aspx) inside this domain.
2. The sign-in page authenticates Bob against AD. If Bob is already authenticated or using a domain joined workstation, he also might be prompted for his AD user name and password.
3. Bob’s browser receives a SAML assertion in the form of an authentication response from AD FS. Bob’s access is authorized based on his AD group membership or on AD user attributes configured on his account.
4. Bob’s browser automatically posts the SAML assertion to the AWS sign-in endpoint for SAML (https://signin.aws.amazon.com/saml). The endpoint uses the AssumeRoleWithSAML API to request temporary security credentials and then constructs a sign-in URL for the AWS Management Console using those credentials.
5. Bob’s browser receives the sign-in URL and redirects to the AWS Management Console.

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html

This scenario has the following attributes:

• The identity broker application has permissions to access IAM's token service (STS) API to create temporary security credentials.
• The identity broker application is able to verify that employees are authenticated within the existing authentication system.
• Users are able to get a temporary URL that gives them access to the AWS Management Console (which is referred to as single sign-on).

https://dzone.com/articles/confused-by-aws-storage-options-s3-ebs-amp-efs-explained