Understanding Commerce Server Authentication and Authorization
For the latest version of Commerce Server 2007 Help, see the Microsoft Web site.
The two general models for providing security for Web applications are the trusted subsystem model and the impersonation model. In the trusted subsystem model, the middle tier of the application authenticates users and makes sure that the operations they are trying to perform fall in the scope of their assigned role(s). When these conditions are met, the application, running under a sufficiently privileged account, accesses back-end resources, such as a database, on behalf of the users. In the impersonation model, the application authenticates users, and then impersonates them in order to access the back-end resources. Therefore authorization relies on whatever authorization mechanisms are being used by the back-end resources to make sure that particular users do not access a resource that they are not allowed to.
In both models, authentication can be performed in various ways. One obvious choice is Windows Integrated Security, which relies on either NTLM authentication or Kerberos authentication. Although typically not advised unless SSL is used together with it, another choice is basic authentication.
By default, Commerce Server uses NTLM-based Windows Integrated Security for authentication and the trusted subsystem model for authorization. How this works is different for customers using a Commerce Server Web application versus a business user who is using one of the smart client applications to manage the data for one or more of the Commerce Server systems. Each of these scenarios is discussed separately in this topic. For conceptual information about authentication and authorization in ASP.NET-connected applications, see https://go.microsoft.com/fwlink/?LinkId=6653.
Managing Authentication and Authorization for Web Application Users
By default, Commerce Server Web applications use ASP.NET authentication. This can be configured to use one of several different modes. The mode is determined by a setting in the Web.config file for your application. The value of the mode attribute of the authentication element in the system.web element determines the type of authentication that your application will use. The choices are "Windows", "Forms", "Passport", and "None". By default, the value is set to "Windows".
The obsolete Commerce Server authentication object AuthManager and the ISAPI filter AuthFilter are still included with Commerce Server for backward compatibility, but their use is discouraged. For more information about the AuthManager object and the AuthFilter ISAPI filter and how to use them to implement your application authentication, see Authentication Concepts and Tasks and How to Restore AuthFilter Functioning.
Commerce Server Web applications should implement application-level authorization, wherein the application itself makes sure that an authenticated user does not see any data or use any application functionality that they should not. For example, a user should never be able to see the shopping basket of another user.
Managing Authentication and Authorization for Business Users
The Commerce Server smart client applications, such as Catalog Manager and Marketing Manager, which are used by business users to manage the operation of Commerce Server Web applications, also use the standard authentication methods included with Internet Information Services (IIS) 6.0 including NTLM, Kerberos, and Basic authentication. This authentication is managed through the Web.config files of the four Commerce Server Web services that these applications use to access the Commerce Server systems that they are used to manage. By default, the setting in the Web.config file for all four of these Web services (CatalogWebService, MarketingWebService, OrdersWebService, and ProfilesWebService) is set to use "Windows" authentication.
Note
To configure the Web services to enable Basic authentication, for example, modify the authentication and access control settings on the Directory Security tab of the properties dialog box for the Web service application in IIS Manager.
Authorization for the smart client applications is implemented by using Authorization Manager, also known as "azman". One of the types of authorization stores that Authorization Manager allows for are XML files. Each Commerce Server Web service has one of the following XML authorization store files in its root directory: CatalogAuthorizationStore.xml, MarketingAuthorizationStore.xml, OrdersAuthorizationStore.xml, and ProfilesAuthorizationStore.xml. These authorization store XML files define the roles and tasks for their corresponding Commerce Server systems, and provide a mechanism for individual Windows user accounts and group accounts to be assigned to different roles. After these assignments are made, ASP.NET will examine these assignments at run-time and use them to control access to individual Web service methods.
Note
The Web services generally require only read access to the XML authorization store files. The Catalog Web service is an exception because it must be able to update its XML authorization store file to create scopes as new catalogs and properties are created in the Catalog System. Therefore, if you use a Web farm to load balance the Catalog System, you must locate the XML authorization store file centrally, such as on a UNC share so that it can be accessed from the Web servers.
See Also
Other Resources
Managing Authorization Policies
What Are the Minimum Authorization Roles to Assign?
Authentication Concepts and Tasks