1 / 19

A Closer Look at CAS

A Closer Look at CAS. SRM Update Identity Management Team OIT/CIT Security May 14, 2007. Review: The Reasonable Options. CUWA/CUWL 1.5 – Attempt to fix what we have CUWA/CUWL 2.0 – Re-build it the way it should be Move to an outside solution Yale CAS Stanford WebAuth CoSign.

rhian
Download Presentation

A Closer Look at CAS

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. A Closer Look at CAS SRM Update Identity Management Team OIT/CIT Security May 14, 2007

  2. Review: The Reasonable Options • CUWA/CUWL 1.5 – Attempt to fix what we have • CUWA/CUWL 2.0 – Re-build it the way it should be • Move to an outside solution • Yale CAS • Stanford WebAuth • CoSign

  3. Review: Service goals considered • Impact of change on campus developer community • Minimal work required to migrate to new versions • Support for required functionality • Predictability of user experience • Long-term viability of CIT’s authentication solution for web-based services • Performance and scalability as use of CUWA and CUWL increase • Support for new server operating systems and web servers (Apache, IIS) • Support for future enhancements to authentication and authorization • Security of central authentication services • Efficient use of scarce CIT resources

  4. Review: IdM Recommendation • CUWebAuth 2.0 Implementation • Fall 2007 deployment • Increase migration window 9/1 Identity Management Rollout Campus Rollout Complete Develop CUWebAuth 2.0 PS Student Launch K4 Shutdown Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun 2007 2008 Discretionary migration window Early Adopters

  5. Five Questions from SRM • Why not go with CUWA 1.5? • What do we get by writing CUWA 2.0? • Will we have to give up other work? • Would an outside solution be smarter? • What are the longer-term implications?

  6. 1. Why not go with CUWA 1.5? • Condition of 8-year-old code has become a support burden • Significant work required for even minor changes • Impact of change on other portions of code difficult to test prior to release, results in more problems for campus service providers • More bugs and security vulnerabilities as a result • Currently requires 2 FTE’s • Increasing campus dependency on CUWebLogin = scalability and performance issues • SideCar limitations and scheduled retirement • Preference for web-based applications

  7. 2. What do we get by writing CUWA 2.0? • Product that is easier to maintain • Simpler protocol • Legacy dependencies eliminated • Less code duplication (one code base instead of four) • More extensible code (and all within local control) • More secure protocol • More scalable web single sign-on solution • No loss of required functions and features • Relatively minimal impact on campus developers

  8. 3. Will we have to give up other work? • Overall development effort not much different -CUWA 1.5 estimated 23.8 FTE weeks -CUWA 2.0 estimated 25.6 FTE weeks • CUWA 1.5 work requires the skill-set of four members of current IdM team • CUWA 2.0 work will require skill-set of only two members of current IdM team • CUWA 2.0 choice frees up skill set required for key projects like Active Directory, PS/STARS, Automated Provisioning, Grouper/Signet

  9. 4. Would an outside solution be smarter? • Assessment is “no” based on more than 100 hrs of research • Alternatives may offer short-term wins for IdM development team • But would have significantly higher impact on user community • Using these solutions off-the-shelf, without mods: -we give up features we currently have (ex: POST data support) -or we accept the same vulnerabilities we have with CUWA 1.5 • Making mods to these outside solutions -may take as much or more time as re-writing CUWA 2.0 -requires unknown level of cooperation with other institutions -may cause entanglements and dependencies beyond our control

  10. 5. What are the longer-term implications? • Lower maintenance cost, from 2 FTE’s to 1 • Better security • More predictable user experience • Positions us better for future enhancements to authentication and authorization services • Opportunity for open-source release

  11. In Review: Summary Pros and Cons • Webauth 1.5 • Lowest short-term risk • Limited benefit • Webauth 2.0 • Best long term solution • Slightly more short-term work • CAS • Great java integration. • Most expensive for the rest of campus. Security not great. • Stanford • Lowest deployment cost for Identity Management • Complex infrastructure and missing features

  12. A Closer look at the CAS Experience • Initial contacts with Rutgers and IU • Posting to the Yale CAS mailing list • Results from: • Rutgers • Cal Poly • University of Connecticut • Indiana University • Virginia Tech • University of Hawaii • Stanford • Duke

  13. General Findings • CAS has an enthusiastic following and an active developer community • CAS works well for institutions which have no significant authentication and authorization infrastuctures already in place • CAS works close to the application layer. This is fundamentally different from CUWA • CAS doesn’t address authorization at all • Cornell is ahead of most on the AuthZ front • Going to CAS would be a significant step backwards on AuthZ • The Indiana University experience is likely a good expample of what would happen if we attempted to make CAS work for us: • Post Data support • GuestID and TokenID support • IIS and Apache mods • IU is now working from its own code base, rooted in CAS 2.0

  14. Comments of Particular Interest • UConn, Matt Smith: “Glad I could help -- allow me to muddy the waters a bit, though: our original spec required that the SSO/ISO solution support multiple backends for authentication, and CAS fits the bill *very* well (and was really the only solution to do so). However, we have since decided to try to move to a pure "Kerberized" (MIT v5 KDC) environment. CAS still fits very well, but solutions like CoSign or WebAuth may have been simpler, plus would have given us a few extra Kerberos bonuses, such as SPNEGO and back-channel ticket delegation. Pure Kerberos is a bit of a Holy Grail for us (particularly where certain NTLM-only Microsoft products come into play), but for environments that are already Kerberized, CoSign or WebAuth may offer more than CAS, without the Java overhead (Tomcat or another servlet container)….” • Stanford, Heather Flanagan: “…frankly, we have a good group supporting WebAuth at Stanford so there is no compelling reason at this time to change to anything else.  We don't need to make more work for ourselves when what we has meets our needs AND is supported.  I just came to Stanford from Duke, and there the look at CAS was a bit more thorough, tho' at the time they also decided to hold off.  In that case, Duke's webauth program (also written in house) was no longer supported by anyone, which made CAS a bit more compelling.  Still, with a lack of resources and a bigger learning curve, as well as the amount of change required by the campus community if they abandoned webauth, no change was made there either.  • Duke, Shilen Patel: “We haven't moved towards deploying CAS, but instead are more interested with Shibboleth.  We have Shibboleth deployed at Duke, but it cannot replace Duke Webauth right now since Shibboleth does not have many of the functionalities we require.  We are looking more towards being involved in the Shibboleth community to hopefully get some of our required functionalities integrated with Shibboleth. ..”

  15. Converting to CAS • We have roughly 212 services actively using CUWebAuth.  • Of these services 50% would be simple conversions to CAS, averaging 1 day each for application plus 2 days for training; 3 days total.  • Another 25% (50+ services) would be relatively easy conversions, but would need to add code to do central authorization.  Add 5 days for that; 8 days per service • The remaining 25% (50+ services) would be in the more difficult category. • some of this involves static content • some involves vendor integration • some would have special central authorization needs • some are currently supported by non-programmers who will need to outsource the deployment • some are a combination of some or all of these.. • Time required to convert these services: unknown, but we are conservatively estimating 25 days (or roughly one FTE month per service to develop, test, deploy..)

  16. Initial Estimate • CUWebAuth 2.0 • FTE weeks per service: 0.5 weeks or less • 0.5 x 212 = 106 FTE weeks • FTE weeks IdMgt: 25.6 • FTE ongoing Maint: 1 • CAS • FTE weeks per service: 2 weeks on average • 2 x 212 = 424 FTE weeks • FTE weeks IdMgt: 23 • FTE ongoing Maint: 1

  17. Questions?

  18. http://identity.cit.cornell.edu/projects/index.html

  19. Identity Management aadssupport@cornell.edu

More Related