Markings

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.

Overview

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:

  1. A marking set is defined, containing several possible values called markings.
  2. Each marking value contains a set of access permissions which define who can assign that specific value to an object property, who can modify or remove that specific value, and, once it is assigned, who will have access to the object it is assigned to.
  3. The marking set is assigned to a property definition on a class such that the value of that property on instances of the class must be one of the markings defined by the marking set.
  4. Values can only be assigned by users authorized by the associated marking and access to the object is restricted based on the marking once it is applied.

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:

  1. A user or process tries to access an object.
  2. First the Content Engine resolves the object's ACL to determine who can access the object and what those users can do.
  3. Then it computes the markings applied to the object to see which users to stop (defined by the marking's Security list) and what they should be stopped from doing (defined by the marking's constraint mask).

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 Enterprise Manager as the object's "active markings" (see below).

Top of page

Limitations

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, you should limit the number of markings in a marking set to no more than 100.

Another limiting factor would be one that occurs with any user interface attempting to display extremely long lists of choices, but this kind of application design problem is not inherent to markings.

Marking security: Add, Remove, Use

Marking security consists of the following permissions:

Add marking and Remove marking

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:

  1. A Document has a property associated with a marking set. No value has been specified for the property.
  2. The marking set has markings Red, Blue, and Green.
  3. Alice has Use rights to Red; Use and Add rights to Blue and Use, Add and Remove rights to Green.

    When Alice views the Document properties, she can set the property value to Blue or Green but not Red. If the property was set to Green, she could alter it to be Blue. If the property was set to Blue, Alice would be unable to alter the property's value.

Use Marked Objects

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.

Effect of use marking on object access

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:

Top of page

Effect of Copy to reservation

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.

Top of page

Constraint Mask

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 cleared, 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:

Effect of constraint mark on object access

In this graphic:

Top of page

Allow, Deny permissions

Each access control entry listed on a marking value's security page is marked either Allow or Deny.

Allow

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.

Deny

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 can set up deny rights on the marking which will override any allow access otherwise granted to the marking. For example:

  1. The security on a document grants #AUTHENTICATED-USERS full control access.
  2. The document has a single-valued property associated with a marking set with possible values of Chicago, New York, and Boston.
  3. The property value is set to Boston.
  4. The Boston marking has a constraint mask of full control allow (all permissions selected).
  5. The group Everyone_Boston has Use/Allow rights to the Boston marking.
  6. The Sales group has Use/Deny rights to the Boston marking.

    In this scenario:

See the next section for how the Allow and Deny permissions are applied to hierarchical marking sets.

Top of page

Hierarchical and Non-hierarchical

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.

Hierarchical markings

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:

Hiearchical marking with Deny

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 can 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:

  1. Allow permissions affect markings downward in the hierarchy; that is, an Allow Permission placed on a superior marking is implicitly present on inferior markings.
  2. Deny permissions affect markings upward in the hierarchy; that is, a Deny Permission placed on an inferior marking is implicitly present on superior markings.
  3. Deny permissions take precedence over Allow permissions.

Top of page

FileNet P8 Domain resource

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.

Top of page

Marking Set TTL (caching)

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.

Top of page

Active markings

"Active markings" is the term 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.

Top of page

Marking administration (create, modify, remove)

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.

Not available with choice lists

Markings cannot be used in conjunction with choice lists.

Top of page