Product DocsMenu


Internet search engines such as Google deal with gigantic amounts of publicly available web documents. Within the realm of an organization, enterprise search engines deal with significantly smaller number of documents, but documents come from various repositories and most importantly, they are often secured. An enterprise search engine must carefully manage content permissions to only return search results that the user performing the search is allowed to see in each of the source repository.

Most on-premises or cloud enterprise repositories come with a security model allowing administrators, and sometimes even users, to set access restrictions to content while other content may remain accessible to all members of the repository, or even any anonymous user.

Some enterprise repositories have distinct authentication means so users have distinct accounts on these repositories and must log on separately to these repositories to access their content. When available, a single sign on (SSO) system can allow a user to log in once and automatically gain access to several repositories, like if he was carrying credentials of all of his accounts.

Example: A person accesses a Search Interface to perform a query matching only two documents in the index, Doc1 in Repo1 and Doc2 in Repo2. The person has three distinct accounts: UserA-Repo1, UserA-Repo2, and UserA-AD. In Repo1, only UserA-Repo1 is allowed to see the document. In Repo2, only GroupY is allowed to see the document, but UserA-Repo2 is a member of this group. Finally, the Repo1 source is configured to chain security providers to link Repo1 users to corresponding AD (Active Directory) users. The Repo2 source is not configured to link users of different types.

When the person performing the search is authenticated as UserA-AD, the index returns Doc1 because UserA-Repo1 is allowed to see the document and is linked to UserA-AD in the Security Cache, but not Doc2, even if UserA-Repo2 is a member of GroupY, because there is no link between UserA-AD and UserA-Repo2, so they appear as two different persons.

Several Coveo components are involved to manage permissions, both at indexing and query time. The schema below illustrates the links between the Coveo components in a simple case where two repositories are indexed.

At Indexing Time

The Coveo components handle permissions at indexing time as follows: 

  • While crawling a repository, each Coveo Connector gets the security entities associated with each indexed documents. Depending on the repository security model, the security entities may be users, groups, profiles, roles, or some other types.

  • The Index stores the security entities associated with each document. The index is not aware of which users belong to these groups, profiles, etc.

  • The Index passes the security entities to the Security Cache to take care of managing the members of each security entity.

  • The Security Cache dispatches the new security entities to the appropriate Security Providers.

  • Each Security Provider interrogates the related repository to get the user members for each security entity (user expansion) and returns this information to the Security Cache.

  • For a given source, Security Providers can be chained to link multiple identities. In this case the Security Cache refers to each chained security provider to link the different users in each repository corresponding to the same person (user mapping).

  • As a result, the Security Cache contains all members of all security entities as well as all linked users (see What Is a Security Cache?).

At Query Time

The Coveo components handle permissions at query time as follows: 

  • A Person authenticated as a user in a given repository accesses a Search Interface and performs a query.

  • The Index

    • Receives the query and the user identity.

    • Gets all documents matching the query.

    • Interrogates the Security Cache to get all security entities to which this user and linked users belong.

    • Filters documents matching the query to only return documents matching allowed security entities to which the user belongs.

    • Returns the filtered results to the Search Interface.

  • The Search Interface displays the results.

Security Cache Update

The permissions in enterprise repositories are typically constantly adjusted as people join, move, or leave an organization. To maintain the security entities information up-to-date:

  • Independently from the indexing, the Security Cache is updated at a regular time interval so that it contains all current members of all current security entities as well as all linked users (see What Is a Security Cache?).

  • The security cache is updated daily at midnight by default to ensure that any security entity changes made in indexed repositories within the last 24 hours are effective in the security cache and consequently, reflected in search results.

  • Coveo administrator can change the security update schedule time or frequency (see What Should Be the Frequency of System Schedules? and Modifying System Schedules).

  • A Coveo administrator can manually launch the refresh of the whole security cache (see Refreshing Security Caches).

  • Using the Security Browser of the Administration Tool, a Coveo administrator can select one or more specific users or groups and update the security cache specifically for them (see Using the Security Browser).

People who viewed this topic also viewed