Category: Uncategorized

Prior to version 5.x of CAS, JSTL was used via JSP pages and it was easy to extend the CAS 2.0 protocol to release attributes as a snippet for release was provided in the documentation.

If you have recently upgraded to the 5.x version, you might have noticed that the templating engine has changed to Thymeleaf 2.1 which uses html pages instead of jsp, and there is no longer a helpful snippet of code to extend the CAS 2.0 Protocol in the documentation to release attributes.   Granted, the 3.0 protocol releases attributes by default, but you might need to provide auth services to a few end points that don’t use the 3.0 protocol.

After a short while of groking Thymeleaf, I came up with the following code to release whatever attributes you give it, under the CAS 2.0 Protocol.  Any attributes that are lists, will be split on “, ” and release as an array of elements.

The older attribute processor could actually notice that an attribute was a list and split it easily; however, in 5.x all the attributes under the 2.0 protocol are provided as a string of “attribute name=value”, which requires a bit more processing.

Also, the split function is by a single character only, so, that being the case I did a cheap move of replacing “, ” with “|” and splitting on “|”.  This should work for most group lists and standard lists, not splitting the space in a display name or between DN elements.  Though it is possible that “|” might be in the list already as it is a valid character for Group names in AD, my company just happens to not have groups with this character in the name or their DN.  Yours might and you might need to pick a different character.

File: casServiceValidationSuccess.html


Screen Shot 2017-08-29 at 9.00.17 PM

Image of the code because it refused to paste in right

You can download the html here

It’s not the best code in the world, but hopefully, it will save some of you a few hours of your life so you can get on to the next problem/project sooner.

In this part of the series I will cover how to setup CAS to authenticate using LDAP and store the ticket information in PostgreSQL, instead of the default memory ticket manager.

We will also be setting up connection pooling for:

  • LDAP
  • PostgreSQL (using C3Po)


Prerequisite Tasks

Letting Tomcat Know How to Use PostgreSQL

Tomcat doesn’t know how to work with PostgreSQL right off the bat, so we need to grab the JDBC4 driver file for it “postgresql-9.3-1102.jdbc4.jar”

  1. Download the file from here

    wget -c
  2. Move the file to /var/lib/tomcat7/lib
  3. Restart Tomcat


Setting Up Your PostgreSQL Server to Use SSL

To use SSL with PostgreSQL, you need to generate (or copy) and put in place to files sever.crt and server.key theses can be the star cert for your domain or self-signed.  Either way, once you have them you will need to place them in your $PGDATA folder.  On Ubuntu, this folder is typically /var/lib/postgresql/<version>/main/

Another option is to place these files in /etc/ssl/private and create a soft link to them in /var/lib/postgresql/<version>/main/ like so:

ln -s /etc/ssl/private/your_cert.key /var/lib/postgresql/<version>/main/server.key
ln -s /etc/ssl/private/your_cert.crt /var/lib/postgresql/<version>/main/server.crt

For more information on this setup, please refer to PostgreSQL’s documentation here.


Adding the SSL Certs For PostgreSQL and LDAPS

We intent to use SSL for both PostgreSQL and LDAP, so we will need to add the appropriate certs to our cacerts file.

  1. Get the certs for Postgres and your LDAP servers  in pem format (here is a post on converting crt and key files to a pem, if you don’t have one)If you will only be using certain servers for LDAP and do not have a cert that covers each of them, you can pull the cert from the server directly, like so:
    echo -n | openssl s_client -connect ldap_server_ip:636 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ldap_server.pem
  2. Once you have the pem files to you cacerts file like so:
    keystore -import -alias <server alias> -file <your_pem_file> -keystore $JAVA_HOME/jre/lib/security/cacerts

    Note: the default password is “changeit”

    If your JAVA_HOME is not set, you can find what it should by by issuing the following command to find your cacerts file:

    find /usr/lib/jvm -name cacerts


Setting Up The Application User and Database For CAS

  1. Open your favorite tool for working with Postgresql (phpPgAdmin, pgAdminIII, psql)
  2. Create the application user by running the following SQL, let’s call the user example_app:
    CREATE ROLE example_app LOGIN
  3. Create the database for CAS (we don’t have to create any tables in it, CAS will do this for us)
     WITH OWNER example_app
     ENCODING = 'UTF-8'
     TABLESPACE = pg_default
     LC_COLLATE = 'en_US.UTF-8'
     LC_CTYPE = 'en_US.URF-8'
  4. If you are limiting connections to your database with the pg_hba.conf file, you should add a line to it for this user and database, like so:
    1. Open /etc/postgresql/<version>/main/pg_hba.conf
    2. Add the following line in the IPv4 section:
      host    cas            example_app       <cas_server_ip>/<host bits>        md5
    3. Save the file
    4. Reload the configuration for PostgreSQL by running the following command
      service postgresql reload


Altering the Maven WAR Overlay

In this part we will be altering the Maven WAR project from part 1.


Adding the LDAP and SQL Connection Pooling Properties

  1. In your $project_home (/opt/work/cas-local) open src/main/webapp/WEB-INF/ and add the following to the end (filling in your details)
    # ========================================
    # == LDAP Connection Pooling Properties ==
    # ========================================
    # Max time in ms to wait for a connection to
    # become available under pool exhausted condition
    # -- Evictor Settings --
    # Period in ms at which the evictor process runs
    # Max time in ms that connection can remain idle
    # before becoming available for eviction
    # -- Connection Testing Settings --
    # Set to true to enable connection liveliness testing on evictor process runs.
    # Probably results in best performance
    # Set to true to enable connection liveliness testing before every request
    # to borrow an object from the pool
    # ===========================================
    # == Database Connection Pooling Properties ==
    # ===========================================
     # == Basic database connection pool configuration ==
    # Maximum amount of time to wait in ms for a connection to become
    # available when the pool is exhausted
    # Amount of time in seconds after which idle connections
    # in excess of minimum size are pruned.
    # Number of connections to obtain on pool exhaustion condition.
    # The maximum pool size is always respected when acquiring
    # new connections.
    # == Connection testing settings ==
    # Period in s at which a health query will be issued on idle
    # connections to determine connection liveliness.
    # Query executed periodically to test health
    database.pool.connectionHealthQuery=select 1
    # == Database recovery settings ==
    # Number of times to retry acquiring a _new_ connection
    # when an error is encountered during acquisition.
    # Amount of time in ms to wait between successive acquire retry attempts.
  2. Save the file
  3. Replace the following section to tell CAS we will authenticate with LDAP:
    	| This is the authentication handler declaration that every CAS deployer will need to change before deploying CAS 
    	| into production.  The default SimpleTestUsernamePasswordAuthenticationHandler authenticates UsernamePasswordCredentials
    	| where the username equals the password.  You will need to replace this with an AuthenticationHandler that implements your
    	| local authentication strategy.  You might accomplish this by coding a new such handler and declaring
    	| edu.someschool.its.cas.MySpecialHandler here, or you might use one of the handlers provided in the adaptors modules.
    	class="" />


        | Use the LDAP auhentication handler
        p:searchBase="<your_base_OU. ex. o=some_ou or blank for searching everything>"
        p:searchContextSource-ref="pooledContextSource" />
  4. Bellow that bean add the following bean to setup the LDAPContextSouce:
    	Define contextSource for LDAP
    	<bean id="contextSource" class="">
    		<!-- DO NOT enable JNDI pooling for context sources that perform LDAP bind operations. -->
    		<property name="pooled" value="false"/>
    		  Although multiple URLs may defined, it's strongly recommended to avoid this configuration
    		  since the implementation attempts hosts in sequence and requires a connection timeout
    		  prior to attempting the next host, which incurs unacceptable latency on node failure.
    		  A proper HA setup for LDAP directories should use a single virtual host that maps to multiple
    		  real hosts using a hardware load balancer.
    		<property name="urls">
                   <value>ldaps://<your ldap server address></value>
                   <value>ldaps://<second ldap server address></value>
    		<!-- Place JNDI environment properties here. -->
    		<property name="baseEnvironmentProperties">
    				<!-- Three seconds is an eternity to users. -->
    				<entry key="com.sun.jndi.ldap.connect.timeout" value="30000" />
    				<entry key="" value="30000" />
    				<!-- Explained at -->
    				<entry key="" value="simple" />
  5. Add the following beans for setting up the LDAP pool context and the context validator:
    	<!-- This uses the variables from -->
    	<bean id="pooledContextSource"
    		p:contextSource-ref="contextSource" />
    	<!-- used by PoolingContextSource.  Does a search of the root pulling
    	     back a single record to check against the specified context.
    		 This is used to ensure that pooled connections are still properly
    		 connected. -->
    	<bean id="dirContextValidator"
    		<property name="searchControls">
    			<bean class=""
    				p:returningAttributes="" />
  6. In the next section change the “@@THIS SHOILD BE REPLACED@@” with the username of the person you want to be able to access the “/service” section of CAS
  7. In the serviceRegistryDao bean, under the <property name=”evaluationOrder” value=”0″ /> or <property name=”evaluationOrder” value=”10000001″ /> line (depending on the one you are using), add the following:
    <property name="allowedAttributes">
  8. After the last bean in the file, add the following bean to setup the data source for your database
        <!-- Connection pooling for database -->
  9. Save the file
  10. Create the file “$project_home/src/main/webapp/WEB-INF/spring-configuration/ticketRegistry.xml” and populate it with the following:
    <?xml version="1.0" encoding="UTF-8"?>
    <beans xmlns=""
   " >
        Configuration for the Jpa TicketRegistry which stores the tickets in a
    database and cleans them out at specified intervals.
      <!-- Ticket Registry -->
      <bean id="ticketRegistry" class="org.jasig.cas.ticket.registry.JpaTicketRegistry" />
        Injects EntityManager/Factory instances into beans with
        @PersistenceUnit and @PersistenceContext
      <bean class=""/>
      <bean id="entityManagerFactory"
        <property name="dataSource" ref="dataSource"/>
        <property name="jpaVendorAdapter">
          <bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
            <property name="generateDdl" value="true"/>
            <property name="showSql" value="true" />
        <property name="jpaProperties">
            <!-- Set the database dialect -->
            <prop key="hibernate.dialect">${database.dialect}</prop>
            <prop key="">update</prop>
      <bean id="transactionManager"
        p:entityManagerFactory-ref="entityManagerFactory" />
      <tx:annotation-driven transaction-manager="transactionManager" />
      <bean id="ticketRegistryCleaner"
        p:lock-ref="cleanerLock" />
       Use JpaLockingStrategy for 3.4.11 and later.
       This bean is only needed for HA setups where multiple nodes are attempting
       cleanup on a shared database, but it doesn't substantially impact performance
       and is easy to setup and is therefore recommended for all JpaTicketRegistry deployments.
       This component automatically creates the LOCKS table so no further configuration
       is required.
      <bean id="cleanerLock"
        p:applicationId="cas-ticket-registry-cleaner" />
      <bean id="ticketRegistryCleanerJobDetail"
        p:targetMethod="clean" />
      <bean id="periodicTicketRegistryCleanerTrigger"
        p:repeatInterval="1800000" />
  11. Save the file
  12. Open your pom.xml file and make it look like the following (with your own value in the groupId property/tag)
    <?xml version="1.0" encoding="UTF-8"?>
    <project xmlns=""
             xsi:schemaLocation="" >
              The below is for connection pooling.
              Leave this commented out if you do not intend to use it -->
            <!-- database pooling -->
                <url> </url>
                <url>http:// </url>
  13. Save the file
  14. Got to $project_home
  15. (optional) In a different window watch your catalina.out log for problems (tail -f /var/log/tomcat7/catalina.out)
  16. Build the cas.war file
     mvn clean package
  17. Wait for Tomcat to recognize the new war file, then stop and restart tomcat
     service tomcat stop
     service tomcat start
  18. At this point, if your SSL, LDAP, and PostgreSQL are setup correctly, you shouldn’t see any errors when Tomcat starts (you will see errors before you stop Tomcat).
    Navigate to your CAS server in a web browser and try to authenticate with a valid account.  If everything is working, you should be sent to the logged in screen and see the validation successfully occur in your Catalina.out log.


Stoping PostgreSQL’s Database From Getting Bloated

The database created by CAS in Postgres has several “oid” fields.  This really shouldn’t be a problem, except that the JDBC and ODBC drivers for PostgreSQL don’t handle unlinking them correctly.  So when your tickets get cleaned up, the referenced object get orphaned, bloating the largeobject, shdepend, and largeobject_meta_data tables in the pg_catatlog.

To make this not happen, we need to inform the large object manager that these objects need to be cleaned.

Run the following SQL statements to create the needed triggers:


CREATE TRIGGER t_st_expiration_policy BEFORE UPDATE OR DELETE ON public.serviceticket
FOR EACH ROW EXECUTE PROCEDURE lo_manage(expiration_policy);

CREATE TRIGGER t_st_service BEFORE UPDATE OR DELETE ON public.serviceticket

CREATE TRIGGER t_tgt_expiration_policy BEFORE UPDATE OR DELETE ON public.ticketgrantingticket
FOR EACH ROW EXECUTE PROCEDURE lo_manage(expiration_policy);

CREATE TRIGGER t_tgt_authentication BEFORE UPDATE OR DELETE ON public.ticketgrantingticket
FOR EACH ROW EXECUTE PROCEDURE lo_manage(authentication);

CREATE TRIGGER t_tgt_services_g_a_t BEFORE UPDATE OR DELETE ON public.ticketgrantingticket
FOR EACH ROW EXECUTE PROCEDURE lo_manage(services_granted_access_to);

I have noticed that in the log, there are periodic exceptions from C3P0 where an unlinked OID is referenced again by the ticket cleaner; however, we have not experienced any problems from our users in relation to this and the database we have hovers around 35-40MB in size, unlike the 6.8GB it grew to with out these triggers.