Security Identity Cache and Provider
Two additional modules must intervene in the indexing and querying processes to support item permissions consisting of groups or granted security identities: the security identity cache and a security identity provider. These modules work together to recreate and handle security identity relationships and fully support more complex secured search scenarios.
In this module interaction diagram:
Blue boxes represent modules involved in the indexing process. However, the security identity provider is also involved in the querying process when a new user makes their first query (see Identity Refresh).
Gray boxes represent modules involved in the querying process.
Orange boxes represent modules involved in both the indexing and the querying process.
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.
Security Identity Cache
The basic secured search scenario consists of determining whether a user is allowed to access an item. If the user’s security identity is allowed to access the item, the item is returned in the user’s search results. If the user’s security identity is denied access to the item or if it’s not specified in the item permissions, the user can’t access the item (see Unspecified Security Identities).
In the basic secured search scenario, users query Coveo Cloud using a single security identity. However, this scenario doesn’t reflect the typical permission model: administrators of secured enterprise systems often mark a group security identity as allowed to access an item instead of listing several user security identities in the item permissions (see Group and Granted Security Identities). To support permission models including group and granted security identities, Coveo Cloud must take the relationship between the user and their group, granted identity, or alias into account (see Security Identity Relationships).
The security identity cache is a module that stores and maintains a list of all relationships between security identities. Upon its first encounter with a security identity, the security identity cache queries the security identity provider to retrieve the security identity relationships. Then, when a user logs in to a Coveo-powered search interface, the security identity cache provides them with additional security identities corresponding to their aliases, to their granted identities, and to the groups of which they’re a member. The user therefore makes a query using several security identities, which may or may not match the security identities allowed to access the queried item.
It’s not necessary to have all allowed security identities to access an item. An item is returned in the search results as long as:
At least one of the user’s security identities is marked as allowed to access the item.
None of the user’s security identities is marked as denied access to the item.
For example, the
R&D_Roadmap_2017.pdf item has the following permissions:
John Smith wants to access
R&D_Roadmap_2017.pdf. He logs in as
firstname.lastname@example.org, and is granted the following additional security identities:
John Smith now makes a query using his four security identities. One of them matches the security identities allowed to access
R&D_Roadmap_2017.pdf, and none of them is denied access to the item.
R&D_Roadmap_2017.pdf is therefore returned in John Smith’s search results.
Security Identity Provider
The role of a security identity provider is to extract all relationships of a security identity: the group members, the granted identities and the identity aliases (see Security Identity Relationships and Security Identity Cache). Once extracted, these relationships are stored by the Coveo Cloud security identity cache. Therefore, the security identity provider acts as a bridge between the secured enterprise system and the Coveo Cloud security identity cache. You can review a list of your security identity providers in the Coveo Administration Console (see Manage Security Identities).
When a newly created user logs in to a Coveo-powered search page for the first time and makes a query, this user’s granted security identities are retrieved during the querying process. The user can then access the items these granted identities are allowed to access (see Group and Granted Security Identities). However, group members are only retrieved and provided to the security identity cache when the group is refreshed, i.e., updated (see Manage Security Identities).
Automatic security identity refreshes are scheduled daily by default (see Edit Security Identity Provider Refresh Schedules). These scheduled refreshes update all security identities of a security identity provider. However, a Coveo Cloud administrator can manually refresh the identities at any time. Such an update makes new users’ group security identities available immediately rather than following the next scheduled refresh. The administrator can either refresh the identities of all identity providers or of a single identity provider (see Refresh All Security Identities or Refresh a Security Identity Provider). The result is the same, i.e., the security cache is updated with the new identity relationships, but updating a single security identity provider is less time- and resource-consuming.
John Smith is a new employee at MyCompany. On his first day of work, the system administrator adds John Smith’s user security identity,
jsmith, to the following Jive groups:
The secured enterprise system also grants
Jive\jsmith the following granted security identities:
If the Coveo Cloud administrator doesn’t manually launch a security identity refresh, until the next scheduled refresh, John Smith won’t be able to access
Engineers_Training.pdf, which has the following permission model:
MyCompany_Presentation.pdf has the following permission model:
John Smith can always access this item upon his first query because his granted security identities, among which one matches the item permissions, have already been provided to the security identity cache.
Item permissions and the security identity relationships stored in the security identity cache are updated differently. When item permissions change (e.g., you share a Google Document with someone else), this change becomes effective following an incremental refresh, a rescan, or a rebuild of the corresponding source (see Item Permission Update). However, if members of a group change (e.g., a new employee is hired and added to existing groups), the source security identities must be refreshed.
In a typical secured search scenario, a user can access an item if at least one of their security identities is allowed to access it, and if none of their security identities is denied access to this item.