SitecoreAI security

The SitecoreAI security model enables you to grant or deny access to almost every aspect of a website. To do this, you use security accounts and security domains to control the access that users have to the items and content on their website, as well as the access they have to SitecoreAI functionality.

Note

If a team member has an Organization Admin role in the Sitecore Cloud Portal organization that contains your SitecoreAI app, or an Admin app role in the SitecoreAI app, they can access everything regardless of their security settings or access rights.

Security accounts

A security account is a role or a user.

  • A user account in SitecoreAI contains the username, domain, email, and password. You can assign access rights directly to a user account.

  • A role is a collection of users, or a collection of users and other roles. You can assign access rights to groups of SitecoreAI users by making them a member of a role.

    You can use SitecoreAI's predefined security roles, or you can create new roles that include the relevant access rights.

    Note

    In SitecoreAI, there are also global roles that all users across domains can see.

Note

A security account is identified by its name (domain name\account name, for example, sitecore\Developer or sitecore\ECM advanced users) and therefore, two security accounts cannot have the same name.

Security domains

A security domain is a collection of security accounts (users and roles) to which you can apply common rules and procedures. A domain is used to group security accounts that have some logical relationship, for example, all the accounts that have access to the SitecoreAI clients could be stored in the Sitecore domain, whereas all the accounts with access to the published website could be stored in the Extranet domain.

There are two types of cookies:

  • Session cookies (non-persistent) - these are temporary cookie files. They are erased when the user closes the browser.

  • Persistent cookies - the browser stores these cookie for the lifespan period specified in the cookie file, or until the user deletes them manually.

Modern browsers tend to preserve session cookies between browser sessions when the relevant browser option is turned on. This can make session cookies behave like persistent ones. Open Web Interface for .Net (OWIN) authentication allows you to store the cookie lifespan value in the cookie value itself. It means that if the cookie expires, it's treated as expired by the web application but the browser still sends it to the server. You can also enable sliding expiration, which restarts the cookie lifetime on any request received while the cookie is still active.

You can set a time span after which the authentication cookie expires and is ignored by the browser.

To specify the authentication cookie lifetime, use the following patch snippet to specify the initial cookie lifespan, and to enable or disable sliding expiration:

RequestResponse
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <sitecore>
    <pipelines>
      <owin.initialize>
        <processor name="CookieAuthentication">
          <!-- Controls how much time the cookie will remain valid from the point it is created.
             Format: d:hh:mm:ss
             No matter the cookie is persistent or not, OWIN authentication will not pass the expired cookie.
             ExpireTimeSpan could be overwritten by the http://www.sitecore.net/identity/claims/cookieExp claim where
             the claim value is Unix time expressed as the number of seconds that have elapsed since 1970-01-01T00:00:00Z. -->
          <ExpireTimeSpan>00:30:00</ExpireTimeSpan>
          <SlidingExpiration>true</SlidingExpiration>
        </processor>
        ...

Do you have some feedback for us?

If you have suggestions for improving this article,