his first installment of a two-part series on Microsoft Passport in ASP.NET applications discusses Passport's basic authentication mechanism and demonstrates the use of related .NET classes. It describes the design and implementation of Passport-enabled Web applications and how such applications communicate with client browsers and Passport servers.
Beginning with a general description of how Microsoft Passport acts as an authentication service, it then describes the sequence of events that occurs when a user (normally a browser client) tries to access a Passport-enabled application. The following section demonstrates the necessary setup steps, and the final section explains how to use ASP.NET classes that wrap the authentication-related functionality that the Passport server provides.
Microsoft Passport as an Authentication Service
E-commerce applications on the Internet use electronic means to identify people trying to reach their enterprise resources. For example, when you create a new Yahoo e-mail account, you enter some personal information along with a user name and a password. The name/password pair becomes your identification when you later check your e-mail messages on the site. This simple authentication mechanism is also applicable to e-commerce applications. The login and password pairs are used to identify site users.
The user-authentication mechanisms that e-commerce applications normally have to implement require the following features:
- A graphical user interface (GUI) for sign-up and login
- A database of user information (at least user names and passwords)
- Authentication logic at the Web server
- Log-out functionality, such as deleting (or destroying) server-side session objects
Microsoft .NET Passport, in its most basic form, provides all four of these features wrapped inside an easy-to-use programmatic interface. Passport provides a simple architecture, in which a single .NET Passport class named System.Web.Security.PassportIdentity wraps all authentication functionality. A Passport-enabled Web application developer need only instantiate the PassportIdentity class and use its methods to perform the complete authentication process.
This means Passport-enabled e-commerce application developers can rely on Passport to manage all the authentication features required by their e-commerce sites. In effect, Passport is a reusable authentication component, pluggable directly into an ASP.NET-based e-commerce application, which makes it very suitable for rapid application development.
Single sign-on (SSO) is another important benefit of Passport. Microsoft hosts its Passport service on its own servers and allows the use of all Passport-enabled accounts (e.g., all Hotmail and MSN.com accounts) to be authenticated on all Passport-enabled Web applications. This means users with Passport-enabled accounts need to remember only one login password pair to access all partner sites. So Passport not only allows rapid e-commerce application development, but it provides ease for users as well.
Author's Note: Microsoft Passport is not the only SSO solution available. Almost all major e-commerce vendors like Oracle and IBM are offering SSO solutions. A major contender for Passport is the Liberty Alliance (see Related Resources for details).
On the other hand, if you host your SSO on your own server, you can offer it only to your own user basenot all Hotmail and MSN users. You'll normally find this type of SSO in enterprise integration applications, where the application is meant only for users who belong to a particular trusted domain (e.g., employees of a company).
Microsoft currently sells Passport as a hosted service, like an application service provider (ASP). Passport is not available as a software product or a component you can host on your Web servers. The disadvantage of this strategy is if you want to authenticate your own user base on a Passport-enabled site, you have to implement your own authentication mechanism in addition to Passport.
This disadvantage makes Passport a generally unsuitable authentication solution for enterprise application integration (EAI) projects. In most EAI projects, customers don't want their users authenticated on a third-party server, because third-party authentication unnecessarily exposes their business information. For such applications, SSO solutions from other vendors like Oracle or IBM are better, as they are available as software components that customers can host on their Web servers.
However, B2C e-commerce applications can take advantage of the Hotmail and MSN user base with Passport.