CN111581631A - 一种基于redis的单点登录方法 - Google Patents

Abstract

本发明涉及互联网技术领域，尤其涉及一种基于redis的单点登录方法，首先做session管理、ticket管理和cookie管理；用户通过浏览器打开任何一个子系统，首先判断session在不在，如果session在就直接进入系统,Session不在，就跳转到中央认证平台登录页面；登录页面加载后，将浏览器存储和中央认证平台的session id和这个子系统的session id都提交到平台后台；平台后台首先判断平台的session id是否存储在redis中，如果不存在，将继续停留在这个登录页面，等待用户输入用户名和密码；如果存在，平台再检查子系统的session id是否存储在redis中，如果也存在，就把这个session id作为请求的一个参数，调取子系统的session验证接口；本发明通过分散的单独登录系统，保证了系统数据的安全性，防止数据泄密。

Description

一种基于redis的单点登录方法

技术领域

本发明涉及互联网技术领域，尤其涉及一种基于redis的单点登录方法。

背景技术

单点登录，简称为SSO，是目前比较流行的企业业务整合的解决方案之一，单点登录的优点是用户不再被多次登录困扰，也不需要记住多个ID和密码。另外，用户忘记密码并求助于支持人员的情况也会减少。提高了开发人员的效率。SSO为开发人员提供了一个通用的身份验证框架。实际上，如果SSO机制是独立的，那么开发人员就完全不需要为身份验证操心。他们可以假设，只要对应用程序的请求附带一个用户名，身份验证就已经完成了。单点登录还简化了管理。如果应用程序加入了单点登录协议，管理用户帐号的负担就会减轻。简化的程度取决于应用程序，因为SSO只处理身份验证。所以，应用程序可能仍然需要设置用户的属性。

虽然单点登录优点很多，是常用的系统开发采用模式，但是单点登录不利于重构，因为涉及到的系统很多，要重构必须要兼容所有的系统，浪费资源，可能很耗时，无人看守桌面因为只需要登录一次，所有的授权的应用系统都可以访问，可能导致一些很重要的信息泄露。对于保密性要求比较高的单位或者系统不适用于采用单点登录。

发明内容

有鉴于此，本发明的目的是提供一种基于redis的单点登录方法,以解决背景技术中的问题。

本发明的目的在于提出一种基于redis的单点登录方法，本方法具体按以下步骤执行：

S1:首先做session管理、ticket管理和cookie管理；前台使用localstorage，后台使用redis实现单点登录。session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构来保存信息。用户的登录信息就保存在session中。但程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否包含了一个session标识(称为session id),如果已经包含一个session id则说明以前已经为此客户创建过session，服务器就按照session id把这个session检索出来使用。如果客户请求不包含session id，就需要通过登录程序新建一个session id。单点登录管理的核心，就是对大量session id的管理。

进一步，ticket管理，当平台处于登录状态，而子系统处于未登录状态时，平台需要子系统免密码直接登录，主动产生session和session id，ticket是平台和子系统之间的凭证。Ticket由平台产生，每次生成都是唯一的，生命周期只有20秒(时间可调)，且只能被消费一次，被消费完或超过20秒，就会作废。子系统收到平台的ticket后，马上要到平台上去消费这个ticket，平台验证ticket正确无误，子系统就可以安全的登录了。Ticket是单点登录的核心安全保障。

进一步，cookie管理，cookie可以认为是浏览器缓存的数据。它是网站留在本地的一个小文本文件，协助网站追踪客户。最简单的用处就是记住密码。单点登录涉及到的系统很多，如果用户同时登录多个子系统，每一个系统都会产生一个的session id，这些session id在用户电脑端，都需要被存储在浏览器的cookie中。当浏览器访问某一个系统时，浏览器会自动把session id从cookie中取出，跟在请求的参数里，系统后台看到session id，才能识别出session。从实现原理上，单点登录首先是平台与子系统之间的登录，并不是用户浏览器和子系统之间在登录。子系统登录反馈的session id，只有平台后台能拿到了，这里还需要从平台的后台推送session id到用户浏览器中，存储在cookie里。

进一步，打开任何一个子系统，首先判断session在不在，如果session在就直接进入系统。Session不在，就跳转到中央认证平台登录页面。登录页面加载后，有一个动作，会将浏览器存储的，中央认证平台的session id和这个子系统的session id，都提交到平台后台。平台后台首先判断平台的session id是否存储在redis中，如果不存在，将继续停留在这个登录页面，等待用户输入用户名和密码。如果存在，平台再检查子系统的session id是否存储在redis中，如果也存在，就把这个session id作为请求的一个参数，调取子系统的session验证接口。如果验证通过，平台把session id传给浏览器，浏览器存储在cookie中，登录页面自动跳转到刚才用户输入的子系统的路径，浏览器就可以单点登录到这个子系统。

进一步，子系统session id不存在或者验证不通过，平台创建一个ticket，这个ticket每次生成都是唯一的，生命周期只有20秒(时间可调)，且只能被消费一次，被消费完或超过20秒，就会作废。平台将ticket下发给子系统的ticket接收接口。

进一步，子系统接收到ticket后，在平台的验证接口，验证ticket的是否正确，如果ticket验证失败，反馈给平台，平台还会再补验证一次，继续失败，平台会直接反馈给页面。验证通过，子系统产生一个新的session，并将session id传给平台。

进一步，平台拿到session id，在redis中存储，传给浏览器，浏览器存储在cookie中，登录页面自动跳转到刚才用户输入的子系统的路径，浏览器就可以单点登录到这个子系统。

进一步，注销系统，在任何一个子系统中，点击注销超链接，子系统后台会请求平台的注销接口。平台收到请求后，在redis中取到这个用户现在正在登录的所有sessionid，逐个调用子系统的session清除接口。子系统收到清除指令后，会清除相应的session并将清除结果反馈给平台。平台收到清除成功的指令后，在redis的记录中进行清除。如果注销失败，也会将详细的失败结果，在页面响应给用户。

本发明的有益效果：可以兼容java，c#等所有子系统。被集成到单点登录服务的所有子系统，session不需要统一，每个系统拥有自己独立的session和session id。用户、角色、权限、菜单等由各个子系统自己管理。所有子系统需要在单点登录服务的登录页面登录，不允许有自己的登录页面。从一个子系统登录完单点登录服务，也就只登录了这个系统，其它系统都不需要登录。用户手工在浏览器输入哪个系统，就登录哪个系统。不需要从单点登录服务上某个页面里，点击超链接才能登录子系统。直接输入网址就可以进入登录状态，输入的网址不需要刻意带ticket、身份证号码等这些参数。在任意一个子系统中注销系统，所有的系统都要能同时注销。通过分散的单独登录系统，保证了系统数据的安全性，防止数据泄密。

附图说明

图1是本发明的登录具体流程图；

图2是本发明的注销具体流程图；

图3是本发明的登录流程图；

图4是本发明的注销总览流程图。

具体实施方式

以下将结合附图和具体实施例对本发明进行详细说明，显然，所描述的实施例仅仅只是本申请一部分实施例，而不是全部的实施例，基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

如图1所示,本实施例中,本发明的一种基于redis的单点登录方法，本实例包括以下步骤：

本方法具体按以下步骤执行：

本实施例中，首先在用户登录时检查session是否存在(check_session)这个接口用于随时检查，某一个用户是否处于登录状态。用户登录后，有一个session id或者token值存储在单点登录服务里，单点登录服务会不定期的拿这个id到子系统中，检查某一个用户是否仍处在登录状态。单点登录服务会在HttpServletRequest的requestedSessionId里，把这个值发送给子系统。子系统需要开发一个验证接口，配合验证。

本实施例中，部分子系统的登录信息，子系统后台存储在session中，session有一个session id，以key value形式存储在用户浏览器的cookie里。如果后台容器使用的是tomcat，系统的sessionid在cookie里存储的key值默认都是JSESSIONID。cookie有一个问题，和ip地址或者域名对应，不区分端口，同一个ip地址上，如果只部署了一个系统，以下内容就不需要看。如果部署了2个及以上的系统，但是域名都不一样，也不需要看以下内容。如果部署了2个及以上的系统，ip地址或者域名一样，只是端口不一样，需要对系统作如下修改，否则几个系统在同一个浏览器cookie里存储的key都是JSESSIONID，登录信息会相互覆盖，无法一起登录。

本实施例中，Tomcat项目找到tomcat文件夹下的conf/server.xml，在Server.Engine.Host下增加：sessionCookieName就是cookie中存储的新的session idkey值，名称可随意命名，只要保证在这个ip地址或者域名里唯一就可以了。Springboot项目在application.yaml中，增加server.servlet.session.cookie.name，在后面输入新的session id key即可。

本实施例中，单点登录服务是集团统一的登录管理服务，用于管理每一个子系统的登录、注销等任务，并记录用户的在每一个子系统中的登录信息。用户是一处登录，处处登录。实际上比如有十个子系统参与了单点登录，用户只使用了其中一个系统，其他系统并没有登录。当用户在浏览器上输入第二个系统的网址时，单点登录服务自动对第二个系统进行登录。即，使用几个系统，登录几个系统，登录新系统时，不需要用户再输入用户帐号和密码。

本实施例中，服务与子系统的关系，子系统的用户、权限、角色、资源等，由子系统自己管理，单点登录服务不涉及这些细节。子系统需要有一个登录接口，但不能自己输入用户帐号、密码登录，这个接口仅供单点登录服务调用。登录接口可以使用javafilter、shiro、OAuth2等任何一种技术或者第三方框架，由子系统自己决定。子系统的登录信息管理，后台可以存储在session中，也可以存储在redis等第三方软件中；可以使用session模式，也可以使用token模式；子系统浏览器的session id可以存储在cookie里，也可以存储在sessionStorage和localStorage里；单点登录服务同样不涉及这些细节。

本实施例中，过程—登录跳转，从子系统输入任意一个需要登录才能查看的页面，子系统检查用户没有登录，跳转到单点登录服务的统一登录页面。跳转时get路径上，需要带上本系统的访问路径，如域名或者ip加端口，80端口不需要写出来，用参数ssoClientUrl传输，格式如下：

/sso/login.html？ssoClientUrl＝http://127.0.0.1:8001

本实施例中，过程—推送session id，统一登录页面首先联系单点登录服务后台，检查这个浏览器上是否有用户正在登录单点登录服务；如果有用户在登录，检查是否已经存储了这个用户登录这个子系统的session id信息；如果存储了，就调用2.1的接口，检查登录状态是否仍有效；如果有效，就把存储的session id推送给同一个浏览器的子系统session id接收页面，在demo程序中为/sso/session.html。子系统收到session id后，按照自己的系统登录规则，存储在前台页面的cookie或sessionStorage或localStorage里，存储位置，由子系统自己管理。

本实施例中，过程—单点登录，如果浏览器上有用户正在登录单点登录服务，但没有登录子系统，或者登录已失效，就临时产生一个门票，门票生命周期只有20秒，单点登录服务将门票连同用户的身份证号码，子系统的系统id，三个参数传给子系统。建议子系统给单点登录服务一个前台html访问路径，用于接收这三个参数，在demo程序中为/sso/login.html。

子系统html接收到三个参数，调用子系统后台sso-supervisor-client.jar中com.ym.sso.supervisor.client.service.SsoLoginService门票检查方法，方法名为checkSession()，查询门票是否有效；如果查询结果为sso_success，就执行登录过程，如创建session等；创建完成后，调用SsoLoginService的上传sessionid方法，方法名为receiveSessionId()，将新生成的session id上传到单点登录服务；看到返回receive_id_success，登录结束。

子系统session id不一定需要每次登录时都新创建，session中也是key value形式，用户登录信息所在的key被清除了，用户也就没有在登录，但session容器还在，登录时，在原session中新建用户登录信息key，也是登录，原session id不变。

本实施例中，过程—帐号密码登录，如果浏览器上没有用户登录，跳转到单点登录服务的登录页面，由用户自己输入用户帐号和密码登录单点登录服务。登录完成后，程序自动执行上面的单点登录步骤，登录子系统。同一个用户在同一个时间段内，只能在同一台电脑的同一个浏览器上登录。例如用户现在使用的是A浏览器打开了A系统，他又想用B浏览器打开B系统，这时B系统需要重新登录，并且要踢掉A浏览器上的A系统的登录。用户换一台电脑，如果用的是在别的电脑上已经登录过的帐号，前一台电脑上的登录状态，也会被踢下去。单点登录服务首先会根据前一次登录的记录，逐个注销前一次登录的所有系统，注销完成以后，再执行本次登录过程。

本实施例中，注销接口，同一个用户在每一个子系统的登录信息，都会上报并存储在单点登录服务中。注销是一处注销，处处注销。在任何一个子系统中点击注销，都会把这个用户在所有系统中的登录全部注销掉。每一个子系统都需要开发一个注销接口，供单点登录服务从后台调用，接口用于清除子系统后台的登录信息，如session、redis记录等。为了保证注销的效率，注销过程不清除子系统前台cookie或sessionStorage或localStorage里的系统，后台信息清除后，前台就算有信息，也登录不上去了。session的信息，建议使用session.removeAttribute清除登录的key值，不建议使用invalidate()方法把整个session都销毁了。当然由子系统自己决定，单点登录服务不涉及这一块细节。

本实施例中，注销工作分两块：首先子系统调用单点登录服务的统一注销接口；其次，单点登录服务根据记录的数据，逐个调用子系统的注销接口，注销子系统。

以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或者等同替换，而不脱离本发明技术方案的宗旨和范围，其均应涵盖在本发明的权利要求范围当中。本发明未详细描述的技术、形状、构造部分均为公知技术。

Claims (10)

1.一种基于redis的单点登录方法，其特征在于：具体按以下步骤执行：

S1：首先做session管理、ticket管理和cookie管理；

S1.1：用户通过浏览器请求创建一个session，服务器首先检查这个客户端的请求里是否包含了一个session标识,如果已经包含一个sessionid则说明以前已经为此客户创建过session，服务器就按照session id把这个session检索出来使用；

S1.1.1：如果客户请求不包含sessionid，就需要通过登录程序新建一个sessionid；

S1.2：当平台处于登录状态，而子系统处于未登录状态时，平台需要子系统免密码直接登录，主动产生session和session id用于子系统安全的登录；

S1.2.1：：用户用浏览器访问平台的一个子系统时，浏览器会自动把session id从cookie中取出，跟在请求的参数里，系统后台看到session id，识别出session；

S1.3：子系统登录反馈的sessionid，平台后台得到信息以后，从平台的后台推送session id到用户浏览器中，存储在cookie里；

S2：用户通过浏览器打开任何一个子系统，首先判断session在不在，如果session在就直接进入系统,Session不在，就跳转到中央认证平台登录页面；

S3：登录页面加载后，将浏览器存储和中央认证平台的session id和这个子系统的session id都提交到平台后台；

S4:平台后台首先判断平台的sessionid是否存储在redis中，如果不存在，将继续停留在这个登录页面，等待用户输入用户名和密码；

S5:如果存在，平台再检查子系统的sessionid是否存储在redis中，如果也存在，就把这个sessionid作为请求的一个参数，调取子系统的session验证接口，如果验证通过，平台把sessionid传给浏览器，浏览器存储在cookie中，登录页面自动跳转到刚才用户输入的子系统的路径，浏览器就可以单点登录到这个子系统；

S6:子系统session id不存在或者验证不通过，平台创建一个ticket，这个ticket每次生成都是唯一的，生命周期只有20秒，且只能被消费一次，被消费完或超过20秒，就会作废，平台将ticket下发给子系统的ticket接收接口；

S7:子系统接收到ticket后，在平台的验证接口，验证ticket的是否正确，如果ticket验证失败，反馈给平台，平台还会再补验证一次，继续失败，平台会直接反馈给页面，验证通过，子系统产生一个新的session，并将session id传给平台；

S8:平台拿到sessionid，在redis中存储，传给浏览器，浏览器存储在cookie中，登录页面自动跳转到刚才用户输入的子系统的路径，浏览器就可以单点登录到这个子系统。

2.根据权利要求1一种基于redis的单点登录方法，其特征在于：在退出系统时进行注销过程如下：

S2.1：在任何一个子系统中，点击注销超链接，子系统后台会请求平台的注销接口；

S2.2：平台收到请求后，在redis中取到这个用户现在正在登录的所有session id，逐个调用子系统的session清除接口；

S2.3：子系统收到清除指令后，会清除相应的session并将清除结果反馈给平台；

S2.4：平台收到清除成功的指令后，在redis的记录中进行清除；

S2.5：如果注销失败，也会将详细的失败结果，在页面响应给用户。

3.根据权利要求1一种基于redis的单点登录方法，其特征在于：在步骤S2中，用开发的check_session接口随时检查某一个用户是否处于登录状态，以此检查session是否存在。

4.根据权利要求1一种基于redis的单点登录方法，其特征在于：子系统的登录信息管理，后台可以存储在session中，也可以存储在redis等第三方软件中；可以使用session模式，也可以使用token模式；子系统浏览器的session id可以存储在cookie里，也可以存储在sessionStorage和localStorage里。

5.根据权利要求1一种基于redis的单点登录方法，其特征在于：子系统需要有一个登录接口，但不能自己输入用户帐号、密码登录，这个接口仅供单点登录服务调用，登录接口可以使用java filter、shiro、OAuth2等任何一种技术或者第三方框架。

6.根据权利要求1一种基于redis的单点登录方法，其特征在于：从过程到登录的跳转过程中，从子系统输入任意一个需要登录才能查看的页面，子系统检查用户没有登录，跳转到单点登录服务的统一登录页面；跳转时get路径上，需要带上本系统的访问路径，域名或者ip加端口，用参数ssoClientUrl传输。

7.根据权利要求1一种基于redis的单点登录方法，其特征在于：过程到推送sessionid的过程，统一登录页面首先联系单点登录服务后台，检查这个浏览器上是否有用户正在登录单点登录服务；如果有用户在登录，检查是否已经存储了这个用户登录这个子系统session id信息；如果存储了，就调用登录接口，检查登录状态是否仍有效；如果有效，就把存储的session id推送给同一个浏览器的子系统session id接收页面；

S7.1：子系统收到sessionid后，按照自己的系统登录规则，存储在前台页面的cookie或sessionStorage或localStorage里，存储位置，由子系统自己管理。

8.根据权利要求1一种基于redis的单点登录方法，其特征在于：在过程到单点登录的过程中，如果浏览器上有用户正在登录单点登录服务，但没有登录子系统，或者登录已失效，就临时产生一个门票，门票生命周期只有20秒，单点登录服务将门票连同用户的身份证号码，子系统的系统id，三个参数传给子系统；

S8.1：建议子系统给单点登录服务一个前台html访问路径，用于接收这三个参数；子系统html接收到三个参数，调用子系统后台门票检查方法，查询门票是否有效；如果查询结果为有效，就执行登录过程，

S8.2：如创建session等；创建完成后，调用登录接口上传session id方法，将新生成的session id上传到单点登录服务；看到返回信息，登录结束；

9.根据权利要求8一种基于redis的单点登录方法，其特征在于：子系统session id不一定需要每次登录时都新创建，session中也是key value形式，用户登录信息所在的key被清除了，用户也就没有在登录，但session容器还在，登录时，在原session中新建用户登录信息key，也是登录，原session id不变。

10.根据权利要求1一种基于redis的单点登录方法，其特征在于：过程到帐号密码登录过程如下：

S10.1：如果浏览器上没有用户登录，跳转到单点登录服务的登录页面，由用户自己输入用户帐号和密码登录单点登录服务，登录完成后，程序自动执行上面的S8单点登录步骤，登录子系统；

S10.2：同一个用户在同一个时间段内，只能在同一台电脑的同一个浏览器上登录；

S10.3：如用户现在使用的是A浏览器打开了A系统，他又想用B浏览器打开B系统，这时B系统需要重新登录，并且要踢掉A浏览器上的A系统的登录；

S10.4：用户换一台电脑，如果用的是在别的电脑上已经登录过的帐号，前一台电脑上的登录状态，也会被踢下去；

S10.5：单点登录服务首先会根据前一次登录的记录，逐个注销前一次登录的所有系统，注销完成以后，再执行本次登录过程。

Images