基于Kerberos协议集成Active Directory的初步方案

基于Kerberos协议集成Active Directory的初步方案

一、背景

从结构化的系统构建思路上来考虑，应用系统的很多基础的非核心业务功能可以抽离成独立的公用的功能模块或子系统来支撑多个核心主业务系统。比如电信运营支撑系统中通常有大量的业务子系统，如订单、客户、计费、资源等等，其中每一个系统都会面临一些共同的非业务功能需求，如安全控制、权限管理、用户认证等。在各项资源条件具备的情况下，这些功能需求都可以通过各自构建独立的子系统来支撑。如此横向拆分系统，一方面可以使各系统更关注于自身领域，另一方面也使得管控维护变得更加容易。所以现在有越来越多的统一XX——统一认证、统一权限、统一支付、统一接口......

其实正是由于一直坚持这种系统构建思路，才使得我们能渐渐沉淀出越来越多的产品。也正是得益于这种思路，这次碰到的Active Directory集成工作才能相对简单的实现。

Active Directory接管的是认证，并希望达到在成功认证AD之后，即能进入业务系统而不需要再次登录。也就是希望能将现有的认证系统切换成AD，并且业务系统能够认可AD的认证结果。如果各个业务系统都要做一次跟AD的集成，那对现有业务系统冲击太大，而且工作量也是相当巨大的。所以，可以将AD集成的工作完全安排在统一认证中心上（SSO Server）。SSO原本只是作为解决业务系统间嵌套页面的问题而存在，同时负责认证和会话管理，如今只是将认证转变成了与AD之间的认证通信。

二、实现方案

整体流程:

1. 用户登录AD域之后，第一次访问某业务系统时，该系统识别到与该用户之间没有会话，即将该用户请求转发给SSO Server。（用户在没有登录AD域并访问业务系统的情况下，系统弹出域登录框，提示用户登录）。
2. SSO Server基于Kerberos协议与AD沟通，获取当前用户的所在域的域名及登录名。
3. SSO Server根据获取到的域名及登录名，向用户管理系统请求查询得到用户在业务系统的账号数据。
4. SSO Server根据上一步查询到的账号数据为当前用户创建SSO会话,并将SSO票据写入Cookie，然后跳转回用户初次访问的业务系统页面。
5. 业务系统根据从Cookie中取到的票据，向SSO Server发起会话查询接口，根据得到的操作员数据，作模拟登录，创建会话。
6. 用户可以打开业务系统页面，访问其有权限访问的页面。

其实，从上面流程中也可以看出，与AD集成只有两个事情需要考虑： * AD域账号与业务系统账号的绑定关系维护。 * 用户访问到系统时，系统如何能识别到有效的AD域账号。

第一点可以通过账号维护管理来实现，这里记录基于Kerberos协议获取当前登录的有效AD域账号的过程。(关于Kerberos协议的介绍可以看这里)。

Kerberos认证:

如下图示，AD中的Kerberos服务、SSO Server和用户的IE浏览器构成了Kerberos协议中的三个角色。

1. 1-6步，IE客户端按照协议向AD发起认证并最终获得到Service Ticket。
2. 7-8步，SSO Server接收到IE客户端发起的请求报文中所包含的Service Ticket，并用预先与AD约定的密钥Decode出用户AD账号信息。
3. 9-10步，SSO Server根据获取到得AD账号信息，向人员管理系统查询得到其对应的业务系统账号数据，并为其创建SSO会话，实现业务系统账号的登录过程。
4. 11步，SSO Server将用户redirect到业务系统页面。

配置相关：

1. AD启动KDC服务，并通过setspn工具为SSO Server创建SPN。
2. SSO Server与AD服务器时间同步，以避免密钥时间戳失效。
3. 用户的IE浏览器需要设置启用“启用集成 Windows 认证(要求重新启动)”选项。

三、关键词

Active Directory Kerberos SPNEGO JAAS