This topic explains what markings are and how they affect the effective security on objects. Primarily designed for use by the FileNet P8 Records Manager application, markings are available to any application that needs the kind of property-based layer of security that markings provide.
See Content Engine Help for information on how to use Enterprise Manager to administer markings and marking sets.
Markings allow access to objects to be controlled based on specific property values. When a marking is applied to an object, the resulting access permissions for the object are a combination of the settings of its original access permissions and the settings of the marking's Constraint Mask for each marking that is applied to it. The result of this combination is the effective security mask.
In general terms the way the markings works is:
Markings do not replace conventional access permissions on an object, but rather are co-equal with them in determining access rights. In other words, if an object has one or more markings applied to it in addition to one or more permissions in its permissions collection (ACL), then access to that object is only granted if it is granted by the permissions and by the markings. Another way to think about how this works is:
You can have multiple properties assigned to a single class with marking sets associated, and they will all be used to determine the final access to the object. The collection of all markings being actually applied to a particular object is displayed by the Enterprise Manager as the object's "active markings" (see below).
The number or size of markings in a single marking set is limited by available system memory. To perform an access check on a marked object, the entire marking set and all its markings must be loaded into memory. This is not going to work if there are millions of markings. For this reason, FileNet recommends that you limit the number of markings in a marking set to no more than 100.
Another limiting factor would be one that occurs with any UI attempting to display extremely long lists of choices, but this kind of application design problem is not inherent to markings.
Marking security consists of the following permissions:
A user with Add rights to a marking can set the property value associated with the marking, if it has not been set. Only those markings to which the user has Add rights will show in the list of marking values available to be set in a property. A user with Remove rights to a marking can remove the marking value.
For example:
Use right determines whether the presence of the marking on an object constrains access to that object. If the user has Use right to the marking, access to the object will not be constrained.
In this example, Alice has the Use Marked Objects access right which lets her bypass the marking. Her access to the object will be evaluated by the object's ACL. Bob does not have Use Marked Objects and therefore will neither see nor have access to the object, regardless of any permissions the object's ACL might grant him.
Markings and marking sets are Content Engine objects, each with a class description:
If the string property containing a marking has kept the default Copy to Reservation setting of True, then a user who has Use Marked Objects but does not have the Add Marking permission will not be able to check out a document, even if the user has Full Control of the document itself.
This is by design, since to checkout a document creates a new Reservation document which must have the marking on it due to its property's Copy to Reservation value of True. This requires the marking to be "Added" to the new document, and since the user in this scenario does not have the Add Marking permission, the checkout will be prevented.
By default, all the rights are checked, meaning all constraints are masked and only those that have the Use Marked Objects access rights on the marking will be able to view and access the object.
When one of the rights in the constraint mask is unchecked, it indicates that users with this privilege on that object are allowed through the marking restriction even if they do not have the Use Marked Objects access right on the marking. In this way, the constraint mask can be used to design more granular control at the marking level.
Here are some examples to illustrate the security behavior of the constraint mask:
In this graphic:
Each access control entry listed on a marking value's security page is marked either Allow or Deny.
Allow is the default setting for each new security added to a marking's security list. It is also the most common way to set up marking security behavior. Unless clearly stated, this topic describes Allow security types.
Typically markings are used to determine who will be denied access to evaluate the security rights of the object. Users who have the Use Marked Objects access right will not be limited by the constraint mask of the marking. However, an administrator may set up deny rights on the marking which will override any allow access otherwise granted to the marking. For example:
In this scenario:
See the next section for how the Allow and Deny permissions are applied to hierarchical marking sets.
There are two types of marking sets: hierarchical and non-hierarchical:
In the following, the user Alice has been granted the Use Marked Objects right by the Top Secret marking. Since this is a hierarchical marking set, the effect of this is that she not only has the Use Marked Objects right for the Top Secret marking, she also implicitly has it for the Secret and the Restricted markings as well. This means that for Alice, objects that are marked with either the Restricted or Secret markings behave as if they are marked with the Top Secret marking. Similarly, Bob has implicit Use Marked Objects right to the Restricted marking, because it is lower in the hierarchy than Secret.
There is an exception to the rule that permissions granted on superior markings are implicitly granted on inferior markings. Recall that there are two types of access permissions:
Deny permissions always take precedence over allow permissions. The way this works for hierarchical marking sets is that deny permissions on inferior markings always take precedence over allow permissions on superior markings. This behavior is illustrated in the example below:
In this example Bob is implicitly granted access to objects marked Secret or Restricted as well as being explicitly granted access to objects marked Top Secret due to the fact that he is granted the Use Marked Objects access right on the Top Secret marking which is superior to both Secret and Restricted.
Alice, on the other hand, is denied access to objects marked Top Secret or Secret but is granted access to objects marked Restricted. The reason for the difference is that Alice is explicitly denied the Use Marked Objects right by the Secret marking. Since Deny permissions are implicitly present on all superior markings, it is implicitly present on the Top Secret marking. She is also explicitly allowed access by the Top Secret marking, but since Deny permissions take precedence over Allow permissions, she is still denied access to objects marked with Top Secret. What may be less clear is why she is granted access to objects marked with Restricted.
The reason is because she implicitly obtains access rights to objects marked Restricted by being granted Use Marked Objects rights by the Top Secret marking which is superior to Restricted. The Deny permission on the Secret marking has no affect on the Restricted marking because the Restricted marking is inferior to the Secret marking.
From this example three general rules can be observed:
Markings and marking sets are persisted in the FileNet P8 domain resource, the GCD. This gives them FileNet P8 domain-wide scope, that is, they are available and have the same meaning across all Object Stores in a FileNet P8 domain served by a common GCD. The marking-enabled property templates and the actual properties based on these templates are, however, specific to the object store in which the property template was created.
Modifications to markings or marking sets are subject to the Marking Set Cache Entry TTL setting which affects how often the marking set cache is updated on the server and the current Enterprise Manager machine.
However, the marking set cache is updated whenever any change or addition is made to markings or marking sets. Therefore, the cache is most likely up-to-date by the time the MarkingSetsTTL forces a refresh of the cache.
"Active markings" is the term the Enterprise Manager uses in its security editor on its Active Markings/Owner button. You will see this button text on object instances whether or not there are actually active markings applied to the object. This button will just say "Owner" for those objects that cannot have markings applied, which include all class definitions.
The Enterprise Manager is your tool for creating and applying marking sets. Applications can also utilize one of FileNet P8's APIs. Here are some general rules governing administration:
Renaming a marking set
Renaming a marking set after it has been persisted is not allowed. The marking set name can be modified only during the creation of markings. Once it has been persisted, the marking set name is read-only.
Changing the marking value
The value of a marking can be modified even when properties exist which use that marking value. Existing objects that have property values set to the old marking value will not be updated to reflect the new marking value and, therefore, will need to be updated manually. If the property value is not updated, the marking security on those objects will no longer have any effect.
Modifying the constraint mask and security
You can change the marking's constraint mask and security any time without affecting existing properties.
Deleting a Marking Set
Marking sets that are referenced by at least one property template cannot be deleted. The marking set can be deleted if it is not associated with any property templates or after any associated property templates have been deleted.
Removing a marking
Individual markings can be deleted from a marking set at anytime, even if a property value is set to that marking.
Export issues
Since P8 domain resources contained in the GCD are not exportable, markings are not directly deployable to another P8 domain.
Markings cannot be used in conjunction with choice lists.