Commerce Server 2000 User Management

Commerce Server user identification and authentication

Microsoft Commerce Server 2000 is the next generation of Microsoft Site Server 3.0 and Site Server 3.0 Commerce Edition. The product is also a core application of Microsoft's .NET infrastructure server product line. Commerce Server provides a set of tools and applications that you can use to build, manage, and maintain both business-to-consumer (B2C) and business-to-business (B2B) Web sites. One of Commerce Server's core competencies is its ability to deliver customized content to Internet users. This customized content can have the format of a personalized Web page or mail message. The Commerce Server technologies behind these competencies are the profiling and targeting services.

Before Commerce Server can offer personalized Web content, it needs to know who's requesting the information. From a security point of view, this process covers three areas: identification, authentication, and access control. In Site Server, these services were known as membership services; in Commerce Server, Microsoft uses the more general term user management services. I introduce you to the identification and authentication features of Commerce Server. (I don't cover access control because Commerce Server uses the access control features of IIS and the Windows 2000 OS.) For an introduction to Commerce Server, see Tim Huckaby, "A Glimpse at Microsoft Commerce Server 2000," August 2000.

Identification and Authentication
Because Commerce Server sites are built on top of IIS and Win2K, they can reuse the basic security features of IIS and Win2K. However, Commerce Server identification and authentication require more features than IIS and Win2K offer.

Identification and authentication are crucial services. Although users can access your Web site anonymously, you might, for example, want to gather information about the spending behavior of these anonymous users, or you might want to offer them personalized services the next time they come around. In other words, you want to make sure that when anonymous users return to your Web site, you can link them unambiguously to the profile data you've previously gathered about them. To make this link, you need to exchange Commerce Server-specific credentials that the profiling system can understand.

On the Internet, you can't know all the users of your commerce site in person. Although you want to allow Anonymous access, you also want to use a set of credentials to identify your commerce site users. To identify your users, you let users enter their credentials in a special form. The form then stores the credentials in the credential database of your Commerce Server site. (Although you want users to be able to access this form anonymously, use Secure Sockets Layer—SSL—to secure traffic to and from the form.)

Identification and Authentication Architecture
As Figure 1 shows, the client uses a browser to access a Commerce Server Web site. On the server side is an IIS Web server and a set of Commerce Server-specific services: the authentication manager (AuthManager), the profiling service, and (optionally) an Internet Server API (ISAPI) authentication filter (AuthFilter). I come back to these components later. The server-side code that handles the client request is Active Server Pages (ASP) and AuthFilter. After the system has identified and authenticated a user, Commerce Server's profiling system retrieves the user's preferences (if the user has visited the Web site before) from the profiling database. The profiling system generates customized Web content, captures the user's preferences, and adapts the user profile accordingly. Note that you can spread the IIS and Commerce Server components, including the credential and profile stores, across multiple machines. Also, you can store user credentials and profiles in different databases (e.g., Active Directory—AD—and Microsoft SQL Server).

You can easily customize the architecture that Figure 1 shows. A key difference between the Commerce Server architecture and the Site Server architecture is the clear role separation between the identification and authentication components and the profiling components. In Site Server, the authentication filter manages both the user-data cache (profiling) and user-token cache (authentication); you use a special component called the Active User Object (AUO) to access the profile data. In Commerce Server, AuthFilter manages the user-token cache, but the user's profile object manages the user-data cache. This separation makes plugging in other authentication providers easy. Instead of using the standard Commerce Server AuthFilter, you can use Microsoft Passport authentication. (See the Commerce Server product documentation for information about customization.)

Tickets, Cookies, and URLs
Before I go into the nuts and bolts of Commerce Server identification and authentication, let's go over some key Commerce Server security components and services. Tickets are the Commerce Server-specific credentials that link users to their Commerce Server profiles. AuthManager issues tickets for any type of user independently of whether that user accesses the site anonymously or with an identity. Commerce Server uses two types of tickets: profile tickets and authenticated tickets.

Profile tickets. Tickets linked to anonymous users are called profile tickets (MSCSProfile tickets). These tickets always contain a unique user ID and can also hold a set of custom properties. This unique user ID is a globally unique ID (GUID) that the Commerce Server AuthManager generates.

Authenticated tickets. Tickets linked to an identified user are called authenticated tickets (MSCSAuth tickets). These tickets always contain a unique user ID, the last logon time, and a time window; they can also hold a set of custom properties. The user ID referred to in an MSCSAuth ticket can be an account name, an email address, a GUID, or any other unique identifier.

Commerce Server can send tickets to users in two ways: by using cookies or, in case the user's browser doesn't support cookies, by appending them to a URL. Commerce Server stores MSCSProfile tickets and MSCSAuth tickets in different cookie types:

Both cookie types can be encrypted to protect the cookie's and the ticket content's confidentiality.

Commerce Server also supports sending tickets by appending them to a URL. This method is known as cookieless shopping. Cookieless shopping isn't an option if you want to use Anonymous access (remember that this access requires persistent cookies). In other words, if a user's browser doesn't support persistent cookies, that browser can't access a Commerce Server site anonymously.

Commerce Server Authentication Components
Earlier, I introduced two Commerce Server authentication components: AuthFilter and AuthManager. Now let's look at what these components are and what they do.

AuthManager is a scriptable COM object (known as Commerce.AuthManager) that creates and validates Commerce Server tickets. It doesn't validate Web authentication requests—only Commerce Server-specific credentials. (Validation of Web authentication requests is the task of the built-in IIS authentication providers or the Commerce Server AuthFilter.) AuthManager supports both cookies and URLs to transport a user's Commerce Server ticket.

AuthFilter is an ISAPI filter DLL that supplements the default authentication features in IIS. AuthFilter doesn't provide additional authentication protocols, but it provides tools to resolve some of the typical problems related to Internet authentication. Here are some examples:

If you've enabled AuthFilter, it loads automatically when IIS (inetinfo.exe) starts. From that moment on, AuthFilter automatically intercepts every incoming user request. To enable or disable AuthFilter, open the Microsoft Management Console (MMC) Commerce Server Manager snap-in, right-click a Commerce Server application, and select Properties. Select no Filter from the Authentication filter drop-down list. Because AuthFilter's primary task is authentication, it doesn't support cookieless shopping: It requires all users to have a valid cookie before it lets them through to the Commerce Server Web site. (For more details about an AuthFilter-based authentication sequence, see the sidebar "The Commerce Server AuthFilter Authentication Sequence," page 11.)

The AuthFilter Authentication Modes
AuthFilter supports three distinct authentication modes and two mixed modes. Table 1 provides an overview of the authentication modes and their effect on cookie type, ticket type, and credential stores.

Windows mode. Windows authentication mode grants access to both anonymous and authenticated users (if the access control settings permit), but it tracks (i.e., sets up a profile for) only authenticated users. This mode validates a user's credentials against AD or against the local SAM database (in the case of a member server). For details about using AD as a Commerce Server credential store, see the sidebar "To AD or Not to AD?". Windows mode uses MSCSAuth tickets and stores them in session cookies. Thanks to its tight integration with the Windows security model, Windows authentication mode can provide fine-grain access control based on ACLs and SIDs that you set at the file level.

Custom mode. Custom authentication mode validates user credentials against a SQL Server database or against any other OLE DB-compliant database. Like Windows authentication mode, Custom mode uses MSCSAuth tickets and stores them in session cookies. Custom mode also grants access to both anonymous and authenticated users, but it tracks only authenticated users. In this mode, you can set access control only at the IIS virtual directory and file level.

AutoCookie mode. AutoCookie mode supports tracking of anonymous users, for which Commerce Server needs a ticket. AuthFilter uses an MSCSProfile ticket stored in a persistent cookie. Because you aren't authenticating the user, you don't need to worry about credential storage and access control enforcement.

Mixed modes. The mixed authentication modes (Windows + AutoCookie and Custom + AutoCookie) are options for Commerce Server sites in which part of the resources are public and part require authenticated access. Both Windows + AutoCookie and Custom + AutoCookie modes permit tracking of anonymous and authenticated users. Unlike Windows mode, Windows + AutoCookie mode doesn't grant access to a resource that allows anonymous access unless the user has a valid MSCSProfile ticket.

You can use AuthFilter through the Commerce Server Manager snap-in. To configure global Commerce Server authentication settings, expand the Global Resources container, right-click the CS Authentication container, and select Properties, which Figure 2 shows. You configure application-specific authentication settings (e.g., to set the application's authentication mode) in the properties of the appropriate application container in the commerce sitessitename container, as Web-exclusive Figure 1 shows. (Note that Microsoft moved the Commerce Server-specific authentication settings from the MMC Internet Information Services snap-in to the new Commerce Server Manager snap-in.)

Many Options to Choose From
Commerce Server identification and authentication offers more configuration options and is easier to extend than Site Server. A good example is Commerce Server's ability to use a variety of profile and credential stores, including AD. Commerce Server remains a complex product to master, and the design of a Commerce Server solution requires a good Internet programming background and a good knowledge of IIS 5.0, Win2K, and SQL Server.