亚马逊云科技中国区域管理控制台与 Okta 及 Azure Active Directory 基于 SAML 的单点登录集成实现（一） – SAML 简介及 Okta Account Federation APP 与管理控制台的 SAML 集成

概念及服务介绍

什么是 SAML

安全断言标记语言 SAML（Security Assertion Markup Language）是一个基于 XML的、用于实现不同业务实体（即系统或服务）之间，交换安全信息（例如认证信息、授权信息、主体属性信息等）的开放标准协议，用于在不同的安全域之间进行身份验证和授权。它允许不同的安全域之间通过 SSO（Single Sign-On，单点登录）进行互操作，使用户可以使用单个身份验证凭据访问多个应用程序和服务。

SAML 中涉及到哪些角色和实体

通常涉及到以下三个主要角色：

身份提供者（Identity Provider，IdP）：负责验证用户的身份并生成 SAML 断言，包含了用户身份和属性信息等。
服务提供者（Service Provider，SP）：提供服务和资源，根据收到的 SAML 断言来验证用户的身份和授权信息。
终端用户（End User）：请求访问服务提供者所提供的资源或应用，需要进行身份验证和授权。

除此之外，还有一些其他的角色如签名者（Signer），断言消费者（Assertion Consumer），断言颁发者（Assertion Issuer），信任锚点（Trust Anchor），这些角色和实体在 SAML 协议中起着重要的作用，共同构成了一个安全和可靠的单点登录和身份验证框架。

SAML 协议中的基本概念

在整个 SAML 协议框架体系中，会涉及到以下几个基本概念：Metadata、Authentication Context、Assertions、Protocols、Bindings、Profiles。如下图所示：

Metadata

SAML Metadata是一组是基于 XML 的安全令牌，描述了 SAML 实体（包括身份提供者和服务提供者）的属性和配置信息。SAML Metadata 包含有关实体的 URL、公钥、协议支持和其他配置信息。身份提供者和服务提供者都可以发布自己的元数据，并使用对方的元数据来配置 SAML 集成。

Authentication Context

认证信息上下文。在某些特殊场景下，SP 需要依据当前主体（Subject）在 IdP 中的认证方式和强度，来决定是否接收断言。SP 也可以在请求中声明，要求 IdP 通过指定的方式来认证用户。Authentication Context 就是用来描述不同的认证方式信息。

SAML Assertion（SAML 断言）

SAML Assertion（SAML 断言）包含有关用户或实体的身份信息和授权声明，这些信息和声明由身份提供者签名，以确保其完整性和真实性，并传递给服务提供者进行访问控制和授权决策。

Assertion 通常由断言签发者、主体（Subject）、关于该主体的一组声明（Statements）以及声明生效的条件（Conditions）四部分构成。

作为 SAML SSO 最关键的部分，如在调试过程中需要获取 SAML Assertion，可以通过 Chrome 的插件 SAML Chrome Panel：

完成安装后，在进行 APP 与 SAML 认证调试时，打开开发者模式，SAML extension 会出现在最后的 tab，可以获取到 SAML Assertion，如下图所示：

Protocols

消息协议，可以简单的理解为 SAML 报文格式，即两个不同系统之间在通过 SAML 协议进行交互时，请求和响应报文的具体规范。

SAML 2.0 规范中定义了六种协议，其中五种都是基于 SAML 断言的使用场景，最后一种是关于名称标识符（Name Identifier）的管理。这些协议包括：

断言查询和请求协议（Assertion Query and Request Protocol）
身份验证请求协议（Authentication Request Protocol）
票据解析协议（Artifact Resolution Protocol）
名称标识符管理协议（Name Identifier Management Protocol）
单点注销协议（Single Logout Protocol）
名称标识符映射协议（Name Identifier Mapping Protocol）

其中，SAML Authentication Request Protocol 是最常用的协议，也是实现 SSO 的核心协议。其他协议则是在特定场景下使用，例如单点注销协议可以让用户在退出一个应用时，同时退出其他所有相关联的应用。

Bindings

用于定义 SAML 消息报文如何通过底层传输协议进行传输，例如：支持通过哪些协议进行传输？通过这些协议进行传输时，应该将请求\响应报文放在协议的什么位置、哪些参数中？SAML 2.0 中，定义了六种 Bidings，其中最常用的四种如下：

HTTP Redirect Binding：定义了 SAML 协议消息如何通过 HTTP 302 跳转方式进行传输。
HTTP POST Binding：定义了 SAML 协议消息如何通过 base64 编码后，以 Form 表单方式进行传输。
HTTP Artifact Binding：定义了 SAML artifact 如何通过 HTTP 协议进行传输。
SAML URI Binding：定义了如何从 URI 中提取 SAML 断言。

Profiles

定义了具体的业务场景的交互流程和约束，通过将 Assertions、Protocols、Bindings 的有机组合，实现具体用例场景需求目标。SAML 2.0 中，定义 8 个场景，其中最常用的就是以下两个场景：

Web Browser SSO Profile：定义了业务系统之间如何利用 Web 浏览器，通过 HTTP Redirect Biding、HTTP POST Binding、HTTP Artifact Binding 三种方式，实现认证请求、SAML 响应和断言的发送与接收，最终实现单点登录。
Single Logout Profile：定义了业务系统之间如何利用 Web 浏览器，通过 HTTP Redirect Biding、HTTP POST Binding、HTTP Artifact Binding 三种方式，实现退出请求及响应的发送与接收，最终实现单点登出。

SAML 工作原理

SAML 工作原理如下（以 SP Initialize 为例）：

终端用户通过 Web 浏览器访问 SP（Service Provider，服务提供者）的应用程序，并尝试登录
SP 重定向 SAML 断言请求到浏览器
浏览器转发 SAML 断言请求到 IdP（Identity Provider，身份提供者），例如 Okta 和 Azure AD
IdP 验证用户的凭据
IdP 根据用户生成一个 SAML 断言，并将 SAML 断言返回给用户的浏览器
用户的浏览器将 SAML 断言转发送回 SP
如果用户通过身份验证，SP 将安全上下文发送到浏览器
浏览器向 SP 请求所需要的资源
SP 允许用户访问请求所需的应用程序和服务资源

因此 SAML 实现了单点登录，用户在首次访问一个应用程序或服务时，需要进行一次身份验证。身份验证成功后，该用户的身份信息将被传递到其他应用程序或服务中，以进行身份验证和授权操作，而无需再次输入用户名和密码。

相比于常见的认证方式，SAML 有以下好处：

单点登录：SAML 可以实现单点登录，使用户只需要进行一次身份验证就可以访问多个应用程序和服务，从而提高了用户体验。
跨组织互操作性：SAML 可以实现跨组织身份验证和授权，使不同的安全域之间可以进行互操作。
安全性：SAML 使用数字签名和加密技术来保护身份验证和授权数据，从而提高了安全性。
灵活性：SAML 可以根据需要配置不同的身份验证和授权机制，从而提高了灵活性。

SAML JIT（Just in time）Provisioning 及工作原理

SAML JIT（Just-In-Time）是一种 SAML 授权模式，用于实现即时授权（On-Demand Authorization）和减少用户管理的负担。在传统的 SAML 授权模式中，用户需要事先预先分配并授权对特定应用程序或服务的访问权限。而 JIT 模式则允许在用户实际尝试访问应用程序时，动态地为用户分配并授权访问权限。这样，用户只有在需要访问应用程序时，才会被授权访问，而不需要提前分配权限。这种方式能够极大地简化用户管理和降低安全风险。

Okta 介绍

Okta 是一家提供安全身份验证和访问管理服务的 SaaS 服务厂商。它提供了一套完整的身份和访问管理平台，帮助组织安全地管理用户身份和访问权限。以下是 Okta 的一些主要功能：

单点登录（SSO）： Okta 可以让用户通过一次身份验证获得访问多个应用程序的权限。这大大减少了用户需要记住多个用户名和密码的麻烦，同时也提高了应用程序的安全性，因为用户不需要在每个应用程序中输入自己的凭据。

多因素身份验证（MFA）： Okta 提供多种多因素身份验证方法，例如短信验证、电话验证、Token 验证和生物识别等，这些方法可以加强用户的身份验证，提高应用程序的安全性。

用户管理：Okta 提供了一套强大的用户管理工具，包括用户创建、用户角色和组织架构管理等功能。这些功能可以让组织更好地管理用户身份，授权和访问权限。

应用程序集成：Okta 可以帮助组织将他们的应用程序与 Okta 集成，使得用户可以通过 Okta 访问这些应用程序。Okta 支持几乎所有主流的 SaaS 应用程序，包括 Office 365、Salesforce、Workday、Box、Slack 等。

API 集成：Okta提供了一套 API，可以让开发者将 Okta 集成到他们的应用程序中，从而实现自定义的身份验证和授权流程。

Azure Active Directory 介绍

Azure Active Directory（Azure AD）是微软的云身份认证和授权服务。它是 Azure 云计算平台的一部分，用于管理和控制云应用程序和服务的访问权限。Azure AD 提供身份验证和授权服务，使用户可以在任何设备上使用单一身份验证，安全地访问云应用程序和其他相关资源。

Azure AD 支持多种身份验证方法，包括用户名和密码、多重身份验证（MFA）、单一登录（SSO）、智能卡、生物识别和其他身份验证方法。用户可以使用 Azure AD 与许多 SaaS 应用程序和其他 Microsoft 服务进行身份验证和授权。Azure AD 还支持联合身份验证，可以与其他身份提供程序（如 Active Directory）集成，从而实现混合环境中的统一身份验证。

本文解决方案简介及流程图

Account Federation 是 Okta App Integration Catalog 中的一个 Application，将 Okta 与 Amazon IAM 服务通过 SAML 集成，最终用户可以使用他们的 Okta 凭证 assume 为他们所被分配到的 Amazon IAM Role，进行单点登录并访问 Amazon console 进行资源操作。

操作步骤为（需要亚马逊云科技和 Okta 管理员权限）：

在 Amazon IAM 服务中添加 Okta 为 Identity provider
配置需要分配的 IAM role 与 Okta 建立 trust relationship
通过创建一个 IAM user 如 OktaSSOuser 通过 API 实现 Okta 与 IAM role 的同步
在 Okta 配置 Account Federation app 并 assign 给所需要的 Okta people 或 group

配置完成后，用户登录到 Okta 的 end user dashboard 中可以看到此 app，当用户点击 app 会跳转到亚马逊云科技 management console，查看所分配到的一个或多个 Amazon IAM role，选择所需的 role，该 role 所 attach 的 IAM policy 定义了他们的权限，从而限制了他们可操作的资源范围，实现了 Okta 和亚马逊云科技管理控制台的单点登录集成。

另外，通过 SAML 集成，Azure AD 作为 IdP，Okta 作为 SP。Azure AD 将用户身份验证信息作为 SAML 断言发送到 Okta SP。Okta SP 使用此信息对用户进行身份验证，并将用户登录到应用程序，实现使用 Azure AD 用户身份登录应用程序的效果。

流程如下图所示：

配置步骤

Okta Account Federation SAML Integration

搜索并创建 Account Federation APP

可以通过 View Setup instruction 进行 SAML 2.0 step by step 配置。

访问 Metadata details 网站获取 APP SAML Metadata 并下载为 .XML 文档保存

配置 Okta 为 IAM Identity Provider

选择 SAML，并且选择 metadata 文件上传：

将 Okta 身份提供程序添加为 Amazon IAM role 的可信来源

如果是已有用户，为其添加以下 IAM trust relationship policy：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "<COPY & PASTE SAML ARN VALUE HERE>"
      },
      "Action": "sts:AssumeRoleWithSAML",
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.amazonaws.cn/saml"
        }
      }
    }
  ]
}

如果是为新角色授予 SSO 访问权限：

转到 Roles > Create Role。
使用 SAML 2.0 federation 作为可信实体类型。
选择 Okta （您的身份提供程序的名称）作为 SAML 提供程序和 Allow programmatic and Management Console access，然后继续到 Permissions。
选择要分配给您正在创建的角色的其他策略以访问所需要的亚马逊云科技资源。
完成角色配置。

生成 API 访问的用户密钥以供 Okta 同步 IAM role

现需要创建一个拥有特定权限的 IAM user，以便 Okta 可以动态获取帐户中可用角色的列表。

例如名为 OktaSSOuser，Policy 如下：

{
    "Version": "2012-10-17",
    "Statement": [
        {
          "Effect": "Allow",
          "Action": [
              "iam:ListRoles",
              "iam:ListAccountAliases"
          ],
          "Resource": "*"
        }
    ]
}