HomeDev GuideAPI Reference
Dev GuideAPI ReferenceUser GuideGitHubNuGetDev CommunitySubmit a ticketLog In
GitHubNuGetDev CommunitySubmit a ticket

Authorize and authenticate

Describes the authentication and authorization model in Optimizely Customized Commerce 13.

This topic describes the authentication and authorization model in Optimizely Customized Commerce, which uses the default membership and role system in ASP.NET. You configure membership and role providers in the website's web.config file. The Customized 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.
  • Provider. A module called by ASP.NET to provide an underlying service.
  • Membership provider. The module that handles authentication in the ASP.NET security model.
  • Role provider. The module that gives the base data for authorization in the ASP.NET security model.
  • Profile provider. The module that stores and retrieves personalized data in ASP.NET.

Administer security and access rights

When you administer access rights, use the following distinct components, which are loosely tied together.

  • Users. Delivered by the current membership provider.
  • Roles. Delivered by the current role provider 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 membership or role provider. 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.

Membership providers have APIs for creating, editing and deleting users. The SQL membership provider lets you modify the user database, while the Windows membership provider does not.

Customized Commerce-specific virtual roles

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

  • CommerceAdmins. Access to all parts of Customized 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.

These virtual roles are configured in EPiServerFramework.config. For example:

<add name="CommerceAdmins" type="EPiServer.Security.MappedRole, EPiServer.Framework" roles="WebAdmins, Administrators" mode="Any" />

📘

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.

Forms authentication model

To work with roles in the forms authentication model, work with the AspNet RoleProvider. The following examples show how to configure the role provider and check if a user is assigned a role.

<roleManager enabled="true" defaultProvider="WindowsRoleProvider"> 
  <providers>
    <clear />
    <add name="MultiplexingRoleProvider"
         type="EPiServer.Security.MultiplexingRoleProvider, EPiServer"
         provider1="SqlServerRoleProvider"
         provider2="WindowsRoleProvider"
         providerMap1="SqlServermembershipProvider"
         providerMap2="WindowsMembershipProvider" />
    <add name="WindowsRoleProvider"
         applicationName="EPiServerSample"
         type="EPiServer.Security.WindowsRoleProvider, EPiServer" />
    <add name="SqlServerRoleProvider"
         connectionStringName="EPiServerDB"
         applicationName="EPiServerSample"
         type="System.Web.Security.SqlRoleProvider,
               System.Web, 
               Version=4.0.0.0,
               Culture=neutral, 
               PublicKeyToken=b03f5f7f11d50a3a" />
  </providers>
</roleManager>

To add a role, add a user to role, or check if a user is assigned to a role, use the following code snippets.

Roles.CreateRole(roleName);
Roles.AddUserToRole(username, roleName);
var isInRole = Roles.IsUserInRole(username, roleName);
var roles = Roles.GetRolesForUser(userName);

OWIN authentication model

Working with roles in OWIN, create claims for the user to map to roles they are associated with. The following example shows working with claims.

// Create identity with the following roles Everyone, Authenticated, Registered
var claims = new List()
  {
    new Claim(ClaimTypes.Name, userName),
    new Claim(ClaimTypes.Role, "Everyone"),
    new Claim(ClaimTypes.Role, "Authenticated"),
    new Claim(ClaimTypes.Role, "Registered"),
  };
var claimsIdentity = new ClaimsIdentity(claims, "ApplicationCookie");
HttpContext.Current.GetOwinContext().Authentication.SignIn(new [] { claimsIdentity });

// Check if current user is in role
var isInRole = EPiServer.Security.PrincipalInfo.CurrentPrincipal.IsInRole(rolename);