Help Center

Menu

Document level security

This feature is not available in the Squiz DXP.

This section describes the document level security features available in Funnelback. Document level security provides the capability to control which documents are visible to users using the Funnelback search engine at the level of the individual document, rather than controlling access to your results by IP address or domain. Enabling document level security will allow repositories with complex security restrictions to be easily searched using a single interface available to a wide range of users.

Please note that when using document level security, access to the cached version of documents via the cache controller is disabled.

Timing of security binding

Funnelback includes security check functions which operate on access control information recorded at the time that each document was gathered (sometimes called early-binding security). This 'early binding' approach provides a good level of search speed while ensuring that permissions are regularly updated when documents are re-gathered to account for document changes.

Earlier version of Funnelback also provided a 'late binding' approach whereby the underlying repository was checked for user permissions at the time of the search query, rather than at the time of gathering. While this approach ensures that access control changes are reflected more rapidly in the search results, there was a large performance cost to performing these checks, hence they are no longer supported by default. Custom security check plugins could be developed to implement such late-binding (or hybrid) security checks if such checks were needed.

Details on security binding

Early-binding.png When document level security is enabled security information of each document is embedded in the collection.

When the origin repository is gathered Funnelback collects the security information of each document, the lock strings. When a user performs a search Funnelback collects its credentials, the user keys, and the query processor tries to match those keys against the lock string embedded in the documents, for each document matching the query.

The user keys are mapped to a metadata class like any other metadata by defining a metadata class with a type of document permissions. (This is automatically done when the collection is created). For example for TRIM collections have a metadata field trim.lockstring containing the document locks mapped to a document permission metadata class, S.

The metadata containing the lock string as well as the format of the lock string itself will vary depending on the collection type and remote repository type. Please see the per-collection instruction for details.

Fetching user keys: The type of user credentials, the way to fetch them and to map them into user keys is configured in security.earlybinding.user-to-key-mapper and will depend on the remote repository type. Various user key mappers plugins are provided in the $SEARCH_HOME/share/security_plugins/ folder.

Matching user keys with lock strings: To find if a user is authorized to see a specific document the query processor tries to match the user keys against the document lock string. The default matching algorithm checks that the document lock string contains at least one of the user keys. The algorithm can be changed by specifying a plugin name in security.earlybinding.locks-keys-matcher.name. Various plugins are provided in $SEARCH_HOME/lib/plugins/.

Available data source types

The following data source types support document level security:

Authentication and delegation

Users must be authenticated for Document Level Security to function. Funnelback currently supports document level security:

  • With some external system (such as a portal or CMS) authenticating users prior to reaching Funnelback.

Switching off document level security

Disabing early-binding document level security can be achieved in two ways:

Method 1: Keep the lock strings in the collection, but use a user key mapper plugin that always returns a master key matching every document. To do so:

This will not work with NTFS filecopy collection. To disable early-binding security on this collection type you need to apply the second method. This will also not work with collections types that use a custom keys / lock matching algorithm (as opposite to the default one) such as TRIM and TRIMPush collections.

Method 2: Remove the lock strings from the collection. To do so:

See also