Using CAS with Acegi in the Spring Framework: Using CAS with Acegi in the Spring Framework Mark Allsop July-2006 www.mallsop.com


Purpose: Purpose This presentation will show you how to secure your Spring Java Web application in a test environment using CAS and Acegi. Jars and Java JDK used: Yale CAS client jar 2.1.0. Acegi security jar 1.0.0. Acegi security CAS jar 1.0.0. Java jdk1.5.0_04


XML and Servlets: XML and Servlets web.xml security-context.xml exampleUsingCas-servlet.xml


web.xml: web.xml Acegi Filter Chain Proxy org.acegisecurity.util.FilterToBeanProxy targetClass org.acegisecurity.util.FilterChainProxy Acegi Filter Chain Proxy /* Note: Acegi delegates to a bean proxy in Spring’s application context using FiltertoBeanProxy. All Acegi filters will be configured using an interface of this class. All must be provided a targetClass to targetBean via an init parameter that points to the bean in the application context. The application context bean is configured with parameters rather than the filter.


security-context.xml: security-context.xml CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /**=channelProcessingFilter,httpSessionContextIntegrationFilter,casProcessingFilter, basicProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor channelProcessingFilter: Ensures a web request is delivered over the required channel. httpSessionContextIntegrationFilter: Populates the SecurityContextHolder with information obtained from the HttpSession. httpSessionContextIntegrationFilter: This filter works hand-and-hand with the HTTP Session object and the Web context to see if the user is authenticated and, if so, then what roles the user has. casProcessingFilter: Processes a CAS service ticket. basicProcessingFilter: Processes a HTTP request's BASIC authorization headers, putting the result into the SecurityContextHolder. filterInvocationInterceptor: Performs security handling of HTTP resources via a filter implementation. exceptionTranslationFilter: Handles any AccessDeniedException and AuthenticationException thrown within the filter chain. This filter is necessary because it provides the bridge between Java exceptions and HTTP responses.


security-context.xml continued…: security-context.xml continued… password=,ROLE_CAS_USER Note: ProviderManager is just a wrapper class around a list of one or more Authentication Providers provided to the class. It cycles thru the list until a compatitble provider is located. If it finds one, it returns a fully populated authentication object or throws and authentication exception. The authenticationManager uses the ProviderManager in your xml.


security-context.xml continued…: security-context.xml continued… YOUR Realm


security-context.xml continued…: security-context.xml continued… changeit https://yourCASserver:8443/cas/proxyValidate


security-context.xml continued…: security-context.xml continued… ticketCache


security-context.xml continued…: security-context.xml continued… Populates the UserDetails associated with a CAS authenticated user. CAS does not provide the authorities (roles) granted to a user. It merely authenticates their identity. As the Acegi Security System for Spring needs to know the authorities granted to a user in order to construct a valid Authentication object. Acegi ignores the password because it was enforced by CAS. The UserDetails returned by implementations is stored in the generated CasAuthenticationToken, so additional properties such as email addresses, telephone numbers etc can easily be stored.


security-context.xml continued…: security-context.xml continued… https://mylocalipaddress:8443/exampleUsingCAS/j_acegi_cas_security_check false


security-context.xml continued…: security-context.xml continued… CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON \A/secure/.*\Z=REQUIRES_SECURE_CHANNEL \A/j_acegi_cas_security_check.*\Z=REQUIRES_SECURE_CHANNEL \A.*\Z=REQUIRES_SECURE_CHANNEL


security-context.xml continued…: security-context.xml continued…


security-context.xml continued…: security-context.xml continued… /casfailed.jsp /secure/ /j_acegi_cas_security_check https://alphaserver.lan.here.org:8443/cas/login false


security-context.xml continued…: security-context.xml continued… CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON \A/secure/super.*\Z=ROLE_WE_DONT_HAVE \A/secure/.*\Z=ROLE_CAS_USER


exampleUsingCAS-servlet.xml: exampleUsingCAS-servlet.xml messages views


Index.jsp in the secure directory: Index.jsp in the secure directory Welcome to the Secure area - exampleUsingCAS Authentication object is of type: Authentication object as a String: Authentication object holds the following granted authorities: (getAuthority(): ) SUCCESS! Your container adapter appears to be properly configured! SUCCESS! Your web filters appear to be properly configured! Authentication object is null. This is an error and your Acegi Security application will not operate properly until corrected.


casFailed.jsp – in the non secure directory: casFailed.jsp – in the non secure directory Login to CAS failed! Login to CAS failed! Your CAS credentials were rejected. Reason:


Creating test certifcates: Creating test certifcates Setup a test CAS server somewhere. Install a temp cerfiicate. We’ll call our server “alphaserver”. Edit server.xml in your tomcat conf directory. Uncomment the port="8443" connector section. This enables SSL access on port 8443 (the default for https is 443, but just as Tomcat uses 8080 instead of 80 to avoid conflicts, 8443 is used instead of 443 here). Now create a SSL key for Tomcat to send to connecting clients. Go to C:\jdk1.5.0_04\bin. When you run keytool below, specify a password value of "changeit". You can create a self-signed key for testing purposes with one of the following commands: %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA (Windows) $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA (Unix)


Creating test certificates...continued.: Creating test certificates...continued. Once Tomcat is restarted, you should be able to access https://localhost:8443/. How To put the your alphaserver certificate into your local pc`s keystore for testing: 1. Download the alphaserver.cer and place in the user 'web' home folder to your jdk1.5.0_04\jre\lib\security folder. 3. Cd to jdk1.5.0_04\jre\lib\security in DOS. 4. Run the tool: keytool -import -v -file alphaserver.cer -keypass changeit -keystore cacerts -storepass changeit -alias alphaserver You should see: Trust this certificate? [no]: yes Certificate was added to keystore [Storing cacerts] This allows your locahost to trust the alphaserver certificate. Otherwise you will get a CAS rejection error. Manual tests may work, but acceptance tests may not work. It does not seem to like the certificate warning. To add a CA-issued key pair, see the Tomcat documentation. (I did not need to do this.)


Related Links: Related Links http://forum.springframework.org/ http://www.acegisecurity.org/