Basic Secured Search

This is for:

In this article

Unspecified Security Identities
Public Items and Anonymous Users
Basic Search Flowchart
Item Permission Update
What’s Next?

A Coveo secured search scenario involves a search interface that displays different content based on the end user’s identity. Typically, the scope of this interface includes at least one source of content that’s secured with a permission system and that’s configured so that this system is replicated in the search interface. As a result, through the search interface, end users can only access the items they’re allowed to access in the original repository.

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 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).

Note

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.

Example

John Smith’s corporate 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 Indexing Pipeline):

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

Note

You can review a list of the permissions applying to each item in the Coveo Administration Console (see Review Effective Permissions on the Item).
The crawler sets jsmith@mycompany.com as the only security identity allowed to access this item.

End-user query

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.
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.
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 isn’t specified.
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 isn’t allowed to access.

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.

Note

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.

Note

The permissions in the example above are item-specific; permissions may also apply to the source content as a whole with connectors that don’t support item-specific permissions.

Unspecified Security Identities

If the permissions of an item don’t specify whether a certain security identity is allowed or denied access to this item, the user authenticated with this security identity can’t see this item in their search results: when information is lacking, Coveo 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).

Example

John Smith is the author and owner of Meeting_Agenda_June_2017.pdf, which is saved on his corporate 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 isn’t returned in her search results because her security identity, jjones@mycompany.com, isn’t 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 using 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, that is, users that didn’t log in before making a query. This makes the item public and accessible to anyone, using any security identity, including an Anonymous User identity.

Note

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 can’t retrieve this item.

Example

At MyCompany, the Coveo-powered search page is used through the main company website by both the employees and the customers. Employees can authenticate on 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-powered search page, regardless of whether the page users are authenticated or not.

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

Logged-in employees can see this public item, along with the secured content they’re 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.

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, that is, a refresh, rescan, or rebuild operation.

Note

Some connectors don’t allow indexing item permissions. Among connectors that do, some don’t allow updating item permissions during a source refresh operation and rather require a source rescan or rebuild. See the desired connector page for details.

Example

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

John Smith wants Jane Doe to access Meeting_Agenda_June_2017.pdf through Coveo, 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).