Types of Users

It is helpful to consider three types of users that you can have at your site:

• Anonymous Users. Users who are not tracked at all in the Membership Directory or Windows NT Server directory database. No personalization can be performed for anonymous users. Anonymous users have no credentials; therefore, they cannot be authenticated and cannot view any type of protected information. These users can access information only through the Anonymous access provision of Internet Information Server (IIS) or the Site Server LDAP Service.
• Cookie-Identified Users. Users whose real identity remains anonymous but who are tracked in the ou=Anonymous container of the Membership Directory by means of an automatically assigned globally unique identifier (GUID). The GUID is stored in the Membership Directory and in a cookie associated with the browser on the user’s computer. The identity of a cookie-identified user is not known to Site Server unless you choose to collect that information. Cookie-identified users can view content that is personalized according to the attributes stored in their profile in the Membership Directory. Cookie-identified users have no password, do not register as members, and do not explicitly log on to your site, although under Automatic Cookie Authentication in Membership Authentication mode, a security context is created, which is in effect an automatic logon. Under Membership Authentication, cookie-identified users can be put into groups and can therefore be given access to restricted (but not private or secure) content. (No access to protected information is possible under Windows NT Authentication for cookie-identified users, because no security context is created for cookie-identified users in that mode.)
• Registered Users. Users who are tracked in the Membership Directory or Windows NT Server directory database by means of a user name established during registration. Registered users, like cookie-identified users, can view content that is personalized according to their attributes stored in the Membership Directory. Registered users can be put into groups and can therefore selectively be given access to all the varieties of protected information. The registered user’s user name and password or client certificate are the credentials by which the user is authenticated at logon time.

An anonymous user who encounters content monitored with either Cookie Identification (Windows NT Authentication mode) or Automatic Cookie Authentication (Membership Authentication mode) becomes a cookie-identified user, unless his or her browser is set to reject cookies. Under some circumstances, a user will have multiple cookie-identified accounts within a given domain (see “Scope of Cookies Within a Domain” in this topic). This will also happen if a Membership Directory serves multiple domains and the user encounters sites from more than one of them. If a user has multiple accounts, user attribute information is not shared among the accounts.

A registered user who encounters content monitored with Cookie Identification (Windows NT Authentication mode) acquires an additional profile as a cookie-identified user in the Membership Directory. No mechanism is provided to link such a user’s registered user profile and cookie-identified user profile.

An anonymous user or cookie-identified user becomes a registered user when he or she completes your registration process. Under Membership Authentication, attributes from any existing cookie-identified user profile for the user’s current browser are brought forward into the new registered user account. Attributes from an existing registered account, if the user has one, are not brought forward. Under Windows NT Authentication, existing attributes in a cookie-identified user profile or previous registered account are not brought forward and continue to exist in the previous separate account.

User information is stored in the attributes of the Member objects in the Membership Directory. In Windows NT Authentication mode, member objects are created by the AUO. In Membership Authentication mode, member objects are created by either the Membership filter (for cookie-identified accounts) or by the Registration page (for registered accounts). The Registration page creates the account using AUO.

The Membership filter, which exists only under Membership Authentication, performs a number of system functions in addition to account creation, including processing cookies for authentication and performing redirection for certain pages associated with error handling and logon.

Scope of Cookies Within an Internet Domain

Under Membership Authentication, you can choose for each site to issue user-identifying cookies at the site level (for example, x.DomainName.com) or at the domain level (DomainName.com). Issuing cookies at the domain level is the default behavior. The following considerations apply:

• If you issue cookies at the site level, users who visit multiple sites within the domain will get multiple cookies and will have a separate personalization profile for each site.
• If you want to issue cookies at the domain level, you will need to coordinate your sites to ensure that they all do this. Users will then have a single profile across all sites within the domain.
• If some sites issue cookies at the domain level and others at the site level, users who visit multiple sites within the domain may get multiple cookies and may have more than one personalization profile. In addition, it is not possible to predict whether the site-level cookie or the domain-level cookie will be presented by the browser at the beginning of a given session; this is determined by the browser software and is beyond the control of P&M.
• To change from issuing site-level cookies to issuing domain-level cookies, each issuing site must remove its own site-level cookie and issue a new domain-level cookie (it is not possible to delete all site-level cookies from a single page within the domain). Personalization information will not be carried forward from a site-level account to the domain-level account.

For information about setting cookie domain scope, see PMAdmin Set Master.

Related Topics

• Access to Application Content