Cookies and Authentication
A Commerce Server cookie contains information about a user visiting your site, such as a logon ID, the date when the user last visited your site, and a time window that indicates how long the cookie is valid. Commerce Server uses cookies to identify and authenticate users, and to associate user IDs with the profile information it collects about them.
Commerce Server includes the CS Authentication resource that the system administrator uses to determine how cookies will be implemented on your site. To configure the CS Authentication resource, the system administrator uses Commerce Server Manager.
Using Cookies
Types of Cookies
CS Authentication Resource
Authenticating Users in a Web Farm
Commerce Server and the Use of Cookies
Using Cookies
Commerce Server provides different features you can apply to cookies on your site:
Encrypt cookies. You can configure Commerce Server to encrypt cookies generated by your applications. By encrypting cookies, you ensure that only your Commerce Server applications can read the cookies.
Share cookies among domains. The system administrator can configure Commerce Server to share cookies among different domains. Each cookie has a domain property that determines the domain in which the cookie is valid. The domain is determined by the string that precedes ".com" (or another extension). For example, assume you have two domains: premier.microsoft.com and msn.microsoft.com. In this example, the domain is .microsoft.com.
Share cookies among applications. The system administrator can configure the CS Authentication resource so that cookies can be shared among applications on the same site.
In some cases, you may not want to share cookies among applications in the same site, because the presence of cookies will impact the analysis results of user activity on your site. For example, if you have a site that sells office supplies, and you share cookies between a supplier application and a retail application, your analysis results will not differentiate user activity between the two applications. The purchases made at the supplier site may show one user purchasing office supplies in very large quantities, but the retail site may show users purchasing supplies in small quantities.
The system administrator specifies how cookies are used in Commerce Server Manager by configuring the authentication properties for the application. For information about configuring an application, see Configuring an Application.
Types of Cookies
Commerce Server creates two types of cookies: persistent cookies and non-persistent cookies:
Persistent cookies. Used by Commerce Server to track anonymous users who visit your site. For anonymous users who allow cookies, these cookies are stored on the computers of the users. When you configure the CS Authentication resource, you determine how long the persistent cookie is valid, typically for several years. Persistent cookies store MSCSProfile tickets.
Non-persistent cookies (also known as session cookies). Used by Commerce Server to track authenticated users who visit your site. When the session ends, the cookies are deleted. Non-persistent cookies store MSCSAuth tickets.
A ticket is a property/value pair such as userID and the value of userID. For example, userID/joeuser is a ticket. Commerce Server uses tickets to store information about users visiting a site. A ticket can be stored in a cookie or in a URL query string.
Both persistent cookies and non-persistent cookies can be encrypted. These cookies contain the following data:
User ID. Used for persistent and non-persistent cookies. A site developer can determine the value to use as the user ID. For example, it can be either the login name or the e-mail address of a user. For anonymous users, the user ID can be, for example, a globally unique identifier (GUID) generated by one of your ASP pages. (Commerce Server includes the GenID object, which you can use to generate GUIDs.)
Time of last login. Used for non-persistent cookies. If a user is authenticated, leaves the computer without logging off (or is inactive for a period of time), and then returns before the close of the Time Window, then the user does not need to be authenticated again. However, if the user returns after the close of the Time Window, then the user must log in again.
Time Window. Used for non-persistent cookies to determine how long, in minutes, the cookie is valid.
After a user logs off a site, the authentication expires.
A site developer can add custom properties to both types of cookies.
CS Authentication Resource
The CS Authentication resource includes two parts:
AuthManager. A Component Object Model (COM) object that is used on every secured ASP page to check whether the user is authenticated to view the page. The Solution Sites use AuthManager. AuthManager is not dependent on any of the configuration settings that are applied during the unpacking process.
AuthManager supports cookieless shopping. Ticket data (for example, a GUID) is appended to the query string.
AuthFilter. An Internet Server API (ISAPI) filter that is used at the Internet Information Services (IIS) 5.0 Commerce Server site level. It can be applied to all users visiting the site. You configure AuthFilter after the unpacking process.
AuthFilter has three modes:
Windows Authentication mode. Checks the user login and password against Active Directory (or a local Security Access Manager account).
Custom Authentication mode. Checks the user login and password against a SQL Server database or other type of database.
Autocookie Generation mode. You can automatically generate cookies for anonymous users, which enables you to collect profile data about how anonymous users navigate and use your site. When anonymous users register, their persistent cookies can be updated, and you do not lose the profile data gathered when the user was anonymous.
AuthFilter does not support cookieless shopping.
Authenticating Users in a Web Farm
When a user logs in to your site, Commerce Server authenticates the user by verifying the login and password against the login and password stored in the Profiles data store. After Commerce Server verifies the user information, it creates a non-persistent cookie and stores it in the ISAPI filter cache for the application. The cookie specifies that the user is authenticated and is allowed to see secured pages on your site.
Commerce Server supports the single authentication of a user in a Web server farm. For example, if a user is authenticated on one Web server, and then is redirected or load-balanced to another Web server, the second Web server does not prompt the user to log in again. To support this functionality, you can use ISAPI filter (AuthFilter) that Commerce Server installs at the IIS Web site level. When the user is redirected to the second Web server, the ISAPI filter reads the user cookie and identifies that the cookie contains the user ID and that it is valid. If you are using Custom Authentication mode, no other steps are performed. If you are using Windows Authentication mode, Commerce Server performs the following steps:
It redirects the request for the secured page to Login.asp, which is not shown to the user.
On Login.asp, using the user ID, it queries the Profiles data store for the user profile. This returns the user login ID and password in clear text.
It appends the login ID and password to the URL, and then redirects the request for the secured page.
The filter intercepts the request for the secured page, and removes the user ID and password from the URL and stores the login ID and password in the ISAPI filter cache.
The filter then displays the secured page to the user. The user ID and password are not transmitted to the user.
Commerce Server and the Use of Cookies
When a user browses your site, the cookie is stored in the Web log files. The system administrator uses Commerce Server DTS tasks to import the site usage data in the Web log files, and the profile data in the Commerce Server database into the Data Warehouse. The Commerce Server Web log import DTS task reads the cookie data and decrypts the user ID, enabling the cookie data to be associated with the profile data. This enables you to analyze the user data.
When the data is imported, it is parsed by the user ID. Each instance of the user ID becomes a row in the Data Warehouse. The user ID is the primary key of the row, so that when analysis is performed on the user data, the data is accessed by the user ID.
If a user does not allow cookies, and you have implemented AuthManager, then the ticket data (including the GUID) is placed in an encoded URL string. The URL string may be used to pass user information between pages. By associating the GUID with the user activity that takes place on the site, Commerce Server enables you to analyze the activities of anonymous users.
See Also
Working with Site Security and Filters