Case Study: Newcastle University Caleb Racey Caleb.Racey@ncl.ac.uk

Overview who I am Newcastle background Drivers Business case Policy Introduction who I am Newcastle background Experiences deploying shib Drivers Business case Policy Architecture Lessons learned

Who am I Web development officer in Newcastle University 6 years experience of Systems Admin for Web 4 years working on SSO issues 3 years with shibboleth Systems Developer: Adapt Open Source software to provide solution Not hard core programmer Not PKI guru Deploy Services not systems

Newcastle University UK University 4,700 staff 17,000 students Research Intensive Medical School Centralised IT service Celebrating 50 years computing

Shib @ Newcastle 3 years Shibboleth experience Early Adopter funded by JISC IAMSECT project http://iamsect.ncl.ac.uk Shibboleth transitioned from pilot to fully supported central service Entering identity enhancement stage Present = usable core attributes - want better Group management Provisioning

Technical Background Distributed ad hoc identity infrastructure No Single Authoritative directory of user info Identity information spread across diverse systems Attributes Aggregated from multiple sources Mixed Infrastructure: Unix: Solaris + Redhat EL Windows SAP Mixed web application platforms: The 3 P’s: Php, Perl, Python Java ASP + ASP.net

Newcastle Requirements Usable across multiple platforms: Apache (PHP, Perl) IIS (ASP ASP.NET) Tomcat (java) Zope (python) Works with complex identity infrastructure Ability to integrate data from many sources Different access technologies LDAP SQL SSO = single username, not “sign on once” Robust, Scalable, Manageable

Drivers for Shibboleth 1/2 Enormous diversity of usernames 3 VLEs Unix systems Adhoc online systems Library Management (exlibris) Athens Windows Active Directory Login Web based Services growing Enormously bargain for individual data feeds data feed “guardians” scarce resource Need for SSO drive obvious

Business Case Core Password infrastructure badly under utilized Mainly Desktop login Support cost of multiple password stores Poor user acceptance of systems SAP admin staff time bottleneck Poor security Insecure Password transfer (http) Insecure connection to back ends Increasing Risk with each system One system compromise = change all passwords User confusion = Easy phishing

Policy Implications Agree to federation policies User “tracking” No account recycling for 2 years Only Newcastle users will have accounts Attribute Data Format (eduPerson) Service Provider policies Only medics get to see medical content Who are we? .ncl.ac.uk or .newcastle.ac.uk ncr18 not NCR18 User account policies All users will have Active Directory accounts Users have to agree to terms and conditions distance learning, medics

Architectural Considerations Need real time access to institutional attribute stores Firewalls + secure connections Mindset change: Central Attribute broker = good idea Active directory compatibility: Secure “pooled” LDAPs support Kerberos Firewall rules Port 8443 opened (conflicts with printer vulnerability) Shibbed kit has to be directly routable. Infrastructure should be robust Multiple boxes Separate locations Monitored

Required Skill sets Working knowledge of own identity infrastructure: Where to get data + how What is usable Who to talk to Working knowledge of using SSL Not hard protocol knowledge Getting signed SSL certs Configuring servers Working knowledge of Apache httpd + tomcat Installation Use in production (robustness, monitoring, updating) Very little java programming 3 years, no lines of code written or required

Problems PKI providers are not easy to deal with Upgrading complex Once you have one you don’t want another There is a reason Thawte etc. charge 10x smaller providers Certs are cheap, procedure and staff time is not Upgrading complex Limited ability to test new installs before swapping Federation removes end to end control SSL means you can’t fake it easily Breaks in attribute aggregation hard to detect Federation imposes: Paperwork Policy Procedure Data Formats (eduPerson)

Lessons learned (1) Federated Use = unique selling point of shib Federation has done much of hard thinking for you Internal use = Much more demanding Greater set of attributes Identity Enrichment drive needed Grouper Review of account management Enabling new lightweight approaches Provisioning on first use 1 technology = auth + data provision Much lower barrier to application deployment

Lessons learned (2) Identity management is not a technology It’s processes + procedures + policies Regardless of technology the lessons are the same It’s the keystone of future development Shibboleth can deal with messy composite Identity Infrastructures It is much better not to need to Driver for identity review, improvement Democratizes platform choice Java based calendaring Php based wiki Perl based Mailing lists

Future Need for identity management review Enhanced use cases Identity enrichment needed Democratise identity information = Grouper? Enhanced use cases Google Apps Collaborative research platforms Shared “regional” services Outsourced identity providers?

Questions?