Typical Secured Search
Typical Secured Search
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).
The following modest yet realistic example addresses the three possible security identity relationship types in a secured search scenario:
-
Parent/child relationship with a group (see Group Security Identities and Child/Parent Relationship)
-
Parent/child relationship with a granted security identity (see Group and Granted Security Identities and Child/Parent Relationship)
-
Alias relationship (see Alias Relationship)
Notes
|
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):
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 typesFinancial Report
in the search bar, looking for itemMyCompany_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
Since one of John Smith’s additional security identities,
management@mycompany.com
, is allowed to accessMyCompany_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 loginJohn Smith logs in to Coveo as
jsmith@mycompany.com
and typesFinancial
in the search bar, looking for Jira itemTask #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 toTask #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 modelJohn Smith logs in to Coveo as
jsmith@mycompany.com
and typesFinancial
in the search bar, looking for itemMyCompany_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 asfinance_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 typesFinancial
in the search bar, looking for Jira itemTask #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 toTask #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 contradictoryJohn Smith logs in to Coveo as
jsmith@mycompany.com
and typesFinancial
in the search bar, looking for itemFinancial_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 typesFinancial
in the search bar, looking for public itemMyCompany_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).