Typical Secured Search

In this article

In a basic secured search scenario, item permissions only mention user security identities. However, since it’s often more efficient to mark a single group of users as allowed or denied access to an item instead of marking the users individually, Coveo must support group security identities, granted security identities, and security identity aliases as well (see Group and Granted Security Identities and Alias Relationship).

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 into account (see Group and Granted Security Identities and Alias Relationship).

CCV2-Permissions-Flowchart

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 as jsmith@mycompany.com (see Alias Relationship).

The security identity cache therefore stores the following relationships regarding John Smith’s security identities (see Security Identity Cache):

CCV2-Permissions-SecuredSearchLeveragingSecurityRelationships

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 him to access many more items than he would if querying with one of his 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

    CCV2-Permissions-TypicalCoveoSecuredSearch

    Since one of John Smith’s additional security identities, management@mycompany.com, is allowed to access MyCompany_Financial_Report_2016-2017.pdf and that 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 that none of his security identities is denied access to Task #114: Review 2016-17 Engineering Department Financial Report, he 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 security identities is marked as allowed to access MyCompany_Financial_Report_2016-2017_Draft_with_CEO_Comments.pdf this item isn’t returned in his search results (see Unspecified Security Identities). 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 to 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 (see Denial Prevalence). 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 and therefore accessible to anyone, John Smith’s security identity is denied access to this item (see Public Items and Anonymous Users). Since this denial prevails over the item universal availability, MyCompany_Financial_Department_Presentation.pdf is therefore not displayed in John Smith’s search results (see Denial Prevalence).

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