--- title: Handling of Sitecore access rights slug: '2311' canonical_url: https://docs.coveo.com/en/2311/ collection: coveo-for-sitecore-v5 source_format: adoc --- # Handling of Sitecore access rights Sitecore provides website administrators the ability to be very specific as to the items a user should be allowed to view. Sitecore handles access rights with a combination of the following: * Security accounts (that is, _users_ and _roles_) * Access rights on items * A set of rules that determine how conflicting access rights are resolved The goal of this article is to explain how Coveo for Sitecore replicates the Sitecore access right data model and how it emulates Sitecore logic in determining whether a user should be allowed to see a given item in a Coveo-powered search interface results list. ## Sitecore security accounts A Sitecore _security account_ is either a _user_ or a _role._ A role consists of a collection of users who typically share common functions. Sitecore website administrators typically prefer to group users in roles and then specify access rights at the role level. This practice simplifies and streamlines management of permissions. See [Sitecore security](https://doc.sitecore.com/xp/en/developers/81/sitecore-experience-platform/sitecore-security.html) for details. A Sitecore security account is defined by its name, which is the combination of a _domain name_ and an _account name_ (for example, `sitecore\Developer`). ## Sitecore security domains A [_security domain_](https://doc.sitecore.com/xp/en/developers/81/sitecore-experience-platform/security-domains.html) is a collection of security accounts that share some logical relationship. Sitecore comes with the following default domains: * _Extranet_ The default domain for website visitors. Most website visits are registered under the `extranet\Anonymous` user. * _Sitecore_ The users that can access the Sitecore clients such as website content authors and developer. * _Default_ Only used when no default domain is specified in the site configurations. ## Sitecore access rights By default, Sitecore associates all new users and roles with the `sitecore\Everyone` role, and this role has `Read` access allowed on all items by default. This way, Sitecore is now able to resolve `Read` access rights to items for the newly created security account. After creating a security account, you can start assigning access rights to the security account at the item level. Coveo for Sitecore uses the `Read` access right setting of an item to determine if a user should be allowed to see the item in a search result list. Consequently, the following sections focus mainly on the impact of other rights and settings on the `Read` access right value resolution. ### Granting the Administrator right to a Sitecore user When creating a Sitecore user, you can specify through a checkbox that the user is an Administrator. ![Screenshot of the Sitecore Edit User window with the Administrator checkbox checked](https://docs.coveo.com/en/assets/images/c4sc-v5/sitecore-admin.png) When you grant the `Administrator` right, the user has `Read` access to all items in the Sitecore content tree. > **Note** > > Setting the user as an `Administrator` doesn't add the user to any Sitecore role. ### Assigning access rights on an item to a security account in Sitecore When assigning access rights on an item to a security account in Sitecore, the following access rights can impact the `Read` access right value resolution for the user in Sitecore and, as a consequence, the right the user has to see the item in a search interface results list: * The `Read` access right You can set this access right to `Allowed` or `Denied` on a Sitecore item for the selected security account. * The `Inheritance` access right By default, all Sitecore items inherit access rights from their parents in the content tree. However, you can prevent an item from inheriting access rights for the selected security account by setting its `Inheritance` access right to `Denied`. Two additional security options can be set on an item which have an impact on the `Read` access right value for all security accounts: * The `Require Login` option When you set an item to `Require Login`, you essentially set its `Read` access to `Denied` for the `extranet\Anonymous` user, and therefore force users to log in through the Sitecore client before they can request the item or one of its descendants. * The `Remove Inherit` option This sets the `Inheritance` access right to `Denied` for the `Everyone` role, which all users and roles are members of. This option therefore negates, for all users, the `Read` access right that the item and its descendants would otherwise inherit from parent items. ## Sitecore rules for conflicting access rights In Sitecore, many access rights and settings come in play when determining if a user should be granted `Read` access rights on a given item, and these access rights and settings inevitably bring about conflicts. Hence, Sitecore has default access right values and a set of rules to avoid insufficient information scenarios, and determine which security setting overrides another. The following table presents the default values for access rights. [%header,cols="2"] |=== |Access Rights |Default Value |All rights |`Denied` |`Inheritance` |`Allowed` |=== When all else is equal, the following rules determine the resolved value for the `Read` access right a given security account has over an item: * `Denied` overrules `Allowed`. * User access rights overrule role access rights. * Access rights explicitly specified on an item directly overrule access rights inherited from a parent. * Access rights explicitly granted overrule the `Inheritance` access right and rights inherited from a parent. For more details regarding Sitecore access rights conflict management, see [Assigning access rights](https://doc.sitecore.com/xp/en/developers/81/sitecore-experience-platform/assigning-access-rights.html). ## Coveo security identities Coveo for Sitecore automatically updates Coveo identities so that they remain in sync with Sitecore security account data. The role of the security cache is to store and maintain a list of all relationships between Sitecore security identities (for example,role - user relationships). Your [Coveo Platform](https://docs.coveo.com/en/186/) security identity cache is synchronized automatically on a daily basis. Sitecore security account modifications and index rebuilds also trigger immediate security identity cache updates (see [Security identity cache and provider](https://docs.coveo.com/en/1527/)). In your Coveo organization, you can view the content of your security cache as follows: . Access the [Coveo Administration Console](https://platform.cloud.coveo.com/login) ([platform-ca](https://platform-ca.cloud.coveo.com/login) | [platform-eu](https://platform-eu.cloud.coveo.com/login) | [platform-au](https://platform-au.cloud.coveo.com/login)). . If applicable, select the organization associated with your production environment Sitecore instance. . In the main menu, select **Security Identities**. . Select the **Expanded Sitecore Security Provider** associated with your Sitecore instance. . Click **Explore Identities**. ## Coveo item permissions management Coveo for Sitecore pushes Sitecore access rights to the [Coveo Platform](https://docs.coveo.com/en/186/) so that when a Sitecore website visitor uses a Coveo for Sitecore search interface to perform a search query, Coveo can return only search results the user is authorized to see. The following sections describe how under the hood, Coveo uses permission levels and sets to map Sitecore access rights. ### Coveo permission levels and sets Coveo for Sitecore feeds Coveo with item permissions inside a JSON object which contains a [permission levels](https://docs.coveo.com/en/1526/) array. Permission levels in this array are listed by order of precedence and each permission level consists of one or several [permission sets](https://docs.coveo.com/en/2007/). The following table summarizes the Coveo rules applied for permission level precedence, permission set data, and the analysis logic. [%header,cols="2"] |=== |Rule |Description |[Denial prevalence](https://docs.coveo.com/en/1618#denial-prevalence) |If a user has at least one of their security identities that's allowed to access the item, and at least one that's denied access, the denial prevails over the allowance. |[Unspecified security identities](https://docs.coveo.com/en/1749#unspecified-security-identities) |If the permissions of an item don't specify whether a certain security identity is allowed or denied access to this item, the user authenticated with this security identity can't see this item in search results. |[Public items and anonymous users](https://docs.coveo.com/en/1749#public-items-and-anonymous-users) |The permissions of an item specify whether this item can be accessed by anonymous users, that is, users that didn't log in before making a query. This makes the item public and accessible to anyone, using any security identity, including an Anonymous User identity. |=== When analyzing the permission sets of permission level `n` of an item, Coveo either determines that the item should be included or excluded from the search results list, or the process moves on to analyze the permission sets for permission level `n+1`. ### How Coveo for Sitecore maps Sitecore rights to permission levels Each time a Sitecore item is created or updated in the content tree, Sitecore calls Coveo for Sitecore. Coveo for Sitecore can then update its permission representation accordingly. The following table shows how Coveo for Sitecore builds the JSON permission level representation it sends to Coveo using the rights specified in Sitecore. The table also explains how Coveo ultimately determines whether the querying user will be allowed to see the given item in a Coveo for Sitecore search results list. [%header,cols="^1,2,3a"] |=== |Permission level |Sitecore rights mapped to permission sets |Condition required for conclusive analysis |1 |Sitecore `Administrator` right |If the querying user is a member of the Sitecore `Administrator` group, the item is included in search results. |2 |`Read` access rights for users specified directly on the queried item |If the permission sets include one for the querying user, the analysis is conclusive. * If `Read` is `Denied`, the item isn't included in search results. * If `Read` is `Allowed`, the item is included in search results. |3 |`Read` access rights for roles specified directly on the queried item |If the permission sets include at least one role the querying user is a member of, the analysis is conclusive. * If `Read` is `Denied` on at least one role the querying user is a member of, the item isn't included in search results. * If `Read` is `Allowed` on all roles the querying user is a member of, the item is included in search results. |4 |`Read` access rights for users specified on the immediate parent of the item |If the permission sets include one for the querying user, the analysis is conclusive. * If `Read` is `Denied`, the item isn't included in search results. * If `Read` is `Allowed`, the item is included in search results. |5 |`Read` access rights for roles specified on the immediate parent of the item |If the permission sets include at least one role the querying user is a member of, the analysis is conclusive. * If `Read` is `Denied` on at least one role the querying user is a member of, the item isn't included in search results. * If `Read` is `Allowed` on all roles the querying user is a member of, the item is included in search results. |6 |`Read` access rights for users specified on the second parent of the item |If the permission sets include one for the querying user, the analysis is conclusive. * If `Read` is `Denied`, the item isn't included in search results. * If `Read` is `Allowed`, the item is included in search results. |7 |`Read` access rights for roles specified on the second parent of the item |If the permission sets include at least one role the querying user is a member of, the analysis is conclusive. * If `Read` is `Denied` on at least one role the querying user is a member of, the item isn't included in search results. * If `Read` is `Allowed` on all roles the querying user is a member of, the item is included in search results. |8 |`Read` ... users ... third parent of the item |If the permission sets include one for the querying user... |=== For information on accessing and reviewing user and group permissions over an item in the Coveo Administration Console, see [Permissions tab](https://docs.coveo.com/en/1712#permissions-tab). For information on accessing and reviewing permission level and permission set data for an item in the Coveo Administration Console, see [Permissions Details tab](https://docs.coveo.com/en/1712#permission-details-tab). ## Permissions retrieval when performing a query When performing a query in a Coveo Hive search interface, Coveo for Sitecore calls the reverse proxy in your Sitecore instance. The reverse proxy relays the request to the Coveo Platform, which returns a JSON list of items, all of which the querying user is allowed to view. See [About the Architecture of Coveo for Sitecore](https://docs.coveo.com/en/2554/) for more details.