A very deep discussion of the rights control (2)

Re: I would also ask a question about the design of the rights issue time: October 24, 2003 16:24:18 reply
Published by: Littlebird published article: 1/Registration time: 2003-10
It is a great benefit to read so many discussions about authority.
Here's what I think about:
I think for most enterprise application projects, relatively not very large projects, the Rights Management Section can be simplified into: User *-->1 role 1-->* operate
The user may have many organizational hierarchies, but it can be flattened here, regardless of the level directly related to the role, and there is only one role
Permissions may also have a number of hierarchical relationships (for example, News includes a, B, or C department), which is also expanded to allow the role to be directly related to the lowest level of authority (such as a departmental news modification authority)
The user obtains its role, and then it obtains a collection of permissions based on the role.
A group is a collection of users, adding it can become quite complex, and of course having the concept of a set of permissions added, which is even more complicated.
Re: I would also ask a question about the design of the rights issue time: October 25, 2003 11:07:20 reply
Published by: Iceant published article: 413/Registration Time: 2002-10
I want to take a look at the difference between ACL and RBAC:
Or the Department of the news to discuss, for static authorization, in the system design to do needs analysis, often can
Identify the kind of system role, like a news system, where, depending on your needs, there may be news Publishers (publisher),
News Reviewer (Reviewer), News Viewer (Visitor), Administrator (Manager), and Super Administrator (the Administrator).
At the time of design we also have to bind these roles with some of the corresponding Operation.
For example, Publisher has publish_operation + modify_operation
Reviewer owns Review_operation + modify_operation + delete_operation
Visitor owns Visit_operation,
Manager owns Create_news_system_instance_operation +
Modify_news_system_instance_operation +
Delete_news_system_instance_operation
The Administrator is responsible for create_user_operation+
delete_user_operation+
assign_permission_operation+
Deassign_permission_operation +
assign_role_operation+
Deassign_role_operation
At the time of authorization, a user is often given a role, such as Manager. This way, USER will
has permission to operate on all news_instance (that is, departmental news).
Now assume that the user (UserA) accesses the Create_news_system_instance feature to create a new news instance,