关于单点登录、门户、统一权限控制的一些理解

 前言

目前在做门户，有很多不明白的地方，经过思考和讨论，大致梳理出了一个基本的思路。

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. 日志管理

日志分为两种：访问日志和操作日志。

3.3.1. 访问日志

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

3.3.2. 操作日志

• 如果是门户本身的操作，比如用户信息的维护，资源的注册和删除等，这些操作日志由门户直接记录。
• 其他设计具体子系统业务的操作，由子系统调用门户提供的接口或者API记录操作日志。

3.4. 各系统功能整合

门户整合子系统根据实际情况有很多种方式。

• 完全整合
  完全控制子系统的各种资源的管理和授权，甚至可以将子系统的功能嵌入到门户中。
• 控制权限、提供单点登录
  完全控制子系统的各种资源的管理和授权，提供单点登录功能，以门户作为入口访问各个子系统。
• 只提供单点登录
  只提供单点登录，子系统同步用户机构等表，自己控制权限。
• 仅整合入口
  仅整合入口，伪单点登录。

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

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

问题二：关于原本使用Shiro控制权限的系统如何作为子系统接入门户？

Shiro原本控制权限使用的是一个唯一的字符串也就是权限标识来控制用户的权限的，这个字符串一般是唯一的，可读性好的，有一定业务含义的。
但是门户控制权限不大可能为使用Shiro的子系统去维护这样的字符串。
所以子系统可以维护一个资源ID和权限标识的映射关系表，获取到拥有权限的资源ID集合以后再映射成权限标识的集合提供给Shiro。
注意：
其实不只是Shiro，各个子系统都可能存在这个问题，就是门户的资源ID和系统的资源ID是不一致的，都可以用这种思路解决。

4. 声明

我对这方面的理解实在有限，本文说的也肯定有不全面或者不对的地方，也许有更好的方案，希望有大神看到指点一二，谢谢！