Security Identity Relationships
Security Identity Relationships
A group or granted identity is usually related to at least another security identity (see Group and Granted Security Identities). Such relationships between security identities are crucial when determining the effective permissions of an item.
|
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. |
Child/Parent Relationship
Two security identities are in a child/parent relationship when one security identity includes another one. In other words, when a group contains several users, the group has a child relationship to each of the users, and each user has a parent relationship to the group. Similarly, if a user has a granted identity, the granted identity has a child relationship to the user, and the user has a parent relationship to the granted identity. A single security identity can have many child relationships and many parent relationships.
Identities in a direct child/parent relationship are directly linked to each other. For example, the users in a group are direct children of this group. However, if Group 1 contains Group 2, which then contains users, then these users are indirect children of Group 1 and direct children of Group 2. Similarly, Group 1 is a direct parent of Group 2, and an indirect parent of the users.
Coveo combines all security identity relationships to create a hierarchical representation of all security identities of a secured enterprise system. Therefore, it can extract from this representation a list of all parent security identities of every single security identity (see Granted Security Identities). As explained under Security Identity Cache and Provider, this list is crucial because it’s used by the index to filter search results.
At MyHospital, there are two teams in the Medical Department: the nurse team and the doctor team.
So, medical_dpt@myhospital.com is a group that contains groups nurses@myhospital.com and doctors@myhospital.com.
medical_dpt@myhospital.com is therefore a direct parent of nurses@myhospital.com, and nurses@myhospital.com is a direct child of medical_dpt@myhospital.com.
John Smith and Barbara Allen are both nurses.
nurses@myhospital.com is therefore a direct parent of jsmith@myhospital.com and ballen@myhospital.com, while jsmith@myhospital.com and ballen@myhospital.com are both direct children of nurses@myhospital.com and indirect children of medical_dpt@myhospital.com.
Moreover, all user security identities, such as jsmith@myhospital.com, are children of both the Medical Department group security identity and the group security identity corresponding to their respective team.
In such a scenario, an item to which access would be allowed to medical_dpt@myhospital.com only could be viewed by all nurses and doctors at MyHospital, that is, John Smith, Barbara Allen, Martin Doe, and Jodie Bates.
An item to which access would be allowed to nurses@myhospital.com only, however, could only be accessed by nurses John Smith and Barbara Allen.
Alias Relationship
The basic secured search scenario applies only for content and users of the same system. So, for a user to access the content they’re allowed to access, they must make their query while authenticated with a security identity from the same system as the queried content. alias relationships (formerly known as user mappings) solve this limitation, therefore making the use of Coveo much more efficient and intuitive.
Two user security identities are in an alias relationship (or sibling relationship) when they represent the same user in two different systems. Aliasing user security identities allows the user they represent to query Coveo with a user security identity and accessing content from a source they should otherwise access with the other security identity.
At MyCompany, John Smith can log in to a Coveo-powered search interface using either his corporate email address, jsmith@mycompany.com, or an additional, unrelated Google email address, jsmith@gmail.com used for Google Drive storage purposes.
If jsmith@gmail.com isn’t considered as an alias of John Smith’s corporate email address, John Smith can see his Google Drive content when logging in as jsmith@gmail.com, but not when logging in as jsmith@mycompany.com.
The same applies for John Smith’s corporate address, which is related to his corporate emails.
However, if John Smith’s Google security identity is identified as an alias of John Smith’s corporate email security identity, John Smith can log in to a Coveo-powered search interface with his corporate email address, and then access the content accessible to either of those identities.
John Smith can therefore retrieve emails as well as Google Drive content when logged in as jsmith@mycompany.com.
|
|
Note
Alias relationships are currently unidirectional. When a security identity provider identifies an identity A as an alias of an identity B, content available to A is available when searching as B, but content available to B isn’t accessible when logging in as A. We recommend that you alias all security identities representing a user to a single identity that can be used to log in to the Coveo-powered search page, such as an email address (see Log in to Coveo). |
In the example scenario above, jsmith@gmail.com is an alias of jsmith@company.com.
As a result, when John Smith logs in to a Coveo-powered search interface with his corporate email address, he can access both his emails and his Google Drive content.
However, if he logs in as jsmith@gmail.com and makes a query, only Google Drive content will be accessible.
|
An alias relationship allows a security identity to access secured data from a different system without requiring the credentials with which this data is secured. When aliasing a security identity B to a security identity A, the developer in charge of these aliases must be aware that any discrepancy or mistake could lead to a security hole. This is especially important when using a regex to alias all security identities from a system to security identities of another system. For example, Jane Smith was hired at MyCompany before John Smith.
Her corporate email address is therefore |
|
|
Note
When a security identity in a system A has several aliases in a system B, logging in and searching with the security identity system A shows results available to all user aliases of this account at once. This happens frequently when conducting user acceptance tests, or in QA or staging environments, as a tester may set up many test accounts using their corporate email address. For example, John Smith is a software tester at MyCompany. To conduct his tests appropriately, he sets up several email addresses. These email addresses are each marked as allowed to see content that none of the other test addresses are allowed to access. John Smith then aliases these test addresses to his corporate email address. Therefore, when he logs in to a Coveo-powered search page using his corporate email address, he can see the content associated to each of his test addresses. 
|
Denial Prevalence
If a user is both denied and allowed access to an item at once, that is,they have at least one of their security identities that is allowed to access the item, and at least one that is denied access, the denial prevails over the allowance.
John Smith is both a software developer and team leader, and therefore belongs to both the Software Developers and the Team Leaders groups. Using Coveo, he tries to retrieve an item to which access is allowed to the team leaders, but denied to the software developers. Since the Denied permission prevails over the Allowed permission, the desired item doesn’t appear in John Smith’s search results.
Denial also prevail over the universal availability of a public item (see Public Items and Anonymous Users).
What’s Next?
In Coveo, the security identity cache and a security identity provider work together to recreate and handle security identity relationships (see Security Identity Cache and Provider).
Very useful
Not really
Very useful
Not really