Authentication and authorization

Abstract

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.

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.

Diagram showing how Sitecore Identity Server stores membership data for users and website visitors in the Security database.

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.

Diagram showing how Sitecore administrators can manage users through the Content Management role.

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.

Security domains segments users into groups allowing for easier administration. The default Sitecore and Extranet security 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.

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 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.

The Sitecore Security database can be separated from the Core into its own database.

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.

Note

While Sitecore Identity Server is the default authentication and authorization system for the Content Management role, Sitecore recommends that you use federated authentication for your authentication and authorization needs on the Content Delivery role.

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.

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

You can configure a visitor user account to be:

  • A virtual user that is transient and only exists as long as the session exists.

  • A persisted user that is stored by the Sitecore Identity Server.

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.