Authentication and authorization

Sitecore uses the same security mechanism to authorize users and secure data on websites, webshops, or portals as it does to authenticate and authorize users of the administrative interfaces.

This means that when an administrator, content author, marketer, or other user tries to access the Sitecore management tools served through the Content Management (CM) role, by default they are met with a login prompt.

The default security authentication and authorization system is based on Sitecore Identity Server that stores the membership data in the Security database. Sitecore Identity Server is a single sign-on solution that is used to log in to both XM and Sitecore Commerce.

When a user logs in, Sitecore Identity Server authenticates the username and password against the data stored in the Security database and, if the authentication succeeds, grants access to the management tools. For traceability, Sitecore writes all authentication attempts, both successful and unsuccessful, to the Sitecore audit logs. It does the same for user and role creation, changes, and deletions.

Administrators can search and manage users in the User Manager served through the CM role. Administrators can, for example, create and delete user accounts, change the user profile details, disable and enable accounts, and change passwords. In addition, they can create and manage roles for authorization and assign users to roles. It is also possible to create roles within roles and therefore manage authorization hierarchies.

Sitecore ships with a set of roles that lets you access different features, for example, managing users and roles, viewing analytics and reporting, and managing email marketing.

For content management, a user receives authorization on a content level. This makes it possible to assign roles and users to specific content hierarchies. You can grant or restrict access to manage specific sites, sections of a site, types of content, and so on. On each piece of content you can control the right to view, create, delete, or edit. You can also control content access at a greater level of detail and restrict or grant access to certain fields or languages.

Sitecore uses security domains to separate administrative users from other website users.

A security domain is a collection of security accounts (that is, users and roles) with some logical relationship that you can administer as a unit with common rules and procedures. For example, by default all the accounts that have access to use the Sitecore administrative interface are in the Sitecore domain, whereas all the accounts with access to the secure website are in the Extranet domain.

Both the Sitecore and Extranet domains are stored in the Security database.

All visitors on the website have an associated user account. For users who are not authenticated there is an Anonymous user account.

If an anonymous user wants to visit a restricted page, the system can be configured to show them an access denied message or redirect them to a login page. This can be completely configured according to the business requirements of the website.

If the website allows user logins, the user can register on the website by providing a username, password, and possibly other user profile information. The user account is created and stored in the Security database.

The business requirements of the website determine the format of the username. However, two user accounts in the same domain cannot have the same username. When a user is created, it can immediately be associated with one or more security roles through the Security API. You can use roles to authorize users for different sections or features on the website.

As an administrator, you can change the role membership of users using the Sitecore administrative interface. You can customize a user profile associated with a user account or extend it with custom fields. Any required information that a business wants to collect and store about users can be stored alongside the user account in the Security database. You can also manage custom user profile fields in the Sitecore user management tools.

When a visitor attempts to logs in, the supplied username and password are authenticated against the user accounts in the Security database. On success, the visitor becomes associated with the authenticated user account and obtains authorization matching the user account's membership roles.

All website visitor logins, registrations, or user account changes are logged in the audit log for compliance and transparency.

If your Sitecore implementation is running the Sitecore Experience Platform (that is, it uses xConnect and the Sitecore Experience database), you can register the user account against xConnect through the xConnect Collection role, and user behavior is tracked against the user account. It is then possible to load contacts and personalize content and experiences based on previous visits or previous behavior, or even based on visits or behavior on other devices.

When a visitor re-visits a secure page and the user account (or the roles associated with the user account) is authorized to read the page content, the visitor is presented with the secure page and the visit is stored in the user account and on the user profile to be used for personalization.

Sitecore also supports virtual users which is a transient user account system for integrating with custom authentication systems. A virtual user is not retrieved or stored through the Sitecore Identity Server but is created transiently in the Private Session State Store. However, this approach to user authentication requires custom solution code through the Security API. It also prevents you from managing user accounts through the Sitecore user management tools. Roles or user profile information for virtual users must also be assigned through custom solution code.

In addition to authentication through the Sitecore Identity Server, Sitecore also supports federated authentication through the Oauth and Owin standards. You can use federated authentication to let users log in to Sitecore or the website through an external provider such as Facebook, Google, or Microsoft. Federated authentication requires that you configure Sitecore in a specific way, depending on which external provider you use.

When a visitor wants to log in to the website using federated authentication, the visitor typically clicks a link to the authentication provider or visits a specific login page on the website. This redirects the visitor to the external provider’s authentication page where the visitor is authenticated.

If successful, the external provider typically creates an authentication token and then redirect the authenticated user back to a federated authentication handler in Sitecore – with the token.

Depending on the external provider, Sitecore can use the provided token to verify the identity of the user and retrieve additional pieces of information, called claims, from the external system.

In Sitecore, the visitor is logged in through the standard Security API and is given a user account in a domain as well as a user profile. Sitecore can map the claims retrieved from the external system to fields in the user profile and use them on the website as user information or personalization.

You can configure a visitor user account to be:

Federated authentication works both for websites (Content Delivery) and Sitecore logins (Content Management).

Refer to the Architecture overview documentation for privacy and security considerations for each role.