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.
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.
## 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 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:
**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.
To add a role, add a user to role, or check if a user is assigned to a role, use the following code snippets.
## 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.