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.