Shibboleth Case Studies: Shibboleth as the Campus Web SSO

1. Shibboleth Case Studies:Shibboleth as the Campus Web SSO Albert Wu, UCLADatta Mahabalagiri, UCLA

2. About UCLA • Approx. 75,000 active users (students and employees). Total of 1.3 million on record • Decentralized IT; multiple accounts; multiple identity management operations • Operated a proprietary Web SSO called ISIS since 1996

3. Working in a Distributed IT Setting • Multiple units hold key components of the Identity management infrastructure • Administrative Information Systems (AIS) has the data and the Web SSO • Campus Technology Services (CTS) has the authentication engine and the largest helpdesk operation • Office of Information Technology (OIT) has theoretical oversight on policy issues. • Departmental units have local helpdesks supporting application-specific user issues • We formed partnerships instead of reorganizing/consolidating.

4. About ISIS • User logs in using one of several popular campus account types • About 200 campus web applications across 50+ IT units use ISIS • Integration with the campus Web SSO is “highly encouraged”, but not required. • Has the typical Web SSO features • Single login form • Basic session management • Rudimentary attribute delivery • Common logout

5. ISIS Issues • Proprietary SOAP Web Service API impedes growth • No scalable attribute delivery mechanism; • Multiple login type support, while practical, isn’t ideal • No organized identity repository • Essentially a garage operation with little formal policies governing its use or funding to support its continued development

6. Along Comes Shibboleth • Standards based… Actually, it effectively creates an identity management standard in the higher education community • Privacy-centric and flexible attribute delivery mechanism is attractive • Having the Internet2 middleware champions working with vendors and universities to adopt Shibboleth is huge • Federation is important – the University of California system is starting to leverage federated access heavily

7. Migrating to Shibboleth - Plan • Part of the Enterprise Identity Management Project • Replace ISIS as the campus SSO • Create ISIS/Shibboleth Bridge to allow phased migration • Target new applications first • Migrate existing applications as they come to natural upgrade cycle • Solidify UCLA Logon as the common logon ID space • Create Enterprise Directory - the identity repository • Formalize support and policy management

8. Migrating to Shibboleth – Current Status • Working with early adopter applications – CDIGIX, Common Campus Learning Environment (CCLE), UCLA GRID project, etc. • Moving our own applications to Shibboleth • Form Management Oversight Group working to address policy and management issues • Waiting for Shibboleth 2.0 release before aggressive rollout

9. Migrating to Shibboleth – Tech Support • Leverage the existing ISIS application support infrastructure • Update the ISIS administration utility to manage Service Provider registrations in parallel. • Same problem reporting and resolution processes • Developing UCLA-specific SP deployment “packages”: • Pre-defined configuration files, UCLA-specific install instructions, support site, etc.

10. Migrating to Shibboleth - User Support • They are still bouncing among helpdesks. Definitely need to address • Create Web SSO diagnostics walk-through scripts for the helpdesks • Make better use of the campus knowledgebase site • Rethink helpdesk? • Generally speaking, Web SSO issues are fielded by the individual helpdesks, but anything beyond basic password issues is forwarded to the ISIS team.

11. Lessons Learned So Far Shibboleth is the right way to go • Having a standard makes things easier • Silences the “it’s not a standard” argument • The community is growing. More and more support material • It gives people a baseline for conversation • Solid version 1 product • There are good people working on the product • Internet2 Middleware • International Community • Open Source Applications – Moodle, Plone, etc.

12. Lessons Learned So Far “Allow plenty of time to digest the changes.” • For the team • New Programming Language • New protocols, more complexity – SAML is hard • Rethinking team priority. We are no longer “coders” • For the campus IT community • New way of thinking about authentication • Lots and lots of documentation to read • More complex user support model, especially if federated • For the data owners/campus executives • New way of thinking about managing data release

13. Lessons Learned So Far “Installing Shibboleth SP is hard!” • There are lots of documentation, but it takes a lot of time to wade through them • System admins and developers don’t speak the same language • How to effectively manage ARP • Need to lower the “Install” bar: System admins should be able to install/activate Shibboleth SP in under 2 hours

14. Lessons Learned So Far “Have a flexible implementation plan.” • Be opportunistic – Leverage other project implementations • No one cares about middleware unless it solves his/her immediate problem • Middleware is difficult to “demo” • Supporting CCLE/Moodle gave us a platform to showcase Shibboleth • Watch for new product releases • Shibboleth 2.0 progress changed our plans • Focus on the end goal • It’s easy to get side tracked and/or compromise design. Be flexible, but make sure the end product still makes sense

15. Lessons Learned So Far “Diagnostics and support needs work.” • No end-to-end log marker to quickly correlate event data • Still require multiple teams from multiple units to troubleshoot basic incidents • Lack knowledgebase material

16. Lessons Learned So Far “Need Tools.” • Log/Event Correlation Analysis Tools • Data owners need tools to manage data release policy (ARP) • Tools to manage SP registration • Tools for SP to manage various configurations

17. Questions? • albertwu@ucla.edu • datta@ucla.edu

18. Migrating to Shibboleth - Technology • Create a shim between ISIS and Shibboleth: ISIS session and Shibboleth session are created in parallel. • Allow interoperability between ISIS-enabled application and Shib-enabled application, as long as the user logs in via the UCLA IdP. • To a UCLA user, it looks as if nothing has changed, except of the one extra redirect page. • We do not operate an PKI infrastructure. At this point, we require our SP to either obtain an InCommon certificate (if applicable) or obtain a commercial certificate for production servers

19. Migrating to Shibboleth – Management and Policy • Data owners (HR, Payroll, Registrars) continue to have oversight on data release decisions; • Working to provide data owners with tools to automate the process. • Hopefully change the way they think about data release: Right now, they address each request on a case-by-case basis. That can’t scale moving forward…

20. Migrating to Shibboleth – Management and Policy • Formed Identity Project Management Oversight Group • Representation from the key operating units (OIT, CTS, AIS), the data owners, and the campus security architect • Meets monthly to address new policy and management issues: • Log retention and release • Helpdesk issues • Security policies • Define and introduce new attributes