单点登陆

跨域：客户端请求的时候，请求的服务器，不是同一个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注销请求，注销所有会话