基于统一身份认证的销售管理平台的实现

白惊寰， 郑国英

(上海交通大学 软件学院, 上海 200030)

0 引言

本课题是基于一家专注于企业销售系统的公司研发的一个销售预测管理系统来展开分析的，身份认证是一个验证真实身份和所声称的身份是否一致的一个过程[1]。在身份认证服务里主要包含两个主要内容，第一是要验证认证消息来源的可靠性，第二是验证认证消息中所声称的身份的有效性。比如用户持有某个凭证或生物特征[2](如指纹)，我们通过验证其真实性和唯一性来确认用户身份。

如今大部分系统都包含多种身份的用户且访问的资源不单一，但往往所有用户的登陆地址是相同的。为了满足这种业务需求，我们通常使用单点登录技术[3,4](Single Sign-On)来实现。单点登陆系统在验证用户有效性的同时给用户进行授权，通过不同的算法策略来赋予每个用户资源访问的权限，对于不同权限可访问的资源往往还需要一个目录结构对资源进行分类。

身份认证中最严重安全问题之一即是口令的安全。根据口令生成器[5](Challenge-Response)使用挑响应的验证方式进行身份认证可以生成一个可以被唯一确认的用户特征。用户是否可以只通过一次口令的验证，当获得了相应的授权和凭证后，用户就能够自动完成之后所有身份认证过程？这种设计思想需要一些特定的协议的支持。比如单点登陆协议Kerberos[6-8]，这是一种目前比较流行的单点登录协议。

1 单点登陆技术研究和系统架构框架设计

在本节系统设计部分，根据一些成熟实现案例为理论基础主要讨论销售预测管理平台如何实现分布式部署[9,10]的架构设计。

1.1 消息的安全性和完整性

按信息系统安全CIA(Confidentiality-机密性，Integrity-完整性，Availability-可用性)准则，其中涉及到安全认证中信息的完整性[11]。消息认证的目的是确保消息的来源是可靠的，并保证消息没有被篡改过，此外如果在消息中加上了时间戳则可以保证消息的时效性没有问题。

消息认证一般有3种方式[12,13]，第一种是消息整体进行加密作为认证标示。消息的接受方可以根据消息的检错码来判断收到的消息是否完整。第二种是根据一个公开的函数加上密钥来产生一个固定的值通过这个值进行消息的验证。

MD5是目前比较流行的一种信息摘要算法，它可以将任意长度的输入消息转化为一个128位的大整数，并保证它是不可逆的。其算法流程如图1所示。

MD5以512位的分组来处理数据参数，然后再将分组划分为16个32位的自分组，当消息长度不够时需要填充信息补满512位。初始化数据的时候，我们需要用512位的摘要缓存器A、B、C、D作为参数的输入点，算法的核心是4个循环压缩的函数模块，每个处理模块由多个步骤完成。组合A、B、C、D四个缓存区的结果，最终得到了128位的信息摘要。

图1 MD5算法处理过程示意图

1.2 基于Kerberos的Web单点登录方案

传统的单点登录SSO对用户验证的方式是基于一个统一存放用户账号和密码的服务[14]。它无法满足当业务复杂的多服务系统身份信息存放服务不唯一时的验证需求。为了解决以上的问题，本文提出了一种基于票据ticket的新型单点登录技术的实现方案，用来解决多服务间用户登录时的身份验证、权限控制的问题[15]。

下面我们详细论述Kerberos安全协议的一些基本概念[16]。第一认证主体(Principal)，在整个Kerberos认证机制中认证主体可以是用户也可以是服务，或是各种主机和服务器，认证主体一般都包含一个用户名和密码。第二是密钥分发中心(KDC)这是Kerberos的核心[17]。这项技术得以实现的前提是，在整个通讯环境中我们必须都信任KDC。第三个概念即为票据(Ticket)，我们可以将票据理解为一种记录，这个票据中往往包含了用户的标示、会话密钥、票据的有效期等其他应用相关授权信息。这些信息通常都是加密的。第四认证记录， 认证记录是存于KDC的一些近期用户登录认证授权的日志记录。

2 基于单点登录的销售预测管理平台的实现

在集群的设计上我们将对这些模块分别部署为一个服务，通过前后端分离的设计模式采用无状态的请求进行模块之间的调度，最后实现分布式部署的目标。从技术选型、技术特点以及技术实现三方面对这个问题做详细的解释。

2.1 基于Kerberos的Web单点登录方案

身份认证服务的设计重点在于如何生产一个有效的信赖凭证并管理。客户浏览器在系统的某一个服务中成功登录，并完成了有效性验证后，其他系统都能够对该用户提供系统的信任，那么我们就可以说是完成了对身份认证服务实现的工作。

先从设计的用例图(图2)入手，对身份认证服务的需求进行深入挖掘，身份认证服务如图2所示。

如图2中身份认证所有服务的身份校验都需要通过身份验证服务进行处理。身份校验服务对应的是整个销售预测管理平台的服务提供了用户新增、用户更新、用户删除的功能接口。如图3所示。

图2 身份认证服务用例图

图3 身份认证系统-功能结构图

2.2 用户令牌的生成算法

身份令牌生成算法是基于jdk中提供的MessageDigest工具类来实现的。代码里我们用实例的digest方法实现。最终我们得到了一个16位的比特数组。基于这个16位的比特数组，我们遍历它并逐位计算它的绝对值，根据这个绝对值我们再计算出其对应的16进制数。显然很多时候这个数字的长度会不足两位，我们需要在得到的16进制数前面进行补0的操作。最后将得到的这些字符串相加，我们就可以将16位比特数组转化为一个32位的16进制字符串了。具体算法如下：

publicstatic String build(String account, String charset) {

MessageDigest digest = null;

StringBuilder buffer = new StringBuilder();

try {// 输入账号如果为空则返回空的身份令牌

if (account == null) {

returnnull;

}// 以MD5的算法来实例化digest

digest = MessageDigest.getInstance("MD5");

} catch (NoSuchAlgorithmException e) {

// 若实例化digest出错，则向控制台输出错误的信息

System.out.println("error msg ： " + e.getMessage());

returnnull; }

// 根据实例化的digest用md5算法生成一组byte数组

byte[] bytes = digest

.digest(account.getBytes(Charset.forName(charset)));

for (bytebs : bytes) {

// 为了保证在byte转int类型时 不丢失符号位

intc = bs& 0xFF;

if (c< 16) {

buffer.append("0");

}

buffer.append(Integer.toHexString(c));

}

returnbuffer.toString();

}

publicstaticvoid main(String[] args) {

String account = "ShanghaiJiaoTongUniversity";

String str = TokenBuilder.build(account, "UTF-8");

System.out.println(str);

}

}

输出结果： 52ed5a8f8fcc62dfcef21d8eb9b2d7a7;

考虑到身份令牌是有时效性的，当用户长时间不进行操作后，他的身份令牌会被销毁。那么当身份令牌被销毁后，如果用户再次访问身份认证服务器，我们需要给他生成一个新的身份令牌。如果我们只根据账号来计算，那么用户永远只会得到一个相同的令牌，因此我们考虑将账号结合当前服务器的时间戳组合到一起，以此字符串来生成最新的32位16进制的身份令牌。获取当前时间戳的算法如下:

publicstatic Timestamp getCurrentTimestamp() {

Date date = new Date();

Timestamp nousedate = new Timestamp(date.getTime());

returnnousedate;}

因为用户不可能在同一时间点里登录两次系统，所以我们可以保证用户账号加时间戳，结合MessageDigest工具类生成的用户令牌是能够满足系统要求的。

2.3 身份认证服务的MVC实现

本节将讨论如何实现身份认证服务的MVC设计。本服务将给予轻量级的springMVC、Spring、hibernate框架实现基于MVC架构的身份认证服务。MVC框架的核心是将系统分为视图层(view层)、业务逻辑层(controller层)和持久化层(model层)。身份认证服务技术架构图,如图4所示。

图4 身份认证服务技术架构图

SpringMVC框架用来实现MVC的分离，在业务逻辑层我们会大量使用spring提供的控制反转IoC机制，将数据库操作交给Spring管理、将服务实例化为javaBean，可以大幅度减少开发的耦合度，同时也将软件开发的可复用性大大提高。持久化层我们选择用hibernate来实现，将数据库的表和JavaBean关了起来，通过HQL语言操作数据库可以大大提高代码的可读性，同时可以避免sql注入攻击等数据库操纵安全的问题。

数据库的设计是系统的核心，接下来我们将详细介绍为身份认证服务提供的表结构。

身份认证服务E-R图，如图5所示。

图5 身份认证服务E-R图

图中表明了表t_authuser与表t_app、表t_ahthlogin_log、表t_token_log、表t_authseroperate_log彼此之间的依赖关系。

当用户访问一个业务系统时，业务系统会去进行业务系统的应用认证，如果应用认证通过则会进行用户信息的校验。用户信息校验完成后，身份认证服务会保存一份用户的token，同时返回一个用户token到用户的客户端。

3 性能测试与分析

本论文解决了销售预测管理系统的统一身份认证的实现方式，在本节中主要对以上的方案进行测试，以测试数据来验证方案的可行性。

3.1 身份认证测试用例

身份认证主要功能的测试场景，如表1、表2所示。

其中包括登录和登录成功后在Token有效期及失效期内用户访问的各种场景。目前测试已经完成，测试结果表明身份认证服务可以满足需求。

3.2 系统性能测试

系统的性能测试主要为压力测试。使用loadrunner测试工具，我们模拟了多个用户短时间里同时访问销售预测管理平台的情况，并通过测试工具计算出了几个关键数据：单个用户最短登录时间、单个用户最长登录时间、用户登录平均耗时。

表1 账号登录测试用例表

表2 Token有效期内系统访问测试用例表

当系统处于正常运行状态时，我们分别用三组数据进行了四次测试，可以看到当并发人数逐渐增加时，服务器响应的时间也会逐渐延长。如表3所示。

表3 用户并发登录耗时测试结果表

平均访问时间可以看到增加了负载均衡的系统在处理请求响应的耗时均有大幅度的提升，而且当并发人数越多登录优化的作用也就越显著。从测试数据我们可以得出结论，在同时访问人数阈值在300人的时候，平均登录时间在3秒以内，能够满足需求。

4 总结

随着企业分布式集群的不断扩大，目前的系统存在着很多需要改进的地方。首先需要考虑的问题是如何实现跨域的基于单点登录的身份认证服务。在这里分析一下跨域身份认证实现的难点。跨域的单点登录中用户和应用服务的双向认证如何实现？在单个域中通常是1对1的认证关系，即一个用户在一个系统中只保留一个用户的凭证。但如何是跨域的单点登录验证，由于每个域的服务中都需要保存一个用户凭证，那么用户和应用服务的验证关系将成为N对N的关系。如何简化这种负责的关系流程进一步要研究的重点方向。