1345 1400 Fiona Cullock Edina Case StudyPresentation Transcript
Case Study - EDINA Fiona Culloch, EDINA JISC Services Briefing Day, Birmingham, 28 September 2007
EDINA develops and hosts services based on licensed data content:
Geographic (Digimap, UKBORDERS, …)
Bibliographic (Times Index, CAB Abstracts, LLL)
Multimedia (Film & Sound Online, EIG)
Repositories (JORUM, The Depot)
Customer institutions take out subscriptions
Authentication by IP address, Athens, UK federation
The Authorisation Decision
EDINA maintains own list of valid address ranges corresponding to each subscribing institution
Eduserv central table of institutions vs services; they tell us whether a user is authorised for our service
How do we decide if user is from a subscribing org?
It’s our problem (like with IP, not like Athens)
What You Can’t Assume
Just because someone has an ID within the federation:
Doesn’t mean they are necessarily entitled to use your service (may be from non-subscribing institution)
They may not even be from “the community” (e.g., anyone can get a ProtectNetwork or TypeKey ID)
They may not be an identifiable real-world person: only true if identity provider claims user accountability
So it’s up to you to check all this. How?
Identifying User’s Organisation
eduPersonScopedAffiliation attribute (in env. var.):
student @ ed.ac.uk
Scope ( ed.ac.uk ), a.k.a. “security domain,” is:
Restricted by federation policy to be a DNS name belonging to a real-world member organisation
Published in federation metadata for those IdPs that may use it; other IdPs can’t (enforced by SP s/w)
Intended for use by SPs to discover user’s org.
Easily referenced within a licence agreement
Affiliations in HE/FE
Affiliation ( student ): user’s relation to organisation.
Maps to categories in JISC Model Licence:
Not authorised alum Not authorised affiliate Authorised member Authorised employee Authorised faculty Authorised staff Authorised student
Authorisation, Organisation Tables
EDINA login scripts (perl) implement business rules for access, using file that maps scopes to authorised services:
ed.ac.uk: eig jorum media statacc … leeds.ac.uk: eig media mediamedical … ox.ac.uk: jorum media
If you already have internal customer codes, you need a mapping from scopes to those, e.g.:
ed.ac.uk: edu leeds.ac.uk: lee ox.ac.uk: oxu
Service providers must invent these wheels themselves. Neither Shibboleth nor the federation can do it for you.
Initially, we generated these scope mapping files by hand
But we had an existing DB of subscription info., keyed by internal org. code (cam, dur, liv, …)
This DB happened to contain e-mail addresses of local contacts at these organisations (and therefore DNS names)
So we now automatically generate scope to licences and org code mappings from this DB and the federation metadata (with manual approval of changes in case of accidents)
You may not be so lucky and may need to change existing DBs (and populate) to include federation scope info.
This is a property of the IdP, not of individual users; therefore, it’s not a user attribute
Only need to worry if you care about traceability
Proposal with Shibboleth core team for attributes about IdPs (expressed in metadata, distinguishable from user attributes), possibly in Shibboleth 2.x
Mean time, must write own XSLT transform to extract entityIDs with <AccountableUsers> label from metadata (Digimap will do this).
UK Federation Core Attributes User ID only when essential (email@example.com). Data protection issues eduPerson PrincipalName Extensible list of URIs intended to list entitlements to access specific resources eduPerson Entitlement Opaque, persistent ID allows personalisation without SP knowing user’s real identity. Each SP sees different value of this for same user eduPerson TargetedID firstname.lastname@example.org (or student, staff, faculty, alum). Identifies user’s status & organisation. Required by most SPs eduPerson ScopedAffiliation