关于单点登录、门户、统⼀权限控制的⼀些理解
. 前⾔
⽬前在做门户，有很多不明⽩的地⽅，经过思考和讨论，⼤致梳理出了⼀个基本的思路。
2. 单点登录
单点登录⽤于多个系统之间的统⼀认证，做到“登陆⼀次，随意通⾏”。单点登录和门户没有必然联系，单点登录组件⽐如CAS只管认证，不管其他的。
问题：若⼲个系统只⽤⼀份⽤户表，那么每个系统⾥⾯没有维护⽤户信息，怎么去维护各⾃系统的权限，⾓⾊，组织机构等关系呢？
⽅案⼀
每个系统都维护⼀份⽤户表，和单点登录的⽤户表保持同步，然后每个系统使⽤⾃⼰的⽤户表来维护⽤户和权限，⾓⾊，组织机构等的关系。
这种⽅式的关键在于⽤什么⼿段保持同步：
在数据库层⾯同步⽤户信息
可以在单点登录⽤户表中创建触发器，在添加、修改、删除的时候同时编辑各个⼦系统的⽤户表还有其他的⽤户关联信息。
这种办法简单好⽤，但是要求各个系统的数据库在同⼀台机器上或者可以提供DBLink之类的连接，缺点是不利于扩展，⽐如⼦系统更换了数据库类型就歇菜了。
在应⽤层⾯同步⽤户信息
各个系统提供维护⽤户信息的WebService接⼝或者API，在维护单点登录⽤户的时候调⽤各⼦系统的接⼝实现系统间的同步
这种⽅式的缺点是：
将同步的操作写在代码中，可能会经常改动代码。
可能会因为接⼝服务宕掉或者其他原因并不能保证各系统之间数据的完全⼀致，最后还是需要⼈⼯参与。
⽅案⼆
抽离出公共的权限模块，⽤来统⼀管理⽤户、⾓⾊、权限、机构等信息。
这个就有点类似于门户的功能了，把这些资源都抽离成⼀个⽗模块统⼀管理，各个⼦系统不需要维护这些关系，⾃然也就不需要同步了。
⽗模块需要提供⽅案供各个⼦模块获取权限、⾓⾊、机构等信息。
3. 门户
门户的概念可⼤可⼩，基本包含如下⼏点：
单点登录
统⼀权限管理
⽇志管理
各系统功能的整合
3.1. 单点登录
门户提供单点登录功能。
3.2. 统⼀权限管理
问题⼀：门户既然统⼀管理权限，各个⼦系统怎么获取⾃⼰需要的权限信息呢？
⽅案⼀：
门户提供Webservice查询接⼝供各个⼦系统调⽤。
这种⽅式性能不太好。
⽅案⼆：
门户提供API（jar包）查询接⼝供各个⼦系统调⽤。
这种⽅式不错，提供Maven依赖也可以⽐较⽅便的更新。
⽅案三：
使⽤Redis保存⽤户信息和权限信息，各个⼦系统和门户都从Redis⾥⾯取信息，从⽽做到Session信息共享。
这种⽅式适合多系统之间Session共享，需要单独的Redis服务器。
问题⼆：⼦系统中有⼀些资源需要授权，但是这些资源门户中很难维护怎么办？
有些数据量很⼤（⽐如数据库的元数据信息）；有些资源变动特别频繁（⽐如⽂件资源）；有些资源权限控制复杂（⽐如需要控制访问范围、读写权限，类似于LInux⽂件）；甚⾄有⼀些资源是需要动态获取的，根本⽆法固化到数据库中。
以上这些资源是很难再门户中维护的。
⽅案⼀
⼦系统同步门户的⽤户、部门等表，具体办法参考上⽂。
⽅案⼆
门户提供⽤户列表、部门列表等信息的查询接⼝或者API供⼦系统调⽤，⼦系统授权的时候从接⼝或者API中获取这些信息，然后⽤来授权建⽴关联信息。这种⽅式只是理论上可⾏，但是肯定⾮常复杂繁琐。
缺点：
开发很困难
不安全
权限管理复杂，有些⽤户有只A系统的权限，没有B系统的权限，那么⽤户A需要只能获取到有本系统权限的⽤户。
3.3. ⽇志管理
⽇志分为两种：访问⽇志和操作⽇志。
shiro权限控制3.3.1. 访问⽇志
如果访问的是门户中的资源，那么门户直接记录访问⽇志。
如果访问的是⼦系统中的资源，需要⼦系统调⽤门户提供的访问⽇志接⼝或者API来记录访问⽇志。
3.3.2. 操作⽇志
如果是门户本⾝的操作，⽐如⽤户信息的维护，资源的注册和删除等，这些操作⽇志由门户直接记录。
其他设计具体⼦系统业务的操作，由⼦系统调⽤门户提供的接⼝或者API记录操作⽇志。
3.4. 各系统功能整合
门户整合⼦系统根据实际情况有很多种⽅式。
完全整合
完全控制⼦系统的各种资源的管理和授权，甚⾄可以将⼦系统的功能嵌⼊到门户中。
控制权限、提供单点登录
完全控制⼦系统的各种资源的管理和授权，提供单点登录功能，以门户作为⼊⼝访问各个⼦系统。
只提供单点登录
只提供单点登录，⼦系统同步⽤户机构等表，⾃⼰控制权限。
仅整合⼊⼝
仅整合⼊⼝，伪单点登录。
问题⼀：⼦系统不想改造，只想简单嵌⼊到门户中怎么办？
实际⼯作中因为门户需要整合其他系统，可能会遇到各种各种的问题或者阻⼒，⽐如已经上线运⾏的系统要整合到门户中，进⾏单点登录、权限等改造是很耗费时间的，尤其是客户不掏钱的情况下⼚商是肯定不想改的。
这种情况可以做⼀种伪单点登录，⼦系统基本不⽤怎么改动即可。
解决⽅案：
1. 这种情况门户中只能维护⼀个⼦系统的⼊⼝，其他的权限、⽤户等等都不⽤管，⽤户点击⼊⼝链接时，门户打开新窗⼝调⽤⼦系统的登录页⾯，将⽤户名密码等信息传过去。
2. ⼦系统的逻辑也基本不⽤修改，判断⽤户名密码是否正确就可以，出于安全考虑链接和请求信息⼀般会加密，所以⼦系统⼀般需要对信息进⾏解密在校验。
3. ⼦系统的⽤户表需要从门户的⽤户表中同步，注意只需要同步有登陆该系统权限的⽤户。
4. ⼦系统开发⼀个没有访问权限的页⾯，如果登录验证失败，就返回这个⽆权限页⾯。
问题⼆：关于原本使⽤Shiro控制权限的系统如何作为⼦系统接⼊门户？
Shiro原本控制权限使⽤的是⼀个唯⼀的字符串也就是权限标识来控制⽤户的权限的，这个字符串⼀般是唯⼀的，可读性好的，有⼀定业务含义的。
但是门户控制权限不⼤可能为使⽤Shiro的⼦系统去维护这样的字符串。
所以⼦系统可以维护⼀个资源ID和权限标识的映射关系表，获取到拥有权限的资源ID集合以后再映射成权限标识的集合提供给Shiro。
注意：
其实不只是Shiro，各个⼦系统都可能存在这个问题，就是门户的资源ID和系统的资源ID是不⼀致的，都可以⽤这种思路解决。
4. 声明
我对这⽅⾯的理解实在有限，本⽂说的也肯定有不全⾯或者不对的地⽅，也许有更好的⽅案，希望有⼤神看到指点⼀⼆，谢谢！

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。