单点登录

 

跨域：客户端请求的时候，请求的服务器，不是同一个IP,端口，域名，主机名的时候，都成为跨域

域：在应用模型，一个完整的，有独立访问路径的功能集合称为一个域

域名和IP是不一样的域，协议不一样不叫跨域

SPRING session 将session保存到三方存储容器中，如mysql,redis

主要解决同域名下多服务器集群session共享的问题，不能解决跨域session共享问题

JWT 数据结构   A.B.C

A -head头信息

B- payload(有效荷载)   用户非重要信息

C-signature 签名

 

头信息   数据结构{"alg":"加密算法","typ":"JWT"}

payload

明文

分为三个部分：

已注册信息(registered claims)：iss(发行者)，exp（到期时间），sub(主题)，aud(受众)

公开数据(public claims), 自定义的

私有数据（private claims）自定义

 

signature

签名信息

先使用header中定义的加密算法，将header和payload 进行加密，

再使用相同的加密算法，对加密后的数据和签名信息进行加密

 

 

 

 

1. 前言

目前在作门户，有不少不明白的地方，通过思考和讨论，大体梳理出了一个基本的思路。
2. 单点登陆

单点登陆用于多个系统之间的统一认证，作到“登录一次，随意通行”。单点登陆和门户没有必然联系，单点登陆组件好比CAS只管认证，无论其余的。
问题：若干个系统只用一份用户表，那么每一个系统里面没有维护用户信息，怎么去维护各自系统的权限，角色，组织机构等关系呢？
方案一

每一个系统都维护一份用户表，和单点登陆的用户表保持同步，而后每一个系统使用本身的用户表来维护用户和权限，角色，组织机构等的关系。
这种方式的关键在于用什么手段保持同步：

    1在数据库层面同步用户信息
    能够在单点登陆用户表中建立触发器，在添加、修改、删除的时候同时编辑各个子系统的用户表还有其余的用户关联信息。
    这种办法简单好用，可是要求各个系统的数据库在同一台机器上或者能够提供DBLink之类的链接，缺点是不利于扩展，好比子系统更换了数据库类型就歇菜了。
 

    2 在应用层面同步用户信息
    各个系统提供维护用户信息的WebService接口或者API，在维护单点登陆用户的时候调用各子系统的接口实现系统间的同步
    这种方式的缺点是：
        将同步的操做写在代码中，可能会常常改动代码。
        可能会由于接口服务宕掉或者其余缘由并不能保证各系统之间数据的彻底一致，最后仍是须要人工参与。

    3提供用户信息视图

     直接对外暴露一个用户信息视图，各子系统想怎么同步就怎么同步，这种方法最简单，须要注意不要把原始的数据库暴露出去，单独建一个用户使用这个用户提供    视图。

方案二

抽离出公共的权限模块，用来统一管理用户、角色、权限、机构等信息。
这个就有点相似于门户的功能了，把这些资源都抽离成一个父模块统一管理，各个子系统不须要维护这些关系，天然也就不须要同步了。
父模块须要提供方案供各个子模块获取权限、角色、机构等信息。
3. 门户

门户的概念可大可小，基本包含以下几点：

    单点登陆
    统一权限管理
    日志管理
    各系统功能的整合

3.1. 单点登陆

门户提供单点登陆功能。
3.2. 统一权限管理
问题一：门户既然统一管理权限，各个子系统怎么获取本身须要的权限信息呢？

获取信息的方式能够有不少种，可是真正的难点在于如何控制好各个子系统的数据权限，好比：

    如何在保证易用性的前提下作到各个子系统访问本身的数据，而不能访问其余子系统的数据；
    有时子系统不可避免的会有对权限进行操做的需求，如何知足这部分需求的同时保证数据的安全。

方案一：

门户提供Webservice查询接口供各个子系统调用。
这种方式性能不太好。
方案二：

门户提供API（jar包）查询接口供各个子系统调用。
这种方式不错，提供Maven依赖也能够比较方便的更新。
方案三：

使用Redis保存用户信息和权限信息，各个子系统和门户都从Redis里面取信息，从而作到Session信息共享。
这种方式适合多系统之间Session共享，须要单独的Redis服务器。
问题二：子系统中有一些资源须要受权，可是这些资源门户中很难维护怎么办？

有些数据量很大（好比数据库的元数据信息）；有些资源变更特别频繁（好比文件资源）；有些资源权限控制复杂（好比须要控制访问范围、读写权限，相似于LInux文件）；甚至有一些资源是须要动态获取的，根本没法固化到数据库中。
以上这些资源是很难再门户中维护的。
方案一

子系统同步门户的用户、部门等表，具体办法参考上文。
方案二

门户提供用户列表、部门列表等信息的查询接口或者API供子系统调用，子系统受权的时候从接口或者API中获取这些信息，而后用来受权创建关联信息。这种方式只是理论上可行，可是确定很是复杂繁琐。
缺点：

    开发很困难
    不安全
    权限管理复杂，有些用户有只A系统的权限，没有B系统的权限，那么用户A须要只能获取到有本系统权限的用户。

3.3. 日志管理

日志分为两种：访问日志和操做日志。
3.3.1. 访问日志

    若是访问的是门户中的资源，那么门户直接记录访问日志。
    若是访问的是子系统中的资源，须要子系统调用门户提供的访问日志接口或者API来记录访问日志。

3.3.2. 操做日志

    若是是门户自己的操做，好比用户信息的维护，资源的注册和删除等，这些操做日志由门户直接记录。
    其余设计具体子系统业务的操做，由子系统调用门户提供的接口或者API记录操做日志。

3.4. 各系统功能整合

门户整合子系统根据实际状况有不少种方式。

    彻底整合
    彻底控制子系统的各类资源的管理和受权，甚至能够将子系统的功能嵌入到门户中。
    控制权限、提供单点登陆
    彻底控制子系统的各类资源的管理和受权，提供单点登陆功能，以门户做为入口访问各个子系统。
    只提供单点登陆
    只提供单点登陆，子系统同步用户机构等表，本身控制权限。
    仅整合入口
    仅整合入口，伪单点登陆。

问题一：子系统不想改造，只想简单嵌入到门户中怎么办？

实际工做中由于门户须要整合其余系统，可能会遇到各类各类的问题或者阻力，好比已经上线运行的系统要整合到门户中，进行单点登陆、权限等改造是很耗费时间的，尤为是客户不掏钱的状况下厂商是确定不想改的。
这种状况能够作一种伪单点登陆，子系统基本不用怎么改动便可。
解决方案：
1. 这种状况门户中只能维护一个子系统的入口，其余的权限、用户等等都不用管，用户点击入口连接时，门户打开新窗口调用子系统的登陆页面，将用户名密码等信息传过去。
2. 子系统的逻辑也基本不用修改，判断用户名密码是否正确就能够，出于安全考虑连接和请求信息通常会加密，因此子系统通常须要对信息进行解密再校验。
3. 子系统的用户表须要从门户的用户表中同步，注意只须要同步有登录该系统权限的用户。
4. 子系统开发一个没有访问权限的页面，若是登陆验证失败，就返回这个无权限页面。
问题二：关于本来使用Shiro控制权限的系统如何做为子系统接入门户？

Shiro本来控制权限使用的是一个惟一的字符串也就是权限标识来控制用户的权限的，这个字符串通常是惟一的，可读性好的，有必定业务含义的。
可是门户控制权限不大可能为使用Shiro的子系统去维护这样的字符串。
因此子系统能够维护一个资源ID和权限标识的映射关系表，获取到拥有权限的资源ID集合之后再映射成权限标识的集合提供给Shiro。
注意：
其实不仅是Shiro，各个子系统均可能存在这个问题，就是门户的资源ID和系统的资源ID是不一致的，均可以用这种思路解决。
---------------------
做者：程序员GO
来源：CSDN
原文：https://blog.csdn.net/hao7030187/article/details/70670323
版权声明：本文为博主原创文章，转载请附上博文连接！

 

 

 

 

 

 

 

 

 

 

 

 

1.登录

用户访问系统1的受保护资源，系统1发现用户未登陆，跳转至sso认证中心，并将本身的地址做为参数

sso认证中心发现用户未登陆，将用户引导至登陆页面

用户输入用户名密码提交登陆申请

sso认证中心校验用户信息，建立用户与sso认证中心之间的会话，称为全局会话，同时建立受权令牌

sso认证中心带着令牌跳转会最初的请求地址（系统1）

系统1拿到令牌，去sso认证中心校验令牌是否有效

sso认证中心校验令牌，返回有效，注册系统1

系统1使用该令牌建立与用户的会话，称为局部会话，返回受保护资源

用户访问系统2的受保护资源

系统2发现用户未登陆，跳转至sso认证中心，并将本身的地址做为参数

sso认证中心发现用户已登陆，跳转回系统2的地址，并附上令牌

系统2拿到令牌，去sso认证中心校验令牌是否有效

sso认证中心校验令牌，返回有效，注册系统2

系统2使用该令牌建立与用户的局部会话，返回受保护资源

 

用户登陆成功以后，会与sso认证中心及各个子系统创建会话，用户与sso认证中心创建的会话称为全局会话，用户与各个子系统创建的会话称为局部会话，局部会话创建以后，用户访问子系统受保护资源将再也不经过sso认证中心，全局会话与局部会话有以下约束关系

1 2 3

局部会话存在，全局会话必定存在 全局会话存在，局部会话不必定存在 全局会话销毁，局部会话必须销毁

 

2.注销

单点登陆天然也要单点注销，在一个子系统中注销，全部子系统的会话都将被销毁

sso认证中心一直监听全局会话的状态，一旦全局会话销毁，监听器将通知全部注册系统执行注销操做

 

用户向系统1发起注销请求

系统1根据用户与系统1创建的会话id拿到令牌，向sso认证中心发起注销请求

sso认证中心校验令牌有效，销毁全局会话，同时取出全部用此令牌注册的系统地址

sso认证中心向全部注册系统发起注销请求

各注册系统接收sso认证中心的注销请求，销毁局部会话

sso认证中心引导用户至登陆页面

 

sso-client

1 2 3 4 5 6

拦截子系统未登陆用户请求，跳转至sso认证中心 接收并存储sso认证中心发送的令牌 与sso-server通讯，校验令牌的有效性 创建局部会话 拦截用户注销请求，向sso认证中心发送注销请求 接收sso认证中心发出的注销请求，销毁局部会话

　　sso-server

1 2 3 4 5 6 7

验证用户的登陆信息 建立全局会话 建立受权令牌 与sso-client通讯发送令牌 校验sso-client令牌有效性 系统注册 接收sso-client注销请求，注销全部会话