Flow models in federated identity management:

  • identity provider initiated model (IdP-initiated)
  • service provider initiated model (SP-initiated)

IdP-initiated

  1. The user gains access to intranet via organization’s authentication mechanism.
  2. The user navigates to a web page on intranet that contains a link to a Connections Cloud product such as Connections Cloud S2.
  3. The user clicks the link.
  4. The SSO process is initiated. A SAML assertion is sent to the Connections Cloud endpoint via HTTP POST. If the user has a valid account, access is granted.
  5. The user interacts with Connections Cloud.

SP-initiated hybrid

  1. The user navigates to the Connections Cloud login page.
  2. The user clicks Use My Organization’s Login.
  3. The user enters the email address that is associated with the user’s account.
  4. Connections Cloud looks up the email address and then redirects the user to organization’s authentication mechanism.
  5. The flow continues from Step 4 of the IdP-initiated model.

AWS SAML

  • AWS supports identity federation with SAML 2.0 (Security Assertion Markup Language 2.0),
  • SAML is an open standard that many identity providers (IdPs) use.
  • It enables federated single sign-on (SSO)
  • users can log into the AWS Management Console or call AWS API without being an IAM user
  • simplify federation configuration with AWS,

IAM federation supports these use cases:

  • Federated access to allow a user or application in organization to call AWS API operations.
    • use a SAML assertion generated in organization to get temporary security credentials.
  • Web-based single sign-on (SSO) to the AWS Management Console from organization.

Using SAML-Based Federation for API Access to AWS

Example to give employees to copy data from their computers to a backup folder.

  1. A user in organization uses a client app to request authentication from organization’s IdP.
  2. The IdP authenticates the user against organization’s identity store.
  3. The IdP constructs a SAML assertion with information about the user and sends the assertion to the client app.
  4. The client app calls the AWS STS AssumeRoleWithSAML API, passing the ARN of the SAML provider, the ARN of the role to assume, and the SAML assertion from IdP.
  5. The API response to the client app includes temporary security credentials.
  6. The client app uses the temporary security credentials to call Amazon S3 API operations.

SAML – Console – AssumeRoleWithSAML

  • Corporate user access AD FS
  • AD FS authenticates user against Directory
  • SAML Token contains membership generated
  • Sigin in with SAML Token to AWS Sign-in Endpoint
  • AssumeRoleWithSAML send to STS
  • STS returns Creds
  • AWS Sign-in endpoint returns Console URL
  • Corporate user Redirected to AWS Console
  • No need to maintain dedicated Fed proxy for application, proxy doesnt need any IAM permission.

Menu