Configuration of CAS Client in Acegi-based apps

The web application side of CAS is made easy due to Acegi
Security. It is assumed you already know the basics of using Acegi
Security, so these are not covered again below. Only the CAS-specific
beans are mentioned.

First of all modify Pentaho’s web.xml to link only one applicationContext file (I’ve called it spring-acegi.xml):

<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/spring-acegi.xml
</param-value>
</context-param>

You will need to add a ServiceProperties bean
to your application context (spring-acegi.xml).

This represents your service:

<bean id=”serviceProperties” class=”org.acegisecurity.ui.cas.ServiceProperties”>

<property name=”service”>

<value>

https://localhost:8443/pentaho/j_acegi_cas_security_check

</value>

</property>

<property name=”sendRenew”><value>false</value></property>

</bean>

The service must equal a URL that will be monitored by the CasProcessingFilter. The
sendRenew defaults to false, but should be set to true if your application is particularly sensitive. What this parameter does is tell the CAS login service that a single sign on login is unacceptable. Instead, the user will need to re-enter their username and password in order to gain access to the service.

The following beans should be configured to commence the CAS authentication process:

<bean id=”casProcessingFilter” class=”org.acegisecurity.ui.cas.CasProcessingFilter”>

<property name=”authenticationManager”>

<ref bean=”authenticationManager”/>

</property>

<property name=”authenticationFailureUrl”>

<value>/casfailed.jsp</value>

</property>

<property name=”defaultTargetUrl”>

<value>/</value>

</property>

<property name=”filterProcessesUrl”>

<value>/j_acegi_cas_security_check</value>

</property>

</bean>

<bean id=”casProcessingFilterEntryPoint” class=”org.acegisecurity.ui.cas.CasProcessingFilterEntryPoint”>

<property name=”loginUrl”>

<value>https://localhost:8443/cas-server-webapp-3.2.1/login</value>

</property>

<property name=”serviceProperties”>

<ref bean=”serviceProperties”/>

</property>

</bean>

<bean id=”exceptionTranslationFilter” class=”org.acegisecurity.ui.ExceptionTranslationFilter”>

<property name=”authenticationEntryPoint”>

<ref local=”casProcessingFilterEntryPoint”/>

</property>

</bean>

You will also need to add the CasProcessingFilter to web.xml:

<filter>

<filter-name>Acegi CAS Processing Filter</filter-name>

<filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class>

<init-param>

<param-name>targetClass</param-name>

<param-value>org.acegisecurity.ui.cas.CasProcessingFilter</param-value>

</init-param>

</filter>

<filter-mapping>

<filter-name>Acegi CAS Processing Filter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

The CasProcessingFilter has very similar properties to the AuthenticationProcessingFilter
(used for form-based logins). Each property is self-explanatory.

For CAS to operate, the ExceptionTranslationFilter must have its authenticationEntryPoint property set to the CasProcessingFilterEntryPoint bean.

The CasProcessingFilterEntryPoint must refer to the ServiceProperties bean (discussed above),
which provides the URL to the enterprise’s CAS login server. This is where the user’s browser will be redirected.

Next you need to add an AuthenticationManager that uses CasAuthenticationProvider and its
collaborators:

<bean id=”authenticationManager” class=”org.acegisecurity.providers.ProviderManager”>

<property name=”providers”>

<list>

<ref bean=”casAuthenticationProvider”/>

</list>

</property>

</bean>

<bean id=”casAuthenticationProvider” class=”org.acegisecurity.providers.cas.CasAuthenticationProvider”>

<property name=”casAuthoritiesPopulator”>

<ref bean=”casAuthoritiesPopulator”/>

</property>

<property name=”casProxyDecider”>

<ref bean=”casProxyDecider”/>

</property>

<property name=”ticketValidator”>

<ref bean=”casProxyTicketValidator”/>

</property>

<property name=”statelessTicketCache”>

<ref bean=”statelessTicketCache”/>

</property>

<property name=”key”>

<value>my_password_for_this_auth_provider_only</value>

</property>

</bean>

<bean id=”casProxyTicketValidator” class=”org.acegisecurity.providers.cas.ticketvalidator.CasProxyTicketValidator”>

<property name=”casValidate”>

<value>

https://localhost:8443/cas-server-webapp-3.2.1/proxyValidate

</value>

</property>

<property name=”proxyCallbackUrl”>

<value>

https://localhost:8443/pentaho/casProxy/receptor

</value>

</property>

<property name=”serviceProperties”>

<ref bean=”serviceProperties”/>

</property>

<property name=”trustStore”>

<value>$JAVA_HOME/jre/lib/security/cacerts</value>

</property>

</bean>

<bean id=”cacheManager” class=”org.springframework.cache.ehcache.EhCacheManagerFactoryBean”>

<property name=”configLocation”>

<value>classpath:/ehcache-failsafe.xml</value>

</property>

</bean>

<bean id=”ticketCacheBackend” class=”org.springframework.cache.ehcache.EhCacheFactoryBean”>

<property name=”cacheManager”>

<ref local=”cacheManager”/>

</property>

<property name=”cacheName”>

<value>ticketCache</value>

</property>

</bean>

<bean id=”statelessTicketCache” class=”org.acegisecurity.providers.cas.cache.EhCacheBasedTicketCache”>

<property name=”cache”>

<ref local=”ticketCacheBackend”/>

</property>

</bean>

<bean id=”casAuthoritiesPopulator” class=”org.acegisecurity.providers.cas.populator.DaoCasAuthoritiesPopulator”>

<property name=”userDetailsService”>

<ref bean=”userDetailsService”/>

</property>

</bean>

<bean id=”casProxyDecider” class=”org.acegisecurity.providers.cas.proxy.RejectProxyTickets”/>

Ageci is set up around the inMemoryDaoImpl, four users are defined Admin and User. This DAO is used
to get the credentials for the users who are authenticated by CAS, CAS can only check if a user is authenticated.
See the example below:

<bean id=”userDetailsService” class=”org.acegisecurity.userdetails.memory.InMemoryDaoImpl”>

<property name=”userMap”>

<value>

Admin=***,ROLE_ADMIN,ROLE_AUTHENTICATED

User=***,ROLE_AUTHENTICATED

</value>

</property>

</bean>

Or if you prefer:

<bean id=”userDetailsService”

class=”org.acegisecurity.userdetails.jdbc.JdbcDaoImpl”>

<property name=”dataSource”>

<ref local=”dataSource” />

</property>

<property name=”authoritiesByUsernameQuery”>

<value>

<![CDATA[SELECT username, authority FROM granted_authorities

WHERE username = ?]]>

</value>

</property>

<property name=”usersByUsernameQuery”>

<value>

<![CDATA[SELECT jbp_uname, jbp_password, enabled

FROM jbp_users WHERE jbp_uname = ?]]>

</value>

</property>

</bean>

Note the granted authorities, usually configured in acegi security, are ignored by CAS because
it has no way of communicating the granted authorities to calling applications.
CAS is only concerned with username and passwords (and the enabled/disabled status).
In this implementation of userDetailsService we use default ROLE_* name definition.
If you want to mantain (for easy understanding) roles coming from CAS credentials remember to
write “ROLE_” prefix before your desired Role, otherwise you’ll obtain an error response
(about UNKNOWN ROLE) while deploying pentaho.war.

Otherwise try to modify role_prefix property to anoter prefix…
see Spring acegi security documentation for this.

If you have to use proxyTickets:

Note the CasProxyTicketValidator has a remarked out trustStore property. This property might be helpful if you experience HTTPS certificate issues. Also note the proxyCallbackUrl is set so the service can receive a proxy-granting ticket. As mentioned above, this is optional and unnecessary if you do not require proxy-granting tickets. If you do use this feature, you will need to configure a suitable servlet to receive the proxy-granting tickets. We suggest you use CAS’ ProxyTicketReceptor by adding the following to yourweb application’s web.xml:

<servlet>

<servlet-name>casproxy</servlet-name>

<servlet-class>edu.yale.its.tp.cas.proxy.ProxyTicketReceptor</servlet-class>

</servlet>

<servlet-mapping>

<servlet-name>casproxy</servlet-name>

<url-pattern>/casProxy/*</url-pattern>

</servlet-mapping>

Finally for logout from Pentaho you need to add the following:

<bean id=”logoutFilter” class=”org.acegisecurity.ui.logout.LogoutFilter”>
<constructor-arg value=”https://administrator-desktop:8443/cas-server-webapp-3.2.1/logout”>
<constructor-arg>
<list>
<bean class=”com.pentaho.security.ProPentahoLogoutHandler”>
<bean class=”org.acegisecurity.ui.logout.SecurityContextLogoutHandler”>
</bean>
</bean>
<property name=”filterProcessesUrl” value=”/Logout”>
</property></list></constructor-arg></constructor-arg></bean>

and remember to add “logoutFilter” to filterChainProxy at the beginning of the configuration file.

This completes the configuration of CAS. If you haven’t made any mistakes, your web application should happily work within the framework of CAS single sign on. No other parts of Acegi Security need to be concerned about the fact CAS handled authentication.

A full example of applicationContext file is here.

Just adapt it to Pentaho’s and CAS configuration parameters.

This guide was written looking at:

• Acegi security guide

• isthisjava blog

If I made some mistakes please post here your suggestions…

Thanks a lot.