Presentation on theme: "Introducing JA-SIG Central Authentication Service 3.0 Scott Battaglia Rutgers, the State University of New Jersey."— Presentation transcript:
Introducing JA-SIG Central Authentication Service 3.0 Scott Battaglia email@example.com Rutgers, the State University of New Jersey
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
What is CAS? CAS is… Single sign on for the web A trusted intermediary A proxy authenticator to back-end services
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!
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.
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
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.
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.
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
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
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
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
Revamped Architecture Built on popular open-source frameworks Spring Framework Quartz xFire Jakarta Commons Log4j Maven Design Philosophy: don’t reinvent the wheel
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
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
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
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
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)
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
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.
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
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
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)
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