A very deep discussion of the rights control (2)

Control 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,
It's called purchasing department news. Because we decided at the time of design that the feature could only be accessed by the Manager,
As a result, the decision section of the permissions in the system first determines whether the current user (UserA) is the Manager role, and yes, it allows
Access, otherwise no authorization error message is displayed.

So, for a Manager such an application:
[1] In the design, we will have such a role with the corresponding Permissions (A list of subject-operation pairs)
Linked together, here's Subject is all news instances (news_instance), Operation
is Create,modify and Delete.
[2] At the time of authorization, the Super Admin (Administrator) can use Assign_role_operation to place the user
Associate with the Manager role. In this way, User has the Create, Modify, and Delete for all news instances
The permissions for the operation.
[3] at the discretion of the authority, the RBAC system first determines whether the current user is the design-time defined role (here is the manager),
If so, the user is allowed access, otherwise the access is denied and an error message is displayed.


There are a few different roles for publisher, the role of Publisher is only tied to Operation, and there is no
The specific Subject is associated, so you need to specify the corresponding Subject at the time of authorization.

So, for Publisher, you can only identify Operation applications in advance:
[1] At design time, we can only determine what the role can do, but not the objects that these operations implement.
[2] At the time of authorization:
[2.1] First associate publisher with the Subject, such as associating publisher with the purchasing department news:
The role of the purchasing department news _news_publisher
The [2.2] Administrator grants the purchasing department News _news_publisher role for users (user). Thereby User
has permission to publish for "purchasing Department News"
[3] When the authority judge, the user visits the purchasing department news _news_publish_operation, the system first judges
Is the user purchasing department news _news_publisher? If so, the user is allowed access, otherwise the access is denied.
and displays an error message.
The method used here might look like this:
Boolean checkpermission (Procurement Department News, Publish_operation,user) {
List Publishers = Rbac.findrole (new Permission (Procurement Department News, Publish_operation));
if (publishers==null) return false;
for (Iterator it = publishers.iterator it.hasnext ();) {
Role publisher = (publisher) It.next ();
if (Publisher.isassignedwithuser (User)) {
return ture;
}
}
return false;
}

If you say, do not adopt RBAC, consider, use ACL, what will it be like?
For the Manager to be able to determine the roles of Subject and Operation at design time, I don't think it's necessary to consider ACLs.
For Publisher, you can only determine the role of Operation in advance, so let's make a comparison.
The privilege system should be flexible, but it should be concise, otherwise it is likely to lead to runaway. Because there are too many levels of nesting, it is possible to
Predictable situation. One day the administrator may be Mo Ming's discovery, how this person will have this authority?
Therefore, I think it is better to not support the hierarchical relationship of role in RBAC.

Okay, now let's see. ACL application to Publisher
The ACL here refers to the practice of directly associating User or Group with Subject.
The User and the Subject are more than a few cases,
Group and Subject are also more than the case,
Similarly, User and Group are more or less the case.

Now, take the procurement department news as an example:
[1] At the time of authorization, the following actions may be available:
[1.1] Associates the User with the Subject, but specifies the corresponding Operation.
such as: assignpermission (Purchasing department news, Publish_operation,user)
[1.2] Associates a Group with a Subject:
such as: assignpermission (Purchasing department news, Publish_operation,group)
[1.3] Associates User with Group
Such as:
Assignusergroup (User,group)

[2] When the authority judge, the user visits the purchasing department news _news_publish_operation, the system does the following inspection:
Boolean checkpermission (Procurement Department News, Publish_operation,user) {
Boolean haspermission = false;
Users include:
1. Permission Direct assigned Users
2. The user assigned with the groups, assigned with permission
List users = getassignedusers (new Permission (purchasing department news, Publish_operation));
Haspermission=users.contains (User) True:false;
}

Re: I would also ask a question about the design of the rights issue time: October 26, 2003 22:32:43 reply

Published by: Greatewei published article: 3/From: Ningbo/Registration Time: 2003-07
Have seen ofbiz about the rights of the design of relevant information, feeling ofbiz in the implementation of a great versatility. After reading, always feel that their understanding is not thorough enough, I hope we can explain in detail, thank you.


Published by: Supermy published article: 21/Registration Time: 2002-10
You can try tiles, it should be very simple. User permissions must be written to death in the configuration file.



Re: I would also ask a question about the design of the rights issue time: October 29, 2003 23:26:09 reply