Download
introducing ja sig central authentication service 3 0 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Introducing JA-SIG Central Authentication Service 3.0 PowerPoint Presentation
Download Presentation
Introducing JA-SIG Central Authentication Service 3.0

Introducing JA-SIG Central Authentication Service 3.0

341 Vues Download Presentation
Télécharger la présentation

Introducing JA-SIG Central Authentication Service 3.0

- - - - - - - - - - - - - - - - - - - - - - - - - - - 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?