Hi,
Our experiences at the University of Hawaii. By the way, we still use
a modified version 2 of the CAS server software.
Russ
>> ---begin brief-ish list---
>
> 1.) What were the key factors in your decision to use CAS?
a. Java-based Web application is quick to get up and running using
Tomcat.
b. Potential to support clients written in many different languages;
not just Java.
c. Very simple and easy for web app developers to use.
d. Easily extensible (version 2 of the server) if you know Java.
> 2.) How many services are using CAS?
86+ (a guess based on what we see in the logs since we don't register
services yet)
> 3.) Are you aware of anyone planning to deploy CAS who has changed
> course or has decided to replaced it?
Yes, a web app developed at another university was tightly integrated
with LDAP authentication and authorization that the developer who was
trying to modify to use CAS decided to stick with LDAP.
> 4.) What authentication db are you using?
LDAP populated by our custom identity management system. We're running
the Sun ONE Directory server as our LDAP server.
> 5.) How many active users does it contain?
50K+
> 6.) Were any modifications to CAS required for use in your
> environment?
a. Person attributes were added to the non-XML validation response
to eliminate additional steps needed to get attributes for
authorization.
b. Provided sites a way to show their own logout page after calling
the CAS logout.
c. Implemented LDAP authentication handler (we started with version 2
of the CAS server; versions 3.0.5 and newer include an LDAP handler).
> 7.) What was your deployment experience like?
Very easy once a WAR file was built.
Most difficult part was understanding the CAS protocol and server code
enough to write the LDAP authentication handler and modify the server
internals to provide person attributes with the ticket validation
response.
> -Approx. time for deployment of central infrastructure?
6 months (development and testing of modifications and deployment
into production)
> -Approx. time per service for deployment?
Varies with developer experience with programming language used and
understanding of web apps.
> -Approx. FTEs for deployment of central infrastructure?
0.5
> -Approx. FTEs per service?
Varies with developer experience with programming language used and
understanding of web apps.
Central support for developers is 0.1 or less.
> 8.) What has been your experience with ongoing support and
> maintenance?
The CAS server only needs to be rebooted once every year or two or
when something causes the JVM to run out of memory.
> -Approx. FTEs for maintenance of central infrastructure?
0.1 or less.
> -Approx. FTEs for maintenance per service?
Not sure but should be less than one on the developers side.
Central support for all services (sites) is 0.1 or less.
> 9.) What mechanisms do you use for authorization on your campus?
Each web app does their own authorization. Some web apps share a
common custom authorization service. Some use the person information
returned with the username from validating the service ticket.
> 11.) Were any technologies or systems particularly hard or easy to
> integrate with CAS?
CAS has only been applied to web apps. We aren't using the proxy
authentication for multi-tiered SSO.
> 12.) Have you been able to adapt CAS use for any vendor applications
> and, if so, how many (and/or which)?
Used to front a wiki running MediaWiki software but not integrated
into the MediaWiki software.
> 13.) In your environment, is CAS used for application-to-application
> authentication and in particular for multi-tier applications/systems?
No.
>
> 14.) Have you integrated CAS with Apache servers that serve content
> other than JSP apps?
Yes; PHP, CGI-scripts, static content (mod_cas).
Some sites are written in ASP or ColdFusion.
> 15.) POST data support: How have you dealt with web applications that
> need to authenticate via CAS on http POST transactions?
No.
> 16.) What sort of average and peak load does your authentication
> service experience?
Don't know and haven't measured it. Load doesn't appear to be an
issue.
> 17.) What has been your experience with the performance of CAS?
Great! Fast, even on one old lung (CPU). Extremely low maintenance.
Just works. Most problems have been on the developers' end.
> 18.) How many servers are you currently using to run CAS at your
> institution?
Two behind a load balancer; one active, one hot-standby; manual
switch in load balancer to standby.
> 19.) What server hardware are you using?
Sun Fire V100 (1 x UltraSPARC IIe 500 MHz, 1 GB RAM)
Shared with a slave Sun ONE Directory server.
> 20.) Does your central authentication system protect:
> -Financial data?
> -Student records?
> -data protected by HIPPA?
> -data protected by FERPA?
All but HIPPA.
>
> 21.) We're also interested in your experience with the CAS community.
> More specifically, has the CAS community met your expectations in the
> following areas?
> -support
Reasonable support via mailing lists and wiki. Of course, you have
to wade through the typical amount of noise.
> -contributions
> ---end list---
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
