Resources to Deploy

We are currently investigating CAS as a SSO for our university. I am trying to estimate the resources required by looking at other CAS deployment institutions. I have a few questions and would appreciate any input from you regarding this.

What kind of infrastructure (servers, load-balancers, etc.) do you have running for CAS?

This is not a dedicated machine but shared amoung all other web application BUT uPortal (which has its own dedicated machine with same configuration as above).

How many people does your CAS server serve?

About 30,000 students and faculty/staff.

How much manpower do you have dedicated to CAS?

One fulltime programmer for about two weeks to have it running, now don't even worry about it!

What kind of systems do you have running? (Learning Management Systems, Portals, etc.)

uPortal and all our web applications

How do you push out new CAS client updates?

I just compile the source code and drop the new jar file into the running application. I make sure that no conflicts will be created with my local changes. So far, I have done two upgrades with NOTHING more than re-compiling with my local changes.

Any problems/ gotchas that you ran into

The only problem, which is not really a problem, is that CAS out of the box does not provide means for authorization (as it was not created for this purpose) and it does not limit which applications are authorized to perform authentication. These were the two changes I made to CAS.

What kind of infrastructure (servers, load-balancers, etc.) do you have running for CAS

3 x Sun Netra X1 (single processor, 1GB RAM) behind redundant Cisco CSS in failover ("sorry server" in Cisco parlance, I believe) configuration. The Netras are dedicated for CAS. We also utilized a separate (shared) database server for centralized audit trail functionality we've added.

How many people does your CAS server serve?

~20,000 faculty/staff/students/etc., plus 10,000+ additional prospective students during admission cycles.

How much manpower do you have dedicated to CAS?

At Cal Poly, CAS is maintained by the same group which supports our uPortal deployment. For initial customization/deployment, this was ~1 person for three months, but this also included integrating a number of key applications. Ongoing support load for the service itself is very low.

Beware that outreach/guidance/policy on client integration may require significant ongoing attention, depending on your deployment strategy and your campus approach to web application support. Our approach has been to strongly encourage standardization on centralized authentication services, and on uPortal integration, and so we're investing significant effort in this area.

What kind of systems do you have running? (Learning Management Systems, Portals, etc.)

uPortal (primary portal for all users), Blackboard, PeopleSoft HR and Finance (Student Admin soon), Oracle SSO (in support of Oracle Collab Suite, Business Intelligence, and other services), Remedy, some other vendor-provided vertical apps, and many locally-developed applications (primarily Java, also PL/SQL, PHP, ASP, Perl).

How do you push out new CAS client updates?

Updates for applications supported by ITS (central IT) are handled in our normal change management process – requested/scheduled/tested/rolled out.

Non-centralized clients are the responsibility of the application administrator — we send advisories on update availability and issues to be aware of, including follow-up in some cases. Key to this, of course, is controlling and/or tracking those applications which are using your CAS implementation!

Any problems/ gotchas that you ran into

Consider policy implications as early as possible, and also integration with your portal offerings. To our end-users there is no distinction between CAS and uPortal, and for us this is a very good thing.

Develop a clear understanding of how CAS fits into your service and security strategies, and communicate that message.

We have implemented a CAS solution here at APU. Because of the number of diverse systems we had, CAS development and trouble-shooting has ended up being a significant portion of our implementation time. And we still have work to do to get some applications/systems tied in that don't easily use CAS. A few of the systems we have tied into CAS are:

• uPortal
• web-based email client (SquirrelMail) & IMAP Server
• several custom Java applications
• online library resources proxy

Outside of simply implementing a CAS server and learning how to use the CAS clients, here are a few things that immediately come to mind to consider:

• what is the primary credential repository/directory server that CAS is to use to authenticate against? An LDAP server (OpenLDAP, Active Directory), Kerberos (MIT, Active Directory)? You may need to implement an authentication provider for your CAS server depending on your setup.
• what applications do you want to try to use CAS authentication for and on what types of systems?

For example, we wanted to protect a non-Java webmail client running on Apache. This required proxiable credentials, however, there was no Apache module that supported proxiable credentials in the official distribution. We ended up creating our own mod_perl module to do this. If everything you are protecting with CAS is on a Java App Server, things are generally simpler, more complete and better documented. (IMO)

• how much custom integration work will be needed vs. just throwing authentication on top of web applications? Many apps aren't really designed for use with a system such as CAS. This can bite you if you don't fully consider everything you need to use CAS for up front.
• what level of understanding do you want your staff to have about CAS? When you do run into problems, a basic understanding may not suffice. Understanding of the architecture of CAS may be necessary. Around my neck of the woods, if you are paying for support, then understanding the details may not be as necessary. However, if we can't yell at a vendor to fix it, then the burden rests square on the shoulders of the team that implemented the solution.

CAS is a great system and we have enjoyed working with it. Our first authentication system (custom) was similar to CAS 1.0, so we were able to hit the ground running. The implementation hasn't been without problems, however, and there are some pretty bright people around here. Admittedly, a significant portion of our time has been spent creating Apache::AuthCAS, our solution to an easy-to-use Apache authentication module that provides support for proxiable credentials. The non-Java clients can be a bit rough around the edges still, so some tweaking may be necessary on that front. More questions than answers, but I hope this helps a bit.

What kind of infrastructure (servers, load-balancers, etc.) do you have running for CAS

We have a single Sun Netra X1 (UltraSPARC-IIe 500MHz) with 1.0GB RAM
dedicated to running CAS.

How many people does your CAS server serve?

It's not clear. There are on the order of 50,000 usernames that could be authenticated via our CAS server. There are more than a handful of Web apps that use it and more under development or experimentation.

How much manpower do you have dedicated to CAS?

Some fractional amount of one full-time staff after the initial implementation. I've gotten some assistance in designing a new face for the login page. I wrote the class (PasswordHandler implementation) that handles the user authentication against our LDAP directory service. I also customized the CAS software to release affiliation data along with the username during the service ticket validation.

What kind of systems do you have running? (Learning Management Systems, Portals, etc.)

Mostly internally developed Web apps. We are trying to encourage more
use.

How do you push out new CAS client updates?

We haven't had to cross that bridge yet. I'm the primary contact point for assistance especially since we have customized the CAS software.

Any problems/ gotchas that you ran into

As mentioned earlier, an implementation site needs to provide a class to handle the user authentication against whatever backend system is used. There is also a need to tailor the login page to what is appropriate for the organization. Attention should also be given to where to direct support questions or ask for assistance. As with all software, you should have some change management process in place. Be prepared to answer all kinds of questions regarding the use of CAS, what is authentication versus authorization, why feature XXX isn't part of CAS, why they should use CAS, etc.