Sweep security

You can monitor the progress of a sweep iteration with System Dashboard for Enterprise Content Management.

The security model that is applied for sweeps generally and for custom sweeps in particular is that a sweep is a server-managed reliable and scalable equivalent of something that might otherwise be done by a client application.

Such an application typically runs under the identity of some user, and security is applied to the operations that are performed by the application according to the access that is granted to that user.

This same model applies to sweeps, where the user in question is the security owner (represented by the Owner property) of the sweep-controlling object – the job, policy or queue sweep instance. This user can be considered as the impersonated user, and that user is typically the creator of the sweep-controlling object. Stated another way, the sweep handler is permitted to perform operations, particularly updates and deletes, only on objects to which the impersonated user has access rights sufficient to allow those operations.

This model has applied to custom job and policy sweeps since the sweep feature was introduced. However, its application to queue sweeps represents a change effective in the V5.5.5 release.

Prior to V5.5.5 custom queue sweeps were run with security checking disabled, meaning that the handler operated on any object in any manner, regardless of access control on those objects.

So in upgrades to 5.5.5 or later, it is possible that previously working custom queue sweeps might incur errors because of the more restrictive application of access control. (The extent to which the change in security model impacts the operation of the sweep depends on the degree to which the handler implementation follows the best practices for exception handling described in Implementing a sweep action handler). In most cases, the queue sweep object will be owned by an administrative user with full control over all objects in the object store, and in such circumstances the queue sweep continues to operate as before.

However, in cases where the ownership does not align, and the more restrictive security does cause issues, you can enact remedies.

The preferred remedy is to ensure that the impersonated user has the necessary rights to all the objects on which the sweep operates. For example, in the case of a queue sweep that updates document, you can either adjust the Owner of the queue sweep object to a user that naturally has those rights or you can update the permissions on the objects to be operated on to give the current queue sweep Owner the required access.

If that is impractical or impossible, you can, if required, enable a specific sweep handler to operate under the pre-V5.5.5 security model by using a configuration setting that is applied as a JVM argument for the server JRE or in FileNet.properties.

To enable the pre-V5.5.5 security model:

1. Use the Administration Console for Content Platform Engine to obtain the ID of the Sweep Action for the custom queue sweep handler, by navigating to Object Store > Sweep management > Sweep Actions.
2. Set the JVM as shown in the following example, using the Sweep Action ID. If you need to revert multiple custom queue sweep handlers, supply the IDs for all sweep actions as a comma separated list. For example:

   -Dcom.filenet.engine.sweep.RelaxedQueueSecurity={2C20B21B-4D39-4708-9DCB-C2EAAAAE1EC1}

3. Alternatively, add the following entry to FileNet.properties:

   com.filenet.engine.sweep.RelaxedQueueSecurity={2C20B21B-4D39-4708-9DCB-C2EAAAAE1EC1}

4. Restart all Content Platform Engine instances.

2020-04-21T14:55:59.388
        527BEA4C SWP  FNRCE0000D - DEBUG Relaxed security enabled for custom queue sweep action
        {2C20B21B-4D39-4708-9DCB-C2EAAAAE1EC1}