下面就简述统一认证系统的应用子系统Session的共享的实现，我和一位同事根据大伙的讨论结果，分两种方式进行实现，详细情况如下：
第一种方式：通过MD5加密随机字符串，使用了Web服务实现了子系统和统一认证系统之间的交互验证。验证信息包含两部分用户在统一登录系统的Session ID和数据库中的随机ID。当子系统将用户重定向到统一登录系统的时候，验证的交互过程开始，详细步骤如下：
1、统一登录系统获取用户的Session ID和登录名
2、统一登录系统将Session ID和登录名插入到数据库，产生一个随机的数据库ID
3、将Session ID和数据库ID结合起来，进行MD5加密
4、使用MD5密文和数据库ID构建一个登录等待页面，返回给用户
5、用户将登录等待页面中的信息自动提交给子系统
6、子系统通过Web服务将MD5密文和数据库ID提交回统一登录系统
7、统一登录系统查询数据库，并进行验证
8、统一登录系统返回用户登录名，并删除数据库中的登录记录。
9、子系统与用户建立认证关系
图 3. MD5随机加密，Web服务实现验证
第二种方式：通过对认证信息（登录令牌）进行非对称加密，一次交互实现验证。验证信息为一个包含了产生时间的Token类。验证的交互过程同样是在重定向到统一登录系统的时候开始，详细步骤如下：
1、构建一个包含生成时间的Token类，将Token类序列化
2、使用SHA-1，对序列化Token编码进行散列，产生验证码H
3、将序列化Token编码和验证码H结合，使用公钥加密
4、使用密文构建一个登录等待页面，返回给用户
5、用户将登录等待页面中的信息自动提交给子系统
6、子系统使用私钥进行解密
7、子系统分离出散列验证码H和序列化Token编码，并进行SHA-1验证
8、检查Token中的生成时间，判断是否超时
9、子系统与用户建立认证关系
图 4. 非对称加密，一次交互实现验证
两种方式各有优缺点，大家很明显就能看出，我就不做总结。我们最终选择的方案是第一种，并且在验证过程中增加了一个Session识别子系统，防止非法的阻塞和冒充。即在应用子系统将用户重定向到统一认证系统系统时，子系统与用户建立Session，并在用户转交认证信息时，验证是否原本用户。防止有非法者获取了和用户转交的认证信息，并在用户之前提交给子系统，骗取认证。
