On the afternoon of Tuesday, 09-04-07, there was a meeting about the usability of the login page and some of the closely related pages.
The first two applications slated for the pilot (Stellar and the Conflunce wiki system) will be directly supporting certificate authentication. Users will tend to only interact with Touchstone if certificates have already failed prior to the user ever arriving at Touchstone. This suggests that those users should not be presented with a choice of using certificates, especially since the Touchstone login is limited to a 5 minute login and new users are unlikely to obtain a certificate within that time limit and without otherwise loosing the session context for the login.
Futhermore NIST and ITAG have suggested that Touchstone should not be using SSLVerifyClient:optional for the certificate authentication. This leads to some additional useability concerns. When using SSLVerifyClient:required (as suggested by NIST and ITAG) an error dialog box will be generated by the user's browser, and we loose the ability to easily control what is displayed in the user's browser once the user has clicked the dialog box away. In some cases the previous page will be displayed, in other cases a blank page will be displayed. Stellar and Wiki are using SSLVerifyClient:optional so that they can catch the error and control what is presented to the user, and no browser generated error dialog box is generated.
All of this has led us to conclude that for the initial pilot rollout, the Touchstone login page will only offer the choices of Username and Password, or "use existing tickets". The certificate option will be added back at a later date as the UI issues are worked out.
One proposed use case for when certificates are added:
When a Stellar or Wiki user arrives at the Touchstone login page, it should be clear that certificate authentication is not a viable option unless the user takes other actions (such as obtaining a certificate in less than 5 minutes). The same should be true for other applications. However, as we move to state where applications will not be handling certificate authentication internally, then certificate authentication should appear as a viable option.
2nd use case:
If a user has been using certififcates via Touchstone for a long time as a stored prefence, the user won't typically see the Touchstone login page. When the user's certificate expires, then the user will be presented with the Touchstone login page, but there should be an indication that certificate authentication has already failed.
Why don't we use SSLVerifyClient:opional on the Touchstone login page?
When using the SSLVerifyClient:optional configuration, it is well documented that only some browsers support it. The option gets negotiated before the server can determine the browser type. What's not so well documented is which browsers support the option. NIST report that they have been bitten by this problem before.
Here is an old, not completely informative list of which browser do and do not support the option:
Some browsers may not handle ssl authentications and certificates correctly with apache.
List of known browsers that work with the following configuration.
- Firefox 1.0
- Internet Explorer
- Mozilla
- Safari
List of know browsers that do not work with the following configuration.
- Konquer
- Lynx
- Netscape (old)
List of know browsers that have yet to be tested.
- Opera
That information was found outside of MIT. Note that few version numbers are indicated. Also note that no mention of the growing number of browsers for mobile devices are mentioned. While Stellar or Wiki may not care about anything other than IS&T supported browsers, Touchstone needs to server a somewhat larger community in order to serve the needs of the entire campus. E.g. DLC web applications may have a requirement of supporting browsers that IS&T does not support. We do need a better understanding of the demographics and the requirements.
I'll also note that as recently as September of 2005 there was a security advisory regarding Apache when using this option.
Potential solution
One suggested solution for controlling what is displayed to the user when a certificate error occurs (if SSLVerifyClient:required is being used):
When the user clicks on the "use certificates" button, first refresh to a page that displays the page that you will want the user to see if an error occurs. Next attempt the authentication and redirection to the original page that the user wanted to access. If an error occurs then the dialog box will appear. When the user clicks it away, the intended error page should be present. If authentication is successful, the user will end up at the correct content.
If the network connection is slow or there are other latency issue, the user might be looking at the error page for quite a while before the authentication and redirection actually succeeds. But this can probably be made acceptable by careful wording and design of the error page.
Certainly at first glance, from a usability perspective using SSLVerifyClient:optional is a more attractive avenue. However as noted not all browsers support that option. There is also a rumor that browsers that don't support it can cause problems on the server side. We need to better understand these issues before a definitive plan of action can be agreed upon.
Other issues:
In order to proceed to pilot there are other tasks to complete, these include:
- Touchstone help page, with links to the set/unset preference page
- update of the run book
- additional Shib HA testing
- creating packages so that NIST can easily reinstantiate the IdPs if or when necessary
- transitioning the operations of the IdPs to NIST
Paul will discuss the transitioning to NIST issues with Mark. Joanna will work with CSS on an introductory Touchstone help page.