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.
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.