打算写这篇博客开始就在想,为什么要存在权限系统,不开发它不行吗,它的存在能为我们带来什么?
还记得第一次敲“机房收费系统”的时候吗,那个时候有三种用户一般管理员、操作员、管理员。不同的用户看的页面不同,他们所拥有的操作就不同。这样说来我们在很早以前就开始进行了权限的设置,所以今天为大家讲解权限问题应该是很容易被理解的。
权限的作用:
1是为了让用户各司其职,只要管理好自己的一亩三分地就可以了。
2它更是一种安全策略。用户可以访问而且只能访问自己被授权的资源。
用户登录后,判断用户是否存在,如果存在查询用户所具有的权限,根据用户的权限做出不同的显示。
权限系统的具体操作,添加资源即权限后,可以将权限赋值给角色,将这个角色直接赋予了用户,当用户登录的时候,就可以根据角色的权限展示了。这种方式是基于角色的访问控制。而我们这次要做的权限系统时既要基于角色又要基于权限,它的意思是用户可以通过通过中间的角色来获得权限,也可以直接将某项或某几项权限赋给用户。
对于在企业环境中的访问控制方法,一般有三种:
1.自主型访问控制方法(DAC/授权Authorization)。目前在我国的大多数的信息系统中的访问控制模块中基本是借助于自主型访问控制方法中的访问控制列表(ACLs)。使用自主访问控制机制,一个用户可以自主地说明其资源允许系统中哪些用户以何种权限进行共享。
2.强制型访问控制方法(多级安全/MultilevelSecurity)。用于多层次安全级别的军事应用。在强制型访问控制方法中,用户和资源都是被赋予了固定的安全属性,在每次访问发生时,检测安全属性以便确定用户是否具有权访问该资源。
3.基于角色的访问控制方法(RBAC-Role-BasedAccess Control)。是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是:
(1)减小授权管理的复杂性,降低管理开销。
(2)灵活地支持企业的安全策略,并对企业的变化有很大的伸缩性。
资源:其实就是权限,系统的所有权限信息。权限的资源包括系统、模块、页面和操作。权限具有上下级关系,是一个树状的结构。用户有没有这项操作,用户能不能看到这个页面,用户 能不能具有这个模块。用户所拥有的客体就是资源。这些讲的都是功能权限,还有一种数据权限。
角色:角色就是一组资源。其实他就是对资源的一次整合,为了满足业务需求,将这些资源整合成各种角色。
用户:应用系统的具体操作者,用户可以自己拥有权限信息,可以归属于0~n个角色,可属于0~n个组。他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。
组织:为了更好地管理用户,对用户进行分组归类,简称为用户分组。组也具有上下级关系,可以形成树状视图。组也可以具有自己的角色信息、权限信息。
授权:将资源的权限分配给用户,或将角色分配给用户。这样用户就具有权限。
1功能权限与数据权限不明确:
在需求分析的初期,大家对目前开发的权限功能实现不够明确,导致了一些理解上的偏差。目前的设计的权限系统是在功能权限的基础之上的,基本没有涉及到数据权限的范围。但是各个系统都是在数据权限才能够达到的高度进行讨论,导致了权限和子系统理解的不一致。讨论过后,明确职责。
一直想找一本关于权限的书看看,但是最后没有找到,只能是通过一些博客和文档来丰富自己关于权限方面的了解。在了解一个知识之前先不要关注与细节,不要关注于它怎么实现的,先跳出了看看,以一个局外之人的身份去审视它,会看到它的全面。