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.