Authentication and authorization


Overview of Sitecore authentication and authorization with security domains and federated authentication.

You can use Experience Manager (XM) to host portals or secure websites and webshops. The system has a flexible and integrated authentication system with username/password authentication, as well as integration to custom or more advanced authentication systems, such as federated authentication. It also allows granular authorization so that you can secure website sections, pages, or even specific content.

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 role, they are, by default, met with a login prompt.

The default security authentication and authorization system is based on the Microsoft ASP.NET membership, which is a standard way to validate and store user credentials. ASP.NET membership can implement different providers in order to store and access credentials and user profiles in different systems. By default, Sitecore uses an SQL based ASP.NET membership provider and the users are stored in the Core database.

By default, Sitecore uses the Core database for storing ASP.NET membership data for both Sitecore users and website visitors.

Therefore, when a user logs in, Sitecore authenticates the username and password against the data stored in the Core database, and if the authentication succeeds, it grants access to the management tools. Sitecore writes all authentication attempts, whether successful or not, as well as user and role creation, changes, and deletions to the Sitecore audit logs for traceability.

Administrators can search and manage users in the User Manager served through the Content Management role. Administrators can, for example, create and delete user accounts, change the user profile details, disable and enable accounts, and change passwords. They can also 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 administrators can manage users through the Content Management role.

The different Sitecore features ship with a set of roles that enable you to access the management tools for the feature, for example, to manage users and roles, to view analytics and reporting, to manage email marketing or marketing automation, and so on.

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 even more granularly and restrict or grant access to certain fields or languages.

Domains separate Sitecore administrative users from users on, or visitors to, the website.

A security domain is a collection of security accounts (that is, users and roles) that you administer as a unit with common rules and procedures. A domain is a collection of security accounts that have some logical relationship. 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.

Sitecore manages all users and roles in a domain through a single ASP.NET Membership provider, and multiple domains can share the same provider. Both the Sitecore and Extranet domain uses the SQL provider and are stored in the Core database.

Security domains segments users into groups allowing for easier administration. The default Sitecore and Extranet security domains are stored in the Core 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 is entirely configurable and determined by 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. A user account is created through the ASP.NET membership provider and stored in the Core database or in another ASP.NET membership provider.

The business requirements of the website determine the format of the user name. However, two user accounts in the same domain cannot have the same user name. 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 Core database – or through another ASP.NET membership provider. You can also manage custom user profile fields in the Sitecore user management tools.


Some ASP.NET membership providers might restrict the write access for Sitecore or administrators and therefore restrict access to creating and managing users through the website or management tools.

When a visitor attempts to logs in, the supplied user name and password are authenticated against the user accounts Core 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 now 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.

You can track and store a users behavior through the xConnect Collection role if your implementation is running the Sitecore Experience Platform.

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 information stored in the user account and on the user profile can be used for personalization.

You can separate a domain into its own SQL database. You can also employ other (or a mix of) ASP.NET membership providers to integrate towards an Active Directory in the Sitecore domain, and you can create custom ASP.NET membership providers against other sources.

Sitecore security domains can be separated into their own databases, and you can a mix of ASP.NET membership providers.

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 an ASP.NET membership provider, but is created transiently in the Private Session State Store. This approach to user authentication of course 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 ASP.NET Membership providers, Sitecore also supports federated authentication through ASP.NET Identity and the Oauth and Owin standards. You can use Federated Authentication to let users log in to Sitecore or the website though an external provider such as Facebook, Google, Microsoft Account, Twitter, Azure AD, or ADFS. 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 provider or visits a specific login page on the website. This redirects the visitor to the external provider’s authentication page, where the visitor will authenticate against the external provider.

If successful, the external provider will typically get 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 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.

Federated authentication allows you to use a third party authentication service such as Facebook or Google and store authorize against a virtual or persisted user.

You can configure a visitor user account to be:

  • Virtual User – transient and only exists as long as the session exists.

  • Persisted – stores the user using the ASP.NET membership provider configured for the domain.

Federated Authentication works both for website and Sitecore logins meaning both the Content Delivery and Content Management roles.

Refer to the Architecture and Roles documentation for privacy and security considerations for each role on the processing and aggregation data flow.