Product DocsMenu

What Is a Security Cache?

The Coveo Enterprise Search (CES) security cache maintains lists of relationships between all the security entities (users and groups) for all the indexed repositories. When a user performs a query, CES refers to the security cache to quickly determine the user permissions and therefore return only documents the user is allowed to see. Without the security cache, CES would have to refer to repositories at each query to get the user permissions, leading to very long query response time.

Example: In Active Directory, the mycompany\jsmith account is a member of the qa_team group. This information is stored in the security cache. When the mycompany\jsmith account performs a query, CES refers to the security cache, sees the account is a member of the qa_team group, and includes in search results documents matching the query that are restricted to the qa_team group.

The security cache also stores mappings between accounts in different repositories for each user.

Example: When a mapping between the Windows account mycompany\JSmith and the Lotus Notes account jsmith.mycompany.corp of a user is stored in the security cache, Lotus Notes documents accessible to jsmith.coveo.corp are also returned for mycompany\JSmith.

CES creates and maintains the security cache using the defined security providers to get the security entities and their relationships from the various repositories (see What Are Security Providers?). The security entities and their relationships can change over time in the indexed repositories. Some of these security changes are continuously updated in the security cache.

Example: In SharePoint, an administrator creates the Project_A_Team group, assigns users to the group, restricts documents to this group, and refreshes the SharePoint source. Within minutes, a user performs a query for which one or more SharePoint documents restricted to the Project_A_Team group are part of the matching results. CES does not include these documents in the search results, even if the user is a member of the Project_A_Team group, because the group information is not yet available from the security cache.

However, CES identifies that this group is not defined in the security cache and queues a request to get the group members. The group information is added to the security cache as soon as the request is performed, typically within minutes.

A few minutes later, a Project_A_Team group member performs a query for which Project_A_Team restricted documents are matching. They are now included in the search results.

The security cache must however be updated regularly to catch all security changes. By default, the security cache is updated daily at midnight.

Example: In Active Directory, and administrator removes the mycompany\jsmith account from the qa_team group. Later that day, mycompany\jsmith performs a query matching qa_team restricted documents that still appear in search results because the security cache has not yet been updated. The next day, mycompany\jsmith performs the same query, but this time, qa_team restricted documents are not included in search results.

Important: The security cache does not contain document permission information. The index does. When the permissions on index documents change in a given repository, the change becomes effective in the index following an incremental refresh, a full refresh, or a rebuild of the corresponding source. The type of source action needed to update permission changes depend on the source connector type. Refer to the connector documentation for more information on updating document permissions.

Note: CES 7.0.7914+ (October 2015) CES comes with an optimized security cache implementation that can significantly reduce the size of the security cache and the server resources needed to update the cache. New indexes created automatically use the new security cache implementation.

CES 7.0.7814– (August 2015) Index created keep the original cache implementation by default. If it is your case and the update of your security cache takes a significant amount of time and resources, contact Coveo Support to get assistance to enable the new security cache implementation.

External Security Cache

The normal method used by CES to handle document permissions is referred to as early-binding, meaning that identifying which users are allowed to access a document is done at indexing time, and stored in the index. With the information maintained in the security cache described above, CES can very quickly return secure search results.

CES can also populate an external security cache for rare cases where it is not possible or not effective to gather permission information at indexing time. In this case, the method used is referred to as late-binding. CES rather determines which documents a user is allowed to see at query time.

When a user performs a query and matching documents are in the late-binding mode, CES checks if the permissions relative to matching documents are in the external security cache. When they are, allowed documents are returned quickly in search results. When they are not, CES uses a security provider to ask the repository if the user is allowed to see each matching document. When the information is returned, CES includes those that are allowed in the search results and adds the collected permission information to the external security cache. Consequently, with this method, the first time a query is performed will be potentially very slow, but next occurrences will be very quick.

Notes:

What's Next?

  • You can also manually start the security cache update process (see Refreshing Security Caches).

  • You can change the security cache update schedule time or frequency (see Modifying System Schedules).

  • You can get familiar with how Coveo components deal with permissions on documents both at indexing and query time (see Security).

People who viewed this topic also viewed