1.1 传统独立系统带来的问题
1.2 统一认证和单点登录平台的优势
1.3 目的
1.4 术语
2.1 基于统一认证平台模式
2.2 基于共享密钥的协议登录
2.3 基于自配置的模拟登录
4.1 应用环境现状
4.3 系统分析
4.4 统一身份标示
4.5 身份映射管理
4.6 认证日志
5 Demo源代码及分享
1 概述
随着企业应用系统的迅速发展和完善，规模变得越来越大，用户如果要登录多个应用系统，不仅要面对多个登录界面，可能还要记忆不同的用户名和口令。每个应用系统都有各自的账号管理系统，互不信任。系统管理员不得不维护多个系统中的用户信息，数据的一致性很难保证。随着用户登录系统的增多，出错的可能性就会增加，受到非法截获和破坏的可能性也会增大，安全性就会降低。
为了满足企业不断增长的用户对不断增加的业务系统的访问需求，减少用户的账号管理工作，避免重复登陆，实现一个账号多个系统同时登录的统一单点登录迫在眉睫！
单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
1.1 传统独立系统带来的问题
每个单独的系统都会有自己的安全体系和身份认证系统。整合以前，进入每个系统都需要进行登录，这样的局面不仅给管理上带来了很大的困难，在安全方面也埋下了重大的隐患。下面是一些著名的调查公司显示的统计数据：
用户每天平均16分钟花在身份验证任务上 - 资料来源：IDS
频繁的IT用户平均有21个密码 - 资料来源：NTA Monitor Password Survey
49%的人写下了其密码，而67%的人很少改变它们
每79秒出现一起身份被窃事件 - 资料来源：National Small Business Travel Assoc
全球欺骗损失每年约12B - 资料来源：Comm Fraud Control Assoc
到2007年，身份管理市场将成倍增长至$4.5B - 资料来源：IDS
1.2 统一认证和单点登录平台的优势
l 简化用户的账号、密码管理，避免了多个业务系统和功能模块的重复登录。
l 安全性好，可支持多种安全认证手段，提高了各个业务系统的账号安全控制，降低安全风险。
l 提供良好的接口和规范，支持第三方系统的账号集成，为第三方系统提供登录认证服务。
l 为企业各业务系统的分布式部暑提供了统一身份认证服务支持。
l 请看下面的统计数据：
- 提高IT效率：对于每1000个受管用户，每用户可节省$70K；
- 帮助台呼叫减少至少1/3，对于10K员工的公司，每年可以节省每用户$75，或者合计$648K；
- 生产力提高：每个新员工可节省$1K，每个老员工可节省$350 - 资料来源：Giga；
- ROI回报：7.5到13个月 - 资料来源：Gartner ;
1.3 目的
l 建立一套完整的身份认证体系；
l 建立统一的身份认证中心；
l 建立统一的认证开发接口；
l 通过统一认证和单点登录提供一个统一的组织机构用户管理、权限授权、安全审计、系统管理等的平台；
1.4 术语
令牌（Token）
由认证中心颁发可在各分站中流通的用户唯一鉴权标识；
凭证（Certificate）
用户登录后产生的鉴权标识，用于识别授权用户；
认证中心（Certification Center）
提供统一的组织机构用户管理、权限授权、安全审计、系统管理等的平台等的中心平台
应用软件系统 Application software system
信息系统的重要组成部分，是指信息系统中对特定业务进行处理的软件系统；
2 单点登录的三种模式
2.1 基于统一认证平台模式
统一身份认证平台存储了全部的身份信息和对应的凭证信息，并提供了不同编程语言(Java，.net，PHP)的认证接口。业务系统完成身份信息同步和认证接口的部署之后，可以使用统一身份认证平台完成身份的认证，不需要自己存储凭证信息和实现认证。图1标识了业务系统完成认证的相应过程。具体如下：
①用户请求访问业务系统。
②业务系统在系统中查看是否有对应请求的有效令牌，若有，则读取对应的身份信息，允许其访问；若没有或令牌无效，则把用户重定向到统一身份认证平台，并携带业务系统地址，进入第③步。
③在统一身份认证平台提供的页面中，用户输入身份凭证信息，平台验证此身份凭证信息，若有效，则生成一个有效的令牌给用户，进入第④步；若无效，则继续进行认证，直到认证成功或退出为止。
④用户携带第③步获取的令牌，再次访问业务系统。
⑤业务系统获取用户携带的令牌，提交到认证平台进行有效性检查和身份信息获取。
⑥若令牌通过有效性检查，则认证平台会把令牌对应的用户身份信息返回给业务系统，业务系统把身份信息和有效令牌写入会话状态中，允许用户以此身份信息进行业务系统的各种操作；若令牌未通过有效性检查，则会再次重定向到认证平台，返回第③步。
通过统一身份认证平台获取的有效令牌，可以在各个业务系统之间实现应用漫游。
2.2 基于共享密钥的协议登录
基于共享密钥的协议登录机制是信息化建设中常用的一种协议认证集成模式，通过共享密钥和其他的信息组合加密完成系统间的认证，它需要在双方系统部署不同程序，但不需要修改原先的认证模块。图2给出采用协议登录机制形成的一般结构：各个业务系统的登录跳转程序都部署在一个入口系统中，而对应的验证程序则部署在各自的业务系统，跳转程序通过HTTP的get或post方法把双方约定的协议数据提交到业务系统的验证程序，验证程序负责验证数据的有效性，若通过验证则跳转到业务系统，否则拒绝使用。
此机制一般要求入口系统与业务系统端共同约定用户账号、时间戳、校验码、共享密钥四个参数，并且要求双方系统进行时间同步。入口系统通过跳转程序要求访问业务系统时，需要在url中加入username、time、verify三个参数值，并传递给业务系统。其中verify是由username、time和key组成并采用md5方式加密形成的一个串值。
业务系统获取各个参数后，比较业务系统服务器时间与接收的时间戳(time)是否在允许的时间差范围内，如果在允许的范围内，则需将接收到的username 、time及原先设定的key进行md5加密计算，获得的一个串值且同verify进行比较，若一致，则完成了本次的认证登录，并以username的身份访问系统，否则登录失败。
通过此机制可以实现单点到多点的单向应用漫游，也可以扩展双方认定的协议内容并进行功能的扩展，比如指定业务系统应用模块参数(module)来实现到具体应用模块的跳转。
1.1 基于自配置的模拟登录
基于自配置的模拟登录机制是针对那些基于Form表单方式登录的Web业务系统设计的，它不需要对业务系统的原有认证模块做任何修改。它利用用户自我配置的业务系统账号、密码等信息，模拟用户使用业务系统登录页面完成登录的过程，在后台直接提交相应的信息到业务系统的登录验证模块，从而完成用户登录的过程。图3描述了形成的主要体系结构。
首先在入口系统中建立一个入口系统账号到各个业务系统账号的映射表，此表一般需要包含以下信息：
1.入口系统账号：存储入口系统自身的账号。
2.业务系统ID：标志不同的业务系统。
3.业务系统账号：存储业务系统与入口系统账号对应的账号。
4 .业务系统基本角色：存储在业务系统中的角色信息。
5.业务系统密码：通过加密方式存储业务系统的密码信息。
其次，需要分析业务系统的登录页面和其对应的验证逻辑，并在入口系统中建立对应的自配置程序，包括业务账号密码配置页面、业务账号密码保存页面、业务账号密码修改页面等。
用户在使用入口系统首次登录业务系统时，需使用自配置程序把自己在业务系统中对应的账号、密码、角色存入入口系统的映射表中，之后就可直接通过入口系统完成到业务系统的应用跳转。
3 模式选型
每种机制都需要先进行一定的数据准备，再部署相应的程序，可以产生不同的应用漫游情况，所以它们适用不同系统的认证集成，具体分析如下表：
在信息化建设中，具体采用何种机制进行认证集成，需要具体情况具体分析，但是一般优先考虑基于认证平台的单点登录方式，之后是基于共享密钥的协议登录机制，最后才考虑基于自配置的模拟登录机制。
4 统一认证平台和单点登录
单点登录的核心技术要求在于如何通过活动主体来建立账号间的联系，使得认证机制相对用户输入透明。在比较广泛的适用场景中，存在着系统间异构、建设时间不同步、活动主体变更等关键问题。藉此，采取不同的模式来关照用户实际建设背景是统一认证和单点登录平台的基本思想。
4.1 应用环境现状
|
特征 |
说明 |
关键问题 |
|
独立用户 |
应用完全独立建设，各自聚合完整的身份账号模型及实现。 |
用户模型不对称及属性集差异化。 |
|
托管用户 |
用户及身份账号被第三方机构托管。 |
由于账号模型被第三方系统管理，其实质属于凝固的，从Server端解决并疏通账号关系存在不可操作性。 |
|
集成账号 |
使用AD、LDAP SERVER的标准化数据基础的用户模型。 |
如何建立集中认证和令牌颁布的接口平台。 |
现状反映趋势，单点登录平台从综合解决方向观察，设计上不是一个物理上的应用，而是一个集成应用、接口、工具集和相关套件的综合体。
4.2 需求分析
4.3 系统分析
认证中心是数据的总集成方，所有的用户和机构信息都是由统一认证中心托管，异构系统的用户和机构数据只需按照标准提供的接口来进行维护即可！
异构系统所使用的用户账号与认证中心的账号是一致的，所有系统的用户和机构数据都是在统一认证中心里进行维护的.
4.3.1 架构设计图
4.3.1 流程图
流程一：匿名用户访问认证中心统一登录页面
匿名用户访问认证中心统一登录页面，首先通过帐号、密码进行登录鉴权，验证通过后产生主站凭证，同时产生令牌，之后跳转到认证中心首页；
流程二：匿名用户访问某应用系统的授权页面
匿名用户访问分站a上的一个授权页面，首先跳转到主站通过帐号、密码进行登录鉴权，验证通过后产生主站凭证，同时产生令牌，跳转回分站a。此时分站a检测到用户已持有令牌，于是用令牌再次去主站获取用户凭证，获取成功后允许用户访问该授权页面。同时产生分站a的本地凭证。
当该用户需要再次验证时将使用本地凭证，以减少网络交互。
4.3.3 认证代理开发指南
4.3.3.1 实现模式
一个完整的 SSO代理需要完成以下职责：
【初次认证】
1、将认证指令桥接SSO以验证身份并获取令牌。
2、将令牌通过Session或者Cookies的模式进行缓存或持久化，备用于后期漫游。
3、通过令牌获取主站凭证；
4、初始化本地数据，产生本地凭证，进入系统视图的预处理工作。
5、打开并展现页面。
其时序图如下所示：
暂无(后续在源代码中加入)
【身份漫游】
1、应用A跳转到应用B时，根据令牌直接跳转；
2、通过令牌获取主站凭证；
3、初始化本地数据，产生应用B凭证，进入系统视图的预处理工作；
4、打开并展示页面；
4.4 统一身份标示
暂无(后续在源代码中加入);
4.5 身份映射管理
单点登录用户映射表（SSO_Users_Mapping）
|
中文含义 |
字段名称 |
字段类型 |
长度 |
主键 |
备注 |
|
映射用户标示 |
M_LOGIN_ID |
Varchar |
100 |
是 |
|
|
映射用户所在域 |
M_DOMAINID |
Varchar |
100 |
是 |
|
|
认证中心用户标示 |
C_IDENTITYID |
Varchar |
100 |
||
|
认证中心用户名称 |
C_IDENTITYNAME |
Varchar |
200 |
||
|
认证中心所在域 |
C_ DOMAINID |
Varchar |
100 |
||
|
排序号 |
M_ORDERNUMBER |
Int |
先写到这里了，后续推出系列二中将提供解决方案的Demo设计和源代码Demo，敬请期待！