单点登录SSO（Single Sign-On）是身份管理中的一部分。SSO的一种较为通俗的定义是：SSO是指访问同一服务器不同应用中的受保护资源的同一用户，只需要登录一次，即通过一个应用中的安全验证后，再访问其他应用中的受保护资源时，不再需要重新登录验证。
目前的企业应用环境中，往往有很多的应用系统，如办公自动化（OA）系统，财务管理系统，档案管理系统，信息查询系统等等。这些应用系统服务于企业的信息化建设，为企业带来了很好的效益。但是，用户在使用这些应用系统时，并不方便。用户每次使用系统，都必须输入用户名称和用户密码，进行身份验证；而且应用系统不同，用户账号就不同，用户必须同时牢记多套用户名称和用户密码。特别是对于应用系统数目较多，用户数目也很多的企业，这个问题尤为突出。问题的原因并不是系统开发出现失误，而是缺少整体规划，缺乏统一的用户登录平台，使用SSO技术可以解决以上这些问题。一、使用SSO的好处主要有
(1)方便用户
用户使用应用系统时，能够一次登录，多次使用。用户不再需要每次输入用户名称和用户密码，也不需要牢记多套用户名称和用户密码。单点登录平台能够改善用户使用应用系统的体验。
(2)方便管理员
系统管理员只需要维护一套统一的用户账号，方便、简单。相比之下，系统管理员以前需要管理很多套的用户账号。每一个应用系统就有一套用户账号，不仅给管理上带来不方便，而且，也容易出现管理漏洞。
(3)简化应用系统开发
开发新的应用系统时，可以直接使用单点登录平台的用户认证服务，简化开发流程。单点登录平台通过提供统一的认证平台，实现单点登录。因此，应用系统并不需要开发用户认证程序。
二、实现SSO的技术主要有
(1)基于cookies实现，需要注意如下几点：如果是基于两个域名之间传递sessionid的方法可能在windows中成立，在 unix&linux中可能会出现问题；可以基于数据库实现；在安全性方面可能会作更多的考虑。另外，关于跨域问题，虽然cookies本身不跨域，但可以利用它实现跨域的SSO。
(2)Broker-based(基于经纪人)，例如Kerberos等；
这种技术的特点就是，有一个集中的认证和用户帐号管理的服务器。经纪人给被用于进一步请求的电子的身份存取。中央数据库的使用减少了管理的代价，并为认证提供一个公共和独立的"第三方"。例如Kerberos、Sesame、IBM KryptoKnight（凭证库思想）等。
(3)Agent-based(基于代理)
在这种解决方案中，有一个自动地为不同的应用程序认证用户身份的代理程序。这个代理程序需要设计有不同的功能。比如, 它可以使用口令表或加密密钥来自动地将认证的负担从用户移开。代理被放在服务器上面，在服务器的认证系统和客户端认证方法之间充当一个"翻译"。例如 SSH等。
(4)Token-based，例如SecurID、WebID、
现在被广泛使用的口令认证，比如FTP，邮件服务器的登录认证，这是一种简单易用的方式，实现一个口令在多种应用当中使用。
(5)基于网关
Agent and Broker-based，这里不作介绍。
(6)基于安全断言标记语言(SAML)实现，SAML（Security Assertion Markup Language，安全断言标记语言）的出现大大简化了SSO，并被OASIS批准为SSO的执行标准。开源组织OpenSAML 实现了 SAML 规范，可参考http//www.opensaml.org。
三、SUN SSO技术
SUN SSO技术是Sun Java System Access Manager产品中的一个组成部分。
Sun 的新身份管理产品包括Sun Java System Identity Manager、Sun Java System Directory Server Enterprise Edition 和 Sun Java System Access Manager，以上三者为Sun Java Identity Management Suite (身份识别管理套件)的组成部分，它们与Sun Java Application Platform Suite、Sun Java Availability Suite、Sun Java Communications Suite、Sun Java Web Infrastructure Suite组成Java ES。具有革新意义的这一系列产品提供端到端身份管理，同时可与 60 多种第三方资源和技术实现互操作，集成产品可以从SUN公司网站下载，一般以Agent软件方式提供，是业内集成程序最高、最为开放的身份管理解决方案之一。
在Sun 的新身份管理产品中，Sun Java System Access Manager是基中的一个重要组成部分，Java Access Manager基于J2EE架构，采用标准的API，可扩展性强，具有高可靠性和高可用性，应用是部署在Servlets容器中的，支持分布式，容易部署且有较低的TCO。通过使用集中验证点、其于角色的访问控制以及 SSO，Sun Java System Access Manager 为所有基于 Web 的应用程序提供了一个可伸缩的安全模型。它简化了信息交换和交易，同时能保护隐私及重要身份信息的安全。
四、CAS 介绍
CAS（Central Authentication Service），是耶鲁大学开发的单点登录系统（SSO，single sign-on），应用广泛，具有独立于平台的，易于理解，支持代理功能。CAS系统在各个大学如耶鲁大学、加州大学、剑桥大学、香港科技大学等得到应用。
Spring Framework的Acegi安全系统支持CAS，并提供了易于使用的方案。Acegi安全系统，是一个用于Spring Framework的安全框架，能够和目前流行的Web容器无缝集成。它使用了Spring的方式提供了安全和认证安全服务，包括使用Bean Context，拦截器和面向接口的编程方式。因此，Acegi安全系统能够轻松地适用于复杂的安全需求。Acegi安全系统在国内外得到了广泛的应用，有着良好的社区环境。
CAS 的设计目标
(1)为多个Web应用提供单点登录基础设施，同时可以为非Web应用但拥有Web前端的功能服务提供单点登录的功能；
(2)简化应用认证用户身份的流程；
(3)将用户身份认证集中于单一的Web应用，让用户简化他们的密码管理，从而提高安全性；而且当应用需要修改身份验证的业务逻辑时，不需要到处修改代码。
CAS 的实现原理
CAS（Central Authentication Server）被设计成一个独立的Web应用。实现原理非常简单。
CAS创建一个位数很长的随机数（ticket）。CAS把这个ticket和成功登录的用户以及用户要访问的service联系起来。例如，如果用户 peon重定向自service S，CAS创建ticket T，这个ticket T允许peon访问service S。这个ticket是个一次性的凭证；它仅仅用于peon和仅仅用于service S，并且只能使用一次，使用之后马上会过期，即ticket通过验证，CAS立即删除该ticket，使它以后不能再使用。这样可以保证其安全性。
关于ST，在取一个ST时，即使用delete Ticket(ticketId)同时将一次性的ST删除；而对于TGT或PT，则通过reset Timer(ticketId)以更新TGT或PT的时间。在CAS服务端返回的ST中只能得出用户名。
另外，CAS3.0版本也已经发布了，现在最新的版本是3.03，希望CAS3.0在向下兼容的同时，更能向我们提供一些新东西。
SUN SSO 实现原理
SSO的核心在于统一用户认证，登录、认证请求通过IDENTITY SERVER服务器完成，然后分发到相应应用。
SUN SSO是java Access Manager的一个组成部分，SSO基于Cookie实现解释如下：
(1)Policy Agent on Web or Application Server intercepts resource requests and enforces access control;
(2)Client is issued SSO token containing information for session Validation with Session service.
(3)SSO token has no content- just a long random string used as a handle.
(4)Web-based applications use browser session cookies or URL rewriting to issue SSO token.
(5)Non Web applications use the SSO API(Java/c) to obtain the SSO token to validate the users identity.
SUN SSO 的应用
这里说的应用是指Sun Java System Access Manager的应用。成功应用例子很多，包括德国电信等公司的应用，国内也有大量高校在使用，也有相当多的其它行业的应用。
SUN SSO的开源
Sun 将发布其网络验证与网络单点登录技术，给一项新的开放源代码计划“Open Web Single Sign-On”（Open SSO）。OpenSSO网站位于：[url=https://opensso.dev.java.net/]https://opensso.dev.java.net/[/url]。该网站对OpenSSO的概述为：This project is based on the co
OpenSSO 计划的第一部份源代码，将于今年年底完成，基本的版本将于明年3月份发布，而完整的版本可能要等到明年五月份。Sun 采用与Solaris 操作系统相同的共同开发暨流通授权（Common Development and Distribution License）方式。
跨平台跨服务器跨网站SSO（单点登录）的方案
最近在研究SSO，看到各种复杂的解决方案觉得很疑惑，自己想出了个简单有效的方案，大家来评评有什么问题吗？
服务器A：网站A
服务器B：网站B
服务器C：验证网站（验证表中有UID和KEY两个字段）。
1. 用户打开网站A的页面http://服务器A/a.aspx，检测发现网站Session中没有存储用户名UID。
2. 系统转到验证服务器登录页面，并在QUERYSTRING中附加前一个页面的URL地址。比如http://服务器C/login.asp?URL=http://服务器A/a.aspx
3. 在验证服务器登录成功后更新验证服务器的Session（超时设置为足够长，比如1天）。然后生成一个GUID值，写入验证表。最后，把这个GUID值和UID保存到一个类中序列化后附加在URL中返回网站A的那个页面。比如http://服务器A/a.aspx? token=sadhsagdkjasgyugd7d8yweihasdiuhagsdiuashdhaiushdi
4. 网站A的页面读取QUERYSTRING，然后反序列化出一个类，读取类的UID和KEY信息。然后，从数据库中查找匹配的记录，如果找到了则表明登录成功，并把这条记录的KEY更新成另外一个GUID（这样就保证了即使这个URL被别人拿走再登录都不能成功）。把UID写入服务器A的Session中即可。
5. 用户打开网站B的页面http://服务器B/b.aspx，服务器B上没有当前用户的Session信息，自动转向验证服务器检测是否存在Session，如果找到了表明用户已经登录过，再重复步骤3和4，如果没有找到就转到验证服务器的登录页面。
巧妙之处在于：
l 网站服务器和验证服务器都拥有一份和用户关联的Session，验证到时候不需要传任何和UID相关的信息，因此也可以跨服务器。正因为如此不需要使用cookie也解决了跨域名。
l 网站服务器和验证服务器可以使用自己的状态机制（不一定是Session），因此跨平台也没有问题。
l 用于验证用户的TOKEN使用GUID在每次验证的时候都会更换，而且GUID和UID是捆绑在一起的，即使GUID碰巧对上了也不知道这个GUID对应了哪个UID。
l 通过验证服务器的验证后，服务器发回的token数据经过了序列化，用户很难伪造。
（实在不放心还可以对这个token进行加密）
不知道大家是否理解了？
更新：经过网友提醒，我想到这个方案在登出的时候有严重问题，比如A网站登出了，我们不能通知其它网站该用户已经登出，它再切换到其它网站又是登录状态（因为Session没有过期），不过我也想到了一个解决方案。就是所有的网站都有一个专门的页面或者服务，根据传过来的令牌来清空这个当前用户的Session。登出以后把所有网站的Session都清空，如果网站不是很多的情况下还好，网站一多登出就会很慢了！
更新：现在看来已经没有什么问题了，到时候放出完整DEMO!
更新：有网友不理解为什么关闭浏览器所有网站退出登录？因为Session是和用户浏览器实例关联的，而我们所有网站都使用Session，因此关闭了浏览器所有网站都退出了。这个和退出登录按钮不一样，退出登录按钮需要发通知让所有网站清除Session。
更新：我们现在把这个框架的登录放到了各个网站中，保证登录和退出在登录服务器Down的情况下也能进行，只是不能进行跨站登录罢了。登录服务器Down还能实现本站登录和退出。过几天放出完整源代码！