Basic Secured Search

In a basic secured search scenario:

  • At indexing time, the crawler extracts the content and permissions of an item, which is then sent to the index (see Coveo Cloud V2 Indexing Pipeline). The security identities that are allowed or denied access to the item are then stored in the index along with the item content.

  • At query time:

    • The user logs in to the Coveo-powered search interface using their user security identity and makes a query.

    • The index compares the security identity used at login and the security identity allowed to access the queried item. The index returns only items which the logged in user is allowed to access (see Basic Search Flowchart).

To place the focus on item permission management, all examples in this article assume that the query made by the search page user matches the title of the desired items.

John Smith’s professional Google Drive contains only one item, Human_Resources_Annual_Report.pdf. John Smith’s corporate Google Account, jsmith@mycompany.com, is the only security identity allowed to access this item.

Indexing process (see Coveo Cloud V2 Indexing Pipeline)

  1. The Coveo Cloud administrator indexes John Smith’s Google Drive account. The Coveo Cloud crawler crawls the item and retrieves the item content, metadata, and permissions.

    You can review a list of the permissions applying to each item in the Coveo Cloud administration console (see Review Effective Permissions on the Item).

  2. The crawler sets jsmith@mycompany.com as the only security identity allowed to access this item.

  3. John Smith logs into a Coveo-powered search interface using the same identity as that allowed to access the desired item, his jsmith@mycompany.com Google security identity.

  4. When John Smith performs a search, the identity with which he logged into the search interface, jsmith@mycompany.com, is passed to the index along with the query.

  5. The index:

    1. Retrieves all items matching the query.

    2. Filters out items to which jsmith@mycompany.com is denied access, as well as items in the permissions of which this security identity is not specified (see Unspecified Security Identities).

    3. Returns the results to the search interface.

    Since jsmith@mycompany.com is allowed to access Human_Resources_Annual_Report.pdf, this item is returned in John Smith’s search results.

    In other words, the search results to display are the items matching the query, minus the items that the querying user is not allowed to access.

    CCV2-Permissions-DisplayedSearchResults

The following diagram shows how permissions are sent to the index, and how the index returns search results when queried. Content accessible to the identity used to make a query then appears in the search results.

CCV2-Permissions-SecuredSearch

In this basic scenario diagram:

  • Blue boxes represent modules involved in the indexing process.

  • Gray boxes represent modules involved in the querying process.

  • Orange boxes represent modules involved in both the indexing and the querying process.

The permissions in the example above are item-specific; permissions may also apply to an entire source (see Content Security). Secured sources are more likely to include content with item-specific permissions.

Unspecified Security Identities

If the permissions of an item do not specify whether a certain security identity is allowed or denied access to this item, the user authenticated with this security identity cannot see this item in their search results: when information is lacking, Coveo Cloud applies the strictest option to avoid security holes. Therefore, for an item to be returned in a user’s search results, the user’s security identity must be specifically marked as allowed to access the item, and not marked as denied (see Denial Prevalence).

John Smith is the author and owner of Meeting_Agenda_June_2017.pdf, which is saved on his Google Drive. He shares it to his coworkers Joey Clark and Jane Davis via the Google Drive document sharing feature. The item permissions are therefore:

  • jclark@mycompany.com: allowed

  • jdavis@mycompany.com: allowed

  • jsmith@mycompany.com: allowed

John Smith’s boss, Jessica Jones, wants to review Meeting_Agenda_June_2017.pdf. She queries Agenda in a Coveo-powered search page, but to no avail: Meeting_Agenda_June_2017.pdf is not returned in her search results because her security identity, jjones@mycompany.com, is not specified as allowed to access Meeting_Agenda_June_2017.pdf. She must ask the item owner, John Smith, to share Meeting_Agenda_June_2017.pdf with her on Google Drive to access it via the Coveo-powered search page.

CCV2-Permissions-UnspecifiedSecurityIdentities

Public Items and Anonymous Users

Besides a list of allowed and denied identities, the permissions of a item specify whether this item can be accessed by anonymous users, i.e., users that did not log in before making a query. This makes the item public and accessible to anyone, using any security identity, including an Anonymous User identity.

Denied access permissions of an item still prevail over its universal availability. As a result, security identities marked as denied access to a public item cannot retrieve this item.

At MyCompany, the Coveo Cloud search page is used via the main company website by both the employees and the customers. Employees can authenticate in the search page whereas customers, who access the search page with out logging in, are anonymous users.

You index Product_Maintenance_Manual.pdf, an item that both your customers and your employees may need to access, and make this item public, which enables anonymous access to this item. Product_Maintenance_Manual.pdf is therefore available on your Coveo Cloud search page, regardless of whether the page users are authenticated or not.

Anonymous users can therefore see this public item in their search results.

CCV2-Permissions-AnonymousSearch

Logged in employees can see this public item, along with the secured content they are allowed to see.

CCV2-Permissions-BasicSecuredSearch-PublicItems-LoggedInAsJohnSmith

Basic Search Flowchart

The following flowchart summarizes the permission analysis process executed for each item matching a query to determine whether the item should appear in the querying user’s search results.

CCV2-Permissions-FlowchartBasicSearch

Item Permission Update

When item permissions change, the item and its permissions must be recrawled and reindexed for changes to be effective. This is done during a source update, i.e., a refresh, rescan, or rebuild operation (see Refresh VS Rescan VS Rebuild).

Some connectors do not allow indexing item permissions. Among connectors that do, some do not allow updating item permissions during a source refresh operation and rather require a source rescan or rebuild. Refer to the list of available connectors for details.

John Smith is the only user allowed to access the item Meeting_Agenda_June_2017.pdf, which is saved on his Google Drive. When his coworker Jane Doe queries Meeting Agenda June 2017 in Coveo Cloud, this item is not returned because her security identity is not allowed specified in the item permissions (see Unspecified Security Identities).

John Smith wants Jane Doe to access Meeting_Agenda_June_2017.pdf through Coveo Cloud, so he uses the Google Drive sharing feature to add jdoe@mycompany.com as a security identity allowed to access this item. The item will be returned in Jane Doe’s search results after the next Google Drive source update (see Refresh, Rescan, or Rebuild Sources).

What’s Next?

Secured enterprise systems typically include user security identities in group security identities and granted security identities (see Group and Granted Security Identities).