从Amazon Connect全球云呼叫中心服务SSO构建流程

Amazon Connect 是 AWS 开发的全渠道云联络中心解决方案，能够提供 60 多个国家和地区的电话号码，所有基础设施都由 AWS 维护，能根据客户的使用量需求动态扩容，无需签约购买许可、按照使用量计费的方式，能够客户随时灵活调整坐席人数。

Amazon Connect实例可以设置基于 SAML 2.0 的身份验证，企业用户可以基于SAML 协议构建SSO模块，实现CRM与Connect的无缝权限对接。不同于直接通过Connect CCP（Contact Control Panel）登陆(图1)， SSO用户首先向IDP进行身份验证。IDP生成SAML断言（assertion），该断言将通过Browser发送给IDP信任的应用程序(SP)，SP读取用户attributes并将其映射到自己存储的用户attributes。在Connect中，SP限定的SSO认证attributes为用户登陆名(login)。联合认证通过后，前端跳转到CCP的中继链接，就可以访问Connect对应的服务（图2）。

图1 CCP登陆Amazon Connect

图2  SSO登陆Amazon Connect

图3: Amazon Connect 用户名attribute与AWS IAM RoleSessionName匹配，最终与IdP用户名attributes一致。

由于IDP认证通过后可以发送多个SAML assertion，因此用户可以单次登录多个应用程序(SP)。搭建SSO模块后，用户可以非常方便地集成其他应用模块，SSO也是亚马逊云科技的权限安全的最佳实践。

启动身份验证流的主要方式有2种：

1. IDP启动流程：用户首先访问IdP，然后提示用户进行身份验证， IDP使用agent生成SAML断言，该断言发送给单个或者多个SP，SP验证断言将其映射到本地用户，然后会话可以跳转到SP服务界面。这种方式多个SP模块可以同时预热，agent通过中继链接可以快速跳转多个SP服务页面。

图4: IDP启动流程

2. SP启动流程，用户访问SP，SP返回用户未验证，Agent随即请求IdP，IDP生成SAML断言,通过agent发送到SP，启动会话。这种方式无需用户主动登陆IdP，用户访问对应SP即可自动触发IdP验证流程。

图5: SP启动流程

在以下范例中我们展示第二种流程，使用Mujina作为IdP实现基于SAML Federation登陆Connect CCP的流程。Mujina是基于OpenSAML的联合认证(IdP & SP).开源mock解决方案（https://github.com/OpenConext/Mujina），优点是可以通过REST API动态增加与修改attribute, 基于其开箱即用，易于调试的特性被广泛使用在各类联合认证的测试场景中。在生产场景，我们建议使用托管服务AWS SSO以及亚马逊云科技的成熟合作伙伴解决方案。

首先，我们开启一台EC2，安装并启动IDP。这里我们使用amazon linux corretto11-java-11镜像，并安装mvn 版本3.8.4， amzn-lnx2-hvm-corretto11-java-11镜像是亚马逊官方托管的amazon linux 2系统环境下开放 Java 开发工具包 (OpenJDK) 的免费、多平台、生产就绪型分发版。Corretto 提供长期支持，其中包括性能增强和安全修复。Corretto 经认证与 Java SE 标准兼容，并在 Amazon 内部用于许多生产服务。之后按照需要对于mujina IdP模块进行修改:

1)在SAMLMessageHandler 按照https://docs.thinkwithwp.com/zh_cn/IAM/latest/UserGuide/id_roles_providers_create_saml_assertions.html配置SAML assertion，

2)生成IdP metadata xml文件，注意location应该为 EC2的publich ip， certificate更改为自有密钥，

3)对application.yml进行对应更改。最终运行：

mvn clean install
cd mujina-idp
mvn spring-boot:run

完成后，看到命令行返回：

表明IDP模块已经初始化。在实例的安全组inbound开放默认IDP 8080端口，浏览器输入http://<instance public ip>:8080可以看到登陆界面

图6: IdP登陆参考界面，version 8.0.0

在SP（AWS）和IdP之间建立信任关系，通过IAM赋予IdP联合授权用户对应权限。信任规则由.xml元数据文件确定。元数据文件格式如下图所示，其中：

entityID: IdP在SSO中的唯一标识。

Location：IdP服务器的public ip, Mujina默认IdP端口为8080。

图7:xml原数据格式范例

在IAM服务中，建立新的Identity providers，上传xml文件，IAM接受后，再Summary中显示Issuer URL, Valid until, Service location，确认信息正确无误后，进行IAM赋权。

图8: 建立新的Identity providers

然后新建对应角色，给予connect:GetFederationToken权限的policy,修改trust relationship给上一步的Identity providers。

图9: 新建对应角色

这时候，当我们再次登陆IdP,再打开AWS控制台，可以看到右上角用户名已经改为对应role_name@account_id。说明已经在SP（AWS）和IDP之间建立信任关系。

Log out 这个临时用户，在拥有AWS AmazonConnect_FullAccess或者adminAccess权限的用户下启动connect实例，选择SAML 2.0-based authentication。

图10: 启动connect实例

进入对应connect实例，在user management下新建相同Login的用户，或者通过csv批量上传与IdP用户列表一致的用户。

图11:新建Connect用户

参考https://docs.thinkwithwp.com/connect/latest/adminguide/configure-saml.html#destination-relay配置中继链接，前端页面跳转。当看到如下界面时，说明SSO成功。

图12: 中继链接跳转

开发者模式可以看到，用户访问中继链接（RelayState）后，跳转SAML通过SigV4进行AWS联合授权，最后跳转到ccp-v2外呼界面。

在这篇blog中，我们探讨企业级用户如何通过SSO进行联合认证登陆指定Connect实例CCP。同时，亚马逊有托管SSO服务与第三方SSO合作伙伴提供企业级SSO解决方案对接云呼叫中心Connect。如有需要，欢迎联系亚马逊云科技。

本篇作者