Understanding security inheritance

Inheritable depth (Apply to)

Each ACE has an inheritable depth setting that is invoked if the ACE is configured to be inherited by a child object. The inheritable depths are:

This object only

This ACE would not be inherited even if it were configured for inheritance.

This object and immediate children

This ACE applies to the object and would be inherited by the parent object's children, but not by the child object's children. After inheritance takes place, the child ACE will have an inheritable depth of This object only.

This object and all children

This ACE applies to the object and would be inherited by every generation of the parent object's child objects. After inheritance takes place, the child object's ACE will have an inheritable depth of This object and all children.

All children, but not this object

This ACE would be inherited by every generation of the parent object's child objects, but does not affect the parent object itself.

Immediate children, but not this object

This ACE would be inherited only by the parent object's immediate children, but not by further generations, and does not affect the parent object itself.

The Administration Console for Content Platform Engine security editor lets you set inheritable depth. See Configure inheritable depth for more information.

Security Folder, Security Proxy Type

You can configure the relationship between a parent and child object in several ways.

Security Folder

A Security Folder is a folder from which an object inherits security, but there is no requirement that its security children be filed in the folder. You can see the Security Folder property on all documents and custom objects: in Administration Console for Content Platform Engine, select the document or custom object, select Properties, then scroll down the list of properties.

Security Proxy Type

Content Platform Engine provides extensible security parent relationships by means of the Security Proxy Type property placed on the metadata of custom object-valued properties. This property would be added to a security child's class and the values set into it establish that child's security parent. You can add this property to any class of objects as required by your security design. An object can have many such Security Proxy Type properties, that is, many security parents with the inherited ACEs from each being merged together and contributing with equal priority to the access check that produces the final security mask.

You can apply the Security Proxy Type property to objects other than folders. For example, you could add a Security Proxy Type = Inherited property to the class of a document and then later set that property in the document (the security child) to a custom object (the security parent). You can see the Security Proxy property on all objects: in Administration Console for Content Platform Engine, select the object, then click the Properties tab and scroll down the list of properties.

If a security proxy object is marked for deletion (which places it in the Recovery Bin), the server continues to allow for the security proxy's permissions to be inherited by the child object. For example, if DocA is a security proxy for DocB and DocA is marked for deletion, then DocB continues to inherit its security from DocA, even though DocA cannot be queried or retrieved by users with typical access rights. Only users with the VIEW_RECOVERABLE_OBJECTS permission on the object store can access DocA. Although objects marked for deletion are not viewable by most users, the objects exist in the object store database, and they are potentially recoverable. Therefore, the server maintains the inherited security from security proxy objects that are recoverable. This behavior can result in an inheriting object granting more permissions than would be expected from inspection by someone without VIEW_RECOVERABLE_OBJECTS permission, potentially causing confusion, or, in unusual circumstances, being counter to the intention of marking the proxy object for deletion. To avoid these potential issues, it is recommended that objects whose primary purpose is to act as a security proxy not be marked for deletion. If the intent is to terminate the proxy relationship, a delete should be used instead.

Configuring inheritance

For configuring inheritance on documents and custom objects, see Configure a document's security parent and Configure a folder to be a security parent.

Folders have an Inherit parent permissions property on the General tab of their property sheets in Administration Console for Content Platform Engine. This check box governs inheritance between folders. When you select it, the folder will inherit permissions from its parent folder if the parent folder has inheritable permissions. Changing the property from True to False removes any ACEs that were formerly inherited from the parent folder.

Subclassed permissions are copied, not inherited

When you make a new subclass from a class definition, some permissions are passed from the parent class definition to the new child class definition in a manner that is not inheritance. When you make a new subclass, those permissions of the originating class definition that have a Source type of Default or Direct and are of inheritable depth This object only are exactly copied to the new subclass with a source of Default and no change in inheritable depth.

During subclassing, the child class receives the ACEs of its parent as described in the following table. Notice that Default permissions with inheritable depth of This object only are not inherited by the child; rather they are copied without change and are therefore modifiable on the child object.

Summary of security sources

The following table summarizes how objects receive initial security. Security inheritance takes place only if the source class or object has inheritable permissions: