It is strongly recommended that you follow the best practices listed in this topic in order to ensure a secure Commerce Server installation.

Using Active Directory

Using AuthFilter

Instantiating AuthManager

Using Autocookie Generation Mode

Securing Passwords

Configuring Authentication Properties

Using Active Directory

• If you use Active Directory in a large-scale scenario, use SQL Server to store an aggregated profile.

  Use Active Directory to store sensitive data such as logon name, password, groups, and e-mail addresses, and use SQL server to store more dynamic and less sensitive data such as user preferences and transaction data.

  SQL Server is faster than Active Directory, but Active Directory provides additional security features as well as cross-application directory integration. For a step-by-step example of how to store some profile properties in Active Directory and other profile properties in SQL Server, see Add new properties to the profile definition for your site.

  Even though Active Directory can store a large number of objects, for performance reasons in e-business scenarios, it is recommended that you store no more than three million objects/users per domain in Active Directory. Commerce Server provides partitioning support across multiple forests to scale Active Directory. This has been tested up to 10 million objects/users, although there is no hard-coded limit. Alternatively, for a much simpler solution, consider using proxy accounts. For more information, see Proxy Accounts.

Using AuthFilter

• If Commerce Server is installed with Windows Authentication, you can use AuthFilter only if you enable SQL Server authentication to the Administration database.

  When using AuthFilter in a Commerce Server deployment that uses Windows Authentication, you must change the connection string to the Administration database because the ISAPI filter (and hence AuthFilter) is running in the security context of the IIS process (inetinfo), known as LocalSystem. Therefore, AuthFilter tries to connect to the SQL Server on another computer, using credentials from LocalSystem, which are invalid; it does not have the rights to make connections across a network. (If the Administration database is local, the connection would work, but you should never locate the Administration database on the Web server.)

  For instructions for using AuthFilter in this scenario, see Using Windows Authentication in a Distributed Deployment.

• Use AuthFilter in Windows Authentication mode to support single sign-on in a Web farm/multi-domain environment.

  In a Web farm, AuthFilter enables an authenticated user who is logged on to one server to access a site on another server, without the user resubmitting login information.

  Note

  • To implement this functionality, you must add custom code to the Login.asp page. For a code example, see Login.asp Code for the Supplier Solution Site.

  However, if the request is sent with the Post method using non-sticky sessions, any information contained in the header body is lost during the required redirection. Only use the Post method with sticky sessions. If you use non-sticky sessions, always use the Get method and SSL (HTTPS) for increased security. For more information, see Authenticating Users in a Web Farm.

• After making a change to the AuthFiles folder (such as renaming the folder), or changing any files in the folder, check the security setting for the AuthFiles folder.

  After you make a change to the AuthFiles folder, use Internet Services Manager to navigate to the virtual directory of the site and verify that the security property is set for anonymous access.

  To set the property to anonymous access

  1. In Internet Services Manager, right-click AuthFiles, and then click Properties.
  2. On the Directory Security tab, in the Anonymous access and authentication control section, click Edit.
  3. Verify Anonymous access is selected, and then click OK.
• To track both authenticated users and anonymous users visiting your site, use AuthFilter in mixed mode (using either Windows authentication or Custom authentication mode together with Autocookie mode).

  You can maintain some content that is served only to authenticated users, and other content that is available to anonymous users. This way, you can allow anonymous users to browse your site, while tracking their browsing tendencies.

  When you use Custom Authentication mode, users must register, and therefore must access your site as an authenticated user. AuthFilter secures all files in the virtual directory that it protects, by allowing only authenticated users to access files in the virtual directory. You cannot configure the virtual directory to have both authenticated and anonymous content available simultaneously.

  After the Login page validates the user credentials, all the content/pages are executed under the context of the Microsoft Internet Information Services (IIS) 5.0 Anonymous account, which is IUSR_computername by default, where computername is the name of the computer where your site is installed.

  To maintain content that is accessible to anonymous users

  1. Add a link on the Login page. Users who are not registered and who do not want to register can access the anonymous content by clicking on that link.
  2. Make that URL another virtual directory that is separate from the original virtual directory. The URL cannot be nested within the original virtual directory.
• Specifying SSL/HTTPS for login pages when using AuthFilter.

  To specify SSL/HTTPS for login pages, when using AuthFilter, use the CS Authentication Login Form property. You must specify the full path to the Login.asp page, for example, https://www.microsoft.com/authfilter/login.asp. For instructions about setting the Login Form property, see Configuring the CS Authentication Resource.

  If you are using AuthManager, you do not need to configure the Login Form property. Instead, use Commerce Server Manager to configure two application properties: Enable HTTPS and Secure host name. AuthFilter does not use these properties. For instructions about setting these properties, see Configuring an Application.

• You cannot use host headers in a deployment of multiple sites that implement AuthFilter.

  IIS does not support the use of host headers with SSL. However, for basic security AuthFilter requires the use of SSL when passing login credentials to the server.

• Use SSL with AuthFilter, Active Directory, and ACLs, rather than using mutual authentication with client certificates.

  With mutual authentication, the client verifies the identity of your server using certificates. Likewise, your server verifies the identity of clients using certificates. However, using certificates to validate users requires an investment in public key infrastructure, such as certificates, certificate servers, and a certificate authority. Additionally, verifying certificates requires additional server resources, such as CPU time. It is easier to use SSL with AuthFilter, Active Directory, and Access Control Lists (ACLs), than to configure your system to issue and verify certificates. For more information about certificates, see the IIS online documentation.

• When adding multiple Commerce sites (protected by AuthFilter) on a single Web server, unpack each Commerce site to a separate directory.

  Do not install one Commerce site in the subdirectory of another site. You can install multiple sites to the same virtual directory if they are contained by separate directories within the virtual directory.

• When using AuthFilter, all Commerce sites must have dissimilar names.

  For example, do not call one site "Retail" and another "retail2." Doing so may cause IIS to send cookies to the wrong site.

Instantiating AuthManager

• Instantiate the AuthManager object at application scope.

  You should instantiate and initialize a single instance of the AuthManager object in application scope, so that the cache of SiteConfig object data is initialized. This improves the performance of future calls to initialize the AuthManager object, because the cache is already populated. However you should never use this instance to use the AuthManager APIs.

  The AuthManager object should be created and destroyed on each ASP page on a per request basis. This is because Authmanager has dependencies on individual user sessions.

  Use the AuthManager object only through Active Server Pages (ASP), because it depends on ASP-intrinsic objects. This AuthManager object should not be used elsewhere.

Note

• Outside of an ASP script, you can use the Initialize, Refresh, GetUserIDFromCookie and GetUserIDFromCookieAndKey methods of AuthManager object.

Using Autocookie Generation Mode

• In Autocookie Generation mode, when anonymous users register, their persistent cookies can be updated programmatically so that the profile data gathered while the users were anonymous is not lost.

  You use the AuthManager object to add update functionality programmatically. The registration page must perform this update by getting the correct GUID or user ID from the registered profile and using the SetProfileTicket method to set it. This logic is necessary because the process for moving anonymous users to registered users depends on your application; for example, whether the same profile is used or a different profile.

  When an anonymous user becomes a registered user, two tickets exist at any given time, when the user is logged in and authenticated.

  • If the new profile is used, update the MSCSProfile ticket with the new identity, or if a new profile is not created and just a flag is turned on, set the appropriate properties as needed.
  • In cases where both the MSCSAuth ticket and the MSCSProfile ticket exist, the Web Log Import Data Transformation Services (DTS) task gets the user ID contained in the MSCSProfile ticket.

    If the MSCSProfile ticket does not exist, then the user ID is retrieved from the MSCSAuth ticket. It uses this user ID to do a lookup of the profile from the primary key for the profile schema that has been exported by the User Import DTS task. The default schema exported into the Data Warehouse by the Profile Import DTS task contains the GUID and LoginName.

Securing Passwords

• If you are using Active Directory, you cannot get clear text passwords from Active Directory, so you must enable sticky sessions.

  User passwords in Active Directory are stored in an encrypted format. To access this password in clear text, the following two options are available when the password is initially retrieved in the login page:

  • Extend the profile schema by adding a new property to store the clear text password. You must extend the schema using the Profile Designer module in Commerce Server Business Desk. For information about this procedure, see Adding Properties to a Profile Definition.
  • Create a custom cache to store the password to be retrieved in clear text. For more information, see Clear Text Passwords.

  Important

  • Storing clear-text passwords is a security risk because they are inherently less secure than encrypted passwords.
• If you are using Active Directory and SQL Server aggregation, capture the password from the Login.asp page and store it in the profile store for the user in SQL Server.

  The password is then accessible from another Web server and using your custom code in Login.asp, users can log in transparently. This allows the login page to send user credentials to AuthFilter that is running on the server that the user is redirected to. This authentication process does not require sticky sessions.

  Important

  • Storing passwords in SQL Server is inherently less secure than storing passwords in Active Directory in an ecnrypted format.

Note

• You can encrypt profile properties. For more information, see Managing Encrypted Profile Properties.

Configuring Authentication Properties

• Use the net stop iisadmin and net start w3svc commands to restart IIS.

  You must restart IIS, when you perform any of the following tasks:

  • Configure CS Authentication resource properties
  • Enable cookie sharing across domains/applications
  • Enable or disable AuthFilter

  By restarting IIS, you unload all applications and update the site configuration properties in the local site cache for AuthFilter.

  Do not use the IISReset command. Although IISReset stops and then restarts IIS, under certain conditions it does not restart the Inetinfo.exe (W3SVC service). For example, IISReset will not restart IIS if the W3SVC service is configured for manual start instead of automatic start. For instructions about using the net stop and net start commands, see Restarting IIS and Commerce Server Services.