Tomcat and CAS

Goals

There are a number of issues related to tomcat and CAS which would be good to fix.

• We would like to switch to using Crowd for authentication instead of kerberos, since this will allow users without SLAC id's to login. Fermi would like to use this.
• It would be useful to restrict access to arbitrary URL's, such as subversion, probe , manager. EXO (and others) would like to use this for protecting access to subversion.

Issues

• The tomcat integration library does not work with the current version of CAS used at SLAC due to a bug in the CAS server. It does work with the latest version of CAS server. The instructions for deploying the tomcat integration library are here: https://wiki.jasig.org/x/bgFXAg. 
• The tomcat integration library allows authentication to be done via CAS, but authorization is still done by a file called manager-user-roles.properties. It should be fairly easy to extend this to use the group manager.
• The version of CAS server used by Fermi has some SLAC specific mods. In particular it depends on and makes calls to the LoginFilter . We need to remember what this is for and if it is really needed. 
• The current version of CAS in Fermi CVS appears to have some minor issues. It is not clear that the maven2 build has ever been deployed. We should probably create a SRS version if it does not already exist, since we are using it for more than just Fermi. We have to keep running it on glast-ground however, since we do not have a certificate for srs. We could run a new version in parallel with the old version for a while.
• We should probably upgrade to the latest version of CAS (from ja-sig) while we are making other changes. Perhaps we should start fresh from the instructions at: https://wiki.jasig.org/x/sgKkAQ
• Developing an interface for crowd should be straightforward. We need to develop our own password handler, similar to the SLACPasswordHandler we have now, but talking to crowd instead of kerberos. The instructions for building a crowd client are here: http://confluence.atlassian.com/x/A-AC. We would start by using crowd-test (https://crowd-test.slac.stanford.edu:8443/).

Status

Maven2 Project org-srs-cas

We have developed a new SRS maven project called org-srs-cas. It contains the following CAS related modules:

Project org-srs-cas-server 

A Maven2 project for the new SRS CAS server has been created and added to the SRS subversion repository. It is built as an overlay of cas-server-webapp as suggested in the instructions at https://wiki.jasig.org/x/sgKkAQ.

It is currently configured to delegate the authentication to the SLAC crowd-test server.

The following are the steps required to authenticate with crowd:

• Add the crowd-integration-client dependency

        <dependency>
            <groupId>com.atlassian.crowd</groupId>
            <artifactId>crowd-integration-client</artifactId>
            <version>2.0.0</version>
        </dependency>

Please notice that we are currently using crowd version 2.0.0. This is somewhat behind the official crowd versions that are around2.2.x.

To import this dependency it is necessary to add the following repository

        <repository>
            <id>atlassian-proxy</id>
            <name>Atlassian Proxy Repository</name>
            <url>https://m2proxy.atlassian.com/repository/public</url>
        </repository>

• Write a custom authentication handler to talk to crowd

Because of the dependency to version 2.0.0, the custom crowd authentication handler org.srs.cas.server.authentication.CrowdAuthenticationHandler is currently using the SOAP mechanism rather than the REST interfaces as suggested in the instructions above. 

• Add the properties file crowd.properties

To authenticate users with crowd, the application delegating the authentication needs to authenticate itself with the crowd server first. We have added the application cas with the crowd-test server and a set of ip addresses for this purpose. When the SOAP SecurityServerClient does the authentication of the service, it looks for the crowd.properties file in the classpath. This file looks like:

application.name=cas
application.password=*****
crowd.server.url=https://crowd-test.slac.stanford.edu:8443/services/

• Tell the CAS server to use our custom crowd authentication handler

This is done in WEB-INF/deployerConfigContext.xml by replacing the default SimpleTestUsernamePasswordAuthenticationHandler with:

     <bean class="org.srs.cas.server.authentication.CrowdAuthenticationHandler" />

• Enable SSL

Add the following code to WEB-INF/web.xml

    <security-constraint>
        <web-resource-collection>
            <web-resource-name>Entire Application</web-resource-name>
            <url-pattern>/*</url-pattern>
        </web-resource-collection>
        <user-data-constraint>
            <transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
    </security-constraint>

Project org-srs-cas-tomcat-integration

This project allows to integrate CAS in Tomcat's authentication, so that Tomcat will delegate user authentication to CAS. This project also provides an implementation of a Realm with role authorization against the GroupManager application.

The project is configured to create an assembly with all the dependencies required to integrate the CAS authentication in Tomcat v6. It currently depends on version 3.2.0 of cas-client-integration-tomcat-v6.

The following steps are required to activate the CAS authentication in Tomcat:

• Create the assembly running mvn assembly:single. This produces a zip file in the target directory of the project
• Copy and unpack the zip file in your Tomcat installation. We put it in tomcat/BASE60/common/common/lib/cas-integration; all the jars in the directory will be loaded when Tomcat is started as we modified the common.loader in tomcat/BASE60/common/conf/catalina.properties

• common.loader=${catalina.home}/lib,${catalina.home}/lib/*.jar,${catalina.base}/common/lib/*.jar,${catalina.base}/common/lib/cas-integration/*.jar
  

• Make sure that above directory cas-integration symlinked from the lib directory of the particular Tomcat instance. For example tomcat/BASE60/glastlnx**/common/lib
• We modified ${CATALINA_BASE}/conf/context.xml to include:

  <Realm
    className="org.srs.cas.tomcat.integration.GroupManagerRealm"
    />
  <Valve
    className="org.jasig.cas.client.tomcat.v6.Cas20ProxyCasAuthenticator"
    encoding="UTF-8"
    casServerLoginUrl="https://glast-ground.slac.stanford.edu/cas-srs/login"
    casServerUrlPrefix="https://glast-ground.slac.stanford.edu/cas-srs/"
    serverName="serverName:serverPort"
    />

where serverName and serverPort are the name and port on which Tomcat is running. The above instructions add the CAS authenticator to the Tomcat context and add the GroupManager Realm for authorization.

The SRS Cas Proxy Authenticator 

In the above example we used the class org.jasig.cas.client.tomcat.v6.Cas20ProxyCasAuthenticator as Valve. As part of the configuration we have to pass the serverName. For most applications that are to accessed using IIS this is fine as the serverName is shared by many servers (like glast-ground.slac.stanford.edu). For applications like probe  that need to be accessed directly on the server, this configuration would require to have duplicate configurations like the one above each on the server on which probe is running.

To avoid duplication of configuration we ended up writing our own class: org.srs.cas.client.tomcat.v6.Cas20ProxyCasAuthenticator. This class is a copy of the jasig class org.jasig.cas.client.tomcat.v6.Cas20ProxyCasAuthenticator (it could not be extended as this class is final).

This SRS copy of the Cas Proxy Authenticator parses the serverName and replaces evironment varialbes. The configuration of the Valve now looks like:

 <Valve
 className="org.srs.cas.client.tomcat.v6.Cas20ProxyCasAuthenticator"
 encoding="UTF-8"
 casServerLoginUrl="https://glast-ground.slac.stanford.edu/cas-srs/login"
 casServerUrlPrefix="https://glast-ground.slac.stanford.edu/cas-srs/"
 myServerName="${HOST}.slac.stanford.edu:8080"
 />

Also notice that the serverName property has not become myServerName (the method getServerName is also final and inherited from the parent).

The GroupManager Realm org.srs.cas.tomcat.integration.GroupManagerRealm

This class is responsible for authorization of users that have been authenticated with CAS.

It extends org.jasig.cas.client.tomcat.v6.AbstractCasRealm and in the overwritten method getDelegate() it returns the CasRealm that does the actual authorization: org.srs.cas.tomcat.integration.GroupManagerDelegate.

When authentication is successful with CAS this delegate class has a chance to reject the user through the authenticate(Principal) method; in this implementation we accept all users. Users that have been accepted will be authorized via the hasRole(Principla, String) method in which we ask the GroupManager if the given user belongs to the role.

To authorize against the GroupManager the following steps are taken:

• Choose which GroupManager to use. This can be chosen at the Tomcat level by setting the System property experiment.groupmanager.url. The default is *http://srs.slac.stanford.edu/GroupManager\* (http://srs.slac.stanford.edu/GroupManager*).
• Choose which experiment to use; the experiment by default is SRS. This default can be overwritten at the Tomcat level by setting the System property* org.srs.web.base.experiment*. Finally the experiment can also be specified at the role level; we accept roles in the form EXPERIMENT:ROLE. For roles that match this pattern a user will be checked for role ROLE against experiment EXPERIMENT.

NOTE: There is another method to implement for a CasRealm: String[] getRoles(Principal). This method is currently not implemented and it throws a RuntimeException.