Case Study Newcastle University Caleb Racey Caleb Raceyncl

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

Overview • 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 • 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 1/2

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 (edu. Person) • Service Provider policies – Only medics get to see medical content • Who are we? . ncl. ac. uk or. newcastle. ac. uk ncr 18 not NCR 18 • 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 – Once you have one you don’t want another – There is a reason Thawte etc. charge 10 x 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 (edu. Person)

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 Identity enrichment needed Democratise identity information = Grouper? • Enhanced use cases – Google Apps – Collaborative research platforms – Shared “regional” services • Outsourced identity providers?

Questions?