单点登录

一、登录机制

http无状态协议

web应用采用B/S架构，使用http作为通信协议。

http是无状态协议，浏览器的每次请求，服务器都会单独处理，不与之前的请求或者之后的请求产生关联

但这也同时意味着，任何用户都能通过浏览器访问服务器资源，如果想保护服务器的某些资源，必须限制浏览器请求；要限制浏览器请求，必须鉴别浏览器请求，响应合法请求，忽略非法请求；要鉴别浏览器请求，必须清楚浏览器请求状态。既然http协议无状态，那就让服务器和浏览器共同维护一个状态吧。这就是会话机制

会话机制

浏览器第一次请求服务器，服务器创建一个会话，服务器将会话的id作为响应的一部分发送给浏览器，浏览器存储会话id，然后在后面第二次和第三次请求时带上会话id，服务器获取请求中的会话id来判断是不是同一个用户，这样后面的请求就与第一次请求产生了联系

服务器在内存中保存会话对象，浏览器怎么保存会话id呢？你可能会想到两种方式

1.请求参数

​ 将会话id作为每一个请求的参数，服务器接收请求自然能解析参数获得会话id，并借此判断是否来自同一会话，很明显，这种方式不靠谱。

2.cookie
　　浏览器自己来维护这个会话id，每次发送http请求时浏览器自动发送会话id，cookie机制正好用来做这件事。cookie是浏览器用来存储少量数据的一种机制，数据以”key/value“形式存储，浏览器发送http请求时自动附带cookie信息

3.登录状态
假设浏览器第一次请求服务器需要输入用户账号和密码来验证身份，服务器拿到用户账号和密码来和数据库中的进行对比。一致则说明当前用户是正确合法的，此时该用户应该为一登录状态。这个会话状态应该保存在会话对象中。tomcat在会话对象中设置登录状态为
java HttpSession session = request.getSession(); session.getAttribute("isLogin",true);
当用户再次访问时，tomcat就在会话对象中查看登录状态
java HttpSession session = request.getSession(); session.getAttribute("isLogin");

每次请求被保护的资源时都会检查会话状态中的登录状态，只有 isLogin=true 的会话才能访问，登录机制因此而实现

二、单点登录

CAS是Central Authentication Service的缩写，中央认证服务，一种独立开放指令协议
SSO是Single Sign On，是指在多系统应用群中登录一个系统，便可在其他所有系统中得到授权而无需再次登录，包括单点登录与单点注销两部分

登录

sso采用一个独立的认证中心，认证中心提供登录入口，其他系统不提供登录入口，只接受认证中心的授权，认证中心采用令牌机制。
例如
认证中心地址：sso.test.com
系统1地址：system1.com
系统2地址：system2.com
1、用户访问子系统1资源时，子系统1现用户是未登录状态，就会重定向到认证中心，在该过程中将自己的地址作为参数传递过去（传递地址是为了认证成功后返回的到系统1）
2、认证中心发现用户未登录，然后引导用户到认证中心登录页面。用户输入密码，提交登录。认证中心收到用户提交的信息，在认证中心验证登录的用户账号密码正确，就会创建一个全局会话（用户与认证中心之间的会话），同时创建令牌（ticket票据），认证中心就会带着令牌跳转到最初的请求地址（也就是系统1带过来的地址）
3、系统1收到令牌，在去认证中心校验令牌是否有效，认证中心返回给子系统令牌有效，注册系统1，子系统创建局部会话（用户与系统1之间的会话），用户就能访问该系统被保护的资源了
4、此时用户进行访问子系统2被保护的资源时，重复以上步骤，系统2发现用户未登录，就会跳转到认证中心，并且将自己的地址作为参数带上。
5、此时用户与认证中心存在全局会话，也就是用户在认证中心是已登录状态，认证中心发现用户已登录，就会将子系统2传递过来的地址取出，跳转回系统2，并且带上令牌（ticket票据）
6、系统2收到认证中心的令牌，就会去认证中心校验令牌是否有效，认证中心校验令牌，返回令牌有效，注册系统2，系统2使用该令牌创建局部会话（系统2与用户之间的会话），返回给用户受保护的资源
当局部会话存在后，用户访问子系统受保护的资源时就不再通过认证中心

系统1访问如图：

系统2访问如图：

系统1与系统2连续图

注销

在一个子系统中注销，所有子系统的会话都将被销毁

参考:
单点登录原理与简单实现
CAS单点登录（一）—初识SSO