...
- 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.
...
- 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:
Module name | Description |
---|---|
org-srs-cas-server | The CAS server. It is an overlay of the standard ja-sig cas server distribution. It contains an authentication handler to talk to the SLAC Crowd server. |
org-srs-cas-tomcat-integration | This module allows Tomcat to use CAS for authentication, for example to access probe. |
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.
...
Code Block |
---|
<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> |
CAS Tomcat Integration
I downloaded:
- http://downloads.jasig.org/cas-clients/cas-client-3.1.12-release.zip
- http://downloads.jasig.org/cas/cas-server-3.4.7-release.zip
I succeeded in installing the tomcat connector on tomcat6 installed on my local machine. I just had to install
...
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
Code Block 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:
No Formatcode |
---|
<Realm className="org.jasigsrs.cas.client.tomcat.v6.PropertiesCasRealm" propertiesFilePath="conf/manager-user-roles.propertiesintegration.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="localhostserverName:8080serverPort" /> --> <Valve |
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:
Code Block |
---|
<Valve className="org.jasigsrs.cas.client.tomcat.v6.Cas20ProxyCasAuthenticator" encoding="UTF-8" casServerLoginUrl="httphttps://localhost:8080glast-ground.slac.stanford.edu/cas-srs/login" casServerUrlPrefix="httphttps://localhost:8080glast-ground.slac.stanford.edu/cas-srs/" serverNamemyServerName="localhost${HOST}.slac.stanford.edu:8080" /> |
and added ${CATALINA_BASE}/conf/manager-user-roles.properties to read:
No Format |
---|
tonyj: manager
|
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 RuntimeExceptionNavigating to the tomcat manager then causes a CAS login request to be issued. With the standard fermi CAS this semi-worked. By installing the latest greatest "out-of-the-box" cas server (cas-server-webapp-3.4.7.war) in webapps on the same tomcat it worked fine.