If you think your work environment is tough to maneuver, let's consider Jim Bland, a covert operative for a top secret government agency (let's just call it TSGA). Like other international men of mystery, our Jim works in a fast-moving, demanding world where information is the most valued currency. Unlike his better-known counterparts, however, our Jim (badge number 013) must struggle with a more traditional working environment that includes an overworked and underbudgeted IT department; and, like most of us, Bland must do more with less.
Jim Bland works as a spy, but our Jim gets only domestic assignments. Bland is currently conducting surveillance on industry bigwigs who are benefitting from the mysterious disappearance of outstanding parking tickets. The top secret files for Bland's latest mission are stashed in a protected storage area (this time, a public rest room in a mall), and Bland must prove his identity in order to access the files. Bland goes to the back stall and wall and lays his hand on the shiniest, newest wall tile. This is actually a scanner that reads his fingerprints. Apparently Bland is recognized and a voice declares: "Identity confirmed." A secret door in the wall is now revealed; it is the door to the elevator that can take him to the location of the secret files. Bland enters the elevator, but before the elevator buttons activate, Bland must pass a second trial--a retinal scan this time--and again a voice declares: "Identity confirmed." After a short ride, the elevator door opens, but there is a problem: there is no floor to step out on! Instead Bland sees a big open space of nothingness. What will Bland do? Will he jump? Will he shimmy down an adjacent water pipe? In fact, our ever resourceful spy knows exactly what he must do: he identifies himself yet again by speaking the magic words, "Bland. Jim Bland." Suddenly a walkway appears, providing Bland safe passage, and he leaves the elevator as the voice confirms Bland's identity: "Access permitted to Agent 013." Bland can now carry on with his business of--well, not of saving the world from evil, but certainly confronting the evils of parking scams. However, this procedure has been tiresome, and we're sure Bland is thinking to himself, "Why is my single sign-on broken again?"
Single sign-on (also known as SSO), while complex to manage, is all about convenience for users, who otherwise become annoyed if repeatedly queried for login information (especially if one is trying to get out of a public restroom). For those of you charged with deploying or maintaining an SSO environment, this article provides some tips and tricks for configuring your complex environment to work reliably for your users. It's possible that your environment might include hidden walkways activated by voice recognition, but more likely, your environment is a typical Web SSO environment. A typical mainstream scenario includes a user who is prompted to enter a user name and password in order to access the environment that includes IBM components such as WebSphere Portal and Domino. This environment might also include Lotus portlets that provide connectivity to Sametime, Quickplace, and Domino mail via Domino Web Access (DWA).
In this two-part article series, we focus on a Portal environment that is additionally complex because of the deployment of multiple directories. Components such as DWA may require the Domino Directory, while other components such as the Portal may be deployed with IBM Directory Server, Active Directory, or any other supported LDAP directory. This article explains how SSO works in environments where multiple directories are deployed, and we will highlight the challenges faced when users are known by more than one name.
Just as in the world of espionage, where operatives often have more than one name, so it is commonplace in SSO scenarios that users may be known by more than one name. Names are critical in the SSO world. To understand how and why this is so, we begin part 1 of this article series by revisiting the SSO fundamentals to explain how users are identified in our SSO environment. We then take a look at issues involved in running a multi-directory, multi-identity site.
Usually, when we talk about SSO, we're talking about the Web user experience (however, see this sidefile if you're interested in SSO with your operating system desktop login). We have a user sitting at a Web browser, such as Jim Bland, who browses to his favorite URL at spycentral (http://spycentral.spies.com/fun). A well-constructed SSO deployment would allow Bland to be prompted to log in only once per session. When Bland first attempts to access this URL at spycentral, he must enter his user name jb013 and his password LazyEye. The Web application server at spycentral successfully verifies Bland's password, and grants him access to the URL. Once logged in, Bland is all set. He has been given access to the SSO environment, and he can browse to other URLs in his environment without having to log in again (see figure 1).
Figure 1. SSO login
In figure 1:
A. Bland browses to his favorite URL and is prompted to log in. The Web application server verifies Bland's password and allows access to the URL. Bland can now be recognized in the SSO environment.
B. Bland browses to another URL in the SSO environment and does not need to repeat login steps.
To achieve SSO, it is critical that SSO servers and applications recognize users after they have logged in. In a Web environment where IBM products are deployed, the magic used behind the scenes to achieve SSO is called Lightweight Third Party Authentication (LTPA). This LTPA technology allows SSO servers to identify users after they have logged in. IBM endorses open standards, but since there isn't a widely deployed defacto standard for SSO, IBM has implemented its own SSO technology. LTPA can be used with various IBM products, and since IBM is committed to open architectures, there are plug-in points provided for both WebSphere and Domino, allowing the incorporation of third-party SSO applications into an LTPA solution. To help you understand LTPA technology, and to support our opening claims that names are critical in the SSO world, we must begin our tale by discussing browsers and browser cookies.
The browser's supporting role in SSO security
Suppose Jim Bland sits at his browser, enters a WebSphere URL, and is prompted to log in with user name and password. The WebSphere application server verifies Bland's identity by checking the password that has been entered. The Web server can then send back the Web site content that should be displayed in Bland's Web browser. The Web user experience is the same as it always is: he enters the correct password and Bland will start viewing the Web site. In this case, and completely behind the scenes, WebSphere sends along a cookie which will be stored by Bland's browser (see figure 2). Note that in order for a cookie to be stored by the browser, the browser must allow cookies to be accepted, and this is a typical browser default. The LTPA cookie is a transient cookie, as it lives only in browser memory, and will be permanently eliminated when Bland kills his browser.
Figure 2. Login returns LTPA browser cookie
The LTPA browser cookie is a typical browser cookie. If you're not familiar with browser cookies, note that cookies are a standard method for saving information on the user's computer for later use. The information that's saved in this LTPA browser cookie indicates that Bland has logged in already. All browser cookies have a few standard attributes, such as a name. The LTPA cookie name in particular is LtpaToken. (By the way, when you configure SSO, note that we generally refer to the LTPA cookie in our configuration utilities as the SSO LTPA "token." When we refer here to the SSO cookie, we could interchangeably use the term SSO token.) In addition to a cookie name, the LTPA cookie has a value, as all browser cookies do. In the case of the LTPA cookie, we can't figure out much about the cookie value on first glance because the value is encoded. By requiring that the LTPA cookie value be encoded, the critical information contained in the cookie can travel incognito across the internet.
As is typical for browser cookies, the LTPA browser cookie has associated domain information. When Bland logs in at spycentral, the spycentral server creates the LTPA cookie. The spycentral server lives in the spies.com DNS domain, therefore the cookie domain information is set to spies.com. The domain information indicates that this cookie should be honored only in the DNS domain of spies.com. Because the LTPA implementation relies on browser cookies that have this domain information, in general this implies that the SSO environment must be deployed only in one DNS domain. In our example deployment, our server machines are spycentral.spies.com, spymeetings.spies.com, and spyVsSpy.spies.com. Every machine is in the spies.com DNS domain. This restriction to deploy SSO within one DNS domain relates directly to the circumstance that browser cookies with domain information are at the heart of the LTPA implementation. (However, note that workarounds exist for this DNS problem -- see this sidefile.)
Now that we've briefly discussed the various parts of the LTPA browser cookie, let's get back to the basics of how this cookie plays a leading role in our SSO solution. After Bland has logged in and the LTPA cookie is received by Bland's browser, the browser is automatically going to be sending out this cookie in HTTP traffic. No special configuration is needed; this is just the standard way for a browser to behave. The browser will constantly be sending this cookie out in every HTTP request it sends to any URL destination in the correct DNS domain. For example, when Bland enters a URL at spycentral.spies.com, the browser sees that it has a cookie that applies to the spies.com domain, and the browser automatically sends the LTPA cookie along. The same is true when Bland accesses a URL on spymeetings.spies.com. On every applicable HTTP request, the browser sends the cookie. What happens when an SSO server receives an HTTP request and sees that the LTPA cookie is included? The server verifies the cookie and sees that the cookie belongs to Bland, the logged in user. The server can then allow the access that is appropriate for Jim Bland at that server.
In summary, it's the browser's job to figure out when it's appropriate to be sending out this LTPA cookie with HTTP traffic (see figure 3).
Suppose Jim Bland browses to a URL that is not in the spies.com DNS domain, for example, suppose he browses to a URL in cia.gov (probably to look for a job with more glamourous assignments). In this case, the browser cannot send the LTPA cookie, because that cookie does not apply to cia.gov, it only applies to spies.com. The browser simply will not send the cookie to a cia.gov destination, therefore the receiving server has no information on who the user is. The cia.gov server will probably prompt Bland to enter his user name and password before allowing access.
Figure 3. Browser sends LTPA cookie only to servers in spies.com
In figure 3:
A. Bland has already logged in. The browser automatically sends the LTPA cookie that allows him access to the URL on spycentral.spies.com.
B. Bland browses to a URL on another server in the spies.com DNS domain, and gains access because the browser is sending the LTPA cookie.
C. The browser cannot send the LTPA cookie to www.cia.gov because it is not in a matching DNS domain, therefore the cia.gov server must prompt Bland to log in with username and password before allowing access.
Keep the keys out of criminal hands
SSO is terrific from the standpoint of user convenience, but it would be of little value if it were insecure. Security is paramount, especially where members of TGSA's arch enemy, BEDLAM (Bureau of Egregiously Dangerous Lawless Assassins and Murderers), are at large. The LTPA cookie is secure because it is created using secure cryptography. The server creating the LTPA cookie uses a set of cryptographic keys. The cryptographic keys are used to encode the cookie, and the encoded cookie travelling to the user's browser cannot be decoded by someone who does not have the cryptographic keys. The cryptographic keys also are used to validate the cookie such that the cookie integrity is verifiable and tampering can be readily detected. All servers in the SSO environment must share the same cryptographic keys. When an SSO server receives an HTTP request and sees that the LTPA cookie is included, the server verifies the cookie using its copy of the shared cryptographic keys, and the information in the valid cookie allows the server to recognize the logged-in user (for example Jim Bland).
The secure cryptography used by the SSO servers ensures there will be no chance to pull off a cookie forgery. Suppose Bland's enemy (and BEDLAM's leader), Dr. Notnow, tries to create his own SSO cookie in hopes of hacking into the SSO servers. Dr. Notnow hopes to erase his parking violations recorded in the online databases. Dr. Notnow will not succeed at hacking into the SSO servers because he does not have the cryptographic keys. A bogus cookie coming in from Dr. Notnow will be ignored because the cookie cannot be validated.
In a WebSphere Portal environment, the LTPA cryptographic keys normally would be created by WebSphere during SSO configuration. An administrator might then export the keys to a file, to be brought over to other SSO servers (for instance, Domino) so that the keys can be imported there. Obviously, you want to handle this key file with extreme care, and keep any copies of the file under lock and key (if not retinal scan)!
"Permit me to introduce myself"
Okay, you should now be convinced that SSO security is built-in (and see this sidefile for additional tips on how to properly deploy a secure SSO environment). So let's get back to discussing what is inside this encoded cookie. Here's more detail about what happens when Jim Bland logs in. First, he provides his user name jb013 and his password. The login server then does a lookup in the directory to find user jb013. In the directory, suppose an entry is found for a user with the distinguished name uid=jb013,ou=secret,dc=spies,dc=com. After the password information is verified for this user, the server now knows the user by this distinguished name. This distinguished name is written in the LTPA cookie that is generated and sent to the browser. The browser sends the cookie along in HTTP traffic. What happens then? As Bland browses to a URL in the SSO environment, an SSO server receives the cookie and uses the cryptographic keys to decode and validate it. The SSO server will see that inside the cookie there is this user name uid=jb013,ou=secret,dc=spies,dc=com. The SSO server identifies the user based on this name that is present in the LTPA cookie (see figure 4).
Figure 4. Inside the encoded cookie
In figure 4:
A. Bland is prompted to log in, therefore he provides his username jb013 and password.
B. The server looks up user jb013 in the directory, and finds a matching user record against which to verify Bland's password.
C. Bland is now logged in. The server sends back to the browser the LTPA cookie which contains Bland's distinguished name.
In an environment where there is only one directory that all SSO components are using, the name in the LTPA cookie is sufficient to positively identify the user. However, problems can arise in more complex environments where there are multiple directories, if there are multiple name formats being used across these directories for a single user such as Bland. Suppose two directories are in use: Microsoft's Active Directory and IBM Lotus Domino Directory. It is problematic when Bland's Active Directory distinguished name is different from his defined Domino distinguished name. When a user has more than one name, this is an issue simply because the LTPA cookie contains one and only one name to identify the logged-in user. The user's name included in the LTPA cookie may be the only information the receiving server has about the user. If the receiving server has trouble recognizing the name in the LTPA cookie, SSO will die an unpleasant death.
Understanding the multi-directory, multi-identity problem
The TGSA IT administrators envy Jim Bland's mission to tackle the parking violators of the world--if only the IT job were a similar "mission possible!" For IT administrators, the world is not enough when there is an entire universe to master. Corporate IT infrastructure is seldom organized according to any master plan, and more often resembles outright chaos. While the ultimate goal of many organizations is to have a single directory containing all the corporate users, it’s more typical that at least two (and often more) directories exist within the corporate structure. Administrators are left with a tangle of password verification issues, multiple identities, and the need for workable solutions.
So why more than one directory? As many of you are aware, diverse applications carry with them diverse directory needs. Multiple application environments across organizations have led to disparate user repositories being populated over time; for example, a company that has an existing WebSphere Portal Application environment with users and groups already created in an LDAP directory, and an IBM Sametime environment that uses the Domino Directory. Domino applications' access control mechanisms (ACLs) and execution control mechanisms (ECLs) are often complex and difficult to change. Reorganizing or duplicating access control lists based on a particular directory that is in use at the time would be a difficult, time-consuming, and cost-prohibitive solution. Finally, in the world of constant change, corporate mergers and acquisitions (or government coups) often force you, the administrator, to go through the exercise of incorporating a new directory into an existing infrastructure again and again.
Good covert operatives, like Jim Bland, always have an escape plan, and so does the TSGA IT department. In the upcoming examples, we'll discuss how IBM helps Bland's superior VM and her IT admins successfully integrate their multi-directory, multi-identity world. Their infrastructure requires the use of two directories. The TSGA implementation of WebSphere Portal Server (WPS) and WebSphere Application Server (WAS) is configured to use an LDAP IBM Directory Server (ITDS); and the lush collaborative environment provided by applications such as Domino Web Access portlets, Sametime, and Quickplace requires the use of the Domino Directory. TSGA agents are located in both directories.
Understanding the multi-identity, multi-directory scenario is key for TSGA, because it is VM's plan to utilize the full range of IBM collaborative products, including Domino, Portal applications, and also IBM Workplace Collaboration Services without incurring upheaval. VM requires functional SSO when deploying the IBM family of products, solutions, and technologies that seamlessly transform the way Agent 013 and his colleagues work in the dangerous world of espionage and parking scams.
As mentioned earlier, names are critical in our SSO world. Jim Bland really only has one name, but--in the world of espionage and in the TSGA IT infrastructure--many identities. Back at TSGA headquarters, several applications have been deployed with varying directory infrastructures so that Bland has many identities, each of which is formatted based on the schema of the issuing directory. For example, Blands' distinguished name (DN) that exists in the IBM Tivoli Directory Server (ITDS) differs from his Domino distinguished name in both hierarchy and syntax:
| LDAP formatted identity (ITDS) | Domino formatted identity |
| uid=jb013,ou=secret,dc=spies,dc=com | cn=Jim Bland/ou=secret/o=spies |
Portal login identity vs. Portal application identity
Remember, it is key that SSO servers and applications recognize the users once they have logged in. When Bland sits at his browser and enters a WebSphere URL, he is prompted to log in with user name and password. Always pressed for time, Bland enters his unique identifier jb013. The WebSphere application server verifies Bland's identity by looking up his name in the ITDS server and verifying the password entered. After his name has been verified, Bland can now access the WebSphere Portal Server content in his browser (see figure 5).
Figure 5. Portal login identity
The LTPA cookie now contains Blands' LDAP identity: uid=jb013,ou=secret,dc=spies,dc=com. This is his Portal login identity.
Jim now decides to check his email (he's waiting for a reply to his CIA job search inquiry) and switches to his Domino Web Access portlet (see figure 5). The LTPA token is sent via HTTP to the Domino Web Access server, which then searches the Domino directory to verify his identity (authentication), and, based on his identity, the server will decide whether to allow him use of Domino Web Access resources (authorization). But the LTPA token contains his Portal application identity. Will Bland be allowed access?
Bland is indeed granted access, and his portal identity jb013 has been mapped to his Domino identity Jim Bland within the Domino Web Access portlet. But, how does TSGA's integrated application environment handle the name mapping?
This concludes our review of SSO fundamentals, and the issues you may encounter running a multi-directory, multi-identity environment. In part 2 of this article series, we'll follow our hero Jim Bland and his associates through several SSO scenarios, and take a look at new SSO features offered in Notes/Domino 7.
- See the developerWorks: Lotus article, “Security APIs in Notes/Domino 7.0,†to learn about the new encryption/decryption APIs offered by Lotus Notes and Domino 7.0.
- For more information about new security-related features in Lotus Domino 7.0, see the article, "New features in Lotus Domino 7.0."
- See the Lotus Notes/Domino product page for more information about the Lotus Notes and Domino products.
- Get involved in the developerWorks community by participating in
developerWorks blogs.
Amy E. Smith is a principal information developer for the Lotus User Experience group. She's primarily responsible for Domino and Workplace security administration documentation. She is also a member of the team that supports the Lotus Documentation site on www.lotus.com. Amy is not now, nor ever has been, a member of the intelligence community, although she would love to have a shoe phone!
Terri Warren is an Advisory Software Engineer at IBM. She has worked on Directory Services since the mid-1990's, concentrating on LDAP and Domino. More recently, she's been focusing on directory integration between Domino and various IBM products, and in her distant past she worked on StreetTalk for Vines and the Distributed Computing Environment (DCE). While Terri is also not a member of the intelligence community, she believes Jim Bland would enjoy his job much more if he spent time tracking his foes on the world's best golf courses!
Jane Marcus is a Senior Software Engineer at IBM. She has been working in the area of security for a number of years, most recently focusing on Single Sign-On issues across various IBM products. Jane spends most of her time developing security for Internet applications and Web server technology, although occasionally she also creates new security user interfaces. Outside of work, Jane's interests include music as well as the quixotic pursuit of improved physical fitness. (Jane has also asked us to add that she's not a spy either.)
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
