Typical secured search

This is for:

Developer System Administrator
In this article

In a basic secured search scenario, item permissions only mention user security identities. However, since it’s more efficient to give or deny access to a single group of users instead of individual users, Coveo must support group security identities, granted security identities, and security identity aliases as well. See Group and granted security identities and Alias relationship for more information.

You can use search token authentication to implement secured search in your interface. However, before you build your search interface, see which approach is right for you.

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.

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. The process is the same as that involved in a basic secured search scenario, except that it takes the user’s additional security identities or alias relationship into account.

Flowchart illustrating the logic that determines whether a user can access an item through their Coveo search results

The following modest, yet realistic example addresses the three possible security identity relationship types in a secured search scenario:

Notes
Example

John Smith is an engineer and team leader at MyCompany. MyCompany has chosen to index its Jira and Google Drive secured enterprise systems to make their content searchable through Coveo.

In Google Drive, John Smith’s user security identity is included in the teamleaders@mycompany.com group, which is itself included in the management@mycompany.com group. The deptleaders@mycompany.com group is also included in management@mycompany.com, but since John Smith isn’t a department leader, he isn’t included in this group. John Smith is also automatically included in the everyone@mycompany.com granted security identity, just like all employees at MyCompany.

In Jira, John Smith’s user security identity, JSmith01, is part of the Engineering_Dept group and granted the All_Users security identity, which also includes all Jira users.

Note

Since Jira and Google Drive are two separate systems with different security systems, their respective security identities are formatted differently.

Moreover, the Coveo administrator has aliased John Smith’s user security identity, JSmith01, to jsmith@mycompany.com so that John Smith can access Jira content while logged in as jsmith@mycompany.com. See Alias relationship for more information.

The security identity cache therefore stores the following relationships regarding John Smith’s security identities. See Security identity cache:

Coveo security cache stores John Smith’s security identities and their relationships in different systems

John Smith logs in a Coveo hosted search page as jsmith@mycompany.com and is granted the following additional security identities:

  • teamleaders@mycompany.com (Google Drive)

  • management@mycompany.com (Google Drive)

  • everyone@mycompany.com (Google Drive)

  • JSmith01 (Jira)

  • Engineering_Dept (Jira)

  • All_Users (Jira)

When John Smith makes a query, the Coveo security identity cache allows access to many more items than would be available if querying with one of the user security identities only.

  • Scenario 1: The user’s security identity is allowed to access MyCompany_Financial_Report_2016-2017.pdf

    John Smith logs in to Coveo as jsmith@mycompany.com and types Financial Report in the search bar, looking for item MyCompany_Financial_Report_2016-2017.pdf. This item has the following permission model:

    • management@mycompany.com: allowed

    • finance_department@mycompany.com: allowed

    • board_of_directors@mycompany.com: allowed

    • interns@mycompany: denied

    John Smith’s search on a Coveo search page matches several items

    Since one of John Smith’s additional security identities, management@mycompany.com, is allowed to access MyCompany_Financial_Report_2016-2017.pdf and none of John Smith’s security identities is denied access to this item, MyCompany_Financial_Report_2016-2017.pdf is returned in John Smith’s search results.

  • Scenario 2: The user’s security identity is allowed to access Task #114: Review 2016-17 Engineering Department Financial Report, but belongs to different enterprise system than the security identity provided upon login

    John Smith logs in to Coveo as jsmith@mycompany.com and types Financial in the search bar, looking for Jira item Task #114: Review 2016-17 Engineering Department Financial Report. This item has the following permission model:

    • Engineering_Dept: allowed

    • Quality_Assurance_Dept: allowed

    • Interns: denied

    Since one of John Smith’s additional security identities is the allowed Engineering_Dept group and none of the security identities is denied access to Task #114: Review 2016-17 Engineering Department Financial Report, John Smith can access this item.

  • Scenario 3: The user’s security identity is unspecified in the MyCompany_Financial_Report_2016-2017_Draft_with_CEO_Comments.pdf permission model

    John Smith logs in to Coveo as jsmith@mycompany.com and types Financial in the search bar, looking for item MyCompany_Financial_Report_2016-2017_Draft_with_CEO_Comments.pdf. This item has the following permission model:

    • finance_department@mycompany.com: allowed

    • board_of_directors@mycompany.com: allowed

    Since none of John Smith’s security identities are marked as allowed to access MyCompany_Financial_Report_2016-2017_Draft_with_CEO_Comments.pdf, this item isn’t returned in the search results. The security identities are unspecified. To be allowed to access the item, John Smith would need to be added to an allowed group, such as finance_department@mycompany.com, or have his user security identity, jsmith@mycompany.com, added by the item owner to the list of allowed security identities.

  • Scenario 4: The user’s security is denied access to Task #826: Write QA Department Financial Report

    John Smith logs in to Coveo as jsmith@mycompany.com and types Financial in the search bar, looking for Jira item Task #826: Write QA Department Financial Report. This item has the following permission model:

    • Quality_Assurance_Dept: allowed

    • Engineering_Dept: denied

    Since one of John Smith’s additional security identities, Engineering_Dept, is denied access to Task #826: Write QA Department Financial Report, he can’t access this item. Task #826: Write QA Department Financial Report is therefore not displayed in John Smith’s search results.

  • Scenario 5: The user’s security identities specified in the Financial_Forecast.ppt permission model are contradictory

    John Smith logs in to Coveo as jsmith@mycompany.com and types Financial in the search bar, looking for item Financial_Forecast.ppt. This item has the following permission model:

    • management@mycompany.com: allowed

    • teamleaders@mycompany.com: denied

    One of John Smith’s additional security identities is allowed to access Financial_Forecast.ppt and one is denied to do so. When permissions are contradictory, the denial permission prevails, so John Smith can’t access this item. Financial_Forecast.ppt is therefore not displayed in John Smith’s search results.

  • Scenario 6: The user’s security identity is denied access to a public item

    John Smith logs in to Coveo as jsmith@mycompany.com and types Financial in the search bar, looking for public item MyCompany_Financial_Department_Presentation.pdf. This item has the following permission model:

    • jsmith@mycompany.com: denied

    Although MyCompany_Financial_Department_Presentation.pdf is public, John Smith’s security identity is denied access to this item. Since this denial prevails over the item universal availability, MyCompany_Financial_Department_Presentation.pdf is therefore not displayed in John Smith’s search results.

What’s next?

Secured items have at least one permission model that lists the security identities that are allowed or denied access to this item. In more complex scenarios, there are many permission models for a given secured item. See Permission sets for more information.