先说几句废话，自我感觉此方案还不错，至少解决了安全性的问题，也实现了统一登出，能跨平台，跨服务期，跨域名，当然需要相应的联盟站点的支持，但从原理上绝对能跨平台。设计和具体实现的描述比较长，今天先介绍一部分

1引言

1.1 编写目的

详细说明单点登录组件(SSO)的设计思想和实现方法，是日后该组件维护和扩展工作的基本依据文档。预期读者是要实现单点登录(SSO)系统的系统设计人员，系统开发人员，系统维护人员。

1.2 背景

说明：

1. 待开发软件系统的名称；jillzhang的SSO组件
2. 本项目的任务提出者为jillzhang、开发者为jillzhang、用户为有用户整合需求平台的开发和设计人员。

1.3 定义

SSO是Single Sign On的缩写，该技术主要用于用户整合。
认证中心：认证中心是用户注册，成员站点管理，用户登录，验证登录信息，保存登录 信息，颁发登录认证的中心站点。 
成员站点: 成员站点是遵从认证中心规则，享用认证中心统一用户的站点。  
注册站点：如果想成为成员站点，必须先在认证中心进行站点登记，登记后，认证中心会保存注册站点的配置信息，并将该配置信息发给注册站点。注册站点也需保存这些配置信息，供日后与认证中心交互时候使用。  
联盟用户：指在认证中心注册的用户，这些用户能被所有的成员站点所共享。
登录请求：指成员站点向认证中心发出的带有站点配置的用户登录请求信息。
登出请求：只用户向认证中心发出的要求退出登录的请求。  
登录请求验证：指的是认证中心根据存储的站点信息对成员站点的登录请求信息进行来 源和真实性的验证。
登出请求验证：指认证中心在接受来自成员站点的登出请求的时候，对请求的来源和真实性进行的验证
登录答复：指认证中心对经过验证的登录请求作出的答复信息。该答复包含用户的登录信息。
在线联盟用户数：指的是在成员站点中，在线的联盟用户数量。  
在线联盟用户列表：指的是在成员站点中，在线的联盟用户的列表信息。 
登录站点清单：是由认证中心维护的用户的登录站点信息，当用户注销的时候，会遍历此清单，逐个登出。

1.4 参考资料

本组件的设计和实现参考了下面的系统和书籍

1. http://www.cnblogs.com/David-weihw/archive/2007/01/25/630621.html
2. 《数字签名技术原理及技术》
   
   

2 程序系统的结构

本组件包括下面几个应用接口，分别如下：

1. ISite：ISite是用于描述和操作成员站点的接口
2. IUser : IUser是用于描述和操作联盟用户的接口
3. IServer:IServer是认证中心处理登录请求和登出请求的接口
4. IClient: IClient是成员站点发出登录请求和处理登录答复的接口
5. IUserLoginList：IUserLoginList是描述和操作用户登录站点清单的接口
6. ILoginRequest：是记录和操作成员站点发送登录请求的接口。
7. ILoginRequestContainer：用于保存和维护登录请求列表的接口
8. IUserStateContainer：是联盟站点中保存用联盟用户登录信息的接口。

它们的定义如下：

组件的工作流程描述如下：

1. 第一步，首先注册联盟站点，注册联盟站点用到接口ISite
2. 第二步：注册好联盟站点之后，将认证中心产生的站点配置信息（包括站点编号，站点公钥，站点私钥，认证中心的登录地址，认证中心登出地址）存储到联盟站点本地。
3. 在认证中心上注册一新用户，注册用户需要使用IUser接口
4. 在联盟站点对认证中心发出登录请求
5. 认证中心验证登录请求
6. 在认证中心进行登录
7. 登录成功后，保存登录票据，认证中心对联盟站点发送登录答复，并将此次登录记录到登录站点清单
8. 联盟站点接收到登录答复后，先进性验证，正确后，根据登录答复中的信息产生用户登录票据，并且更新联盟用户登录数和登录列表
9. 在联盟站点中发出登出请求
10. 认证中心验证登出请求，正确的话，销毁认证中心用户登录票据，通过用户的登录站点清单，逐个调用联盟站点的登出页面
11. 在认证中心回调联盟站点的登出页的时候，联盟站点会在登出页中销毁各个的登录票据，并更新在线用户数和用户列表。

3 ISite接口设计说明 

3.1 接口描述

ISite接口包括7个属性和2个方法，分别用于在认证中心用于描述和操作站点的配置

信息。

其中，各个属性的含义如下

还包括两个方法，分别为：

3.2功能

该接口能在认证中心完成新联盟站点添加操作，添加之前可以验证站点是否存在。

3.3 默认实现

在SSO组件中，已经实现了一个默认的ISite对象。为DefaultServer/ DefaultSite.cs，它将放置在认证中心根目录下的sites.config文件作为存储介质，通过Add方法添加新联盟站点后的效果为：附件中的site.config文件，可自行下载文件后，看其结构。

4 IUser接口设计说明

4.1接口描述

IUser接口包括2个属性和2个方法，用于在认证中心端描和操作述联盟用户。

其中，各个属性的含义如下

还包括两个方法，分别为：

4.2功能

该接口能在认证中心完成新联用户添加操作，添加之前可以验证用户是否存在。

4.3 默认实现

在SSO组件中，已经实现了一个默认的IUser对象。为DefaultServer/ DefaultUser.cs，它将放置在认证中心根目录下的users.config文件作为存储介质，通过Register方法添加新联盟用户的效果为：附件中的users.config文件，可自行下载文件后，看其结构。

5 IUserLoginList接口设计说明

5.1接口描述

IUserLoginList接口包括3个方法，用于在认证中心描述和操作用户登录的站点清单。

还包括三个方法，分别为：

5.2功能

该接口在认证中心用于用户记录和维护用户登录的站点清单  

5.3 默认实现

在SSO组件中，已经实现了一个默认的IUserLoginList对象。为DefaultServer/ UserLoginLog.cs，它通过一个Collection对象来实现用户登录站点清单的维护工作。

6 IServer接口设计说明

6.1接口描述

IServer接口包括2个属性和5个方法，用于接收，验证登录请求，发送登录答复，接搜，验证登出请求，创建本地登录票据，维护用户登录清单。

两个属性为：

还包括三个方法，分别为：

6.2功能

该接口在认证中心，用于接收，验证登录请求，发送登录答复，接搜，验证登出请求，创建本地登录票据，维护用户登录清单

6.3 默认实现

在SSO组件中，已经实现了一个默认的IServer对象。为DefaultServer/ LoginRequest.cs。

7 ILoginRequest接口设计说明

7.1接口描述

ILoginRequest接口包括2个属性，用于记录和描述联盟站点的登录请求，这些信息在发出登录请求的时候创建，在收到登录答复的时候销毁。用于确保登录答复的不可复用性。

两个属性为：

7.2功能

该接口在联盟站点，用于记录和描述联盟站点的登录请求，这些信息在发出登录请求的时候创建，在收到登录答复的时候销毁。用于确保登录答复的不可复用性。7.3 默认实现

7.3 默认实现

在SSO组件中，已经实现了一个默认的ILoginRequest对象。为DefaultServer/ LoginRequest.cs。

8 ILoginRequestContainer接口设计说明

8.1接口描述

ILoginRequestContainer接口包括3个方法，用于在联盟站点中记录和维护登录请求

8.2功能

该接口在联盟站点，用于在联盟站点中记录和维护登录请求

8.3 默认实现

在SSO组件中，已经实现了一个默认的ILoginRequestContainer对象。为DefaultServer/ LoginRequestContainer.cs。

9 IUserStateContainer接口设计说明

9.1接口描述

IUserStateContainer接口包括5个方法，用于在联盟站点中记录和维护在线联盟用户信息

9.2功能

该接口在联盟站点，用于在联盟站点中记录和维护在线联盟用户信息

9.3 默认实现

在SSO组件中，已经实现了一个默认的IUserStateContainer对象。为DefaultServer/ UserState.cs。

10 IClient接口设计说明

10.1接口描述

IClient接口包括6个属性和2个方法，用于发出登录请求和登出请求

8个属性为：

2个方法为

10.2功能

该接口在联盟站点，用于发出登录请求和登出请求

10.3 默认实现

在SSO组件中，已经实现了一个默认的IClient对象。为DefaultServer/ DefaultClient.cs

11 本系统的安全性

11.1 登录请求的格式

联盟站点向认证中心发送的登录请求格式如下：

站点信息+登录请求编号+时间戳+空用户信息+对站点信息和登录清秋号的签名信息。
除了签名信息之外的全部信息均为明文传送，但因为重要的数据均经过数字签名，结果是站点信息和登录请求编号是不能被篡改的，保证了认证中心收到的登录请求的真实性。

11.2 登录答复的格式

认证中心发给联盟站点的登录答复格式如下

登录用户信息+登录请求编号+时间戳+对用户信息和登录请求号和时间戳的签名信息
其中登录用户信息是经过非对称加密的。请求号和时间戳因为经过签名，故也不能篡改，这样就可以保证联盟站点收到的登录答复的真实性和完整性。并且非正常联盟站点无法解密用户信息，也无法从中获取好处。  

篇幅太大，下面还有很长的内容要说，先发布以下，感兴趣的朋友可以先下载程序尝试使用。以后，我会逐渐添加Sql 和 Oracle的实现。您也可以根据接口规范，开发符合自己系统需求的SSO系统，今天先到这吧

程序文件：/Files/jillzhang/SSO.rar

更新：新增登录流程图：

[原创]单点登陆(SSO)组件的设计与实现二-登录流程图 

新增登出流程图 2008-02-02



上面是整体流程图，这个SSO组件在安全上有了很充分的考虑，可以说是非常安全，那么下面看看登录请求数据的格式，和为何它能保证真实性和完整性



这样，当数据在传输过程中，如果站点编号，用户编号，请求号任意一项做任何的修改，当认证中心接收到数据之后，均无法与签名信息进行匹配。凡是认证中心能验证通过的请求均为合法的，真实的，完整的请求信息。

登录答复的格式如下图所示

因为登录号，时间戳，用户信息均加入数字签名信息，所以这些数据在传输中不能被伪造和篡改，而用户信息经过非对称性加密，也防止非真正请求发送者能解析出用户信息，这样在接受和发送请求和响应的时候，就实现了绝对的安全。
当然不是没有破绽，破绽在于当请求答复未到达联盟站点之前，有人截获并先于正常用户登录了联盟站点，此时我们可以将用户的ip信息作为答复数据的一部分，加入签名，以此实现很高的安全保证

登出流程图

　　一直希望有一个电子化的工具能够方便、形象的整理头脑中漫无边际的杂乱想法，就像铅笔和白纸能够做到的那样，但是又能避免写满东西的白纸不易传播和保存的缺点。

　　最初通过一些介绍文章，看到了FreeMind，著名的开源free思维管理工具，优势是明显的，比如：

1. 跨平台。除了Windows之外，也提供了Mac OS X、Linux等版本，实际上，它支持所有的操作系统。
   
2. 免费使用。不需要任何破解和注册码之类，可以心安理得的不花钱永远使用它。
   
3. 功能比较强大，基本的思维导图应该具备的功能都有，也可以发布到web上。
   
4. 轻便小巧，但是可定制程度依然很好，当然这是针对那些动手能力较高的用户而言，对我这样不会写代码的人，这个方面的特性并不在考虑之列。

　　使用的时候需要先安装java的运行库，有点麻烦，而且关键是有一些操作方式，个人感觉不太顺手，导致思路频频被打断，被迫开始摸索使用的方法，这样对于一个普通的使用者来说，学习的时间成本便上升了，后来不得不尝试了商业软件－MindManager，这款软件并不开源，也不能跨平台，只支持Windows这一家系统，但是由于很好的迎合了windows软件的操作方式，大大降低了熟稔windows软件用户的学习成本，更和office系列软件做到了紧密整合，数据在其中流动非常顺畅。

　　第一个令我激动的MindManager应用就是Web2.0周刊的制作，我当时的需要就是每天用最简单的方法收集相关信息，包含链接、笔记或评论、分类等信息，在周末的时候统一整理一下，直接输出相应的html页面，可以上传到服务器上供访问，MindManager刚好可以近乎完美的实现，（这里可以看到实际效果）我只需要自己写一下css，用来保证最终的html页面以我想要的样式呈现，其它的html代码，就无需我操心，全部由MindManager代劳了。想尝试一下这个功能的话，可以在"File"--"Export"--"Save as Webpages..."中找到。

　　实际上无需什么教程，安装完MindManager之后，“help”和"Learning Center"都是非常棒的使用教程，而且后者还是直观的视频模式，快速浏览一下，就可以对MindManager这款软件有大致的了解了。

　　在“Learn More”中的“提示和技巧”使用了MindManager的格式来展示，很有意思，在这里可以学到“生成图片格式”、“格式编排”、“浏览导图”、“编辑技巧”等方面的知识。

　　MindManager6分为基础版和专业版，两个版本共有的一些新特性包括：

1. 大纲编辑模式。"view"--"outline"
   
2. 制表制图。"topic"--"Spreadsheet"
   
3. 组织结构图布局，可用来展示团队和公司的组织结构。"format"--"topic..."之后选择"Subtopics Layout"的标签，然后选择"Org-Chart"
   
4. 输出到powerpoint。"format"--之后选择"Microsoft PowerPoint Slides..."
   
5. 从IE导入。如果使用IE的话，可以通过点击工具栏的按钮添加某个网页的标题和链接到MindManager中自动生成一个topic。
   
6. 支持掌上电脑手写笔记及大纲。"topic"--"notes"以及"view"--"outline"
   
7. 分类线，可以把同类的topics用一条线划到一起，以示区别。
   
8. 自动编号。"Format"--"Numberling..."
   
9. 自动平衡,可以重新摆放topic的位置，使其看起来更协调。"view"--"balance map"
   
10. note中的拼写检查。"topic"--"notes"
    
11. 特别的粘贴。可以选择需要以何种格式粘贴剪贴板中的内容。"edit"--"paste special"

　　而只在MindManager6专业版中才有的特性如下：

1. 导出到visio。"format"--"Microsoft Visio Stencils...","File"--"export"--"Microsoft Visio Export"
   
2. 链接到excel表格。"insert"--"Microsoft Excel Range..."
   
3. 插入附件。"file"--"Add Attachment..."
   
4. 超强过滤器。"edit"--"filter"-"power filter"
   
5. 超强选择。"edit"--"select"--"power edit"
   
6. 自定义属性。"topic"--"Custom Properties..."
   
7. 加入书签。"topic"--"bookmark"
   
8. 评论模式，可以区分别人所作的评论，并方便的拒绝或者接受。"tools"--"start review"
   
9. 闹钟提示。"topic"--"alert..."
   
10. 文本记号。希望和你进行对话的使用者可以在你制作到导图上使用文本记号（text marker），标记出他们的意见。"topic"--"test marker"
    
11. 记时器。"tools"--"timer"
    
12. 标签。"topic"--"label..."

　　如果你主要使用Windows系统工作，而且office也始终在你的电脑中占有一席之地，最后，你也不在乎花一些美刀或者勇于想办法不花这些美刀，来得到一个真正强大、全能的思维导图工具的话，选择MindManager pro 6吧，应该不会后悔。

上面已经说明了全路径覆盖的含义（目前Cover工具无法达到的功能），那么全路径覆盖是不是很有必要且一定要的呢？答案是“YES”.做到全路径覆盖的测试是很痛苦的一件事情，但是，当你从全路径覆盖中找到重大问题时，才会回头来看“如果我做了全副该测试，这段路径的错误逻辑就不会出现的”。

就拿上篇"CheckedException VS UncheckedException"中的例子，当代码结构逐渐演化为多出入口调用C模块时，“C处不能决定具体的出错信息”。但是在代码中，如果恰恰就是在"C处误认为可以决定错误消息"时，对于这个“误操作”，就可以通过全路径覆盖发现这个问题。if(a==b||c==d||e==f) {throw new MyException("error msg.")}，这样的一行代码，需要面对三种问题去报出错信息，其负担太重，情况复杂（然后有了错误代码）。

如果做了全路径覆盖，可以走到（e==f）的判断，此时即可发现错误消息不正确的问题。

如何才能保证完成全路径覆盖呢？
1）手工debug跟踪，保证每一步都走到，对于最后的(e==f)，跟踪的好辛苦阿，创造这样的条件（走到e==f）就好累的。
2）利用Ncover的功能，对于这样的复杂逻辑，手工进行debug跟踪。
3)拆开代码，为三行（每个step为单独的一行），利用NCover自动分析。 哈，老师教过的"，不允许出现过于复杂的代码"这个原则被发挥到极致了。

你可以想象的出，一个库函数的异常信息不完整，对于他的用户来说，是多么不友好的事情。假设 MSDN 中 File.Open() 会抛出 IOException ，你的程序就很难想到很规矩的对 IOException 做了 catch ，然后提示用户检查相应位置的文件是否存在 / 被打开等。别指望 MSDN 的那些信息能够对终端用户有多大的帮助，太多不懂计算机的人在傻呆呆的握着鼠标了。再加上 MicroSoft 的提示信息本身就存在着“答非所问”，“莫名其妙”的事情，用户看到这些情况就更不知道怎么解决问题了。再加上自己的应用程序中会弹出一个个“蹩脚”的运行时错误的错误框，真的不是一个很如意的创作。

        但是，如果使用的是 Checked Exception ，这时候编译器会强迫你的外部接口的异常相当的完整，最起码可以做到比 MSDN 的异常类型齐整。

1.1 ． .NET Framework 1.1

   public StreamWriter(    string path  );

异常

1.2 JDK 1.4.2 :

public FileWriter(String fileName)  throws IOException

				Constructs a FileWriter object given a file name. 
		

Parameters:

fileName - String The system-dependent filename.

Throws:

IOException - if the named file exists but is a directory rather than a regular file, does not exist but cannot be created, or cannot be opened for any other reason

2 、解析

.NET 的 Excetpion 是 Unchecked 异常，客户端不要求去 Check 代码，但是 JAVA 的绝大部分 Checked 异常，它要求客户端的代码检测异常。

假设一个这样的场景，方法 OutMethod 调用 InnerMethod ，而内部方法 InnerMethod 抛出的异常 InnerException 。

对于 Java 的 CheckedException ，或者 OutMethod 去抛出 InnerException ，或者 OutMethod 捕捉 InnerException （然后做处理）。

再来观察一下 JDK 的 FileWriter 的异常声明，我没有详细测试其在各种可能出错情况下抛出的 IOException 的消息，但是其分类远远不如 .NET 的 StreamWriter 。假设 Java 想照抄 .NET 的 StreamWriter ，对于 Java 的使用者来说，无异于恶梦。外部的代码需要捕获如此多的异常消息（不捕捉就会在 OutMethod 抛出一大堆的异常，问题继续传播下去，这是 CheckException 的一个弱点）。也许正是出于这样的问题，所以此处 Java 接口的异常声明比较简单。

那么假设我是一个库设计者，正在用到了 IO 。如果我使用 .NET 进行开发，对于 IOException 来说，我是否有必要捕捉呢？捕捉的目的是为了“处理”，那么对于库设计者，显然这时候需要通知其“客户程序员”出错的原因，所以这里的库设计者的行为最好就是“不处理”。如果处理，那只能是“ catch 、再 throw ”。那么这样的处理显然是无意义的，因为原始异常已经足以提醒客户程序员出错的原因了。如果捕捉，那代码会特别的丑陋（直接 catch Exception 的行为是不可取的）。

CheckedException 的另外一个缺点就是“将 Exceotion 加入了 Interface 的规格声明“。假设 OutMethod 调用了 InnerMethod ，此时 InnerMethod 的设计者需要增加一个异常，那么会直接影响到 OutMethod 。当然这里的 InnerMethod 的设计者此时已经做了“修改接口声明“的行为。

   随后待续......