在结构设计上复用性是一个很重要的特征，昨天半夜我发的系统地非侵入性也是很重要的，有同志邀我看看他的SSO系统，不过看后都我觉得不甚满意，如果要服用的话需要把分散的代码一点点抠出来，然后经过反复的修改调试后才能在新的系统中使用，那位老兄的SSO系统功能可能确实强大，而且还用了新技术，不过在复用性上我看还是没有摆脱集成上的痛苦，作过系统集成的同学们肯定对此深有感触。
昨天才批判了很多同学写东西语焉不详，结果回头就自己给了自己一耳巴子，上几篇关于SSO的描述都不够详细，于是这里在手把手系列里我们来一起看看如何设计一个高度可服用的SSO模块，这里我们假设所有的站点都使用.NET，因为成熟的SSO需要和采用各种不同技术的站点之间实现SSO，于是有JAVA,PHP,COM+,.NET多种形式的PSO模块。这里我们精力有限，所以先假设都用.NET，如果你会JAVA也可以自己用java来实现PSO。
一般来说单点认证都需要两端来完成，在认证中心端的我们称之为SSO，在网站端的模块我们称之为PSO。两个模块之间采用二次重定向技术来实现同步两端票据的方式来实现单点登陆
首先我们就来看看这两个模块式如何配合来完成单点认证的
第一个场景是用户首先访问认证中心登陆再去进入成员网站的情况：
首先是登陆后产生一个SSO的票据，这个票据是最重要的，因为它是决定用户是否登陆的关键。这个票据可以是Cookie,也可以是Session,我比较倾向于Cookie，因为现在有3DES加密，加密后篡改Cookie几乎成为不可能，所以无论是对于服务器负担来说还是安全性都是Cookie比较好，可能人认为万一不支持Cookie呢，不过我想Demo应该没问题吧，大不了我设计成两个都支持：}，
PS，为什么不用非对称加密？其实那个效率不高，3DES的安全性已经足够了，至少现在还没有人宣称能破解
在登陆后就可以通知用户你已经登陆了，现在你可以去访问成员站点了，这个时候用户点击了成员站点的URL，进去了，这个时候首先就需要接受PSO组件的盘查，你有没有PSO的票据呢？很显然是没有的，所以这个时候请求就被Redirect回了认证中心，认证中心检查用户已经有了SSO的票据了，认为用户已经登录了，就把用户的SSO票据附加在URL后边然后Redirect回成员站点，成员站点的PSO这个时候获取到了SSO票据，于是知道了用户已经在认证端登录了，于是就创建一个PSO票据，然后返回给用户他所请求的内容。所以我们来看看其实PSO的逻辑更加复杂一点。
SSO的逻辑：
PSO的逻辑：
这里我们可以看到其实两个模块的功能都不算复杂，这里存在几个现实的问题，第一个是加密问题，票据需要加密，传输的URL也需要加密。
还有一个就是上一次我上篇文章里说的，在SSO把票据通过URL发送给PSO的时候，如果我们能够截获这个URL，不管他加没有加密，在下一次我们直接用这个URL去访问站点的时候因为已经包含SSO票据了，所以PSO会认为已经登陆了而直接产生PSO票据然后就让用户进去了，这显然是一个漏洞。所以呢，我们需要在这里给这个URL加一点盐值（所谓盐值其实就是加点料），我们通过在URL里加入时间戳来让这个URL具备时间限制，这个样子URL具备失效期，过了这个时间即使截获到了这个URL也完全没有作用了。