1. Case Study: Newcastle University
Caleb Racey

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

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

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

17. Questions?