IdM Campus Developers Meeting 6/18/07

1. OIT/CIT Security, Identity Management Team IdM Campus Developers Meeting 6/18/07 • Introduction • CUWebAuth 2.0 and K4-K5 Upgrade • Central AuthZ Phase 1 • ServiceID Manager • Shibboleth • IdM Provisioning Projects

2. Andrea Beesing amb3@cornell.edu Opening Remarks • Fast-track projects • Emergency mass notification support • Active Directory for Exchange

3. Fast-track projects • Launched at President Skorton’s request within the past few months/weeks • Important for different reasons • Health and safety • Cornell’s endowment • July targets for IdM work to complete with August go-lives

4. Emergency Mass Notification Support • Charge to the Cornell Emergency Management Committee • Mechanism for notifying community members by voicemail, email and cell phone • Changes to WhoIAm by August 15 for students, affiliates, sponsored exceptions • Changes to self-service front end for contact info for faculty and staff in early fall from WhoIAm to Employee Essentials • New attributes in directory (all private) • Personal cell phone attribute will have privacy selection

5. Active Directory for Exchange • Very narrow scope with attention to scalability for future • Integration with other IdM infrastructure • Kerberos • Provisioning/enterprise directory • Phase II to follow • Campus Steering Committee (members identified) • Address broader campus needs, support model • Please bring your concerns to my attention!

6. Tom Parker jtp5@cornell.edu CUWebAuth 2.0 and K4-K5 • Current schedule keying on PS Student Records roll-out in Mar ’08 to reduce customer resource requirements • Issues with current code base used for web single sign-on argue for reassessing our approach to the Kerberos 5-only release • Timeline for retirement of Kerberos 4 now three to six months out

7. Opportunity Identified • Can we use additional window in K4 shutdown schedule to position ourselves to better support our web-based authentication solution for the long term? • Specifically: Should we invest resources in rewriting CUWebAuth (used with applications) and CUWebLogin (infrastructure component)?

8. Kerberos 5 Upgrade: Where Are We Now? 6/14 Identity Management Rollout Campus Rollout Complete PS Student Launch You Are Here 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

9. Where Are We Now? • Code review (4 code bases) 6/14 Identity Management Rollout Campus Rollout Complete PS Student Launch You Are Here 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

10. Where Are We Now? • Code review (4 code bases) • Security audit (new vulnerabilities) 6/14 Identity Management Rollout Campus Rollout Complete PS Student Launch You Are Here 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

11. Where Are We Now? • Code review (4 code bases) • Security audit (new vulnerabilities) • Rollout requirements • (PS launch) 6/14 Identity Management Rollout Campus Rollout Complete PS Student Launch You Are Here 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

12. Where Are We Now? • Code review (4 code bases) • Security audit (new vulnerabilities) • Rollout requirements • (PS launch) 6/14 Identity Management Rollout Campus Rollout Complete PS Student Launch You Are Here 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

13. Where Are We Now? • Code review (4 code bases) • Security audit (new vulnerabilities) • Rollout requirements • (PS launch) 6/14 Identity Management Rollout Campus Rollout Complete PS Student Launch You Are Here 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

14. Where Are We Now? • Code review (4 code bases) • Security audit (new vulnerabilities) • Rollout requirements • (PS launch) 6/14 Identity Management Rollout Campus Rollout Complete PS Student Launch You Are Here 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

15. Where Are We Now? • Code review (4 code bases) • Security audit (new vulnerabilities) • Rollout requirements • (PS launch) window of opportunity 6/14 Identity Management Rollout Campus Rollout Complete PS Student Launch You Are Here 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

16. Current State • Age of code = complexity = support burden for CIT and the customer • High potential for introducing security vulnerabilities when changes are made both to code itself and individual app config files • Difficulty providing product support for standard tools and new releases of operating systems

17. 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

18. 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

19. Proposal • Consider rewrite of CUWA and CUWL based on high-level design reviewed by ATA, IS, IT Security and campus development partners • Advantages identified to date • Merging CUWA into one code base, down from two • Separate security configuration from other configuration parameters, leading to fewer security issues for apps • Ability to routinely support new operating systems • Compatibility with standard tools (ex: PHP)

20. Recommendation • CUWebAuth 2.0 Implementation • Late Fall 2007 deployment • Maintain migration window Identity Management Rollout Campus Rollout Complete Develop CUWebAuth 2.0 PS Student Launch Ide 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

21. 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? • What are the longer-term implications? • Would an outside solution be smarter?

22. 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

23. 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

24. 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

25. 4. 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

26. 5. Would an outside solution be smarter? Assessment is “no” based on more than 150 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

27. 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

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

29. 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 example 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

30. 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..)

31. 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

32. Current Assumptions AuthZ Project Dependency > Permit Server replacement complete > I2 Grouper in production No significant higher priority projects tap our current (very limited) resource pool > Emergency Notification Service > Applicant Provisioning > Active Directory/Exchange Server deployment

33. Tom Parker jtp5@cornell.edu Central Authorization Phase 1 • Transparent cutover of Permit Server to Grouper • New UI for service owners and application developers

34. Under Development Permit Shim Permit migration application Organizational namespace Grouper UI ServiceID Manager application User documentation and training Detailed test plan Detailed launch and back-out plan Load testing

36. Joy Veronneau jv11@cornell.edu New ServiceID Manager Application • What is a ServiceID? • People are going to be requesting keytabs to replace their srvtabs as we move to Kerberos 5 • Needed a more automated process • Needed better information about who owns ServiceIDs and what they are used for • ServiceIDs will need to be available in the Directory for the Grouper Authorization Project (Permit server replacement.)

42. Joy Veronneau jv11@cornell.edu Shibboleth Update “Shibboleth is standards-based, open source middleware software [from Internet2] which provides Web Single SignOn (SSO) across or within organizational boundaries. It allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner.”

43. What Does Shibboleth Look Like?

44. Federations • Think about your ATM card and various bank federations like: NYCE, PLUS • They trust each other. • InCommon Federation: a group of 50+ Higher Education institutions (including Cornell-Ithaca) and sponsored participants (including EBSCO, Napster.) • InCommon uses Shibboleth as its federating software.

45. Why we’re interested in Shibboleth: • (Napster used Shibboleth.) • We would like to eventually have a “Cornell Federation” with Ithaca, Weill and Qatar. • Solves other problems. (example coming up!) • Shibboleth fits in well with our electronic directory, CUWebLogin, and Grouper.

46. Shibboleth Simplified • Identity Provider (IdP) - protected by CUWebLogin • Service Provider (SP) - protects an application like the EBSCO website. Knows how to ask “Where are you from?” and then talks to your Identity Provider. • Both an IdP and an SP can be configured to talk to more than one Federation.

48. Bill Turner wrt1@cornell.edu IdM Provisioning Projects • Alumni NetID Creation • Application Changes • STARS Applicant Provisioning • Staff NetID Provisioning

49. Alumni NetID Creation • Alumni NetID creation began 12/12/2006 and was completed 12/22/2006 • 189,661 records were identified by AAD as Alumni with mailable addresses • 66,974 had existing NetIDs • 121,562 new NetIDs were created • Final count for mailing after deduping etc. was 188,782

50. Cleanup processes • Lots of work identifying and dealing with duplicate and problem records • And lots more to go • After further discussion and consideration, project sponsor decided to remove Activation Code for all active non-Alumni NetIDs