关于统一身份认证的思考

部门要上统一身份认证，统一门户，统一数据库的所谓数字化某某某的东西，可设计的理念和我想的相距甚远
关于统一身份认证的做法，公司是这样做的，逻辑还是相对比较简单的
一个统一认证的点，可以根据用户名和密码返回真或假，用户角色是各系统独立自行判断，可以根据用户名得到用户的更进一步信息，包括所属部门信息，用户只有实体用户，没有虚的岗位用户，都自行由角色去整合。
=============
作为开发人员，我觉得存在很多问题，我的统一身份认证的想法是可以有部分的角色功能，简化各系统的开发
统一认证包括用户，角色，所属部门，分别处理谁，能干什么，能干那些。根据用户名密码能得到角色和所属部门。
1、用户有统一数据库里的实体用户，也要有虚的岗位用户，这些岗位用户由各应用系统申请建立，有些共性的岗位用户可以相互共享。（公司认为虚的岗位用户更难管理，可以通过角色给实体用户已岗位用户的角色，我是认为这样会公私不分的，一个用户登录邮箱，既有自己的私人邮件，又有办公邮件，似乎是件更麻烦的事，人员调动还有修改角色，也是很麻烦。）
2、角色是用户的集合，用户权限的设置都应该放在角色上，系统应该能够返回基本的角色信息，便于简单系统可以免自行设置角色的麻烦，比如在学校，登录后能返回“教师”或者“学生”，虚的岗位用户可以在加入的时候直接设置角色名称。
3、部门是最基础的数据，分级处理，00，0001，0002这样，0001是00的下级部门，用户根据用户的登录情况，进行信息的分类和过滤显示，而不能直接在上面做权限的设置。部门应该比较稳定，应该根据实际存在的情况进行分类（公司按照公章分类，而公章是有大量同一套人，两个公章的概念的，行政和党委很多时候是一个人，而且外面的同级有联系的部门，或者上级部门，直接用“其他类”来表示），部门作为基础数据，应该是可以不通过电脑直接读的，用字母表示应该更好，就像域名cn中国，tw台湾等，但国际区号我就不知道也很难记住了，而且如果给各部门建文件夹，做Logo等情况，用字母表示的代码一眼就知道是那个部门（公司却认为字母会重叠，数字好，他们倒是有业务构件系统，但数字化不是仅仅建立在他这个公司上面的呀，而且还把排序的功能赋给了部门，根据数字的大小排序，中间留空，备部门添加的时候插入用。我是认为部门不应该有排序信息，排序由各应用系统根据另外的文件规定自行排序）

关于部门编码，我也是有个疑惑，两个领导的部门到底如何编码合理，单根的树下去我觉得很不错，但对于比如市气象局，到底父代码作为省气象局还是市政府？

转载于:https://www.cnblogs.com/tltgg/archive/2009/07/24/1529990.html