关于统一身份认证的思考

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

关于部门编码,我也是有个疑惑,两个领导的部门到底如何编码合理,单根的树下去我觉得很不错,但对于比如市气象局,到底父代码作为省气象局还是市政府?
posted @ 2009-07-24 10:55  我想我是风  阅读(2665)  评论(19编辑  收藏  举报