Skip to main content

Integrating Beyond Identity with AWS IAM Identity Center

  • Updated

Version: 1.0

Date: May 6, 2025

Audience: External Customers, Technical Stakeholders, AWS Competency Reviewers

1. Introduction

This document outlines the recommended architecture for integrating Beyond Identity with AWS IAM Identity Center to meet workforce identity requirements. This architecture leverages an existing primary corporate Identity Provider (IdP) – such as Okta, Microsoft Entra ID (Azure AD), or OneLogin – for user lifecycle management and SCIM (System for Cross-domain Identity Management) provisioning into AWS IAM Identity Center. This approach aligns with AWS best practices by utilizing the SCIM integrations that AWS has tested and validated with these major IdPs.

Beyond Identity enhances this ecosystem by providing phishing-resistant, passwordless Multi-Factor Authentication (MFA) and device posture checks. It integrates with the primary IdP to ensure that users accessing AWS resources (via IAM Identity Center) and other corporate applications are strongly authenticated and accessing from trusted devices, while the primary IdP handles the foundational identity provisioning into AWS.

2. Key Components

  • End User: Workforce user requiring access to AWS resources and other applications.
  • Primary Corporate IdP: The customer's main identity provider (e.g., Okta, Microsoft Entra ID, OneLogin) responsible for user lifecycle management, core authentication, and SCIM provisioning to AWS IAM Identity Center (required for outbound provisioning via SCIM to AWS IAM Identity Center).
  • Beyond Identity: Provides strong, passwordless, phishing-resistant MFA and device identity, integrating with the Primary Corporate IdP to secure the authentication process. It can act as an identity provider or an authentication service called by the primary IdP.
  • AWS IAM Identity Center: AWS service for centrally managing workforce access to multiple AWS accounts and applications. It acts as a SCIM service provider (receiving identity information from the Primary Corporate IdP).
  • AWS Accounts & Applications: Target AWS resources and integrated enterprise applications.

3. Architectural Overview & Data Flows

This architecture separates the identity provisioning (SCIM) flow from the user authentication (SSO) flow, with Beyond Identity strengthening the authentication leg.

Diagram:

                        

4. Detailed Flows

A. One-Time Setup & Ongoing Identity Provisioning (Addresses AWS SCIM Requirement for IDAM-003)

  1. SCIM User/Group Sync (Admin Task & Automated):
  • The Primary Corporate IdP (Okta, Microsoft Entra ID, etc.) is configured to automatically provision users and groups into AWS IAM Identity Center.
  • Data Flow: Primary Corporate IdP --(SCIM v2.0)--> AWS IAM Identity Center
  • Mechanism: This utilizes the outbound SCIM capabilities of your Primary Corporate IdP (acting as a SCIM client) and the inbound SCIM endpoint of AWS IAM Identity Center (acting as a SCIM service provider).

B. User Authentication & Access Workflow (End-User Experience with Beyond Identity)

  1. User Access Attempt:
  • The End User attempts to access an application or service that is federated with the Primary Corporate IdP, or they might attempt to access the AWS User Portal (managed by IAM Identity Center) directly, which will also redirect to the Primary Corporate IdP.
  1. Authentication Initiated by Primary Corporate IdP, Involving Beyond Identity:
  • The Primary Corporate IdP initiates the authentication process. As part of its policy, it redirects or calls out to Beyond Identity to perform strong, passwordless MFA and device posture checks.
  • Data Flow (Simplified): User <--> Beyond Identity (for MFA & device check) <--> Primary Corporate IdP
  • Mechanism: This integration can occur via standards like OpenID Connect (OIDC) or SAML, where Beyond Identity might act as an external IdP called by the primary IdP, or its authentication SDK/APIs are invoked. (Refer to Beyond Identity docs for Okta, Entra ID, OneLogin, Generic OIDC integrations).
  1. Identity Validation & Policy Enforcement by Primary Corporate IdP:
  • Beyond Identity provides an authentication assertion (e.g., signed token, SAML assertion fragment) and device trust signals back to the Primary Corporate IdP.
  • The Primary Corporate IdP validates this response, combines it with its own user context and policies, and then issues its own assertion (typically SAML) for the target service (e.g., AWS IAM Identity Center or another application).
  • Data Flow: Beyond Identity --(AuthN Assertion/Device Status)--> Primary Corporate IdP
  1. Accessing AWS Resources via IAM Identity Center:
  • The Primary Corporate IdP (now assured of a strongly authenticated user via Beyond Identity) sends a SAML assertion to AWS IAM Identity Center.
  • IAM Identity Center, having received user identities via SCIM (Step A.1) and now a valid SAML assertion, grants access to the appropriate AWS roles and applications.
  • Data Flow (Authentication): Primary Corporate IdP --(SAML Assertion, post-Beyond Identity check)--> AWS IAM Identity Center
  • Data Flow (Authorization): AWS IAM Identity Center --(Temporary AWS Credentials/SAML to AWS Services)--> AWS Accounts/Applications

5. Conclusion

This federated architecture allows customers to effectively use Beyond Identity to significantly enhance the security of their workforce access to AWS, managed via AWS IAM Identity Center and their Primary Corporate IdP. It ensures a secure, compliant, and efficient way to manage identities and access, directly supporting the goals of AWS best practices by layering strong, phishing-resistant authentication and device trust onto an AWS-approved SCIM provisioning model.

Related articles

Comments

0 comments

Article is closed for comments.