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

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

In iManage Security Policy Manager, user claims (claims) are internal identifiers representing either allow or deny access for users on assets—that is, clients, matters, collections, and so on. Allow-type claims and Deny-type claims differ in generation and application, but both are represented by a string of characters that is unique per tenant. 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 are 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.

What's the difference between a token and a claim?

Like claims, tokens are also internal identifiers representing allow or deny access, but they are specifically related to, and stored against, individual assets: Users are assigned these tokens as claims based on their access. So when a token is assigned to a user for access purposes, it is a claim: The user makes a “claim” on the asset. In practice, this means that, for that asset, the user gets a claim which reflects—or matches with— the relevant tokens of that asset. This can be an Allow claim, a Deny claim, or both.

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

Claims are used to help define a user’s access to given assets. They are also used by SPM agents, to apply policy on assets in target systems.

Assets are sent, along with corresponding users and their claims, to the agent by iManage Security Policy Manager. These are used by the agent to assess policy for and apply policy to, the assets in the target system.

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 Allow claims. Deny claims aren’t limited or truncated, to maintain a zero-trust model.

What are the limits?

The Allow claim limit is 10,000. There's no Deny claim limit.

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

What happens if I reach or exceed the limit?

When the (Allow) claim count for a user reaches 8,000, a 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 (Allow) claim count for a user reaches 10,000, a 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 two types of effect:

  • The total number of Allow claims is truncated to 10,000—and this truncation is applied to all agents and therefore 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. The order in which over-limit claims are revoked is not chronological, but based on internal policy processing efficiency considerations, and is therefore not predictable.

  • 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 these. Refer to:

If you are 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 Collections (departmental security) reduce token 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 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 token reduction of 9,999, for identical access (assessment and application). 

NOTE: If the collection includes matters under a client with open-up security—that is, where security policy is set so that matter staffing is not required to be limited to users named under client staffing, collection users will receive an additional claim for each such client, but not for each matter under such client. For example, if there is one such client with 100 matters in the collection, collections users would receive one additional claim only.

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

Unlike collections, client groups don't have claims of their own. They're a grouping construct designed to ease administration, and their security policy is not 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 token count.

NOTE: The addition of a user to a client causes the addition of two user claims: one is for the client policy, and one is for the default policy application of all the matters within that client.

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 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, then only one claim is required for the user to gain access to those matters; an effective saving of 999 claims.

Similarly, if a user is added to a collection—whether individually or as part of a group—but is also present on or added to the staffing of a matter that is in that collection, this overriding of asset claims by collection claims holds true: That is, such user only requires (and has) a single claim for all the matters in the collection, regardless of whether they're also part of those matters' staffing lists.

Also refer to the note under How can Collections (departmental security) reduce token count?

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 claim 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, as a result 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. To be denied on those matters, just one Deny claim, for the collection, is required for that user. This gives a claim reduction of 999, for identical access permissions. 

If you require further support on reducing user claim count, to avoid potential loss of access, please contact iManage Support or your Customer Success Representative.