1. Introducing JA-SIG Central Authentication Service 3.0 Scott Battaglia scott_battaglia@rutgers.edu Rutgers, the State University of New Jersey

2. Outline What is CAS? History of CAS  CAS 1.x  CAS 2.x Introducing CAS 3  Development Process/Developers  Design Goals  Why build CAS 3? Advanced CAS 3 Usage  Clustering/Load Balancing  Accepting Multiple Credential Types  SAML Support The Future Helping with CAS Development

3. What is CAS? CAS is…  Single sign on for the web  A trusted intermediary  A proxy authenticator to back-end services

4. History of CAS CAS 1.x CAS 2.x

5. History of CAS: CAS 1.x Original version released by Yale University Offered single sign on for the web Consisted of servlets and JSP pages

6. History of CAS: CAS 2 Also developed at Yale University Introduced concept of proxy authentication to CAS Simple: 6 servlets and fewer than 10 JSPs Extremely popular Large User Community

7. Introducing CAS 3.0

8. CAS 3.0: Why Build CAS 3? CAS 2.0 was an excellent project CAS 2.0 was easy to use CAS 2.0 was not easy to extend or augment with local requirements CAS 3.0 attempts to solve the last problem!

9. CAS 3.0: Why Build CAS 3? Making changes to CAS 2.0 generally requires forking the code base Adding new features may require a lot of copying and pasting which may get out of sync with core code base.

10. CAS 3.0: Why Build CAS 3? CAS 3 offers…  CAS 2 compliance out of the box  Unit/Integration Tests and Compliance Tests  Proper domain model  Revamped architecture  Support for well-known modifications

11. CAS 3.0: Design Goals First and foremost CAS3 will be Flexible, Extensible and Elegant. CAS3 will maintain backward compatibility with CAS 2.0 and CAS 1.0 protocols while providing extension points for well-known modifications and new features such as support for Web Services, SAML and Shibboleth. CAS Clients written for older versions of CAS will work with CAS3 without modification.

12. CAS 3.0: Development Process Started as a Yale/Rutgers collaboration Became JA-SIG Project in December 2004 JA-SIG project makes it open-source Available in public JA-SIG CVS, nightly builds on Clearinghouse machines, etc.

13. CAS 3.0: Development Team Yale University  Susan Bramhall  Howard Gilbert  Drew Mazurek  Andy Newman  Andrew Petro Rutgers, the State University of New Jersey  Scott Battaglia  Dmitriy Kopylenko  Bill Thompson

14. CAS 2 Compliance In terms of protocol, drop in replacement for CAS 2.0 Requires no modifications to client applications Includes adaptor to allow plugging in CAS 2 PasswordHandler into CAS 3 architecture

15. Unit/Integration/Compliance Tests Unit and Integration Tests coverage of major components  Utilizes JUnit, Clover  According to Clover, 99.5% test coverage  Allows us to refactor with confidence! Compliance Tests  Run against live server  Test compliance to CAS 2 specification  Currently 48 tests

16. Proper Domain Model Major Breakthrough: Only Two Types of Tickets  Ticket Granting Ticket  Service Tickets Domain logic belongs with Domain Objects  Example: A ticket can determine if its expired  Simplifies implementations of supporting pieces

17. Revamped Architecture Built on popular open-source frameworks  Spring Framework  Quartz  xFire  Jakarta Commons  Log4j  Maven Design Philosophy: don’t reinvent the wheel

18. Revamped Architecture Loose coupling of components  Via Dependency Injection  Declarative configuration via XML files Coding to interfaces  Swap implementations to suite needs  Implementations adhere to contract  Example: TicketRegistry

19. Revamped Architecture Uses Design Patterns  Patterns allow for a common understanding  Example: Template Design Pattern Layered Architecture  Separation of UI concerns from business concerns  Allows for better re-use of code  Example: Web Tier vs. Web Service

20. Revamped Architecture Use of AOP to separate cross-cutting concerns for business logic  Allows for major additions to functionality without modifying core code  Example: auditing Use of Spring Workflow allows for declarative reconfiguration of Login process

21. Support for Well-Known Modifications Gathered list from current and future (potential) CAS deployers CAS 3 includes extensions points for well- known modifications CAS 3 (via Spring) supports using AOP to introduce modifications

22. Support for Well-Known Modifications Audit Trail Modification (identified by CalPoly) Services Whitelist (identified by Columbia and University of Delaware) Additional Principal (and Authentication) Attributes (Rutgers, others) Ticket Statistics (Yale)

23. Support for Well-Known Modifications Audit Trail Modification  CAS supports publishing of events  EventListener listens for events  Deployers can code and register “EventHandlers” that allow them to log particular events

24. Support for Well-Known Modifications Attributes  CAS supports plugging in PrincipalResolvers and MetaDataPopulators  Allow to attach attributes to principals (i.e. hair color or employee type)  Attach attributes to Authentication (i.e. safeword authentication)  Can customize view to pass back attributes.

25. Support for Well-Known Modifications Ticket Statistics  Exposed via JMX  Tell how many of each ticket type were vended  Tell how many tickets of each type were vended per second

26. Advanced CAS 3 Usage

27. Clustering/Load Balancing CAS All CAS Domain objects are serializable Tickets are only stored in TicketRegistry TicketRegistry is interface Implement JGroups TicketRegistry (David Stacey)

28. Accepting Multiple Credential Types Web Login defined by workflow Dartmouth identified need to have augmented login workflow Need to check for Client Certificate before displaying login form

29. SAML Support Standard XML-based framework Used to create and exchange info amongst online partners CAS can offer alternatives to the CAS 2 Protocol views One alternative is a SAML response

30. The Future of CAS

31. Advanced SAML Support  Support for both SAML request and responses Shibboleth Support  Requires advanced SAML support  Allow CAS to speak to Shibboleth Who knows what else…  current architecture allows for many possibilities

32. The Future of CAS Already working on a 3.0.1 (and beyond)  XMLBeans view  More robust registry cleaners  Increased compatibility testing  Support for Single Sign out (requires new clients)

33. Helping with CAS 3.0 Development What can YOU do to help?  Look at what CAS 3 has to offer  Use CAS 3  Report bugs/feature requests/etc to the development list  Give your extensions back to the community  Share your experiences using CAS with the community  Join the CAS mailing list

34. Questions or comments?