目录简介十一、SAML集成原理11.1 为什么公有云使用SAML11.2 SAML认证流程十二、AWS集成12.1 AWS身份认证架构12.2 IAM与STS简介12.2.1 IAMIdentity and Access Management12.2.2 STSSecurity Token Service12.3 Keycloak配置12.3.1 创建SAML Client12.3.2 配置Role映射12.4 AWS配置Identity Provider12.4.1 创建Identity Provider12.4.2 创建IAM Role12.5 登录验证12.6 AWS多账号架构十三、阿里云集成13.1 阿里云身份认证架构13.2 阿里云配置Identity Provider13.3 创建RAM角色13.4 Keycloak配置13.4.1 创建SAML Client13.4.2 配置Role映射13.5 集成第二个阿里云账号13.6 登录验证十四、OCI集成14.1 OCI IAM架构简介14.2 OCI联邦认证流程14.3 创建OCI Identity Provider14.4 配置Default Identity Provider Policy14.5 配置OCI JITJust-In-Time14.6 配置OCI Group Mapping14.7 Keycloak配置14.8 OCI权限模型14.9 OCI多环境治理14.10 登录验证简介在开源身份认证与访问管理平台 - Keycloak二中我们演示了Jenkins、GitLab、Kibana、Grafana等DevOps平台与Keycloak的集成实现了统一身份认证与单点登录SSO。但在企业实际场景中除了内部平台之外还存在大量公有云控制台需要统一接入例如AWS Console阿里云控制台Oracle Cloud InfrastructureOCI因此本篇继续介绍Keycloak与公有云平台的集成方案重点演示SAML联邦认证AWS IAM Identity Federation阿里云RAM SSOOCI IAM Identity Provider多账号角色映射JITJust-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负责签发临时TokenIAM Role负责权限控制因此AWS联邦认证本质上是“临时授权模型”。这与传统“用户名密码登录”存在很大区别。12.2 IAM与STS简介在开始配置之前需要先理解 AWS 的身份体系。12.2.1 IAMIdentity and Access ManagementIAM是AWS的权限管理系统主要用于管理User、Group、Role、Policy等。在企业场景中AWS 更推荐使用IAM RoleFederation 而不是IAM UserPassword原因包括降低长期凭证泄漏风险集中身份管理更容易审计更适合多账号体系12.2.2 STSSecurity Token ServiceSTS是AWS的临时凭证服务也是AWS的底层核心服务。本示例中SAML登录后AWS会调用AssumeRoleWithSAML为用户生成AccessKeySecretKeySessionToken这些凭证通常只有几小时的有效期。因此即使凭证泄漏风险也远低于长期IAM User。12.3 Keycloak配置12.3.1 创建SAML Client关键配置如下其中AWS相关的参数都是固定格式12.3.2 配置Role映射AWS要求返回IAM Role Arn,SAML Provider ArnAWS根据这个字段决定用户能切换哪些角色。我们直接在Keycloak的Groups中创建映射关系上面模拟的是dev组的成员可以切换118585065000这个AWS账号的ReadOnly和AIOps两个Roleinfra组的直接切换Admin这个Role。12.4 AWS配置Identity Provider12.4.1 创建Identity Provider访问https://keycloak.tools.devops.com/realms/tools-devops/protocol/saml/descriptor 把元数据保存keycloak-saml-metadata.xml。登录AWS的root账号创建资源创建完成后AWS会生成SAML Provider Arnarn:aws:iam::118585065000:saml-provider/keycloak是AWS的标准格式所以在Keycloak的Role映射中我们已经提前填好了。12.4.2 创建IAM Role添加提前规划的权限例如Admin Role挂载AdministratorAccessReadOnly挂载一些只读权限也可以提前创建自定义的策略在这里选择挂载信任策略需要配置正确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 Role13.2 阿里云配置Identity Provider进入阿里云控制台,创建身份提供商上传元数据同样使用Keycloak之前保存的keycloak-saml-metadata.xml文件。阿里云会生成对应的IdP ARN例如acs:ram::1055646107708198:saml-provider/keycloak13.3 创建RAM角色类似AWS我们创建两个RoleAdmin和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/keycloak13.5 集成第二个阿里云账号我们再找一个测试的阿里云账号重复上面的步骤。13.6 登录验证通过Keycloak Account Console点击跳转或者直接访问https://keycloak.tools.devops.com/realms/tools-devops/protocol/saml/clients/aliyunzhangsan登陆后可选择不同环境账号的Admin角色lisi登录后可选择不同环境账号的ReadOnly角色点击登录以所选择的Role的身份进入阿里云控制台十四、OCI集成相比AWS与阿里云而言OCIOracle Cloud Infrastructure的身份体系存在明显不同。AWS/阿里云更偏向临时凭证 Role Assume而OCI更偏向Federated User Policy模式。虽然OCI同样支持SAML、Federation、Identity Provider等但其底层权限逻辑与AWS并不完全一致。本章节主要演示Keycloak与OCI SAML集成OCI Federation配置OCI JITJust-In-TimeOCI Policy权限模型OCI与AWS身份体系差异14.1 OCI IAM架构简介OCI的权限体系主要包含组件说明TenancyOCI租户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 更接近企业用户映射模型。14.3 创建OCI Identity Provider进入OCI控制台,创建资源这里同样上传Keycloak的keycloak-saml-metadata.xml文件。并导出OCI一侧的SAML元数据OCI这里的Provider ID不是统一固定值参数较多稍后直接在Keycloak导入即可14.4 配置Default Identity Provider Policy增加Console支持的登录方式14.5 配置OCI JITJust-In-TimeOCI支持Just-In-Time Provisioning即用户首次登录时OCI自动创建对应用户。这样企业无需提前批量创建OCI用户最大程度的降低维护成本弥补架构差异带来的不足。14.6 配置OCI Group MappingOCI支持Group Mapping即Keycloak中的Group可映射至OCI IAM Group首先在JIT中启用映射功能我们采用如上的选项所以根据规划预设Groups然后对两个OCI组进行授权这样OCI Policy即可直接基于Group生效。14.7 Keycloak配置导入OCI侧导出的元数据XML文件确认并配置相关参数14.8 OCI权限模型由上面的配置步骤可以发现OCI权限核心并不是Role Assume而是重度依赖Policy。OCI Policy具有如下特点可读性高语义化强权限边界清晰但相比AWS IAM灵活度会略低一些。14.9 OCI多环境治理OCI通常不会像AWS一样大量创建Account而是一个Tenancy 多Compartment。不同区间之间资源隔离权限隔离配额隔离因此OCI企业治理重点更多在Compartment设计。14.10 登录验证首次登录已经自动在OCI中创建了用户并要求绑定2FA我们以Root身份查看OCI中用户信息发现已经创建了实体用户