Case Study: Newcastle University

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

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

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

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

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

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

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

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

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

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

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

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

13. Problems • PKI providers are not easy to deal with • 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)

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

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

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

17. Questions?