标签：
最近接触了一点单点登录的知识，有一点理解，记录一下。有些问题并没有找到完美的解决方法，还需要找点已有框架来看看。
欢迎留言探讨。
有一个网上广为流传的定义“SSO是一种统一认证和授权机制，指访问同一服务器不同应用中的受保护资源的同一用户，只需要登录一次，即通过一个应用中的安全验证后，再访问其他应用中的受保护资源时，不再需要重新登录验证”。
个人理解，其中的“同一服务器”的限制应当去掉，关键在于“一次登录”，另外，很少有人提及“退出”的处理逻辑，因此较为完备的定义应该如下：
l 单点登录SSO指用户访问一组相互关联的应用时，只需登录一次，即可访问所有应用中其有权限访问的部分，而不需要每个应用都登录一次，即便各个应用有自身的用户系统。
l 单点登录也应具备“单点退出”的内涵：即用户在任意业务应用退出后，即可保证在所有业务应用及认证服务退出。
l 单点登录应当与应用的具体物理部署没有关系，所谓一组相互关联的应用，仅由业务条件来约束。
单点登录可分为WEB-SSO和非WEB-SSO，本文仅讨论WEB-SSO。根据多个应用的域名关系，可分为“具有公共域名的SSO”和“跨域名的SSO”，所谓具有公共域名的SSO，指多个应用及认证服务具有公共的域名，例如password.baidu.com，tieba.baidu.com，map.baidu.com即具有公共域名baidu.com。
单点登录涉及的几个系统角色说明如下：
l 认证服务：认证服务提供两个职责，其一，提供用户登录的接口界面并对用户进行认证，例如提供用户输入用户名、密码的页面；其二，令牌颁发及校验：对于登录后的用户，生成并颁发令牌给用户，并提供校验令牌的。系统中逻辑上仅有一个认证服务。
l 业务应用：提供业务相关服务的应用，系统中可有多个业务应用，所有业务应用应当支持使用认证服务颁发的令牌来确认用户身份并相应控制其在本业务系统中的权限。也即是说，用户认证交给了认证服务来完成，但是权限管理则应当仍然由各个业务系统管理。
典型流程如下图，以下几点需要注意：
l 本序列图仅为一种实现方式，并非唯一实现；SSO应当存在多种变种，适用于不同场景。
l SessionId相关问题：
l 如认证服务、业务应用属于同一个域名下的子域名，则可不必使用“URL中附件令牌”的方式来传递令牌，也可使用domain为二者公共域名的Cookie来传递令牌。
l 业务应用需要根据令牌获得用户的信息以处理本业务应用内的权限等，有多种方式来实现，例如步骤10返回用户ID等用户信息；
l 步骤9/10也可省略，例如直接由业务应用按照约定的算法从令牌中解析出用户信息，并根据解析出的信息进行令牌的校验。
本流程描述用户已在认证服务登录成功，并且成功访问业务应用1后再访问业务应用2的场景，以下几点为关键点：
l 本序列图描述的是跨域名时的场景，如多个业务应用具有公共域名，并且“未登陆状态访问业务应用”中已正确把令牌设置至domain为公共域名的Cokkie中，则步骤1时，浏览器会自动带上令牌访问业务应用2，业务应用2直接校验令牌即可判断用户是否已通过认证。
l 步骤4/5：认证服务此时可通过浏览器携带的认证服务sessionId来判断用户的登录状态，因此不必要求用户输入用户名、密码登录，因此步骤3至步骤10对用户而言其实是透明的。
一种退出实现的序列图如下，几点需要注意的：
l 步骤7，认证服务通知退出时，仅能携带用户ID，业务应用需要具有用户id与其自身session的映射关系。
认证服务中的令牌应当具备有效期，否则“直接关闭浏览器”的情况会导致认证服务中的令牌数量不断累积。
另一方面，一般情况下，用户的操作是在各业务应用，而不在认证服务，因此如果认证服务中令牌的有效期设置过短，则可能会出现这种情况：用户使用认证服务登录成功，持续访问业务应用1，一段时间后，用户访问业务应用2，但是此时认证服务中的令牌已过期，则会出现要求用户重新登录的错误响应。
解决办法：
第一，可以考虑在业务应用的页面均添加一个隐藏的对认证服务的访问，这样每次访问业务应用的任何页面也会隐藏的访问认证服务，从而保证认证服务的session不过期，即保证了令牌的不过期。这个方法的不好之处在于对于业务应用改动虽然不大，但是需要散布至所有页面，如果是对已有的业务应用进行改造，则这个缺点更突出。
第二，可考虑在业务应用和认证服务之间增加类似于“心跳”接口。
l 含令牌的接口应当使用HTTPS协议，保证令牌传输过程中的安全性；
l 认证服务应当限制“校验令牌”接口调用方，仅允许可信任的系统来调用；
标签：
原文地址：http://www.cnblogs.com/lidabnu/p/5256099.html
