1 / 34

Introducing JA-SIG Central Authentication Service 3.0

Introducing JA-SIG Central Authentication Service 3.0. Scott Battaglia scott_battaglia@rutgers.edu 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?

Mercy
Download Presentation

Introducing JA-SIG Central Authentication Service 3.0

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. The Future of CAS • 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?

More Related