Other considerations

You should also consider the following when choosing Passport authentication.

Enabling Passport

Using Passport authentication requires site registration with the Passport service and installation of the Passport SDK on the server.

Delegation

On Windows 2000, it is not possible to delegate a user's Passport security credentials from one server to another.

Mapping to user accounts

The Passport User ID (PUID) is an identity only. If your user accounts are defined within Active Directory or any custom database, and you need to map the PUID to a user, you will need to implement your own custom code. Future versions of Windows may provide native support of mapping PUIDs to Windows accounts.

Making Passport secure

The nature of the encrypted cookie makes Passport secure when used as a stand-alone authentication method. However, to avoid replay attacks and to maintain the highest-security level, Passport needs to be used in combination with SSL.

Implementation

To implement Passport, you need to install the Passport SDK on the server. You also need to register with Passport to use the service. You must configure your web.config file as follows:

Copy Code

// web.config file

<system.web>

   <authentication mode="Passport" />

</system.web>

For more information about the Passport service, see:

·       The Passport Authentication Provider

·       Passport technical white paper

·       Passport developer information

Forms Authentication

Forms authentication refers to a custom user interface component that accepts user credentials; for example, a user name and password. Many Internet applications used today present such forms for users to log on. It is important to note that the form itself does not perform the authentication and is provided solely as a way of obtaining the user credentials. The authentication is performed by accessing the user name and password database using custom code.

When the user is authenticated, the server typically gives the client some means to indicate that it has already been authenticated for subsequent requests. If required, you can force the client to authenticate upon every request, although this impacts performance and scalability. There are two basic approaches that you should consider to identify a client who has previously logged on:

·       Cookies. A cookie is a small piece of data initially presented by the server to the client. It is subsequently presented by the client back to the server within each HTTP request. This can be used as an indication that the client has already been authenticated. ASP.NET provides a mechanism for you to use cookies for Forms authentication in the CookieAuthenticationProvider module. Cookies are supported by most Web browsers, including Internet Explorer and Netscape Navigator.

·       Custom. You can implement your own custom mechanism to identify the client to the server. If your clients have disabled cookies, you may consider storing a unique identifier within each URL query string. You can also use hidden form fields, which are stored in a persistent top-level or non-visible frame. In either case, you need to make sure that a hacker cannot simulate being authenticated to your application programmatically.

Cookies are widely utilized by Web sites that implement Forms authentication. The initial release of .NET will support only Forms authentication using cookies.