背景
GrowingIO 作为专业的数据运营解决方案提供商,我们的客户来自不同的行业,但他们都有相同的安全需求。在众多的客户中,许多客户都有自己的账号认证系统。因此我们需要能通过简单的配置接入客户的账号认证系统。目前 GrowingIO 一共支持了 CAS, OAuth2, LDAP 三种不同的接入协议。本文将详细介绍我们是如何支持这三个接入方式的。
不同接入协议的认证流程
OAuth2
一般来说,使用 OAuth2 来实现认证都是使用的授权码模式,我们这里也不例外,下面是 OAuth2 授权码模式的标准流程。
(A)用户访问客户端,后者将前者导向认证服务器。
(B)用户选择是否给予客户端授权。
(C)假设用户给予授权,认证服务器将用户导向客户端事先指定的"重定向URI"(redirection URI),同时附上一个授权码。
(D)客户端收到授权码,附上早先的"重定向 URI ",向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的,对用户不可见。
(E)认证服务器核对了授权码和重定向URI,确认无误后,向客户端发送访问令牌(access token)和更新令牌( refresh token)。
LDAP
LDAP 全称 Lightweight Directory Access Protocol,中文名称轻量目录访问协议。认证登录是其主要应用场景之一,下面是 LDAP 认证的流程。
CAS
CAS 是一个开源的 Java 服务器组件,给企业提供 Web 单点登录服务,CAS 服务器是构建在 Spring Framework 上的 Java 应用程序,其主要职责是通过颁发和验证票证来验证用户并授予对启用 CAS 的服务(通常称为 CAS 客户端)的访问权限。当服务器在成功登录后向用户发出票据授予票据 (TGT) 时,将创建 SSO 会话。服务票证 (ST) 根据用户的请求通过浏览器重定向使用 TGT 作为令牌颁发给服务。ST 随后在 CAS 服务器上通过反向通道通信进行验证。
整体架构
总体思路
整体上就是把这三种认证方式都集成到了 OAuth2 授权码模式的流程中,认证中心 IAM 系统在对接不同的认证协议时扮演了不同的角色。
-
对于账号密码