Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Enable Single Sign-on in ASP.NET with Passport : Page 3

Learn how to use Microsoft Passport's authentication features to enable single sign-on (SSO) in your Web applications. This article details the features that comprise SSO and demonstrates the SSO process.


advertisement
The Single Sign-on Experience with Passport
This section demonstrates the SSO experience for Passport users and shows how a Passport-enabled application can control that experience. For this demonstration, I developed two sample Passport-enabled applications. The first application is a fictitious tour operator, and the second is a fictitious hotel. The source code download for this article includes both applications along with instructions for installing and running them.

Both the applications use the PassportIdentity class. The PassportIdentity objects in the two applications differ slightly, which will demonstrate the control you can have of the user experience according to the business logic of your Passport-enabled applications. The two applications also pass different values for the second and third parameters to the PassportIdentity.LogoTag2 method. The result is that one application requires more frequent re-authentication of the user than the other does.

I will elaborate on the difference between the PassportIdentity objects in the two applications shortly, but first I'll demonstrate SSO using the two sample applications included in the source code download. I used the following sequence of operations to demonstrate SSO in the download files:

  1. I deployed the two applications independent of each other on two different IIS servers running on two different machines.
  2. Once the two applications were running, I opened a browser session and accessed the first application (the tour operator application). I received the page shown in Figure 1. I pressed the Sign-in button and received the login page shown in Figure 2.
  3. I entered a user name and password and checked the Sign me in automatically check box. Then I pressed the Sign-in button.
  4. I received the page shown in Figure 4, which is the successfully authenticated and logged in screen for the tour operator application.
    Click to enlarge
    Figure 4: Successfully Authenticated Page for Tour Operator Application
  5. I started another browser window and accessed the second application (the hotel application). I received the screen show in Figure 5. I pressed the Sign-in button and received the successfully authenticated and logged in screen shown in Figure 6. Notice I did not need to enter the user name and password this time, because the Sign-in process used my previously authenticated data for login.



    Click to enlarge
    Figure 5: The Hotel Application Showing a Sign-in Button

    Click to enlarge
    Figure 6: Successfully Authenticated Page for the Hotel Application
Why didn't the hotel application ask for the user name and the password? How did it know that I am already authenticated? The tour operator application set the Passport ticket as a cookie in my browser. When I pressed the Sign-in button, the ticket was presented. The Passport server analyzed the ticket and found it to be a valid authentication token, so the Passport server authenticated me without first asking for the user name and password. After successful authentication, the Passport server re-directed me to the hotel application, which simply served the page shown in Figure 6.

Try the same procedure without clicking the Sign me in automatically check box. The Passport ticket will not be stored in the browser and therefore you will have to re-enter the authentication information each time you login to any Passport-enabled application.

In the real world, different Passport-enabled applications will have different user-authentication preferences. For example, a banking application may set a very short session time after which users will be required to re-authenticate. A vacation tour operator, on the other hand, may not need to implement such a strict security policy and may allow users long session times.

To demonstrate this, I used different values in the second and third parameters of the PassportIdentity.LogoTag2 method in each of the two sample projects. The following code shows the PassportIdentity.LogoTag2 method call in the tour operator applications:

passportId.LogoTag2( _ Page.Request.Url.ToString(),_ 900, _ False, _ Nothing, _ 1033, _ Page.Request.IsSecureConnection, _ Page.Request.ServerVariables("SERVER_NAME"), _ 0, _ False))

The following listing shows how I used the PassportIdentity class in the hotel application:

passportId.LogoTag2( _ Page.Request.Url.ToString(), _ 180, _ True, _ Nothing, _ 1033, _ Page.Request.IsSecureConnection, _ Page.Request.ServerVariables("SERVER_NAME"), _ 0, _ False))

Look at the PassportIdentity.Logotag2 method call in the tour operator application. Notice that the time window parameter value (the value of the second parameter) is set to 900 (i.e., time in seconds after which user authentication ticket will expire) and forced login (the third parameter) is set to 'False'. In the hotel application , the time window value is set to '180' and the forced login is set to 'True', which means the user will be forced to re-authenticate after the time window expires. Try these application settings to see the effect of the windows.

Try the following steps and observe interesting results:

  1. Access the tour operator application and get authenticated. After authentication, you'll arrive at the page shown in Figure 4 (Don't forget to check the "Sign me in automatically" box).
  2. Open a new browser window and access the hotel application. You will get the screen shown in Figure 5. Wait about three minutes, and then press the Sign-in button. You will get the screen shown in Figure 7, which requires your password. Enter your password and press the sign-in button. You will be authenticated.

    Click to enlarge
    Figure 7: Screen That Asks for the User's Password

You might be wondering why you got the Figure 7 screen. The reason is simple. The hotel application has a time window of 180 seconds and forced login set to true. When you accessed the second application, the authentication ticket in the cookies set by the tour operator application was presented for re-authentication. The PassportIdentity object in the hotel application checked the time passed since the first authentication and found that the ticket is more then 180 seconds old. So you were re-directed to the Passport server for re-authentication.

What would have happened if the forced login was set to false? Try this yourself by authenticating first at the hotel application and then visiting the tour operator application. This time, you will not get a screen that asks for the password (Figure 7), even if you wait for more than 900 seconds (time window for the tour operator application). After the time window expires, the authentication ticket automatically refreshes for the tour operator application, because the forced login is set to false. So when you access the tour operator application, the authentication ticket previously created (at the time of signing into the hotel application) is accepted and re-authentication is not required.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap