ad 用户必须修改密码 登录失败_【架构15】：业务支撑层之统一身份认证和单点登录...

统一身份认证和单点登录以及统一授权系统是三个独立且又紧密相连的系统，尤其是身份认证和单点登录容易混淆在一起使用。去除统一授权系统，统一身份认证和单点登录两个系统是必须存在的。

图1是一个典型的身份验证拓扑。主要包含了认证、授权、登录和业务四部分。

图1. 身份验证拓扑

认证

根据上文的描述，建议认证系统采用Microsoft Active Directory。它主要负责用户名和密码的校验，并负责基础属性的维护和提供，譬如用户名、部门和email。而其他扩展属性因为隐私安全关系，可以采用API方式提供。

另外，密码的管理也在Active Directory中进行维护，尤其是密码安全策略的实行，必须与前端的登录系统配合，在特定的场景下强迫用户修改密码。

请注意：Active Directory只是最常见的认证方式。除此之外还有很多种认证方式，譬如微信认证、QQ认证、OpenID、短信认证等认证方式。

授权

授权可以是一个显性的系统，也可以是一个由登录系统包含的隐性模块。

我们推荐的授权系统仅用于判断某个用户是否可以访问某个业务系统。我们并不建议统一授权深入到业务系统内部，这种方式导致授权系统和业务系统的耦合度太紧密。它可能适用于企业，但不一定适合高校。

在我们的架构中，这属于服务的访问策略，可以通过轻应用来管理哪些用户可以访问哪些业务，然后通过API返回结果，让登录系统反馈用户的访问权限。

单点登录

登录主要是指单点登录。作为一体化架构，唯一的单点登录系统是必须的。其功能主要是负责提供界面让用户输入身份信息(用户名、短信、生物特征等)，并与后端的认证系统交互核验，然后与后端的授权中心核验用户和业务的授权信息。也就是说单点登录起到了前端单一窗口的作用。

常见的单点登录开源系统有Apereo CAS，keycloak。

其他

在以前的文章中，我曾经写过这一部分，所以本文就不详细展开。但是有几点需要注意：

1. 职责要明确。单点登录系统就是为了登录，至于用户数据不准确的问题，则属于数据治理范畴。

2. OAuth认证有少许尴尬。懂信息化的朋友认为使用OAuth是应该的，不懂信息化的朋友认为是繁琐的，所以这里面有一个矛和盾的问题。

3. 业务系统需要认证登录，应该尽量使用单点登录系统，而不是直连LDAP(AD)。

4. 一个系统不一定具有所有的功能，这可以通过插件或者模块来弥补。

5. 所用协议一定要标准，勿自改协议。如果要自创协议，则需要提供对现有协议的支持。

总之，认清登录、授权、认证的本质，至关重要！

往期推荐

【架构14】：数据支撑层之Active Directory / LDAP

【架构】13:数据支撑层之一校一库

【架构】12：基础设施中的容灾(泛谈)

【架构】11：敏捷基础设施中的云桌面

【架构】10：基础设施的高可用 vs. 上层业务的高可用

【架构】09：数据支撑层之对象存储

【架构】08：容器中持久卷的备份

【架构】07：敏捷基础设施中的备份

【架构】06：敏捷基础设施中的容器化和Kubernetes集群

【架构】05：敏捷基础设施中的网络

【架构】04：敏捷基础设施中的Oracle数据库部署

【架构】03：敏捷基础设施的虚拟化之道

【架构】02：敏捷基础设施的硬件层

【架构】01：总体架构