A Closer Look at CAS

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 CITs 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
Feb
Mar
Apr
May
Jun
Dec
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
Jan
2007
2008
Discretionary migration window
Early Adopters
5
Five Questions from SRM

1. Why not go with CUWA 1.5?
2. What do we get by writing CUWA 2.0?
3. Will we have to give up other work?
4. Would an outside solution be smarter?
5. 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 FTEs
• 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 FTEs 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 doesnt 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.htm
l
19
Identity Management
aadssupport_at_cornell.edu