什么是单点登录

简单点说就是公司有A,B两个系统,我登录了A系统之后再跳转到B系统可以直接访问,而不需要再次登录B系统.

几种常见的单点登录实现方式

在讲解单点登录之前先讲解几个基本的概念:

Cookie:

Cookie是一段不超过4KB的小型文本数据,是保存在用户本地的,常见格式为:

Expires属性：设置Cookie的生存期

Domain属性：指定了可以访问该 Cookie 的 Web 站点或域

比如图中的Domain:192.168.1.72这就表示只能只有1.72下的请求可以使用这个cookie,百度什么的就不能使用这个cookie

Path属性：定义了Web站点上可以访问该Cookie的目录

图中的Path是/,这表示这个cookie是根目录拥有的,只要1.72的请求都会默认带上这个cookie,加入Path是/webaikn,那么只有http://192.168.1.72/webaikn/**的请求会带上这个cookie,而http://192.168.1.72/webadmin/**就无法使用这个cookie

其他:略

Session:

http请求是无状态的,但是我们日常访问系统的时候都是希望系统能记住我这个用户,这时候就要靠session去实现,因此session成为会话控制.但是光靠session还是无法实现会话控制的,还需要cookie的配置,如图所示:

这个JESSIONID就是保持会话的关键,它的value对应的就是该用户在服务器的sessionId,所以我们代码直接写HttpSession   session   =   request.getSession();  才不会数据错乱.

Ps:session的存在方便了我们的开发,但是也在一定程度上增加了麻烦,比如多机部署时候的seesion丢失,

重定向

       一句话，转发是服务器行为，重定向是客户端行为.

      转发和重定向都可以由java后台实现,例如:

请求转发：

request.getRequestDispatcher(“/user”).forward(request,response);

重定向：

response.sendRedirect(request.getContextPath + “/user”)

当设置转发之后,请求会直接去转发的地址,而重定向的话请求会先返回客户端,然后再由客户端重新发起请求去新的地址.这里就隐藏了一个知识点,当我在后台设置了cookie然后重定向的时候,其实我重定向的请求中已经带上了我设置的cookie

(1)   假设A和B两个系统都部署在192.168.110.110服务器上

用户在登录了A系统之后,后台代码设置将userName和password作为cookie存入到用户的浏览器中并将cookie的domain设置为192.168.110.110,path设置为/

之后访问B系统的时候由于大家的Ip都是一样的,所以B系统能够获取到A系统设置的cookie,这是只需要设置一个拦截器,在拦截器中判断用户是否是登录状态,如果未登录就去request中获取cookie信息,获取到之后解密然后模拟登录,这样用户可以无感知的登录到B系统.

点评:这是典型的同域单点登录实现方式,局限性非常大,必须要两个系统在同一个服务器或者二级域名相同的情况下才能实现,一般称为伪单点登录

(2)   知识库系统的单点登录实现

知识库的方案1的基础上增加了Nginx作为反向代理(有反向代理就有正向代理,自行查找资料什么是正向代理什么是反向代理)

虽然webaikn和webadmin部署在不同的服务器,但是对客户是无感知的,由于都是访问Nginx,然后再由nginx做转发代理,所以域名是同一个,这样cookie也是可以共享的,这里有一个点需要注意一下,webaikn可能是多机部署,所以nginx在做转发的时候需要设置ip_hash策略,目的就是保证用户上一次请求访问的哪台服务器,下一次还是访问那一台服务器,不至于导致session丢失的情况.   

点评:解决了多机部署单点登录失效的情况,但是还是需要服务器端保存用户的session状态,一方面对于服务器端会产生内存压力,另一方面需要配置ip_hash导致流量不均衡,某些服务器压力比较大的情况.而且用户名和密码保存在cookie中也存在一定的安全隐患,只要被截取到一次请求都会造成账户被盗的情况

(3)   跨域token实现单点登录

主要步骤:

1. 用户登录A系统,A系统拦截器发现请求没有带token,于是重定向到单点登录认证中心sso系统,注意带上用户之前请求的url,我们后面就叫oldUrl
2. Sso接收到请求,发现request的cookie中没有登录成功的令牌token,于是重定向到本系统的登录页面,继续带着oldUrl
3. 用户输入用户名和密码,提交
4. Sso验证用户名是否正确,不正确继续重定向到登录页面,如果正确,进行下面的操作:

生成一个cookie,name就叫token,value可以是任意不重复的值,uuid就行(注意这个cookie是浏览器和sso系统之间的)

将用户信息保存到redis中,key是生成的uuid,value就是user对象

重定向到oldUrl的地址,注意要拼接上token参数

1. A系统再次收到请求,不同的是这次有token参数,A系统根据token的值去redis验证,这里需要分情况讨论了

 没有找到:说明其他子系统发起了注销操作,需要重定向到sso登录页面

 找到了:有了User对象之后可以判断当前请求是否在用户权限表中,存在就直接放行,不存在返回权限不足,之后的请求都需要将token放到请求头信息或者url中

1. 用户浏览完A系统之后,准备去B系统转转,于是浏览器向B系统发起请求,B系统拦截器收到请求,发现请求没有带token,发起重定向去sso,记得带上本次请求的oldUrl
2. 这时候其实和上面的第二步差不多,区别在于由于之前登录过sso所以这次的request中是有token的cookie的,所以sso只需要重定向到oldUrl指向的地址就行,同时记得将cookie中取出来的token拼接到url中
3. B再次系统收到请求,之后的操作和步骤5是一样的了

点评:独立出单点登录认证中心,统一做权限认证操作,清晰明了

子系统不需要用session保存用户登录状态,减轻了服务器的负担

每次请求都是以token作为验证标准,就算请求被拦截了,用户的信息也不会泄露

后期做三方登录的时候也不需要将用户数据暴露给其他系统,其他系统能获取的只有token(真要做三方登录redis中存放的肯定是最简单的一些用户信息)

下面这个图取自哪位大佬我已经没有地址了,好像是百宝门