其实就是统一用户管理平台,如今各种系统数不胜数,这就难免需要用户名和密码登录，但是账户越多越容易忘记，而且每次访问需要登录还很麻烦，所以单点登录系统应运而生，这也是我上班的第一个任务-利用公司现有的SSO服务器来配置客户端开发用户登录接口从而和别的公司对接。
起初我还以为是做外包的，认为i很简单啊，不就是要实现一个用户登录验证之后再来个重定向吗，于是自己回顾一下之前的最最原始的MVC模式，把基本功能实现之后最后在加上个页面重定向到目标地址，蛮有“成就感”的给经理看看。 结局就是做的全是无用功，重新来过，应该是基于公司已有的SSO服务器来开发，于是乎，漫长的摸索单点登录系统的道路开始了。。。
在网上也看了很多的资料，较为粗略的看了下原理：
1. SSO服务器的处理大致流程就是：用户在A客户端登录---->SSO服务器验证用户信息---->验证成功后在SSO服务器端会记下一个TGC(Ticket Granted Cookie)票据而且返回到A客户端时还带有一个ticket参数(它是唯一，不可伪造的参数),在A客户端拿到 Service 和新产生的 Ticket 过后，与 SSO服务器进行身份核实，以确保 Service和Ticket 的合法性---->退出登陆时,会向SSO服务器发送logout请求（清除Session）,之后SSO服务器会广播到其他应用服务器的logout（清除Session）。
下面拿我做过的案例来说：
例如原始应用的网址是http://localhost:8080/cas-client/，在这个客户端登录页面里form表单包含登录用户名和密码，一开始有如下语句，转向CAS服务器的单点登录页面https://sso.nubb.com/login?service=http://localhost:8080/cas-client/。
SSO服务器完成主体认证后，会使用下面URL进行重定向http://localhost:8080/cas-client/?ticket= ST-2-7FahVdQ0rYdQxHFBIkKgfYCrcoSHRTsFZ2w-20。 收到ticket之后，应用程序需要验证ticket。这是通过将ticket 传递给一个校验URL来实现的。校验URL也是SSO服务器提供的。
SSO服务器通过校验路径获得了ticket之后，通过内部的数据库对其进行判断。如果判断是有效性，则返回一个NetID给应用程序。 随后CAS将ticket作废，并且在客户端留下一个cookie。
以后其他应用程序就使用这个cookie进行认证（当然通过CAS的客户端），而不再需要输入用户名和密码。
