Implementation of dynamic Proxy and Java ACL User Access control mechanism

The user access control mechanism is always discussed in terms of coarse-grained and fine-grained two aspects:

Coarse-grained control: You can provide access to a layer of an entire object or group of objects, while fine-grained control is always controlled at the method or property layer, such as:

Allowing a file to be read-only is coarse-grained control, and allowing write operations on a particular line of the file is fine-grained.

A good user control mechanism, of course, allows fine-grained control as well as coarse granularity, in jive we see Using proxy for this purpose, but we also find that because of the need for fine-grained control of each class, it is necessary to make a proxy class for each class, This brings a lot of proxy classes, such as Forumproxy Forumthreadproxy Forumfactoryproxy, and intangible increases the complexity of the system.

Using dynamic proxy can be a good solution to this problem. Combined with the ACL mechanism of JAVA.SECURITY.ACL, we can realize the double control of coarse granularity and fine granularity flexibly.

When a user login, we have to set up in memory for the corresponding authorization to access the mechanism, the use of Java.security.acl can be very convenient to establish such a security system.

First, any object should have a basic attribute: A group owned or owned (each directory security descriptor in Windows consists of 4 parts: the creator of the object, the group to which the object belongs, free access control, and system access control).

1. Java ACL First step is to establish a subject Principal, where Securityowner is the owner of the subject: private static final Principal _securityowner = new Principalim PL ("Securityowner");

2. When the user login in, he comes with two basic data: access to the password and the object applicationname he wants to access. First verify the username and password, then remove its permission data from the database, establish permission, use feature to inherit permission, and define the details of the permissions in feature (such as read-write deletion).

Remove the permission relationship between the user and the object being accessed, which may be more than one, i.e., the user

It is possible to have multiple permissions on the accessed object, including read-write deletion, and package it in the hasbtable.

Hashtable features = Loadfeaturesforuser (Sapplicationname, sUserID);

3. Create a User Object

User user = new Userimpl (sUserID, New Hashtable ());

4. Create an active ACL entry for this user

Addaclentry (user, features);

The most critical of these is the fourth step addaclentry, and let's see how it is implemented:

// 为这个用户创建一个新的Acl entry
AclEntry newAclEntry = new AclEntryImpl( user);
　　 //遍历Hashtable features，将其中多种权限加入:
....
feature = (Feature) hFeatures.get(keyName);
newAclEntry.addPermission( feature );
....

Finally, we must join the principal owner Securityowner

Such a security system is already in place.

When you are in the system to verify that a user has access to a certain permission, such as the right to read, as long as

Acl.checkpermission (user, feature), the ACL is an instance of the ACL, so the permission check is given to the

Java.security.acl.ACL to deal with it.