he first article of this series, "Set Up Passport Authentication in ASP.NET
", discussed using the authentication features of Microsoft Passport in ASP.NET applications. This second and final installment demonstrates how to use the same authentication features to enable single sign-on (SSO). SSO enables users to authenticate themselves at one site and then use the resources of several trusted sites without re-authentication.
To provide an understanding of the SSO process, the article first explains the features that comprise single sign-on. The second section details the data formats Passport uses, as well as the information exchange during SSO. The next section puts the pieces together and demonstrates the actual SSO process. The final section describes how to fulfill the sign-out requirements of Passport authentication.
Single Sign-on Features
The following subsections describe the features that SSO enables in participant sites and applications.
Using the Same Authentication Token on Multiple SSO-enabled Sites
E-commerce site users can use the same authentication token on multiple SSO-enabled sites. Authentication tokens identify the site user. The login/password pair is one type of authentication token, the digital certificate is another.
Microsoft Passport uses keys and encryption for its authentication. Microsoft Passport server issues a private key to every Passport-enabled application and stores the matching public key in its database. It uses the public key to encrypt the Passport ticket (which contains the user authentication data) being sent to the Passport-enabled application. The
PassportIdentity class (also called the Passport Manager) automatically decrypts the Passport ticket using the private key. This way, the Passport Server ensures that the authentication data remains confidential while traveling over the Internet.
Sharing Authentication Process Overhead
SSO also enables different Web applications to share authentication process overhead. This means one application, which has authenticated a user, can share that authentication information with other trusted applications.
This sharing of authentication information is useful only if the different applications trust the authentication process. Therefore, SSO is usually applicable only within a trusted domain. If you didn't trust the authentication process that Microsoft Passport server performs, you wouldn't Passport-enable your site and therefore wouldn't be part of the trusted Passport domain.
Such a trusted domain may or may not cross the boundaries of an enterprise. For example, different applications running within the same enterprise may share authentication information. The enterprise therefore serves as a trusted domain for all the applications. Another example of trusted domains is an electronic marketplace.
Enforcing Their Own Authorization Policies
Authorization (allowing an authenticated user to use a particular resource or service) is based on company polices. Microsoft Passport allows Passport-enabled applications to see some profile information of authenticated users, such as name, occupation, country of origin, etc. A Passport-enabled application can use the profile information to implement its own authorization polices. Therefore, you can use Passport as an authentication mechanism to allow your site users to login and then, once they're logged in, grant them privileges according to your own authorization policies.
Handing Sign-out Logic
Just like authorization polices, SSO also allows a participant site to handle sign-out logic. When a user signs out, the Passport server calls the sign-out page of all Passport-enabled applications to which the user was authenticated during his or her current sign-in session. It is up to the Passport-enabled applications to handle their own sign-out logic. (The "The Passport Sign-out Procedure" section of this article examines the sign-out details.)