Metadata Driven Sparse ACL Test Generator
Publication Date: 2010-Nov-18
The IP.com Prior Art Database
The purpose of this article is to provide a metadata driven ACL test generator for any sparse ACL security model. The proposed solution will provide a generic and simpler ACL test generation and execution framework. The advantages of this metadata driven ACL test generation and execution framework are: · An object tree with required minimum authority check points set for the lowest ACL(in our example, the Resource level), which can be seen as a security check flow, is needed as an input · A simple algorithm, which can automatically generate the required minimum authority check points for the other ACLs based on the one for the lowest ACL · A full coverage for the security check flow can be automatically generated based on the required minimum authority check points for each ACL regardless of the logic in the security check flow. Means we do not set weight for any check points. · A trimming algorithm will be applied to greatly reduce the number of test cases for a full coverage · A simple rule to judge whether an operation should succeed or failed based on the security check flow · Improve the productivity of testing. A shorter time will be taken for a bigger coverage. If any change made to the security check flow, only minor changes made to the metadata, then regenerate and rerun the test cases. The metadata representation defines below things: · Each operation has one unique security check flow · Each security check flow has a different metadata representation · A metadata representation consists of a set of security check points, which stand for the minimum authorities required to accomplish the operation. · Each security check point is defined with a unique ID for target item, a unique user ID, required authority.
Page 01 of 8
Metadata Driven Sparse ACL Test Generator
To secure network resources in a protected object space, each object must be protected by security policy.
Inheritance of security authority
The object with an explicitly defined security authority is called a secure object in object tree. As opposed to, the object without an explicitly defined security authority is called a non-secure object. To protect the object space, each object must be protected by security authority that can be assigned in one of the following ways:
Use default security authority for entire configuration object tree
Define an explicit security authority on an object
Allow the non-secure object to inherit the security authority of the first secure object above it in object tree
Adopting an inherited security authority can greatly reduce the administration tasks for a security administrator. This section discusses the concepts of inherited security authority.
The power of security authority inheritance is based on the following principle:
Any object without an explicitly defined security authority inherits the authority of its nearest object with an explicitly defined security authority. The inheritance chain is broken when an object has an explicitly defined security authority.
Security authority inheritance simplifies the task of setting and maintaining access controls on a large protected object space. In a typical object space,
need to attach only a few security authorities at key locations to secure the entire space.
Security checking level (SCL
The security checking level is a special attribute available in Configured System Group (CSG). As mentioned earlier, it can be modified by only security administrator. The attribute is vital to improve the performance of checking authorization regarding the objects being accessed.
With the security authority inheritance, the non-secure object can inherit the security authority of first secure object above it in the configuration tree. It really provides the flexibility and greatly reduces the administration tasks for a security administrator. However, how efficient it performs really depends on how deep the object being accessed in the object tree is regarding the first preceding secure object. In other words, the more the depth is, the worse the performance is, because there exists possibility of checking a lot of non-secure objects prior to first preceding secure object. To solve the problem, the security checking level is introduced in Configured System Group level.
The power of security checking level is based on the following principles:
Value of security checking level attribute is the same as hierarchical object types in Defined View, that is, Configured System Group, Configured System, Resource Group and Resource.
Page 02 of 8
Value of security checking level indicates the start point of checking authorization regarding the object being accessed in the tree.
Any object lower than that hierarchical...