Security Indexes

To check access to an object, an index is created. The index is the result of preprocessing the access rules for objects with similar characteristics (owner, organization, project, policy, state, and so on). The index is stored in the database (or 3DSpace Index), and queries perform a 'join' against this table with data that comes from the active user context.

The security index is limited to the computation of show access (the security attribute that allows objects to be visible in query results and also allows query results to be included in facets).

Each entry in the index is called an accesslist that is managed like any other administration object. When an access query is received for an object, the system matches the rows in the accesslist with the rows derived from the user context. If a match is found, access is granted.

The security index is based on the ownership vector (OV).

Each OV comprises an access rule (policy state) and a list of organization/project combinations (ownerships). Each business object has two OVs:

• One that describes security for the object's direct ownership (its directly-assigned organization and project)
• One for the OV that describes security granted by way of additional multiple ownerships or inherited ownerships. For more information, see Ownership.

This sharing minimizes the amount of security data that needs to be computed and managed. It also minimizes the amount of data that needs to be transferred to other servers, such as the 3DSpace Index.

OVs contain the base properties of the security index, including:

• Rule. The access rule for which it was created
• Owner. The object owner for which it was created
• RefCnt. The number of objects referencing this OV
• Valid flag. Indicates whether the compiled view of this OV is up to date
• Obsolete flag. indicates whether the OV definition is up to date

OVs are administration objects and can be manipulated as such on the MQL command line. The MQL noun for OV is accesslist (for example, print accesslist, list accesslist, and so on). For more information, see MQL Commands for Accesslists.

The owner field in the OV table refers to the business object owner for which the OV was first created. If the OV access rule grants show access based on any owner (or revoke owner), then the OV is dependent on the owner field just like the rule field. Such an OV cannot be shared by objects that contain a different owner field. This means that the number of OVs that must be maintained in not the product of the number of access rules and the number of unique owner lists, which is a much larger number. The system is designed to handle this, and this is still better than storing an access list with each object. If an application developer has a choice in granting show access to owner, choosing not to do this will result in a measurable improvement in performance, capacity, and scalability.

Ownership vectors are validated for every business object when an object's OV fields (Direct Ownership Vector or DOV, and Inherited Ownership Vector or IOV) are interrogated. The DOV and IOV are examined to see whether they reference a valid OV. If not, a new OV is either constructed or reused from another object in the same state. The act of selecting a DOV/IOV results in a valid DOV/IOV being constructed.

During use of the system, some OV information could become invalid. For example, when an object is promoted its state changes, so it can no longer use the same OV in subsequent operations. When this happens, the object's DOV/IOV fields are invalidated, and remain so until the next select of DOV/IOV. Evaluation of security attributes is always on an as-needed basis to avoid any performance or concurrency risk of managing security attributes on a real-time, transactional basis.

This table lists the transactions that impact the state of the security index:

Event	Action
Delete access rule	Mark all OVs referencing this rule as obsolete.
Delete user	Mark all OVs referencing this owner as obsolete.
Promote/demote	Set object DOV/IOV as invalid.
Set owner	Set object DOV/IOV as invalid.
Set organization/project	Set object DOV as invalid.
Add/remove ownership	Set object IOV as invalid.
Change relationship access rule	Mark all OVs using the previous access rule as obsolete.
Add/remove user assignment	Invalidate any OVs dependent on this user, its assignments, or its assignments' relations.
Change user hierarchy	Invalidate any OVs dependent on this user or its relations.
Edit access rule	Invalidate all OVs for this access rule (mark obsolete if the rule starts/ends granting of show access by owner).
Add role	Invalidate all OVs that grant show access by public.

None of the above events actually recalculates any security attributes. When these events occur, the minimal dataset is marked as either invalid or obsolete, and is not recalculated until the next select of DOV/IOV (presumably the next index time).

Updates to the security index are made asynchronously with respect to any data/model changes that make updates necessary. Typically the 3DSpace Index indexer runs as a background process to update the security index.

You could run the following MQL commands at night to update security attributes for everything that had changed during the day:

temp query bus * * * select dov iov dump | output <FILENAME1>;
query connection type * select dov iov dump | output <FILENAME2>;

This command produces a list of all ownership vectors (OVs) that have changed during the day:

list accesslist modified after DATE;

To implement a connector to 3DSpace that wanted to consume the security index attributes, potentially creating a replica of the index within another system, you can use additional selectables on either the temp query or list accessrule command to retrieve this information. For example:

print accessrule <0x19cc67c2> select access.pass;
    access.pass[LOGINROLE|ASSIGNMENT] = [No|Yes|MaybeNo|MaybeYes]