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:
Web server resources such as pages, images, and other static files.
Database resources such as per-user, application-wide, or other forms of dynamic data.
Network resources such as remote file system resources and directory stores such as Active Directory.
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.
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.
Review the Sitecore XP installation instructions (available from the Sitecore XP Download page) 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. You can review the predefined database role mapping requirements here . 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. See the Profile Store Integration Management topic for more information.
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.
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.
Each business user is assigned a domain account.
Business management Windows or Active Directory groups are created according to your business needs. You can review the set of predefined security roles here.
Each business user domain account is added to one or more business management group accounts.
You assign business management groups to one or more predefined authorization roles. For more information, see this topic.
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. You can review the predefined database role mapping requirements here.
IIS application pool and IIS worker process group assignments are made. You create an IIS application pool for each Web service and you assign the Web service account to its application pool and the IIS worker process group.
You must grant Web application service identities write permissions to the temporary ASP.NET and Windows temporary folders. To enable user access to the Catalog Web service, you must assign the Catalog Web service identity write permissions to the Catalog authorization role.
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:
You assign each service a service identity. You can review the service accounts that you need to create here.
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. You can review the predefined database role mapping requirements here.
In addition, several additional deployment tasks are required to enable specific services to access specific resources. The following table summarizes these tasks.
Service | Requirements |
|---|---|
Commerce Server Staging | Grant the service group, CSS_SG, permission to replicate the Internet Information Services (IIS) metabase. For more information, see How to Configure Access to the IIS Metabase. |
Commerce Server Adapters | Provide the service identity, CSLOB, access to Web services by assigning them to predefined authorization roles. For more information, see How to Set Authorization Roles for the BizTalk Adapters. |
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.
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.
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.