This section provides answers to frequently-asked questions about user claims in iManage Security Policy Manager (iManage SPM).

What's a user claim in iManage Security Policy Manager (SPM)?

User claims (claims) are how iManage SPM represents security in target systems. It can be said that a user has a(n Allow) claim to a matter, meaning they are allowed access to it. Similarly, a user can have a Deny-type claim, which prevents that user from accessing a matter or other specified content.

The claims that a user has aren't fixed entities stored in iManage SPM—for example, in the database—but are assigned to a user when the access for that user needs to be calculated and applied, for example when there's a change to a user’s security policy in iManage SPM. Therefore, a user’s claim count will vary with how their access is changed in SPM.

NOTE: This information about claim application applies to iManage Security Policy Manager only, and may not apply to other iManage products.

What do claims do?

Claims define Allow or Deny access for a user on a given asset. More specifically:

  • Allow claims represent access to an asset. An Allow claim may be given to a user, for example, when they're added as a member of a restricted matter.

  • Deny claims represent a denial of access to a given asset. A Deny claim may be given to a user, for example, when they're added as a conflicted user on an asset, or when they're on a different side of an opposing team set from the asset.

If a user has both Allow and Deny claims for an asset, the Deny claim takes precedence. Nonetheless, the user keeps both types of claims, in accordance with existing security policies at that time.

How and why are claims used by iManage Security Policy Manager to apply policy?

iManage SPM uses claims to model access to assets. Agents connected to iManage SPM receive this information and apply this access in the target system(s).

When Collections—which in terms of tokens and claims, are treated similarly to clients and matters—are used in iManage SPM, a user’s access can therefore be represented in a much more concise manner. For example, when a matter is added to a collection, the documents (in iManage Work) belonging to a restricted matter are indexed with the Collection’s allow token. This allows SPM to grant a user access to many Matters by matching a claim that only reflects the Collections allow token, instead of one for each matter. This has a major impact on overall search times in iManage Work. Refer also to Why is there a claims limit?

Why's there a claims limit?

Claims limits were introduced in response to iManage Work Server full-text-searching limits. High user claim counts can impact search performance in iManage Work—for all users in that iManage Work Library, not just those users with high claim counts.

The claims limit for a user is currently set at 10,000 claims.

What are the limits?

For a given user, the claims limit is 10,000. Allow claims and deny claims are combined in the count—for example, 5,000 Allow claims and 5,000 Deny claims would summate to reach the limit of 10,000 claims.

Warnings about approaching or exceeding the limits are presented on the Monitoring page. It's important that the combined claim limit of 10,000 is adhered to.

What happens if I reach or exceed the limit?

When the claim count for a user reaches 8,000, a yellow warning appears on the Monitoring page of the iManage SPM Administration Console, advising of this. This is also presented in the server logs.

NOTE: You must have the Monitoring role to view the Monitoring page.

When the claim count for a user reaches 10,000, a red warning about this appears on the Monitoring page of the iManage SPM Administration Console, and also in the server logs. When the 10,000 limit is breached, there are three possible types of effect:

  • The total number of claims is truncated to 10,000—and this truncation is applied to all agents and therefore to all target systems. For the user, this means that they may lose access to some assets or collections to which, according to policy, they have access—or conversely, they may have access to assets to which, according to policy, they don't have access. It's therefore important that you limit the number of claims that any given user in your system has.

  • The order in which over-limit claims are revoked is hierarchical, with truncation of Allow claims always prioritized.

  • Impacts in iManage Work as described in Why is there a claims limit?

NOTE: Because claims are relevant in the context of applying policy, a system that is not connected to agents—for example a standalone iManage SPM sandbox service—will not display claims warnings.

What should I do if I see warning messages about claims in iManage SPM?

If you see claim limit warnings in your iManage SPM instance, there are actions you can take to reduce the number of claims. Refer to:

If you're uncertain about how to proceed, or if you still see warning messages after taking any of the actions above that are applicable to your organization's security model, contact iManage Support for assistance.

How can I view details of a user’s claims—and make use of those?

If you have users approaching or exceeding the limit of 10,000 user claims, warning banners are displayed on the Monitoring page to advise of this.

By selecting View details on such a banner, the Claims dialog appears, showing you a quick, sortable view of all users exceeding or approaching claims limits, along with details of those claims. This information can help you understand on which assets that user's claims may not be applied. In addition, if the report shows a high number of deny claims, this may indicate a reliance on client-level security for matters: using restricted collections would reduce claim count in these scenarios.

How can Collections (departmental security) reduce claim count?

Collections in iManage Security Policy Manager are treated as assets and so can have their own claims. This provides claims efficiency, as demonstrated in the following example:

  • Without collection usage: A user from a litigation team is added to the staffing of 10,000 individual matters relating to that litigation type, within iManage Security Policy Manager. These matters aren't in a collection. Assessment of access for policy application for that user requires 10,000 Allow claims.

  • With collection usage: The user is added to the staffing of a restricted collection that contains the 10,000 matters (and for simplicity in this example, all these matters are under open-security clients) for that litigation type/department. To access those matters, that user a user needs just one Allow claim for the collection. This gives a claim reduction of 9,999, for identical access (assessment and application). 

Do I need to change matter staffing to reduce claim count?

Whether a user is on matter staffing (as an allowed user) or not doesn't always have bearing on the claim count, when the matter is under a collection that the user is also on the staffing of.

While you don't need to change matter staffing to reduce claim count, there can be performance benefits in moving matter staffing to collections.

Can I add clients to client groups to reduce claim count?

Unlike collections, client groups don't have claims of their own. They're a grouping construct designed to ease administration. Their security policy isn’t discrete, but is effectively a cascading of client policy.

When a user is added to a client group, the user claims are added for each client in the client group. Therefore, adding clients to a client group doesn't reduce claim count.

Can I add matters to cases to reduce claim count?

Similar to client groups, cases don't have claims—or a discrete security policy—of their own. They're a grouping construct designed as an administrative container for subjudice matters.

Adding matters to a case doesn't reduce claim count.

How can I adjust my organization’s current security model to include collections?

If your organization has a security model in which users or groups of users are added to or denied from similar groups of matters, then you can group such matters into inclusionary or exclusionary collections, adding groups of users as required.

NOTE: “Matters” is the default term for iManage Work C2-level security containers in iManage SPM. This terminology is customizable and may be presented differently in your system—for example, as “Engagements”.

Similarly, if you have matters which are individually staffed by virtue of their department, location, or other common property, you can set up self-maintaining rules to create collections to reflect that common property, and apply staffing at the collection level.

For additional information, refer to Collections. If you require further support on planning or implementing collections security, please contact iManage Support or your Customer Success Representative.

How do collections claims interact with existing asset claims?

Collections claims can override similar claims on assets, reducing claim count.

For example, if a user is added as an allowed user to the staffing of 1,000 restricted matters (and for simplicity in this example, all these matters are under open-security clients), this means that there are 1,000 claims required for (assessment and application of policy for) that user to gain access to those matters. If all of those matters are then added to a single collection, and the user is added to that collection's staffing—and removed from the staffing of the matters—then only one claim is required for the user to gain access to those matters; an effective saving of 999 claims.

NOTE: Collections do not affect opposing team set-related deny claims.

Can exclusionary collections also reduce claim count?

Yes. Exclusionary collections—that is, collections with open security and on which conflicted users or groups are added—provide the same type of claims reductions associated with (inclusionary) collections. To adjust the example above:

  • Without collection usage: A lateral hire is individually conflicted on the staffing of 1,000 individual matters, because of conflicts of interest. These matters aren't in a collection. Enforcement of policy for that user requires 1,000 Deny claims.

  • With (exclusionary) collection usage: The 1,000 matters are placed in a collection—for example, by the bulk addition of matters to the collection. The user is conflicted on the collection. To be denied on those matters, just one Deny claim—for the collection—is therefore required for that user. This gives a claim reduction of 999, while providing identical access restrictions. 

If you require further support on reducing user claim count, please contact iManage Support or your Customer Success Representative.