Shibboleth Case Studies: Shibboleth as the Campus Web SSO

1
Shibboleth Case StudiesShibboleth 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,
  isnt 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 its 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 dont 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
• Its 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_at_ucla.edu
• datta_at_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 cant 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