Authentication and secure access requirements

Authentication in Sitecore Commerce Server involves validating user credentials for internal business users and internal service accounts. Authentication of external site visitors should be done by Sitecore.

Authentication of external site visitors should be done by Sitecore. Commerce Server uses a different authentication approach for each of these user segments. In all scenarios, users and services need access to the following types of site assets in the Web site application:

In turn, the Web site application needs access to system resources such as the registry, event logs, and configuration files.

Review the following sections for a summary of the secure deployment methods that are used to support access by the different user segments.

External Access by Site Users:

Review Sitecore installation for instructions on how to set up a Sitecore site and with the accounts and permissions that are required. Controlled access to specific databases and the ability to read or write to the databases is controlled through SQL Server database login accounts and database user role mappings. To review the predefined database role mapping requirements, go to What are the required accounts and groups to create?. It is recommended to use integrated security in the Commerce Server database connections strings instead of explicit SQL logins. Commerce Server will then use the application pool account to talk to the Commerce Server databases, not the user account that is logged in.

Sitecore uses the ASP.NET membership provider framework for authentication and authorization. Using this framework gives you many advantages when it comes to xDB and site personalization. By default, Sitecore uses the basic SQL provider for membership and roles, which should work for your needs. However, you do have the option to have these work side by side with other providers, such as the Commerce Server Membership and Profile providers. By using the Sitecore switcher framework, Sitecore can authenticate users against the Commerce Server Profile database. With the Commerce Server Profile provider, you can use whatever membership provider you like and persist some or all of your profile data into the Commerce Server Profile database. Full details on profile integration are located at Profile Store Integration Management.

Internal Access by Business Users and Commerce Server Services:

Internal business users must have access to the Commerce Server Business Management applications and Commerce Server services must have access to various Commerce Server resources. Commerce Server implements two levels of granular security that address these areas.

The first level of security is implemented by using Windows Authorization Manager to define scopes, roles, tasks, and operations to manage access to the Catalog, Inventory, Marketing, Profiles, and Orders systems via the web services. Between four and ten security roles are defined per system.

The second level of security is implemented by mapping users to predefined database roles. This grants access to operations, not to resources, for the service identities. The back-end resource managers, such as databases, trust the application to authenticate users and grant access to the trusted service identity. For example, a database administrator might grant access exclusively to a specific human resource application, but not to individual users.

Business User Access to Business Management Applications:

The following list summarizes the secure deployment requirements used to support business users access to Business Management applications, and these applications access to Web services. These deployment tasks are performed on the production server where the Commerce Server Web services are run. In an Enterprise deployment, this is the business management server.

Business management Windows or Active Directory groups are created according to your business needs. To review the set of predefined security roles, go to What are the required accounts and groups to create?

Commerce Server Services Access to Commerce Server Resources:

In addition to Commerce Server Web services, you can run many additional services, such as Staging, and Commerce Server adapters. The following summarizes the secure deployment requirements used to support these services access to Commerce Server resources:

In addition, several additional deployment tasks are required to enable specific services to access specific resources. The following table summarizes these tasks.

Authorization Role-Based Access:

Commerce Server provides several predefined roles to which you assign business users, so that they can perform specific tasks such as editing a catalog, creating a discount, and deleting an order. To restrict business users from performing all tasks, you assign them to specific roles such as the CatalogPropertyEditor role, where users can only manage individual catalog properties. By assigning user accounts or Windows groups to the administrator roles, such as MarketingAdministrator or OrdersAdministrator, these users can perform any operation associated with the corresponding Commerce Server system. For example, the MarketingAdministrator role lets users perform any operation in the Marketing System.

With role-based access control, you specify access control relative to the organizational structure of your company. You use Windows Authorization Manager to add individual users or user groups to a role. Before you assign business user access to the Authorization Manager roles, we recommend that you assign the business user to a Windows group, and then give the Windows group Authorization Manager permissions on the Web services.

Database Role Mapping and the Trusted System Model:

To simplify authentication and eliminate the requirement of configuring database roles and permissions for each business user, Commerce Server uses the trusted system model. In this model, you configure database roles and permissions for groups of users according to user role, such as Catalog Editor or Marketing Manager, and then associate the individual business users with these user roles.

With this model, the Business Management server uses fixed identities to access the resources on the database server. The security context of the originating business user does not pass through the service at the operating-system level. The database trusts the Web server to authenticate users, and to let only authenticated users access the database using the trusted identity.

The advantage of using the trusted system model is that users cannot access back-end data directly without using the application and being subjected to application authorization. Only the Web tier service account has access to the back-end resources. Additionally, you only have to configure access control lists (ACL) for the Web tier service account instead of for every individual user identity. The trusted system model also supports connection pooling. This enables multiple clients to reuse available, pooled connections because all back-end resource authentication assumes the security context of the service account, regardless of user identity.

The disadvantage of using the trusted system model is that an attacker who manages to compromise the Web tier has broad access to back-end resources because the back-end resources rely completely on the Web tier to authenticate users. The trusted system model also makes auditing difficult because the Web tier service account masks the originating user identities.

Windows Authentication and Windows Integrated Security:

Commerce Server supports Windows Authentication to SQL Server. This is also known as Windows Integrated Security. We recommend that you use Windows authentication for a Commerce Server installation. With Windows authentication, Windows Server uses Windows user accounts to authenticate to SQL Server. Commerce Server sets a tag in the connection string that tells the SQL Server to use Windows authentication when checking the security context of the user trying to access a given database.

When you use Windows Authentication, user names and passwords are not stored in the SQL Server connection string, and are not changed when the SQL Server password is reset.

SCpbMD communicates with Dynamics solely through the Commerce Run Time assemblies provided by Microsoft Dynamics. These assemblies require Windows Integrated Security access to a published Channel database. Once authentication has been established to the channel database. then the channel database contains authentication protocols to the Commerce Data Exchange (CDX) and Real Time Services (RTS). These security protocols are resolved transparently by the Commerce Run Time assemblies in communicating with these Dynamics Services.

Dynamics AX provides utilities within the product to configure and manage these access protocols.