Basic Secured Search
A Coveo Cloud 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 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 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,
email@example.com, is the only security identity allowed to access this item.
Indexing process (see Coveo Cloud V2 Indexing Pipeline):
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).
The crawler sets
firstname.lastname@example.org the only security identity allowed to access this item.
John Smith logs into a Coveo-powered search interface using the same identity as that allowed to access the desired item, his
email@example.comGoogle security identity.
When John Smith performs a search, the identity with which he logged into the search interface,
firstname.lastname@example.org, is passed to the index along with the query.
Retrieves all items matching the query.
Filters out items to which
email@example.com denied access, as well as items in the permissions of which this security identity isn’t specified (see Unspecified Security Identities).
Returns the results to the search interface.
firstname.lastname@example.org 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.
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.
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 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:
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,
email@example.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.
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 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.
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.
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.
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.
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, i.e., a refresh, rescan, or rebuild operation (see Refresh VS Rescan VS Rebuild).
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 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 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 Cloud, so he uses the Google Drive sharing feature to add
firstname.lastname@example.org 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).
Secured enterprise systems typically include user security identities in group security identities and granted security identities (see Group and Granted Security Identities).