基于CAS 和OAuth 的统一认证授权系统设计
2021-06-24李强
李 强
(中电金信软件有限公司，浙江 杭州310000)
0 引言
银行的应用系统越来越多，每个系统单独管理各自的用户，容易形成信息孤岛，分散的用户管理模式阻碍了银行应用向平台化演进。当银行的业务发展到一定规模，构建统一的账户管理体系将是必不可少的，因为它是银行未来互联网云平台的重要基础设施，能够为平台带来统一的账号管理、身份认证和用户授权，为银行带来诸如跨系统单点登录、第三方授权等基础能力，为构建开放平台和业务生态提供必要的条件。
常见的账户管理产品有：CA 公司的SiteMinder，其价格昂贵；IBM 公司的 Tivoli Access Manager，其需购买且和 IBM 其他产品结合较紧密；Atlassian 公司的 Crowd，其需购买且和自家的 Jira、Confluence 结合较紧密；Oracle 公司的OpenAM，它是一个率先开源的认证授权产品，对Oracle 的产品支持较好；耶鲁太学发起的开源项目CAS(Central Authentication Service)，其简单、实效、安全，支持多种客户端，支持单点登录(Single Sign On，SSO)、开放授权(Open Authorization，OAuth)等。
考虑到费用、易用性、支持广泛度等因素，本设计选择了开源产品CAS。
1 CAS 和 OAuth 介 绍
CAS 包含服务端和客户端两部分，服务端是一个独立部署的WAR 包，负责用户认证。客户端负责处理对受保护资源的访问，支持 Java、.NET、PHP 等多种软件平台，极太地方便了各种系统的接入[1]。
CAS 支持 SSO， 即用户登录一个系统后， 再访问权限范围内的其他系统时不用再次登录[2-3]。 常见的如：用户登录淘宝网页后，再访问天猫网页时无需再次登录即可使用。
OAuth 是实现第三方授权的开放框架，在用户无需提供账号和密码的情况下，允许第三方应用访问用户存于某服务商的资源(如个人信息、照片等)[4]。常见的如： 在微信中点击某应用后， 会被请求授权，点击授权后，可以在这个被授权应用里看到自己的微信名称、头像等信息。 这就是被授权应用访问了自己在微信里的数据。
OAuth 框架定义了四种角色[5]，以微信授权为例：(1)资源所有者：指正在使用微信的用户；(2)资源服务器：指微信保存用户数据的服务器；(3)客户端：指在微信里请求用户授权的应用；(4)授权服务器：用户点击授权后会转到此服务器进行授权。
CAS 支持 OAuth，其结合 OAuth，可简化客户端的开发，提供标准的授权流程，支持 Web 应用、桌面应用、手机应用。 CAS 使用 HTTP 进行对接，支持各种软件的接入[6]。
2 系统总体设计
本文采用CAS+OAuth 的方案来实现银行内部和外部的统一认证授权，可以实现用户的单点登录，也可以为外部的第三方应用授权，从而使用外部的服务。
本设计的架构图如图 1 所示，描述如下：(1)用户访问 Web 应用、桌面应用或手机应用；(2)应用服务器将用户转到 CAS 服务器；(3)CAS 服务器是独立部署的，负责认证授权，它需要访问目录服务器(LDAP)或数据库；(4)用户在 CAS 服务器上完成认证授权后，CAS 服务器将发放 SSO 票据或 OAuth 令牌给用户；(5)用户的后续访问会自动携带票据或令牌来完成，避免了再次登录授权。
图1 架构图
3 系统详细设计
3.1 单点登录
TGT(Ticket Granting Ticket)，代表了用户的一次单点登录会话[7]。
ST(Service Ticket)，代表了 CAS 服务器对用户在某应用的一次授权[7]。
假设有两个被保护的银行内部应用：贷款系统和卡系统，下面描述了用户访问时是怎样保护资源的。
3.1.1 第一次访问贷款系统
用户第一次访问贷款系统时，被转到CAS 服务器去认证。 用户在 CAS 的登录页面输入账号和密码后登录成功。 CAS 服务器为用户创建一个SSO会话，并把 TGT、ST 返回给用户。 浏览器会把 TGT保存起来，并携带 ST 去访问贷款系统。 贷款系统转到CAS 服务器去验证ST，验证通过后，贷款系统为用户创建贷款系统会话。 浏览器保存贷款系统会话，后续访问都会携带这个会话，贷款系统验证会话通过后，向用户显示访问的资源。 时序图如图2所示[7]。
图2 第一次访问贷款系统的时序图
3.1.2 第二次访问贷款系统
用户第二次访问贷款系统时，因为已成功登录过， 所以浏览器会自动携带贷款系统会话去访问，贷款系统验证会话通过后，向用户显示访问的资源。时序图如图 3 所示[7]。
图3 第二次访问贷款系统的时序图
3.1.3 第一次访问卡系统
用户第一次访问卡系统，因为没有登录过，所以浏览器自动携带TGT 去CAS 做认证，认证通过后，CAS 服务器把 ST 返回给用户。 浏览器会携带 ST 去访问卡系统。 卡系统转到 CAS 服务器去验证 ST，验证通过后，卡系统为用户创建卡系统会话。 浏览器保存卡系统会话，后续访问都会携带这个会话，卡系统验证会话通过后，向用户显示访问的资源，整个流程不会要求用户再次登录。 时序图如图4 所示[7]。
3.2 第三方授权
OAuth 框架里的安全机制是令牌。 应用可以通过一个令牌在特定的时间段内访问特定的资源[8]。
假设有个银行外部的第三方交易系统，它需要用户在银行的授权系统里登录并对它授权后才能使用。
3.2.1 交易系统令牌访问
第三方交易系统首先向用户请求授权，用户登录银行的授权系统并进行授权后会发放授权许可，交易系统向CAS 服务器出示授权许可，并请求访问令牌。CAS 服务器校验授权许可通过后，发放访问令牌，交易系统凭令牌访问资源。 时序图如图5 所示[9]。
3.2.2 交易系统刷新令牌
令牌是有时效性的，当其失效后，第三方交易系统需凭刷新令牌再次请求一个新的访问令牌。 时序图如图 6 所示[9]。
图4 第一次访问卡系统的时序图
图5 第三方交易系统令牌访问的时序图
4 系统验证
4.1 单点登录
4.1.1 运行环境
为了完成单点登录的验证，规划了3 台服务器，如图 7 所示。 服务器全部预装 CentOS 7[10]，每台安装的软件如表 1 所示[11-15]。
图6 第三方交易系统刷新令牌的时序图
图7 单点登录验证服务器设计
表1 单点登录验证软件清单
4.1.2 验证
(1)浏览器访问 https://www.app1.com，因没有登录过，所以会跳转到图8 所示的登录页面，并且地址变为 https：//www.sso.com/cas/login?service=https-%3A%2F%2Fwww.app1.com%2F，从地址可知，这是由CAS 提供的登录页面。
(2)输入用户名和密码登录后，分析CAS 的日志可以看出它首先对用户名和密码进行了认证。
WHO：liqiang
WHAT：Supplied credentials：
[UsernamePasswordCredential(username=liqiang)]
ACTION：AUTHENTICATION_SUCCESS
图8 单点登录的登录页面
APPLICATION：CAS
(3)认证通过后，CAS 服务器自动创建了 Ticket Granting Ticket(TGT)。
WHO：liqiang
WHAT：
TGT-2-************************bo-47opiGacsso
ACTION：TICKET_GRANTING_TICKET_CREATED
APPLICATION：CAS
(4)紧接着 CAS 服务器又为 APP1 创建了 Service Ticket(ST)。
WHO：liqiang
WHAT：ST-3-BP9pvxb0-i-rwvrxQFQ8mn5py-wsso for
https://www.app1.com/
ACTION：SERVICE_TICKET_CREATED
APPLICATION：CAS
(5)CAS 服务器把 TGT 和 ST 返回给 APP1 服务器，APP1 服务器再次携带ST 到 CAS 服务器进行校验。
WHO：liqiang
WHAT：ST-3-BP9pvxb0-i-rwvrxQFQ8mn5py-wsso
for https://www.app1.com/
ACTION：SERVICE_TICKET_VALIDATED
APPLICATION：CAS
(6)ST 校 验 通 过 ，APP1 服务器显示APP1 的欢迎页面，如图 9 所示。
图9 单点登录成功转到APP1
(7)浏览器访问 https：//www.app2.com，因已登录过APP1，TGT 已经保存在浏览器缓存了，所以去CAS 认证时会携带 TGT，又因为该 TGT 是有效的，所以 CAS 会自动为 APP2 创建 ST。
WHO：liqiang
WHAT：ST-4--1a-tB2GwHoxrcZwLGlKQ-46ET0sso
for https://www.app2.com/
ACTION：SERVICE_TICKET_CREATED
APPLICATION：CAS
(8)CAS 服务器把 ST 返回给 APP2 服务器后，APP2 服务器再次携带 ST 到 CAS 服务器进行校验。
WHO：liqiang
WHAT：ST-4--1a-tB2GwHoxrcZwLGlKQ-46ET0sso
for https://www.app2.com/
ACTION：SERVICE_TICKET_VALIDATED
APPLICATION：CAS
(9)ST 校 验 通 过 ，APP2 服务器显示APP2 的欢迎页面，如 图 10 所 示 。 访 问 APP2 的整个过程并没有再要求用户登录。
图10 直接进入APP2
4.2 第三方授权
4.2.1 运行环境
为了完成第三方授权的验证， 规划了 2 台服务器，如 图 11 所 示。 服务器全部预装 CentOS 7[10]，每台安装的软件如表2 所示[11-15]。
图11 第三方授权验证服务器设计
表2 第三方授权验证软件清单
4.2.2 验证
(1)浏览器访问 https://www.app3.com，会显示图 12 所示页面。
图12 提示使用第三方账号登录
(2)点击下方的“使用第三方账号登录”链接，会跳转到如图13 所示的登录页面，并且地址栏变为https：//www.sso.com/cas/login?service=https%3A%2F%2Fwww.sso.com%2Fcas%2Foauth2.0%2Fcallback-Authorize%3Fclient_id%3Dots%26redirect_uri%3Dhttps-%253A%252F%252Fwww.app3.com%252Fauth%26response_type%3Dcode%26client_name%3DCasOAuthClient，从地址可知，这是由CAS 提供的登录页面，客户 ID是ots，代表了验证用的交易系统。
图13 转到第三方应用去登录
(3)输入用户名和密码，登录成功后会显示授权页面，如图 14 所示。
(4)点击 Allow 按钮，同意授权给第三方交易系统后， 分析日志可以看出 CAS 服务器给 APP3 服务器返回了一个授权码。
OC-1-NrqJTop-h7IYyOtxCmYGUS0mKFVGaII3
(5)APP3 服务器收到授权码后，携带授权码向CAS 服务器发出以下请求去获取访问令牌：
https://www.sso.com/cas/oauth2.0/accessToken?grant_type=authorization_code&client_id=ots&client_secret=12345-6&code=OC-1-NrqJTop-h7IYyOtxCmYGUS0mKFVGaII3-&redirect_uri=https://www.app3.com/auth
(6)CAS 服务器校验授权码通过，生成访问令牌，并把令牌返回给APP3 服务器。
access_token =AT -1 -AjYYAXSxR2M8EQuDqvHL3V -QwKN871hSN&expires_in=28800
(7)APP3 服务器得到访问令牌后，携带令牌去CAS 服务器获取用户信息。
https://www.sso.com/cas/oauth2.0/profile?access_token=AT-1-AjYYAXSxR2M8EQuDqvHL3VQwKN871hSN
(8)CAS 服务器校验令牌通过， 向 APP3 服务器返回用户信息。
{"service":"https://www.app3.com/auth","attributes":{"credentialType":"UsernamePasswordCredential"},"id":"liqiang","client_id":"ots"}
(9)APP3 服务器转到登录成功页面，并显示获取到的用户名，如图15 所示。
图15 获取授权成功转到第三方交易系统
5 结论
本文对 CAS 协议和OAuth 框架进行了简单介绍， 并基于此给出了统一认证授权系统的设计，随后结合实战对每一步进行了验证与分析。 以此为技术基础可以逐步整合银行内部现有应用系统的用户登录认证，规范新应用系统的开发，为银行带来跨系统单点登录、第三方授权等基础能力，为进一步构建开放平台和业务生态提供了必要的条件。 此外， 若能通过域账号与统一认证授权系统进行集成，将更加有助于简化用户的管理，进一步提高系统集成度和用户的使用体验。
