 |
Session authentication on Lotus Labs
by
Tara
Hall
Level: All
Works with: Notes/Domino
Updated: 10/27/2003
Inside this article:
Domino session authentication
Single sign-on
Troubleshooting
Your feedback
Related links:
LDD Exposed: Implementing cookies on the Lotus Developer Domain
WebSphere and Domino single sign-on
Configuring a Lotus single sign-on environment tutorial
Domino Administration help
Get the PDF:
 (220 KB)
|
 |
As we told you in our article, "Implementing cookies on the Lotus Developer Domain," session authentication was coming, and now it's here. We've replaced our standard HTTP authentication, which only allowed you to sign into one forum at a time, with session authentication that allows you to sign in once and to access all forums and the Sandbox during a single session. While more than a few of you experienced some inconvenience during our initial implementation of session authentication, we have since resolved those issues and hope that you find session authentication useful and convenient. This article describes what session authentication is and explains the changes that we made to resolve the issues that you experienced.
What is session authentication?
To understand session authentication, you need to know what is a session or more accurately what is a user session. In Web metrics, a user session is also known as a visit. A user coming from a specific IP address who has not previously visited our site in the last 30 minutes constitutes a single user session or visit. For instance, if you visit our site from IP address 9.99.99.999 at 10:00 in the morning, leave the site at 10:30, and then return to our site at 1:00 in the afternoon of the same day using the same IP address, you have made two visits to our site. If, however, you visit the site at 10:00 AM, leave the site and return at 10:20, then it constitutes only one visit.
Authentication is the process by which your credentials are verified. Using a user name and password pair, authentication can determine if you are who you say you are. Sessions in which you log into our forums or the Sandbox are authenticated sessions. The session remains authenticated for as long as the user name and password that you provide remain active.
Let's revisit the previous scenario. Suppose you visit the site this morning at 10:00 AM and sign into one of our forums. If you leave our site at 10:10, and return at 10:20, you are still authenticated on our site if these two conditions are met:
- You did not close your Web browser. If you close your Web browser and reopen it to return to our site, you must log in again because the cookie we use for authentication is only temporary and not permanent. We discuss this in more detail later in this article.
- You did not sign out of our site before leaving. If you sign out of the site, leave the site, and then return, you must sign in again. Signing out removes our temporary cookie.
Our cookie does not expire for 12 hours, so if you visit the site at 10:00 AM, leave the site at 10:30 AM, and then return at 9:59 PM, you remain authenticated on our site as long as you do not close your Web browser or sign out during those 12 hours.
When you log into our site the following occurs:
- After you click the Sign In to participate link, the Login form opens. This form is secured by HTTPS or Hypertext Transfer Protocol over Secure Socket Layer (SSL), so the credentials that you submit are encrypted.
- The Domino server receives the user name and password pair and compares them to the Person documents in our Domino Directory. If you submit valid credentials, you return to the form that you logged in from and can now create topics and responses. If the credentials that you submit are not valid, then an error page is returned to you.
But let's suppose that your Web browser does not have cookies enabled. Session authentication cannot work if your Web browser does not allow cookies; however, our application cannot detect whether or not you have cookies enabled, so instead of returning an error page, our application continually prompts you for a valid user name and password. If this happens to you, check your Web browser's cookie settings.
- Assuming that your user name and password were authenticated, the Domino server on which you logged in sets a temporary cookie valid for the length of your session and returns you to the forum in which you logged in via HTTP. This temporary cookie, also known as a session cookie or session authentication token, lasts for 720 minutes (12 hours) or until you close your Web browser. The cookie is stored in memory and not on your hard-drive like permanent cookies. If you close your Web browser, the cookie immediately expires. If your session remains idle for more than 12 hours, the cookie expires.
Domino session authentication
In Domino, you can configure session authentication for a single server or for multiple servers. When you configure multi-server session authentication in Domino, you implement single sign-on. This implementation allows users to log in once to a domain and to access applications on different servers. For instance, if you implement single sign-on in your domain, if a server fails and users are failed over to another server, their credentials remain valid and they can continue working as usual. The transition is seamless.
In single server session authentication, when the server fails and users are failed over to another server in the domain, they must log in again because their credentials were not shared among the servers in the domain. This was our original implementation of session authentication. For example, you logged into one server in our Web domain, after validating your user name and password, and our application returned you to the forum or to the Sandbox on the same server. As long as you remained on that server during your session, your session was authenticated. If, however, you left the server for whatever reason, your credentials were no longer valid.
Generally, when you visit our site, our load balancing servers direct you to a server and you remain on that server for the duration of your session. However, during your session, you may be directed to another server if the server you access fails or needs to be restarted. If this was the case when we implemented single server authentication, you had to log in again to access the forums or Sandbox.
There are two ways to enable session authentication in Domino: using Web Site documents or using the Server document. We use Web Site documents because our site uses Web Site documents. When you configure session authentication, you specify in the Web Site document the following information:
- Multiple servers, single server, or disabled (disabled does not allow Domino to use cookies for authentication)
- Idle session timeout in minutes, if you choose single server (default is 30 minutes)
- Maximum number of active user sessions allowed on the server (default is 1,000)
Single sign-on
Single sign-on in Domino requires a Web SSO Configuration document. You can create this document and share it across more than one Domino domain. To enable single sign-on, the same DNS domain must appear in the URL and in the cookie. In the Web Site or Server document, the full DNS server name must appear in the Host name field for your clustered servers.
Domino can generate a Light-weight Third Party Authentication (LPTA) token for single sign-on. Domino supports SSO with both Domino and WebSphere servers using a WebSphere-generated LPTA token. For that type of environment, Domino and WebSphere must share the same LDAP directory.
LTPA tokens store the following information:
- The token (cookie) name LtpaToken
- The domain name
- Cookie expiration information (The LTPA token expires when you close your Web browser.)
- Security information (For instance, you can specify whether or not the token is only sent through SSL.)
- The token value, such as Base64Encoded(LtpaToken)
The LTPA token encrypts the following information:
- User ID
- Expiration time (not to be confused with the cookie expiration information, the expiration time sets a time limit for expiration with 30 minutes being the default)
- Digital signature to authenticate the token
The common LDAP directory is required because the LTPA token uses the distinguished name to identify users. Typically, users with flat names cannot use SSO; however, when all the servers are Domino, you can use SSO with flat names.
Configuring Domino and WebSphere for single sign-on involves the import and export of keys, but that information is beyond the scope of this introductory article. If you want more information regarding Domino and WebSphere single sign-on, refer to the respective document for each product. Note, however, that WebSphere is not required for single sign-on. Domino is capable of single sign-on using its own token.
For more information about session authentication and single sign-on, see the Domino Administrator help. For information about WebSphere single sign-on, see the developerWorks article, "WebSphere and Domino single sign-on."
Standard HTTP authentication versus session authentication
Standard HTTP authentication (also known as basic name and password authentication) and session authentication differ in these respects:
- Standard HTTP authentication stores your user name and password in the HTTP header, which is not secure. Session authentication, on the other hand, encrypts your user name and password and stores your credentials in a temporary cookie.
- Standard HTTP authentication sends your credentials each time you make a request, such as creating a topic and a response. Session authentication sends your credentials only once during a session when you log into the server.
- Standard HTTP authentication remains active until you close your Web browser. Session authentication lets you sign or log out, so that if you leave your workstation, no one can use your credentials to post in our forums or Sandbox.
While some of you have encountered problems with session authentication on our site, we hope that the benefits of session authentication outweigh standard HTTP authentication.
Troubleshooting
Let's address some of the issues that you experienced with session authentication and describe how we resolved those issues (or what you may need to do to fix these).
Timeout
One problem that some users reported involved being prompted to log in again while completing a post in one of our forums. We understand how frustrating it must be to write a topic or response, and then to lose it before you could post it because you were prompted again for a user name and password. We believe that this problem was a result of the idle session timeout. Initially, we accepted the default value of 30 minutes, but increased it to 720 minutes or 12 hours to prevent your session from timing out.
However, even after this change was made, some of you continued to experience a timeout problem. We concluded that our single server implementation of session authentication was the cause, so we switched to multi-server session authentication. Now if any of you are failed over to another server in our domain, your user name and password remain authenticated.
Repeated prompting for user name and password
If you are repeatedly prompted to enter a user name and password, then the problem may lie in your Web browser. As stated earlier, if you enter an incorrect user name and/or password, our application returns an error message to notify you of the problem. However, if you do not receive an error message, check your Web browser cookie settings. For instance, Microsoft Internet Explore 6.0 and higher users can check their Privacy settings for cookie enablement. Choose Tools - Internet Options, then select the Privacy tab.
Refer to your Web browser help for instructions on how to enable cookies.
Saving user names and passwords
Some of you have asked for the ability to save your user name and password so that the next time you return to our site, your credentials are stored locally on your client machine so you don't have to remember them each time you visit our site. This feature is enabled both through our application and through your Web browser. We modified our Sign In form to enable your Web browser to store your user name and password. Our form describes how to enable both Microsoft Internet Explorer and Netscape Mozilla browsers, so we won't repeat them here. The AutoComplete feature in Internet Explorer and the Password Manager feature in Mozilla let you save passwords. The following screen shows the AutoComplete Setting dialog box in Internet Explorer.
Your feedback
If you continue to experience problems with session authentication on our site, please let us know by submitting feedback. Be as specific as possible when giving feedback and answer as many of the following questions as you can:
- Which areas of the site did you visit (Sandbox, Notes/Domino 6 forum, and so on)?
- How long did your session last before timing out?
- Which Web browser and version are you using?
The more information that we receive from you, the better we are able to resolve your problem. |
|