CASifying Horde

Horde CASification discussions are now happening within the Horde project wiki. This is excellent news! In general there's a great deal of potential in moving CASification onto the radar of the applications themselves.

Biometric CAS authentication

More proof that CAS is a web authentication platform flexible enough to accomodate authentication mechanisms other than usernames and passwords.

Work for the inventors of CAS

Yale University ITS Technology & Planning has two -- count 'em two! -- openings listed. Technology & Planning is a great place to work -- awesome coworkers, good working environment, neat projects. Be interested in these jobs.


Systems Programmer I Requisition #: CCRF33463
Posting Date: 3/15/06
Department: ITS Technology & Planning Work Site: 175 Whitney Avenue
Salary Grade: 24 Duration: REGULAR - 12 MONTHS


Schedule/shift: Full Time - 37.5 HRS; Weekdays 8:30-5:00
Internal applicants send bids to: Corey Rossman, 155 Whitney Avenue

Job Description:

General Purpose
Work with a small focused senior ITS professionals that develop strategic technical directions for the University and explore emerging technologies.
Essential Duties of Position
1. Work in a collaborative fashion with a broad range of IT professionals to establish both needs and opportunities for emerging technologies.
2. Participate in large scale multi-University development efforts that utilize a fluid mix of both new and legacy development methodologies and technologies.
3. Track and evaluate emerging technologies in fields that include (but are not limited to) software development languages and environments, network, information security and telephony.
4. Produce technical white papers and presentations for consumption within Yale's ITS organization and at national conferences.

Education and Experience
1. Bachelor's degree or equivalent experience as well as a minimum of two years experience developing software in Java programming language.
2. Experience developing middle-tier applications utilizing Java Servlet/JSP technology. This experience should include familiarity with current design and coding approaches and methodologies.
3. Documented record of software development experience in either a corporate or university setting is necessary. Code samples may be requested and reviewed with the candidate.

Skills and Abilities
1. Demonstrated track record of inquisitive self-direction and the ability to learn new things rapidly and completely.
2. Familiarity with the basic principles of relational database design.
3. Experience with at least one other high level programming language is desireable but not required.
4. Technical familiarity with one of the following operations systems is additionally desireable: Unix/Linux, Microsoft NT/XP, Mac OSX
5. Excellent written and verbal abilities.



Systems Programmer III Requisition #: CCRF33464
Posting Date: 3/15/06
Department: ITS Technology & Planning Work Site: 175 Whitney Avenue
Salary Grade: 26 Duration: REGULAR - 12 MONTHS


Schedule/shift: Full Time - 37.5 HRS; Weekdays 8:30-5:00
Internal applicants send bids to: Corey Rossman, 155 Whitney Avenue

Job Description:

General Purpose
Take a technical leadership position working with a small focused staff of senior ITS professionals that develop strategic technical directions for the University and explore emerging technologies.
Essential Duties
1. Facilitate and lead in collaborative fashion projects involving a broad range of requirements as well as customers.
2. Participate in large scale multi-University development efforts that utilize a fluid mix of both new and legacy development methodologies and technologies.
3. Work with the University IT leadership to establish goals and directions for foundation technology that serve us into the future.
4. Track and evaluate emerging technologies in fields that include (but are not limited to) software development languages and environments, network, information security and telephony.
5. Produce technical white papers and presentations for consumption both within Yale's ITS organization and at national conferences.

Experience and Training
1. Bachelors degree or equivalent experience as well as a minimum of 6 years experience developing software in the Java programming language.
2. Experience developing middle-tier applications utilizing Java Servlet/JSP technology. This experience should include familiarity with current design and coding approaches and methodologies as well as a concrete and demonstrated ability to evaluate, adopt and fully understand complex software frameworks and architectures.
3. Experience with at least one other high level programming language
4. Experience with the management, performance characteristics and basic principles of operation either Unix/Linux or Microsoft's NP or XP operating environment.
5. Familiarity and practical experience with project planning approaches and the ability to budget both temporal and fiscal resources.
6. A documented record of software development experience in either a corporate or university setting is necessary. Code samples may be requested and reviewed with the candidate.

Skills and Abilities
1. Demonstrated ability to lead a technical team effectively.
2. Complete understanding of relational database principles and design.
3. Excellent written and verbal communications skills.
4 Demonstrated track record of successfully identifying, promoting and deploying products and services that represent long term value to their employer as well as providing bedrock technology upon which additional services are built.

Real Security vs. Excessively Clever Tricks

Someone asked off-list:

Has there ever been any thought to add additional checks to guard against rogue Ticket Granting Cookies? This thread got me thinking that CAS server could record and check the TGC against the IP address, User Agent, etc that is as issued to. Not sure this would actually add anything...thoughts?

I'm very reluctant to add additional checks for Ticket Granting Cookie validity in CAS. None of them would actually improve security, and all of them would make CAS less convenient or more fragile. I'd suggest that adding these tricks can only hurt - it makes CAS more complicated and provides opportunities to overlook the things that are very important to its security.

One of the beauties of CAS is how little there is in it that doesn't need to be there.

Either we trust SSL or we don't. If SSL fails all bets are off, the Adversary will have your passwords and session identifiers and is home free. Either we trust the end user to supply a non-compromised web browser and machine, or we don't. If the end user types her password into a compromised machine, if she uses a x509 cert on a compromized machine, then all bets are off. The Adversary has primary credentials and is home free.

Security is about the tickets being large random numbers and about not letting the Adversary get at them in the first place.

This connects back to a discussion from some time ago about whether the expected "service" should be included in CAS's ticket validation error response to help application developers to debug.

CAS is not secure because the Adversary can't guess the service identifer: he can. The namespace is too small. CAS is secure because the Adversary cannot acquire or guess a valid Service Ticket [1]. Failing to report the correct service identifier when a service ticket fails to be validated because the service identifier doesn't match doesn't add anything to CAS's security and only misses an opportunity to provide a more useful error response. It doesn't add anything to the security because guessing service identifiers is a formally easier problem than guessing service ticket strings.

CAS is not secure because the Adversary cannot guess the user-agent, can't fake out remote address headers, etc. He might be able to do all those things too; the namespace is too small.

CAS is secure because the Adversary can neither acquire nor guess a valid TGC string in the first place. If that's not true, then CAS is not secure, and no amount of IP address checks, User Agent matches, or any other tricks will help, since an Adversary that can acquire a TGC can with significantly less difficulty guess all those things and fake out all those tricks.

We do not seek to merely inconvenience the Adversary. We don't want to throw minor roadblocks in his path, make him guess service identifiers, IP addresses, user agents, anything like that. We want to shut him out completely. So CAS uses random numbers drawn from large namespaces and SSL. Defeauting CAS is formally equivalent tomsolving any of several hard problems: defeating SSL, hacking the CAS server box, or defeating the SecureRandom random number generator.[2] These are the hardest problems we have available. Adding easier problems for the Adversary to also solve won't make CAS any more secure.

[1]: An application can choose to insecurely receive its service ticket at an http:// URL, and in doing so accepts the risk that the Adversary will intercept the ticket and thereby illicitly access the application, just as it accepts the risk that the Adversary will steal the session on any subsequent request since session cookies and the like are also being sent in the clear. But it is a per-application risk that doesn't compromise the secure session as regards accessing other applications.

[2]: Of course, the Adversary can compromise individual end user machines to get individual end user credentials.

Web Calendar CASification solution

Roberto Cosenza has generously shared a solution for CASifying Webcalendar. WebCalendar is a PHP-based database-backed calendar application that can be configured as a single-user calendar, a multi-user calendar for groups of users, or as an event calendar viewable by visitors.

eXo Platform CAS support

eXo Platform now supports using CAS for single sign on.

On the use of the "final" keyword

The CAS codebase makes aggressive use of the final keyword. Some developers attempting to extend CAS by subclassing are annoyed and inconvenienced by this. Why do we use the final keyword?



If the CAS framework is to be extended by subclassing, then support for extension by subclassing needs to be deliberately designed into the classes in order to provide maintanable APIs and a maintainable project. The effort required to do this design is greater than zero work but it is important for everyone involved -- it retains some explicitness about what APIs we're exposing so we can be careful that implementation changes don't damage exposed APIs. It provides additional sanity for the person doing the local subclassing, exposing deliberate and documented template methods and documenting what is being guaranteed as opposed to what happens to be true.

The final keywords pretect the project from frozen implementing code via all of the implementation having been inadvertantly exposed as APIs to potential subclasses. The final keywords protect you, the local CAS implementer, from making assumptions the project had not intended to guarantee.

Therefore, wherever a class has not been designed for subclassing, it should be marked final. This protects everyone from following bad expectations -- implementing extension by subclassing and thereby coding against assumptions that aren't recognized as something to contnue to support without understanding this risk.

Wherever a class is not marked final, any method that isn't designed to be replaced by a subclass should be marked final. Any method that isn't designed to be invoked by a subclass should be marked private (balanced against the advantages of package-scoping internal implementation methods for application of unit testing of the internal methods). This is annoying for a would-be subclasser, but it protects the project against exposing APIs and having to contnue to support them when the implications of this haven't been thought through.

No code is perfect. All code ages. The CAS3 design decisions aren't perfect and no design decision is without tradeoffs. Nonetheless, aggressive use of the final keyword is a technique for slowing project cruft-accumulation of APIs we've exposed that it turns out shouldn't have been exposed.



So, wherever it is that you're annoyed that we've marked something final, that probably means that there's a specific opportunity to recognize an extension point and design it in, or to better document what the preferred alternative to doing that subclassing is, or possibly that you've really found an extension point that's out of
scope of the CAS project because though you need it your need is so esoteric that the complexity cost of adding the extension point is greater than its value. (This latter is unlikely but I'd like to manage expectations: CAS cannot become the union of all
possible features, and it can't even support the union of all possible extension points, but it can and should and wants to support many many common extension points.)

We hope you'll voice your needs on the discussion lists, engage the CAS developers and join the process of identifying, advancing, and implementing support for CAS extension points, and share your code. The final keyword isn't intended to communicate that we think CAS is perfect as is and no one would ever want to change our code (we don't think this). It is intended to focus effort on identifying and supporting the extension points you can productively use in a way that is maintainable for the project and benefits all involved.

Our use of the final keyword enables the developers to respond to a newly recognized extension point need by adding the extension point, confident that this does not break existing subclasses of the object to be enhanced, since those subclasses were discouraged by the final declaration.