Security configuration

OpenKM can work with several security managers, depending on the selected value, the manner in which the result is evaluated is different. This application has separated managers, one for the search engine and other for the rest of the application.

Search engine managers:

• lucene.
• am_more, am_window or am_limited.

Note

The fastest one is lucene, because it is the Lucene search engine which restricts the search results based on the node security. The others are am_more, am_window and am_limited, which make use of the AccessManager - security.access.manager value - to restrict the search results, these will reduce OpenKM performance (at least in search) but will match customer requirements. The performance can be improved customizing com.openkm.cache.parentNodePermissions cache.

Rest of application manager:

• simple.
• recursive.
• read_recursive.

Note

The simple option only evaluates the selected node. With recursive, the security is evaluated starting with the selected node until the repository root (so, evaluating form bottom to top). The read_recursive is used to prevent showing documents in search results when any folder in the path doesn’t have read access for the user who ran the query. Should be used in combination with am_more.

Application by default is configured with:

Field / Property	Type	Description
security.access.manager	String	simple
security.search.evaluation	String	lucene

Diferences betweem simple and recursive

• okm:root
  • level-1a
    • level-2a
      • level-3a
        • alpha.doc
        • beta.doc
        • gamma.doc
      • level-3b
  • level-1b
  • level-1c

When using simple if you revoke permission from the level-2a folder and the user tries to view the level-3a folder, OpenKM will still show the documents to this user. When the user performs a search, OpenKM will return these documents as search results. However, the user can’t access the documents because when OpenKM tries to access the document, it will open every path location and will fail to open level-2a because the user has no rights. But these document can be accessed using the API. You need to apply revoke recursively to prevent the user from seeing these documents, so they won’t be shown in the search results.

When using recursive if you revoke permission from the level-2a folder and the user tries to view the level-3a folder, OpenKM will report an error because Access Manager also evaluates the permission of the level-2a ancestor node. When the user performs a search, OpenKM won’t show these documents in the search results. Keep in mind that this Access Manager implementation is slower because it needs to evaluate more nodes: the more depth node the more parent nodes need to be evaluated.

Extending security

You can use the extend security to download files, start workflows, add, remove or modify property groups ( metadata ) or compact history. To enable extended security evaluation you must change the value of security.extended.mask parameter.

Note

After the value is changed, refresh the browser to take effect in user view.

Values:

• DOWNLOAD = 1024;
• START_WORKFLOW = 2048;
• COMPACT_HISTORY = 4096;
• PROPERTY_GROUP = 8192;

For example, to enable download and property groups you should put the mask 9216 ( 1024 + 8192 )

Field / Property	Type	Description
security.extended.mask	Integer	9216

Configuration for security changes which take a long time

By default when you change the security of a node in standard view, every time you click to grant or revoke a permission the action is performed by OpenKM. This means that if you want to change the security of 10 users, 10 commands are sent to the server. This became a problem when every change affects several hundred (or even thousands) of nodes. There’s an alternative security configuration parameter named security.mode.multiple which enables multiple changes at a time, so it’s so faster.

Field / Property	Type	Description
security.mode.multiple	Boolean	true

Some security changes can take a long time to be completed because affect a lot of nodes. It’s a good practice to do it as a background task. For it there’s a configuration parameter named security.live.change.node.limit used to set the limit of nodes which can be changed in “live” or “realtime” mode. By default this value is set to 100, which means that any change which affect to more than 100 nodes will be automatically done as a background task.

Field / Property	Type	Description
security.live.change.node.limit	Integer	100

To check the progress of these pending tasks go to Administration > Statistics > Pending task queue.