Client Certificate over SSL

Every Web Browser has the ability to install Client Certificates. For our purposes, there are two types.

1. Well known vendors (Thawte) will provide free Client Certificates attesting to an E-Mail address. Since the process of vending the certificate involves sending mail to the address, a certificate for Howard.Gilbert@yale.edu means that the subject had access at some time to this mail account. These certificates are almost impossible to revoke, so there is no recovery after a break-in. Using these certificates for active members of the community is a bad practice, but may have to be tolerated.
2. Institutions can issue their own certificates to active members using their PKI. In this case, the root CA would not be known outside the institution, but the Subject field can be controlled and the certificate can be revoked and reissued upon a break-in.

An X.509 Certificate has a Subject field in X.500 DN format. There are many local conventions for this format and, in general, some custom code may have to be added to the AuthHandler to interpret specific Subject formats. There is also provision for alternateSubjectNames in particular formats: RFC822 names for E-Mail, Windows UPN, or Kerberos principal names, DNS names for computers, Windows NT 4 Domain names. This is both a mess and obsolete. RFC 822 includes both Howard.Gilbert@yale.edu and gilbert@NET.YALE.EDU. Windows NT was long ago replaced by Active Directory, but no new formats were defined.

While X.509 Certificates are the most obvious and accessible form of new authentication, a lack of standards and obsolecence means that it may never be possible to provide a standard module that handles Certificates for all CAS institutions. Instead, a sample of plug-in logic may be provided that a Java programmer at an institution may have to adapt to local conventions.

Because a Certificate can contain more than one Subject name, it may generate more than one Authetication Subject Entry. In a well run institution, all forms of Subject name should be foreign keys to all other Atuhentication database. However, there is no guarantee that "gilbert@NET.YALE.EDU" (my K5 principal in the MIT Kerberos realm) will necessarily be linked to "Howard.Gilbert@yale.edu" (my Windows Active Directory Universal Principal Name). Therefore, the Certificate AuthHandler may produce more than one CAS Subject Entry from a single Certificate.

Institutions requiring multiple methods of authentication may want both a Certificate and a Userid/Password to allow access to particularly sensitive information. In this case the AuthHandler would generate a CAS Subject Entry for the Netid (authentication method = certificate) but require a second AuthHandler to generate a second Subject Entry (authentication method = password).

Certificates can be rejected if:

They are expired.
They have been revoked.
They are issued by an unrecognized CA.

A browser may have multiple Client Certificates issued by more than one CA. The Web Server has an installed list of CA's. If the Server is not brain dead, it will present the Browser with a list of acceptable CA's, and the Browser will only return a Cetificate with one of those CA's in the Issuer chain. CAS/Tomcat inherit the default CA environment provided by Java, but this can be overridden by giving Tomcat a special CA Trust database in the form of a JKS file specified in the server.xml. Generally speaking, an institution with its own local PKI should present a JKS file in which the institutional CA is the only entry, thus forcing the Browser to present an institutional Certificate in preference to some piece of Thawte trash.