开源身份认证与访问管理平台 - Keycloak（三）公有云Console集成实践（AWS / 阿里云 / OCI）

简介

十一、SAML集成原理

[11.1 为什么公有云使用SAML](#11.1 为什么公有云使用SAML)

[11.2 SAML认证流程](#11.2 SAML认证流程)

十二、AWS集成

[12.1 AWS身份认证架构](#12.1 AWS身份认证架构)

[12.2 IAM与STS简介](#12.2 IAM与STS简介)

[12.2.1 IAM（Identity and Access Management）](#12.2.1 IAM（Identity and Access Management）)

[12.2.2 STS（Security Token Service）](#12.2.2 STS（Security Token Service）)

[12.3 Keycloak配置](#12.3 Keycloak配置)

[12.3.1 创建SAML Client](#12.3.1 创建SAML Client)

[12.3.2 配置Role映射](#12.3.2 配置Role映射)

[12.4 AWS配置Identity Provider](#12.4 AWS配置Identity Provider)

[12.4.1 创建Identity Provider](#12.4.1 创建Identity Provider)

[12.4.2 创建IAM Role](#12.4.2 创建IAM Role)

[12.5 登录验证](#12.5 登录验证)

[12.6 AWS多账号架构](#12.6 AWS多账号架构)

十三、阿里云集成

[13.1 阿里云身份认证架构](#13.1 阿里云身份认证架构)

[13.2 阿里云配置Identity Provider](#13.2 阿里云配置Identity Provider)

[13.3 创建RAM角色](#13.3 创建RAM角色)

[13.4 Keycloak配置](#13.4 Keycloak配置)

[13.4.1 创建SAML Client](#13.4.1 创建SAML Client)

[13.4.2 配置Role映射](#13.4.2 配置Role映射)

[13.5 集成第二个阿里云账号](#13.5 集成第二个阿里云账号)

[13.6 登录验证](#13.6 登录验证)

十四、OCI集成

[14.1 OCI IAM架构简介](#14.1 OCI IAM架构简介)

[14.2 OCI联邦认证流程](#14.2 OCI联邦认证流程)

[14.3 创建OCI Identity Provider](#14.3 创建OCI Identity Provider)

[14.4 配置Default Identity Provider Policy](#14.4 配置Default Identity Provider Policy)

[14.5 配置OCI JIT（Just-In-Time）](#14.5 配置OCI JIT（Just-In-Time）)

[14.6 配置OCI Group Mapping](#14.6 配置OCI Group Mapping)

[14.7 Keycloak配置](#14.7 Keycloak配置)

[14.8 OCI权限模型](#14.8 OCI权限模型)

[14.9 OCI多环境治理](#14.9 OCI多环境治理)

[14.10 登录验证](#14.10 登录验证)

简介

在开源身份认证与访问管理平台 - Keycloak（二）中，我们演示了Jenkins、GitLab、Kibana、Grafana等DevOps平台与Keycloak的集成，实现了统一身份认证与单点登录（SSO）。

但在企业实际场景中，除了内部平台之外，还存在大量公有云控制台需要统一接入，例如：

AWS Console
阿里云控制台
Oracle Cloud Infrastructure（OCI）

因此，本篇继续介绍Keycloak与公有云平台的集成方案，重点演示：

SAML联邦认证
AWS IAM Identity Federation
阿里云RAM SSO
OCI IAM Identity Provider
多账号角色映射
JIT（Just-In-Time）用户创建

同时也会对比AWS、阿里云、OCI在身份架构上的差异。

十一、SAML集成原理

11.1 为什么公有云使用SAML

虽然现代应用越来越多使用OIDC/OAuth2，但很多公有云控制台仍然以SAML作为企业联邦认证协议。主要原因：

SAML更早进入企业市场
与 AD/ADFS深度兼容
浏览器跳转式认证更适合控制台场景
公有云控制台本身并不是"现代 Web 应用"

11.2 SAML认证流程

与OIDC返回Access Token不同，SAML更核心的是Assertion（断言）机制。

十二、AWS集成

AWS是目前企业中最典型、也是最成熟的SAML联邦认证场景之一。AWS本身并不建议企业大规模直接创建IAM User，而是更推荐：

企业AD/LDAP
第三方身份源
SAML Federation
临时凭证（Temporary Credentials）

这也是现代云平台"身份与权限分离"的典型实现。本章节将演示：

Keycloak 与 AWS SAML 集成
AWS IAM Identity Provider 配置
AWS STS 临时凭证机制
IAM Role 映射
多账号角色切换

12.1 AWS身份认证架构

AWS控制台联邦登录，本质上依赖以下几个核心组件：

组件	作用
IAM	权限管理
STS	临时凭证服务
SAML	联邦认证协议
IAM Role	权限载体
Identity Provider	外部身份源

AWS并不会创建IAM User，也不会签发长期密码，而是：

Keycloak负责认证
AWS STS负责签发临时Token
IAM Role负责权限控制

因此：AWS联邦认证本质上是"临时授权模型"。这与传统"用户名密码登录"存在很大区别。

12.2 IAM与STS简介

在开始配置之前，需要先理解 AWS 的身份体系。

12.2.1 IAM（Identity and Access Management）

IAM是AWS的权限管理系统，主要用于管理：User、Group、Role、Policy等。

在企业场景中，AWS 更推荐使用：IAM Role+Federation ，而不是：IAM User+Password，原因包括：

降低长期凭证泄漏风险
集中身份管理
更容易审计
更适合多账号体系

12.2.2 STS（Security Token Service）

STS是AWS的临时凭证服务，也是AWS的底层核心服务。本示例中，SAML登录后AWS会调用：AssumeRoleWithSAML，为用户生成：

AccessKey
SecretKey
SessionToken

这些凭证通常只有几小时的有效期。因此，即使凭证泄漏，风险也远低于长期IAM User。

12.3 Keycloak配置

12.3.1 创建SAML Client

关键配置如下，其中AWS相关的参数都是固定格式：

12.3.2 配置Role映射

AWS要求返回：IAM Role Arn,SAML Provider Arn，AWS根据这个字段决定：用户能切换哪些角色。我们直接在Keycloak的Groups中创建映射关系：

上面模拟的是：dev组的成员可以切换118585065000这个AWS账号的ReadOnly和AIOps两个Role，infra组的直接切换Admin这个Role。

12.4 AWS配置Identity Provider

12.4.1 创建Identity Provider

访问https://keycloak.tools.devops.com/realms/tools-devops/protocol/saml/descriptor ，把元数据保存：keycloak-saml-metadata.xml。

登录AWS的root账号，创建资源：

创建完成后，AWS会生成SAML Provider Arn：arn:aws:iam::118585065000:saml-provider/keycloak，是AWS的标准格式，所以在Keycloak的Role映射中我们已经提前填好了。

12.4.2 创建IAM Role

添加提前规划的权限（例如Admin Role挂载AdministratorAccess，ReadOnly挂载一些只读权限；也可以提前创建自定义的策略，在这里选择挂载）

信任策略需要配置正确：

12.5 登录验证

通过Keycloak Account Console点击跳转，或者直接访问：https://keycloak.tools.devops.com/realms/tools-devops/protocol/saml/clients/aws

经过Keycloak登录验证后，AWS会读取Assertion中的Role Attribute并登录AWS Console或者展示角色选择页面。

我们以lisi为例：

点击登录，以所选择的Role的身份进入AWS控制台：

12.6 AWS多账号架构

企业中通常不会只使用一个AWS Account。而是通过AWS Organizations管理多个Account，例如下面展示，不同的Account管理不同的环境：

复制代码

Root
 ├── Security
 ├── SharedServices
 ├── Dev
 ├── Test
 └── Production

这样做的原因包括：

权限隔离
财务隔离
审计隔离
安全边界
配额独立

因此：用户真正登录时，实际上会选择：不同Account的Role。在阿里云集成章节中我们会看到企业常用的做法。

十三、阿里云集成

相比AWS而言，阿里云的身份体系整体思路非常接近。如果已经理解了AWS联邦认证，那么阿里云的SAML集成会非常容易。

13.1 阿里云身份认证架构

阿里云权限系统叫做：RAM，其功能与 AWS IAM 基本一致。阿里云同样不建议企业大规模创建RAM User，而更推荐Federation + RAM Role

13.2 阿里云配置Identity Provider

进入阿里云控制台,创建身份提供商：

复制代码

上传元数据同样使用Keycloak之前保存的keycloak-saml-metadata.xml文件。阿里云会生成对应的IdP ARN，例如：acs:ram::1055646107708198:saml-provider/keycloak

13.3 创建RAM角色

类似AWS，我们创建两个Role：Admin和ReadOnly，并设置信任策略如本示例：

两个Role分别添加提前规划的授权，如示例中：

13.4 Keycloak配置

13.4.1 创建SAML Client

配置方式与AWS类似，主要参数如下：

13.4.2 配置Role映射

阿里云同样要求Role Attribute,例如：

复制代码

acs:ram::1055646107708198:role/Admin,acs:ram::1055646107708198:saml-provider/keycloak

13.5 集成第二个阿里云账号

我们再找一个测试的阿里云账号重复上面的步骤。

13.6 登录验证

通过Keycloak Account Console点击跳转，或者直接访问：

https://keycloak.tools.devops.com/realms/tools-devops/protocol/saml/clients/aliyun

zhangsan登陆后，可选择不同环境账号的Admin角色：

lisi登录后，可选择不同环境账号的ReadOnly角色：

点击登录，以所选择的Role的身份进入阿里云控制台：

复制代码

十四、OCI集成

相比AWS与阿里云而言，OCI（Oracle Cloud Infrastructure）的身份体系存在明显不同。AWS/阿里云更偏向：临时凭证 + Role Assume，而OCI更偏向：Federated User + Policy模式。虽然OCI同样支持：SAML、Federation、Identity Provider等，但其底层权限逻辑与AWS并不完全一致。

本章节主要演示：

Keycloak与OCI SAML集成
OCI Federation配置
OCI JIT（Just-In-Time）
OCI Policy权限模型
OCI与AWS身份体系差异

14.1 OCI IAM架构简介

OCI的权限体系主要包含：

组件	说明
Tenancy	OCI租户
Compartment	区间/资源隔离
Group	用户组
Policy	权限策略
Federation	联邦认证
Identity Provider	外部身份源

OCI与AWS最大的区别之一是：OCI通常使用一个Tenancy管理多个环境，而不是：多个Account管理多个环境，OCI 企业治理通常围绕Compartment展开。

14.2 OCI联邦认证流程

OCI认证流程如下：

复制代码

User
  │
  ▼
OCI Console
  │
  │ Redirect
  ▼
Keycloak
  │
  │ LDAP/AD认证
  ▼
AD/LDAP
  │
  │ 返回SAML Assertion
  ▼
OCI IAM
  │
  │ JIT创建Federated User
  ▼
OCI Console

这里与AWS最大不同在于：OCI 通常会创建Federated User，而AWS通常不会真正创建用户实体。因此OCI 更接近：企业用户映射模型。