...
| Code Block |
|---|
<bean class="org.jasig.cas.authentication.handler.support.JaasAuthenticationHandler" p:realm="CASJAASconfig" /> |
JAAS is a rather complicated standard feature of current Java Runtime systems. It can be used directly through an API, or it can be configured for use by other components. In CAS, the JaasAuthenticationHandler uses it directly to validate a userid/password pair against various back end systems.
JAAS is a standard service into which a system administrator can configure pluggable authentication modules. This system model is used widely in Unix under the name "PAM". An application that accepts userids and passwords can simply pass them to JAAS without knowing exactly how they are going to be tested. The Application programmer doesn't have to know about security and authentication. Someone else configures a bundle of authentication parameters that indicate which back end protocols to use and which back end systems to contact.
Internally, JAAS is essentially duplicating the same set of services represented by the AuthenticationManager and AuthenticationHandlers. In some configuration file the name "CASJAASconfig" is associated with one or more fully qualified Java classnames of classes that implement the JAAS Service Provider interface, but for CAS the only interesting provider class is the one that uses Kerberos 5. There is a JAAS LDAP provider, but CAS has a separate optional LDAP module with a Handler and Resolver that provides a better choice.
That said, it is possible that you will want to authenticate users with some new option (say a smart card) and the vendor of that technology will provide a JAAS Service Provider class and JAR file as the preferred way to use the device. In that case, you use the JaasAuthenticationHandler configured as above, but in the realm property you put the name of a bundle of parameters in the JAAS login config file that selects and configures the vendor JAAS provider module (which in some cases will communicate out through the net to an appliance device that does most of the work).
The one restriction is that the JaasAuthenticationHandler module supplied with CAS 3 only supports Credentials with a userid and password. If some new technology generates one time use passwords, it can be Java that hasits own more comprehensive description page.
The configuration example given above tells CAS to authenticate the userid and password through JAAS using the bundle of parameters in the JAAS "login configuration" file named "CASJAASconfig". To determine exactly what JAAS is going to do, you have to search the environment, find the login configuration file, and lookup the name.
However, at this time it is very late for Java to be using legacy systems that JAAS supports like NIS and NT LAN Manager. If you want to authenticate to an LDAP server, it is better to use the CAS LDAP AuthenticationHandler described immediately below instead of using JAAS LDAP. So in practice, you use this configuration when you want to authenticate the userid and password in a Kerberos 5 KDC. This could be an MIT K5 server, or it could be Active Directory.
It is a matter of discussion whether the best way to authenticate to AD is using the K5 protocol though JAAS or using the LDAP Handler. Which is most efficient? Which provides the best recovery when a Domain Controller goes down? For the moment, Yale is inclined to use the LDAP Handler.
However, JAAS remains a live prospect when you are using exotic hardware (a USB dongle or a smart card) that requires authentication through some network appliance and the vendor only supplies a JAAS plug-in to do the authentication.
The one restriction is that the JaasAuthenticationHandler module supplied with CAS 3 only supports Credentials with a userid and password. If some new technology generates one time use passwords, it can be used as is. However, if authentication requires more than these two data items, then it may be necessary to modify this original handler to support any extra fields.
[to be continued]
The JaasAuthenticationHandler uses the JAAS Java API to authenticate a userid and password against an external Kerberos 5 or LDAP system. The realm parameters (set to "K5auth") is just the name of a bundle of configuration parameters in the login configuration file. In normal Java, a login configuration file is specified by the "login.config.url.1" property in the {jre}/lib/security/java.security property file. An application specific configuration file can be provided by the Java code that calls JAAS. Each JAAS login configuration file contains named bundles of configuration parameters designating the name of a class that provides the JAAS login service and a list of parameters needed by that class to connect to the Kerberos KDC, the LDAP server, etc.
When more than one login configuration file is specified, they are concatenated. An exception is thrown if the same named configuration bundle is found more than once, say in the JRE configuration file and the local application configuration file.
JAAS uses the credentials (typically the userid and password) to log the user on to the backend system and generates some standard Java objects (Subject and Principal). If the backend system is a Kerberos 5 KDC, then the generated Principal object can contain a key and a Kerberos TGT. However, the JaasAutheticationHandler does not use artifacts generated by the login. It simply uses JAAS to autheticate the userid/password combination and then logs the user off from the backend system before returning to the AuthenticationManager.
LDAP (AD) Password Handler
...
LDAP (AD) Password Handler
| Code Block |
|---|
<bean class="org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler">
<property name="filter" value="sAMAccountName=%u" />
<property name="searchBase" value="dc=yu,dc=yale,dc=edu" />
<property name="contextSource" ref="ldapContextSource" />
<property name="ignorePartialResultException" value="yes" /> <!-- fix because of how AD returns results -->
</bean>
|
...
JAAS can authenticate a userid/password by logging the user on and then off of an external LDAP source. However, the BindLdapAuthenticationHandler shown here is more efficient because it maintains a pool of existing LDAP connections to AD that it reuses to validate passwords rather than setting up and tearing down a connection for every user login.
X.509 Certificate Handler
...
passwords rather than setting up and tearing down a connection for every user login.
X.509 Certificate Handler
| Code Block |
|---|
<bean class="org.jasig.cas.adaptors.x509.authentication.handler.support.X509CredentialsAuthenticationHandler" p:trustedIssuerDnPattern="CN=Yale University ITS Issuing Certifying Authority.+" p:maxPathLength="3" <bean class="org.jasig.cas.adaptors.x509.authentication.handler.support.X509CredentialsAuthenticationHandler" p:trustedIssuerDnPattern="CN=Yale University ITS Issuing Certifying Authority.+" p:maxPathLength="3" p:maxPathLengthAllowUnspecified="true" /> |
The X509CredentialsAuthenticationHandler examines a User Certificate submitted with the HTTP request. The container (Tomcat, JBoss, etc.) has already verified that the Certificate comes from a trusted Certificate Authority.Generally the container is configured to only accept User Certificates issued by one of the standard Yale University CAs and not from any public sources. With this configuration, the Bean requires that the CA be specifically the Yale University ITS Certifying Authority and not one of the other CAs that the container trusts.
...
p:maxPathLengthAllowUnspecified="true"
/>
|
The X509CredentialsAuthenticationHandler examines a User Certificate submitted with the HTTP request. The container (Tomcat, JBoss, etc.) has already verified that the Certificate comes from a trusted Certificate Authority.Generally the container is configured to only accept User Certificates issued by one of the standard Yale University CAs and not from any public sources. With this configuration, the Bean requires that the CA be specifically the Yale University ITS Certifying Authority and not one of the other CAs that the container trusts.
X.509 Certificate Resolver
| Code Block |
|---|
<bean class="org.jasig.cas.adaptors.x509.authentication.principal.X509CertificateCredentialsToIdentifierPrincipalResolver"
p:identifier="$CN" />
|
If you decide to use X.509 certificates, you must configure or code a Resolver that knows how to search through the Distinguished Name fields and the SubjectAltName fields to extract the Netid. In extreme cases, the Netid may not be in the Certificate itself, so the Resolver will have to do some sort of (probably) LDAP lookup using the Certificate DN to find a suitable Netid string. However, in this example the netid is the first CN= field in the DN of certificates issued by the Yale ITS CA.