Try our conversational search powered by Generative AI!

Loading...
Applies to versions: 14 and higher
Other versions:
ARCHIVED This content is retired and no longer maintained. See the version selector for other versions of this topic.

Authorization and authentication

Recommended reading 
Note: This documentation is for the preview version of the upcoming release of CMS 12/Commerce 14/Search & Navigation 14. Features included here might not be complete, and might be changed before becoming available in the public release. This documentation is provided for evaluation purposes only.

This topic describes the authentication and authorization model in Optimizely Commerce.

The authentication in Optimizely CMS is based on the ASP.NET Core built-in framework for users and roles. Optimizely CMS uses a standard API that makes it easy to create your own provider for any type of user database, and third-party providers.

In addition, the Optimizely Commerce sample site has several predefined users, groups, and roles for managing content and administering Commerce tasks.

Terminology

Authentication and authorization are used by the system to identify users and user groups, and determine what they are allowed to do. Here are common terms used in this context:

  • Authentication. The process of identifying a user. Typically done via username and password.
  • Authorization. The process of determining actions a user is allowed to perform.

Administering security and access rights

When you administer access rights, use the following distinct components, which are loosely tied together. The EPiServer.CMS.UI.AspNetIdentity implements and registers the UIUserProvider, UIRoleProvider, UISignInManager and SecurityEntity provider in the container.

  • Users. Delivered by the current UIUserProvider.
  • Roles. Delivered by the current UIRoleProvider and the virtual roles.
  • Access control lists (ACLs).

An ACL is a list of SecurityEntity classes and an access level. The security entity is a name and information stating whether the name represents a role or a user. A security entity in an ACL is not affected by changes in the UIUserProvider or UIRoleProvider implementations. So if you delete a role and then look at an ACL that had an access entry for this role, it still appears in the ACL.

Commerce-specific virtual roles

In addition to the default Optimizely CMS groups (WebAdmins, WebEditors etc), Commerce has virtual roles that you can use to control access to parts of the user interface.

  • CommerceAdmins. Access to all parts of Commerce except Administration and CMS admin view.
  • CommerceSettingsAdmins. Access to Settings menu for administering, for instance, dictionary values.
  • CatalogManagers. Access to the Catalogs user interface.
  • MarketingManagers. Access to the Marketing user interface.
  • CustomerServiceRepresentatives. Access to the Order management screen.

Note: MarketingManagers group users also have access to the CMS editing user interface by default. To restrict this group's ability  to edit content, limit access via the Admin view > Set Access Rights screen. Here, grant "Read" access to MarketingManagers.

To add a role, add a user to role, or check if a user is assigned to a role, you can use UIRoleProvider.

_roleProvider.CreateRoleAsync(roleName);
_roleProvider.AddUserToRoleAsync(username, roleName);
var userRoles = _roleProvider.GetRolesForUserAsync(userName);

Related topics

Do you find this information helpful? Please log in to provide feedback.

Last updated: Jul 02, 2021

Recommended reading