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:
- I deployed the two applications independent of each other on two different IIS servers running on two different machines.
- 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.
- I entered a user name and password and checked the
Sign me in automatically check box. Then I pressed the Sign-in button.
- I received the page shown in Figure 4, which is the successfully authenticated and logged in screen for the tour operator application.
|Figure 4: Successfully Authenticated Page for Tour Operator Application|
- 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.
|Figure 5: The Hotel Application Showing a Sign-in Button|
|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:
The following listing shows how I used the
PassportIdentity class in the hotel application:
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:
- 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).
- 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.
|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.