基于代理的SSO设计

1 概念
SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统的一种机制。


2 开源的josso,cas.

开源的josso,cas的设计实现是差不多的。都是一个认证中心加数个sso代理的方式。
主要看了josso,由于有一些限制，最后没有采用。
如java web的认证方式有限制，用户统一管理。


必须承认,安全问题是复杂的,sso作为一个跨多个系统的安全方案,也不会简单到哪里去.

用户，角色，认证，授权，sso,这些个东西在一起本身没有一个通用的模型，所以只能具体问题具体分析，
借鉴一些开源的思想，做一些可以满足当前需求的简单sso。


3 设计SSO中需要注意的东西

3.1 sso是否要解决授权问题？
一般sso的出现是当要集成多个老系统，或者集成老系统和新系统，一般来说，各个系统的授权是不一样的，很难用统一的方式来管理。
所以，sso一般都是只关心用户认证这一块.

3.2 多个系统是使用同一套用户schema，还是保留各自的用户schema。
同一套用户schema的好处是比较方便管理，但是前提条件是多个系统的用户schema基本相同,而且基于这个schema以前的授权系统还可以用.
保留各自的用户schema,则各个系统的独立性更强,各个系统的授权系统基本不需要改动.不足之处是认证中心需要维护一个user mapping.

3.3 是否跨域
是否跨域会影响sso的实现.主要是一些技术上的选择.比如cookie的使用与否.

3.4 是否有强侵入性
一般的sso产品都会说自己基本没有侵入性,这个是建立在很多假设上的.
一般的security是一个系统的一个横向切面的一个关注点问题,即使为了sso,在sso agent和原系统的security上面改动一些代码也是可以接受的.

3.5 sso agent如何获得已认证用户信息
可以选择多种技术手段来得到已认证用户信息,如编码过的用户信息放入cookie,通过session id在做一次查询,证书等等.

3.6 是否保留原系统的security.

3.7 一个系统登录是否代表所有系统登录
视需求而定,若A,B,C系统已经实现了SSO,则是否认为一个用户登入A系统的同时也登入了B,C系统.

3.8 数据传输的选择
可以用url para,xml rpc, ws等等.


4 基于代理的sso的工作过程

一台认证服务器（假定为CAServer），有两个应用A、B，分别部署在不同的服务器上, A,B上部署有SSO Agent.

1> 用户访问A，A应用无法找到用户的身份信息，使用redirect方法将用户引导至http://CAServer/login?backurl=http://A/path
   其中backurl是完成认证返回的url.

2> CAServer 显示登录界面，用户输入登录信息，CAS server进行认证。

根据sso设计实现的具体情况作必要的操作,
如实际登入各个子系统并把各个系统的session id放在cookie里(实际的登入调用各个子系统完成).
如果保留各自用户的schema,则进行user mapping得到A的用户.
生成可以标示该CA session的session id.
生成统一用户的加密信息.

返回http://A/path的同时返回可以标示该登录成功的信息.(Cookie,http para,token,cert,session id).

3> A上的SSO agent可以通过这个信息得到该用户(解密,请求CA Server,解析para,cert,load自己的session id).

SSO agent的部分运行完成,转入A的授权部分或者实际业务.

4> 用户访问B。
有两种情况.
一种是从CA login的信息中可以直接解析出用户,另一种则需要和CA server交互,redirect至http://CAServer/login?backurl=http://B/path
注意这里和1>中的跳转是有区别的,1>中的跳转除了backurl没有其他信息传递给CA server, 而此时的redirect则会传递标示登录成功的信息给
CA server,通过cookie,或者http para.

5> CA server接受B的redirect
同时,根据sso的具体情况可以做如下操作.

验证该token,cert是否有效.
进行user mapping,得到B的用户.
实际登入B.

返回http://B/path的同时返回可以标示该登录成功的信息.(Cookie,http para,token,cert,session id).

6> B上的SSO agent可以通过这个信息得到该用户(解密,请求CA Server,解析para,cert,load自己的session id).

SSO agent的部分运行完成,转入B的授权部分或者实际业务.

不知道您有没有听说过SAML2这个规范，这个是单点登录的一个规范。

我们现在做的单点登录系统就是应用SAML2规范封装用户信息的。

以前用.net的wcf作A&A时用过，不过没有作sso。
用saml作sso应该也是可以的，但是同时，这个的架构就要复杂多了。我的这个简单的sso，把认证和user mapping集中了。
你用saml的话，认证和跨安全域的security token转换就比较分散了。
你们计划怎么做。

我们现在用的SSO就是这样的，而且用的就是SAML2.没感觉比这个架构复杂多少。

SSO系统内一般都有Identity Provider概念（类似楼主的CAS）和Service Provider（A,B应用），不就是楼主的概念么

en，概念是相似的。
我这个简单是指Identity Provider只有一个。很多环节可以根据需求做适当的剪裁。
而SAML2作复杂的话，可以各个系统有自己的security token serivce server,颁发自己的security token,然后做跨安全域再认证，这样就比较复杂了。当然，也可以只有一个security token serivce server,向各个系统统一颁发。