单点登陆sso原理

http://patann.blog.163.com/blog/static/46849990201032511331328/

在结构设计上复用性是一个很重要的特征，昨天半夜我发的系统地非侵入性也是很重要的，有同志邀我看看他的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也彻底没有做用了。