New to CAS, new to Apereo

210 views
Skip to first unread message

Hank Foss

unread,
Aug 11, 2016, 4:38:31 PM8/11/16
to CAS Community
Hello,

I'm brand new to CAS and Apereo, and am asking the best way to begin. We are migrating our CAS from the cloud to on-premise as a cost savings measure. This will likely save us $60+k annually, as the vendor is also provides our portal.

The externally hosted portal contains LDAP as well as CAS links. I understand CAS 5 comes out this fall (October?) which offers LDAP support, so I am on the fence a bit more. Since AD authentication drives many of our authentication, I have been told that we will either need to use ADFS or Shibboleth. The goal for this to be live is December of this year, so there are learning curve, architecture, installation and customization components of this project that all come into play.

I built the Linux box, most current version of CentOS, but I believe being an open source application that the support of at least the OS should actually be a licensed RHEL instance.

I'm technical, but this is uncharted territory  so suggestions, comments, and criticism are all greatly welcome.


Thanks,
CAS-Newbie

Misagh Moayyed

unread,
Aug 11, 2016, 4:45:43 PM8/11/16
to CAS Community
If you mean CAS is going to provide you with an LDAP server, the answer is no. AFAIK, that has never been the case. If you mean you wish to authenticate via AD/LDAP and get access to your portal and other CAS-protected apps, then it’s quite simple. Since the dawn of time, CAS has supported LDAP/AD authentication. 90% of the deployments use that method of authentication.

-- 
Misagh
--
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To post to this group, send email to cas-...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/ccf659bc-12d9-4cb8-98dd-4dbf926f403a%40apereo.org.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

Christopher Myers

unread,
Aug 11, 2016, 5:13:46 PM8/11/16
to cas-...@apereo.org
This is the super-down-and-dirty writeup I did internally when I did a fresh 4.x install to upgrade us from 3.5 (we use Novell eDirectory, but it should be very similar for any non-AD LDAP) :














Comment by Christopher Myers [ 25-Feb-2015 ]

Edit as-server-4.0.0/cas-server-webapp/src/main/webapp/WEB-INF/deployerConfigContext.xml

Comment out

    <bean id="primaryAuthenticationHandler"
          class="org.jasig.cas.authentication.AcceptUsersAuthenticationHandler">
        <property name="users">
            <map>
                <entry key="casuser" value="Mellon"/>
            </map>
        </property>
    </bean>

Replace it with

<bean id="ldapAuthenticationHandler"
      class="org.jasig.cas.authentication.LdapAuthenticationHandler"
      p:principalIdAttribute="mail"
      c:authenticator-ref="authenticator">
    <property name="principalAttributeMap">
        <map>
            <!--
               | This map provides a simple attribute resolution mechanism.
               | Keys are LDAP attribute names, values are CAS attribute names.
               | Use this facility instead of a PrincipalResolver if LDAP is
               | the only attribute source.
               -->
            <entry key="member" value="member" />
            <entry key="mail" value="mail" />
            <entry key="displayName" value="displayName" />
        </map>
    </property>
</bean>

<bean id="authenticator" class="org.ldaptive.auth.Authenticator"
      c:resolver-ref="dnResolver"
      c:handler-ref="authHandler" />

<bean id="dnResolver" class="org.ldaptive.auth.PooledSearchDnResolver"
      p:baseDn="${ldap.baseDn}"
      p:allowMultipleDns="false"
p:subtreeSearch="true"
      p:connectionFactory-ref="searchPooledLdapConnectionFactory"

      p:userFilter="${ldap.authn.searchFilter}" />

<bean id="searchPooledLdapConnectionFactory"
      class="org.ldaptive.pool.PooledConnectionFactory"
      p:connectionPool-ref="searchConnectionPool" />

<bean id="searchConnectionPool" parent="abstractConnectionPool" />

<bean id="abstractConnectionPool" abstract="true"
      class="org.ldaptive.pool.BlockingConnectionPool"
      init-method="initialize"
      p:poolConfig-ref="ldapPoolConfig"
      p:blockWaitTime="${ldap.pool.blockWaitTime}"
      p:validator-ref="searchValidator"
      p:pruneStrategy-ref="pruneStrategy"
      p:connectionFactory-ref="connectionFactory" />

<bean id="ldapPoolConfig" class="org.ldaptive.pool.PoolConfig"
      p:minPoolSize="${ldap.pool.minSize}"
      p:maxPoolSize="${ldap.pool.maxSize}"
      p:validateOnCheckOut="${ldap.pool.validateOnCheckout}"
      p:validatePeriodically="${ldap.pool.validatePeriodically}"
      p:validatePeriod="${ldap.pool.validatePeriod}" />

<bean id="connectionFactory" class="org.ldaptive.DefaultConnectionFactory"
      p:connectionConfig-ref="connectionConfig" />

<bean id="connectionConfig" class="org.ldaptive.ConnectionConfig"
      p:ldapUrl="${ldap.url}"
      p:connectTimeout="${ldap.connectTimeout}"
      />

<bean id="pruneStrategy" class="org.ldaptive.pool.IdlePruneStrategy"
      p:prunePeriod="${ldap.pool.prunePeriod}"
      p:idleTime="${ldap.pool.idleTime}" />

<bean id="searchValidator" class="org.ldaptive.pool.SearchValidator" />

<bean id="authHandler" class="org.ldaptive.auth.PooledBindAuthenticationHandler"
      p:connectionFactory-ref="bindPooledLdapConnectionFactory" />

<bean id="bindPooledLdapConnectionFactory"
      class="org.ldaptive.pool.PooledConnectionFactory"
      p:connectionPool-ref="bindConnectionPool" />

<bean id="bindConnectionPool" parent="abstractConnectionPool" />






Add the following to the bottom of the file /opt/cas-server-4.0.0/cas-server-webapp/src/main/webapp/WEB-INF/cas.properties

#========================================
# General properties
#========================================
ldap.url=ldap://ldapserver.school.edu

# Base DN of users to be authenticated
ldap.baseDn=o=our_base_dn


# LDAP connection timeout in milliseconds
ldap.connectTimeout=3000

# Whether to use StartTLS (probably needed if not SSL connection)
ldap.useStartTLS=false

#========================================
# LDAP connection pool configuration
#========================================
ldap.pool.minSize=3
ldap.pool.maxSize=10
ldap.pool.validateOnCheckout=false
ldap.pool.validatePeriodically=true

# Amount of time in milliseconds to block on pool exhausted condition
# before giving up.
ldap.pool.blockWaitTime=3000

# Frequency of connection validation in seconds
# Only applies if validatePeriodically=true
ldap.pool.validatePeriod=300

# Attempt to prune connections every N seconds
ldap.pool.prunePeriod=300

# Maximum amount of time an idle connection is allowed to be in
# pool before it is liable to be removed/destroyed
ldap.pool.idleTime=600

#========================================
# Authentication
#========================================

# Search filter used for configurations that require searching for DNs
ldap.authn.searchFilter=(uid={user})




 

While you're in the cas.properties file, also set up the URLs for the server, etc.

Also edit the line:

<entry key-ref="primaryAuthenticationHandler" value-ref="primaryPrincipalResolver" />

and replace it with:

<entry key-ref="ldapAuthenticationHandler" value-ref="primaryPrincipalResolver" />




 

Comment by Christopher Myers [ 26-Feb-2015 ]

modify the value of CAS's web.xml file, change the default login session timeout to 2 hours

  <session-config>
    <!-- Default to 5 minute session timeouts -->
    <session-timeout>120</session-timeout>
  </session-config>




 
Comment by Christopher Myers [ 26-Feb-2015 ]

Edit .../cas-server-webapp/pom.xml and add the following dependency inside the <dependencies /> section:

    <dependency>
      <groupId>${project.groupId}</groupId>
      <artifactId>cas-server-support-ldap</artifactId>
      <version>${project.version}</version>
    </dependency>






Comment by Christopher Myers [ 26-Feb-2015 ]

You can't use the maven 2 version that was already on the boxes to build the new version of CAS; instead, need to download the 3.2.5 version from http://maven.apache.org/download.cgi, extract it, and change the "maven" symlink to point to the new install folder.







Comment by Christopher Myers [ 26-Feb-2015 ]

The first time I tried to run "mvn package" after doing this, I got the error:

Non-parseable POM /root/.m2/repository/org/jasig/parent/jasig-parent/39/jasig-parent-39.pom: Expected root element 'project' but found 'html'

When I looked at the contents of that .pom file, it was an HTML document that just said basically "HTTP 301 moved permanently."

I deleted the /root/.m2 folder, and after doing so, things started running.




Comment by Christopher Myers [ 26-Feb-2015 ]

Now I'm getting the error:

Failed to execute goal com.mycila.maven-license-plugin:maven-license-plugin:1.9.0:check (default) on project cas-server: Resource /opt/cas-server-4.0.0/src/licensing/header.txt not found in file system

Found this: https://github.com/Jasig/cas/issues/745

Modified the pom.xml file, changed

<header>${cs.dir}/src/licensing/header.txt</header>

to

<header>${licenseHeader}</header>

After doing so, that error went away.




Comment by Christopher Myers [ 26-Feb-2015 ]

Now I'm getting the error:

Caused by: java.io.FileNotFoundException: Could not open ServletContext resource [/WEB-INF/-servlet.xml]

I found this Jira issue about it: https://issues.jasig.org/browse/CAS-799 which basically says "we can't reproduce the issue" and someone recommended to disable the tests since everything else tests fine:

mvn package install -Dmaven.test.skip=true




Comment by Christopher Myers [ 26-Feb-2015 ]

Finally, after all is completed:

/opt/cas-server-4.0.0 # mv /opt/cas-server-4.0.0/cas-server-webapp/target/cas.war /usr/share/tomcat/webapps




Comment by Christopher Myers [ 26-Feb-2015 ]

CAS 4 is up and running now!












>>> Misagh Moayyed <mmoa...@unicon.net> 08/11/16 3:45 PM >>>

Hank Foss

unread,
Aug 11, 2016, 5:23:22 PM8/11/16
to CAS Community, mmoa...@unicon.net
Thanks, Misagh, much appreciated.
 
It sounds like this will work quite well for us. Most of our web apps rely on LDAP authentication.
 
Regarding architecture, hope you don't mind a couple of other questions:
 
  1. How many servers are in your CAS environment (presuming you recommend an HA environment) - e.g. 1 web server (Tomcat?) + 2 HA CAS ticketing servers
  2. Do you recommend RHEL for OS?
 
Our user environment is about 12,000 (2,000 staff + 10,000 students) so I am trying to architect the CAS to support that.
 
 
-Hank
 
On Thursday, August 11, 2016 at 4:45:43 PM UTC-4, Misagh Moayyed wrote:
If you mean CAS is going to provide you with an LDAP server, the answer is no. AFAIK, that has never been the case. If you mean you wish to authenticate via AD/LDAP and get access to your portal and other CAS-protected apps, then it’s quite simple. Since the dawn of time, CAS has supported LDAP/AD authentication. 90% of the deployments use that method of authentication.
 
-- 
Misagh
From: Hank Foss <hank...@gmail.com>
Reply: Hank Foss <hank...@gmail.com>
Date: August 11, 2016 at 1:38:35 PM
To: CAS Community <cas...@apereo.org>
Subject:  [cas-user] New to CAS, new to Apereo
 

Ray Bon

unread,
Aug 11, 2016, 6:09:45 PM8/11/16
to cas-...@apereo.org
Hank,

We have 3 CAS (v 3.5.2.1) virtual machine servers in a primary, secondary, tertiary setup with LDAP (all on Redhat). CAS is very capable and can handle several logins per second.

Ray

Philippe MARASSE

unread,
Aug 12, 2016, 4:08:31 AM8/12/16
to cas-...@apereo.org
Hello,

1.
Here we have about 1400 employees, our architecture is pretty simple : 2 front servers sharing a virtual IP (active/passive, apache + mod_jk), 2 CAS applications servers (CAS v3.5, Clustered tomcat, EHCache ticket registry, JPA Service registry). It works like a charm since 2012.

2.
Our servers run Debian 7/8. IMHO, OS doesn't matter as long as you use custom JVM for your CAS server.

Regards.

-- 
Philippe MARASSE

Responsable pôle Infrastructures - DSIO
Centre Hospitalier Henri Laborit
CS 10587 - 370 avenue Jacques Cœur 
86021 Poitiers Cedex
Tel : 05.49.44.57.19

William G. Thompson, Jr.

unread,
Aug 12, 2016, 8:32:36 AM8/12/16
to Philippe MARASSE, CAS Community
We have a similar deployment but are moving to nginx+ and as the
front-end instead of apache+mod_jk. This should give us the ability to
bring backend Tomcat/CAS nodes in and out of production without a
service outage. We are also running with a json backed service
registry, instead of pulling in JPA/RDMBS dependencies.

CAS3 has been rock solid for more than 10 years, but I'm looking
forward to moving to CAS5 with MFA support and simplifying our
deployment configuration even more thanks to Misagh.

Best,
Bill
> https://groups.google.com/a/apereo.org/d/msgid/cas-user/cb01bad3-3148-3295-3418-10ae0f513422%40ch-poitiers.fr.

Christopher Myers

unread,
Aug 12, 2016, 8:50:22 AM8/12/16
to cas-...@apereo.org
Likewise, we have 3+1 (two primary, one secondary, and an "oh crud the entire production VMWare environment went offline" backup.) All are running 4.0.x, connected together with hazelcast replication. We've got over 20 registered services, including connecting Shibboleth to CAS for its authentication source, which handles even more services.

Each TC server is on its own VM, on a different VMWare server. All are front-ended by our Barracuda, with SSL offloading.

So yeah, it's a pretty robust system :)

Chris




>>> Ray Bon <rb...@uvic.ca> 08/11/16 5:09 PM >>>

Hank Foss

unread,
Aug 12, 2016, 9:11:26 AM8/12/16
to CAS Community, cmy...@mail.millikin.edu
Chris,

So you have TC and CAS on separate boxes. Is it possible to have both on the same box or is it better to have them separate? It sounds like in your environment you have quite a few services configured which is why you chose to separate the roles to different servers. So, e.g. having CAS  and TC on same server, then replicate to other VMs - is that viable?

Hank

Christopher Myers

unread,
Aug 12, 2016, 9:36:12 AM8/12/16
to cas-...@apereo.org
Actually, CAS is just an application that's deployed on an app server, so they're all on the same boxes. Each VM has a Tomcat instance that's running CAS, so we have four SLES12 VMs, each running a copy of CAS on Tomcat, and each VM is running on a different physical host. (We use SLES12 for our app servers, because we can get "unlimited virtualization host" licenses for fairly inexpensive after the education discount.)

And yep, that's basically what we did -- built one VM, then cloned it to create the others (changing a few minor things on each VM as it was cloned (hostname, IP, and server identification string.)) Super easy to do, and makes it incredibly easy to spawn up new application servers should we need to do so -- roughly 15 minutes from start to finish.

We have all of the session data replicated between the four nodes using Hazelcast. It's a lot easier to set up than other technologies IMO. That way if we happen to take one node offline during the day (upgrades, patches, hardware failure, etc.,) the logins will be redirected to the other servers without a hitch. It also enables us to do the "active-active-failover-lastresort" setup we've got. (Our third VM is just as robust as the first and second, and has the same software configuration, but is configured as a "failover" node on the load balancer because we primarily use it for doing scheduled tasks. But if the first and second nodes go offline, all of the traffic will get directed there as well. This is all done through the policies on the Barracuda.)

Also, the SSL offloading done by the load balancer makes things a lot easier too...no more dealing with keystores on each individual box. Plus it lets Tomcat do what it's best at -- delivering applications. It leaves all that messy CPU-intensive encryption and decryption to hardware designed for the purpose. There is a bit of additional configuration you have to do to Tomcat, but it's not bad.

Chris




>>> Hank Foss <hank...@gmail.com> 08/12/16 8:11 AM >>>

Hank Foss

unread,
Aug 12, 2016, 11:38:23 AM8/12/16
to CAS Community, cmy...@mail.millikin.edu
Thanks, Chris, great information.

Hank
Reply all
Reply to author
Forward
0 new messages