1345 1400 Fiona Cullock Edina Case Study

  • 701 views
Uploaded on

 

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
701
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
16
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Case Study - EDINA Fiona Culloch, EDINA JISC Services Briefing Day, Birmingham, 28 September 2007
  • 2. EDINA Services
    • 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
  • 3.  
  • 4.  
  • 5.  
  • 6.  
  • 7.  
  • 8. The Authorisation Decision
    • IP address:
      • EDINA maintains own list of valid address ranges corresponding to each subscribing institution
    • Athens:
      • Eduserv central table of institutions vs services; they tell us whether a user is authorised for our service
    • UK federation:
      • How do we decide if user is from a subscribing org?
      • It’s our problem (like with IP, not like Athens)
  • 9. 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?
  • 10. 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
  • 11. 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
  • 12. 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.
  • 13. EDINA Experience
    • 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.
  • 14. User Accountability
    • 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).
  • 15. Contacts
    • http://www.ukfederation.org.uk/
    • http://shibboleth.internet2.edu/
    • [email_address]
  • 16. UK Federation Core Attributes User ID only when essential (fculloch@ed.ac.uk). 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 member@ed.ac.uk (or student, staff, faculty, alum). Identifies user’s status & organisation. Required by most SPs eduPerson ScopedAffiliation