The following topics are available:
iManage Security Policy Manager
iManage Security Policy Manager (SPM) is an optional add-on application for iManage Work that manages security. This application allows for more detailed control, audit, and reporting of security. It's a security layer before iManage Work's access permissions, and provides additional control, including new security features. It's designed to work with iManage Work but it's a separate application. iManage Work can't change or set SPM values. SPM can also be applied to other applications, including iManage Records Manager and the Microsoft Windows file system. Contact iManage for additional information about the application.
SPM introduces two conditions that apply first when determining access permissions for items, including containers (such as workspaces, folders, matters, clients, and cases) and documents:
- Open access: This permission allows the selected users and groups access to those items. However, normal iManage Work access permissions still apply. For example, SPM may grant a user open access to a matter, but iManage Work doesn't allow access for that user on that matter. The combined result is that the user has no access.
- Restricted access: This permission denies the selected users or group access to the items. Restricted access permission is a convenient method to limit access without having to modify iManage Work access permissions, and includes avoiding refile events. For example, SPM assigns a user restricted access to a matter. Regardless of the iManage Work access permission, even if the user is granted explicit iManage Work access permission, the user will have no access to the matter.
In the sections that follow, the discussion assumes a user or group has open access to an item.
iManage Work Object Security
The iManage Work security model offers a versatile and flexible means of managing security across all workspaces, containers, and documents. Each item has a series of security settings. Precise refinements can be made to each security setting, providing an increasing amount of security and specifying exact access for any user or group.
For example, an editor's group may be added to an item that allows those group members to edit documents. All other users can be excluded entirely, perhaps for conflict of interest reasons, from viewing documents. Additional versatility is provided by even being able to exclude specific members of that editor's group from editing or viewing a specific document.
Every item has the following security characteristics:
- Security Policy Manager access limitations
- Default security
- Access permission
- Library and global role restrictions
- Security model and groups membership conflict resolution
The bottom-line result of the combinations from all the sources is called effective security.
Default security
The default security value is the basic security level and is inherent at all times. A value is automatically assigned when a container is created, or a document is created or initially uploaded. This value may be changed later by someone with the proper permissions. Refer to Changing Security.
The following are the four default security values:
Security value | For Containers | For Documents and emails |
|---|---|---|
Private | Only the user who created the container (also called the owner) can access it. Other users or groups can be explicitly granted access permission (refer to Access permission) and will have access only to the limit allowed by those permissions. An item that is private to a user or group will only be accessible to them. | Only the user who created the document (called the operator) or the assigned author (who is provided with implicit full access to the document) can access the document. Other users or groups can be explicitly granted access permission (refer to Access permission) and will have access only to the limit allowed by those permissions. |
View | All users and groups can access the container's contents but can't add or remove items from the container, or modify, delete, or move documents. | All users and groups can view the document, but can't modify, delete, or move documents. The user who created the document (called the operator) or the assigned author (who is provided with implicit full access to the document) can modify the document. |
Public | All users and groups can access the container's contents. They can add, delete, and move items into or from the container. | All users and groups can view or modify the document. However, they can't delete or move the document. The user who created the document (called the operator) or the assigned author (who is provided with implicit full access to the document) can delete or move the document. |
Inherited | Indicates that the container or tab doesn't have an explicit default security of its own, and instead assumes the default security and access permission of its parent container. iManage Work calculates this permission level automatically. A best practice is that only the highest-level container, typically the matter, is explicitly assigned an access level, and that all other containers be assigned Inherited security. | Indicates that the document doesn't have an explicit default security of its own, and instead assumes the default security and access permission of its parent container. iManage Work calculates this permission level automatically. A best practice is that only the highest-level container, typically the matter, is explicitly assigned an access level, and that all other containers, documents, and emails be assigned Inherited security. |
Access permission
Access permission is an optional security value a user can have for a container, document, or email. Access permission refers specifically to a user's granted access to an object. These include the following values. A user or group isn't required to have access permission. The access permission may be more or less restrictive than the object's default security. If specified, it overrides the default security. If not specified, the item's default security value is used.
Access permission | For containers | For documents and emails |
|---|---|---|
No Access | A user or group can't view the contents of a container, or search for documents inside of it. | A user or group can't view the contents of a document or email, search for the item, or see the item in the iManage Work browser. |
Read | A user or group can view the contents of a container or view the document, but can't add, edit, or remove items. | A user or group can view the contents of a document or email, but can't add, edit, or remove content. |
Read/Write | A user or group can view, add, or remove the contents of a container or view the document, but can't delete or move the container itself or change the container’s security. | A user or group can view, add, and edit the contents of a document or email. They can't delete and move the item, or change the security or metadata properties of the item. |
Full Access | A user or group can view, add, or remove the contents of a container or view the document, but can also remove or move the container itself and change the container’s security. This is the same as having Owner permissions with the container. | A user or group can view, add, or edit the contents of a document or email. They can delete and move the item, and change the security or metadata properties of the item. |
Library and global roles restrictions
A library role is a named set of library-level privileges. Library roles are assigned to individual users, and each user must have a role, even if only the default role automatically applies to each new user. Some library-level privileges affect access to containers and documents. For example, if a container's default security is full access, a user is explicitly granted full access, which includes being able to delete items. However, if the user's library-level role privilege Delete is not granted, the user won't be able to delete items.
The following library-level privileges may affect user access.
Documents
Value | Description |
|---|---|
Import/Create | Allows users to import/create documents. |
Checkout Documents | Allows users to check in and check out of documents in the library to which the user has access. |
Unlock Documents | Allows users to unlock documents that are checked out or currently in use. This is basically a forced check-in. Any changes to the document won't be saved back to the library. The document remains on the checked-out device, along with any changes. Care must be taken in this case. The document does remain on the checked-out device and may represent a security issue. |
Delete | Allows users to delete documents and containers from libraries to which the user has access. For some iManage Work environments, the document will be moved to the user's Trash and is recoverable. For other environments, if Trash isn't enabled, the document will be deleted permanently. |
View for NRTADMINs | Allows NRTADMINs to view the contents of private documents when they don't have explicit access permission to the documents. In general, this should remain disabled to ensure the security of sensitive information. NRTADMINs will still be able to search for private documents regardless of this setting. |
Folders and tabs
Value | Description |
|---|---|
Create Public Folder | Allows users to create a new public project folder. The user can still create private folders or subfolders with security inherited from the parent folder. Allow users to create folders with public or view default security. When this is disabled, users can still create private folders. Folder creation is also subject to the user's security permissions in the individual workspace when trying to create a folder. |
Create Public Searches | Allows users to save public searches and mark them as public. Allows users to create search folders public or view default security. When this is disabled, users can still create private search folders. Search folder creation is also subject to the user's security permissions in the individual workspace when trying to create a search folder. |
Workspaces
Value | Description |
|---|---|
Create private Workspaces | Allows users to create private workspaces. |
Create public Workspaces | Allows users to create public workspaces. |
Delete Workspaces | Allows users to delete workspaces. Workspaces and their containers will be permanently deleted and must be re-created if there's accidental deletion. The workspace contents will be moved to Trash for cloud customers and for on-premises customers may be permanently deleted if Trash isn't enabled. |
Changing Security
Only a user or group with Full Access to that item can change security levels. This includes having access permission of Full Access, or being an item's operator (also called an owner), who by default has Full Access for that item.
Security can be changed in the following ways:
- iManage Security Policy Manager: iManage Security Policy Manager can set Open or Restricted access for users and groups. This access doesn't change the iManage Work system settings but instead is a security layer that is checked before trying to access iManage Work.
- Direct assignment: The user can change the default security directly to an item. In the property panel, or at the time the document is created or initially uploaded, a properties panel displays. If the user has the proper level of permissions, they can change the default security.
- Refile: Refile is an iManage Work process that automatically updates container and document security. This includes the collective default security and access permissions, and metadata for each item. If a parent container has its security changed, this service automatically propagates those changes downward through all the children containers and their documents. For example, if a workspace changed its default security to View, that new default security is automatically changed for all children containers with a default security of Inherited.
Security Model
The iManage Work security model resolves access conflicts if a user belongs to two or more groups. The model is called hybrid security. The hybrid model grants:
- Access using the most permissive access levels from among the available groups.
- Except if a denial exists. The denial takes precedence over any access grant.
For example, a user is a member of both Group 1 and Group 2, and is trying to access Container A.
Source | Access level |
|---|---|
Container A | Default security is View. |
Group 1 | View |
Group 2 | Read/write |
The hybrid model grants access from the most permissive access levels. Here, Group 2 offers Read/write, so the user is granted Read/write access to Container A.
For another example, a user is a member of both Group 1 and Group 2, and is trying to access Container A.
Source | Access level |
|---|---|
Container A | Default security is View. |
Group 1 | No access |
Group 2 | Read/write |
The hybrid model grants access from the most permissive access levels except if there is a denial among those. Here, Group 1 offers No access, so the user isn't granted access to Container A.
Conflicts from different groups
The following matrix determines the net result of conflicts caused by a user being in two or more groups.
- First, determine the group with the most restrictive access in the first column. This means the group either has No Access, or any other access.
- Second, determine the group with the least restrictive access in the second column.
- Third, using the single row that matches the first and second access levels, cross-index with the user's access rights. The result is the user's access level from groups.
Hybrid security model | |||||||
|---|---|---|---|---|---|---|---|
The user's access permission | |||||||
Most Restrictive Group Access Rights | Least Restrictive Group Access Rights | No Access | View | Unspecified | Read/Write | Full Access | Owner |
No Access | (Any access) | None | None | None | None | None | Full |
Any access other than No Access | View | None | View | View | Read/Write | Full | Full |
Any access other than No Access | Unspecified | None | View | Read/Write | Full | Full | |
Any access other than No Access | Read/Write | None | Read/Write | Read/Write | Read/Write | Full | Full |
Any access other than No Access | Full | None | Full | Full | Full | Full | Full |
Unspecified access permission indicates that access permissions haven't been defined for the item. The item may not have any default values, or all existing values have been removed.
Examples
If the user is part of a group that offers the most restrictive access of No Access, regardless of any other access permissions (except for the owner who always has full access) the user will have no access.
If the user is part of a group that offers the most restrictive access of View, another group offers the least restrictive of Read/Write, and the user has access permission of View, the effective security is Read/Write. The security model resolves the different access levels as the least restrictive, here as Read/Write.
How to calculate Default Effective Access Rights
How to Calculate Default Effective Access Rights | ||
|---|---|---|
Effective Default Security Policy* | Non-External User | External User |
View | Read | None |
Public | Read/Write | None |
Private | None | None |
How to calculate Effective Default Security Policy
How to calculate Effective Default Security Policy | ||
|---|---|---|
Default Security | Inherited Default Security | Effective Default Security |
Inherited | View | View |
Inherited | Public | Public |
Inherited | Private | Private |
View | X | View |
Public | X | Public |
Private | X | Private |
Effective Security
Effective Security is the net result of a combination of these item attributes:
- Security Policy Manager access level
- Default security
Access permission
Roles restrictions
- Conflicts among groups the user belongs to
- The security model being used
If an item has only default security, all users will be limited to that security level. For example, if the default security is view, then all users have view access to it.
Users may have access permission different than the default security. Continuing the example, user Sandhya needs to be prohibited from viewing a container's contents, perhaps due to a conflict of interest. In this case, she'd be assigned an access permission of no access. After that, Sandhya won't be able to view the contents of the container. If the access permission of no access were applied to a document, she couldn't read it, and is even being prohibited from seeing it in a container.
The effective security in these two cases is straightforward. The access permission always has priority. In the example above, no access has priority over the view default security.
However, access can also be provided through groups.
If the user is provided access from only one group (and with no explicit security otherwise), the group's access priority is over the default security. For example, the user Nicole is part of a group with read/write access to a container with view default security. Nicole has the effective security of read/write. This is granted from the group having priority over the default security.
If a user is a member of at least two groups, and some of the groups have different access levels, an access level conflict occurs. The resolution depends on the security model being used.
Owner
The owner is a role that's automatically assigned to the user who creates a new workspace or folder. That user has Full Access privileges to the workspace/folder. A workspace/folder can have only one owner, and the current owner can assign the role to another user.
Operator
The operator is a role that's automatically assigned to the user who creates a new document or initially uploads a document. That user has Full Access privileges to the document. A document can have only one operator, and the current operator can assign the role to another user.
Author
An author of a document is a role that's automatically assigned to the user who creates a new document or initially uploads a document. The author can be changed by a document's operator or another user who has full access to the document. The author role doesn't grant ownership to the document (see Operator) but does grant implicit full access to it.
ACLs
An ACL is an access control list used by iManage Work to mark access permissions for documents and containers. Any entity with the appropriate access (for example, system administrators, third-party tools) can view/modify an ACL. A child container can be said to "inherit its parent's ACL," meaning the default security and all users and groups in that container access permission from the parent.
Refile
iManage Refile Service is a service that propagates security and property field changes throughout a library in a background operation. This isn't part of an item's effective security but can affect an item's security values.
The propagation begins with well-defined events, such as changing the security on a container, or changing a property field value. For example, changing the default security of a container may trigger a refile event. After an event is initiated, the propagation is automatic and doesn't require confirmation from the user. During propagation, items are updated according to explicit rules. The refile processes downward, through each subfolder and is recursive through all subfolders. For example, a change at the matter level may affect all items within that matter. If the event occurs in a child folder within that matter, only that child folder and items contained by it, including other folders, may be affected. The propagation never transverses to a higher container. The operation occurs in the background and isn't noticeable by users. They can continue to use the application. However, it may take a few minutes for the refile service to propagate these changes through the entire container hierarchy.
Refer to Refile for additional information.
Encryption
Data encryption is a security measure that prevents visibility of documents in the case of unauthorized access or theft. This isn't part of an item's effective security but can affect an item's security values.
Also called data at rest encryption, documents are encrypted when they aren't being used. In the event they're compromised, such as by theft, wrongful disclosure, or unauthorized access (including internal unauthorized access), the files are encrypted, and therefore, unreadable. When an authorized user accesses a document (such as through editing or viewing within a client application), the document is decrypted and will be able to be read or edited normally. When the user is done with it, it's returned to its encrypted state. This encryption is compliant with HIPAA and other American statutes protecting sensitive information.
A document or email will be encrypted if at least one of the following conditions is applicable, even if other conditions specify not to enable encryption. More than one condition has no additional effect.
Condition | For more information: |
|---|---|
The document class or subclass sets HIPAA-compliant encryption to Yes. | |
A custom field (such as custom1 or custom3) specifies document encryption. Any document with that custom field in its profile will be encrypted. | |
The file type specifies document encryption. |