1 / 19

Citizen of the Federation

Fiona Culloch, EDINA JISC Access Management Showcase, 18 July 2006. Citizen of the Federation. Install Service Provider (SP). https://sp.com web server Configure to protect content, e.g., in Apache:

donnan
Télécharger la présentation

Citizen of the Federation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Fiona Culloch, EDINA JISC Access Management Showcase, 18 July 2006 Citizen of the Federation

  2. Install Service Provider (SP) • https://sp.com web server • Configure to protect content, e.g., in Apache: <Location /content> AuthType shibboleth ShibRequireSession On require valid-user </Location> • https://sp.com/content/index.html now invokes Shib authentication • But to talk to a real Identity Provider (IdP) you will want to join the federation

  3. GlobalSign Thawte VeriSign • TERENA good future option for non-commercial (UKERNA RA) SDSS TERENA Euro acad. certs. Pick certificate supplier • Not free choice (m2m) • Must use one of the CAs qualified by the federation • VeriSign qualification planned • Not all cert types from vendor (e.g., Thawte SSL123 online registration vs. standard) • SDSS certs expire 2008, move!

  4. public key in .csr file X.509 certO=SP Ltd.,CN=sp.com(.crt or .pem file) SP Ltd., certificate of incorporation verification CA https://sp.com Get SSL server certificate

  5. Enrol in federation • Send e-mail with: • Acceptance of fed. policy terms & conditions • Entity ID, usually https://sp.com/shibboleth • URL used by IdPs, usually https://sp.com/Shibboleth.sso/SAML/POST • Cert. DN: O=SP Ltd., CN=sp.com • Tech., admin. & support contact details

  6. After acceptance • The supplied data is encoded as XML fragment • Then added to sdss-metadata.xml published on fed. website • Every fed. member regularly downloads own copy of this (you need to do this too, and verify signature!) • Reconfigure default shibboleth.xml configuration file with: • federation and site-specific details • SDSS website has step-by-step instructions for all this

  7. Congratulations • You are now a citizen of the federation! • Any member IdP can now approach your SP: Oxford Uni., or self-reg. Open IdP: it’s your job to grant access (or not) based on who is asking • No legal contract with IdP (or federation). For a contract, make customer sign a licence (probably happens already) • How do you reliably tell where a user is from? Rest of talk…

  8. Controlling access • Simple case: allow any user from a list of licensed institutions • How are institutions identified? Scopes • Federation requires scope for an IdP to be a DNS domain name belonging to the organisation • so Edinburgh University’s scope is ed.ac.uk

  9. Scopes • Are verified by the federation, checked during IdP enrolment. Edinburgh IdP can’t assert ox.ac.uk (& has letter of authority) • Allow SP to identify user’s real-world organisation • Resemble DNS names, but are just strings. So, ed.ac.uk is not equivalent to edinburgh.ac.uk. IdPs must choose one form or the other (otherwise every SP would have to know all variant forms) • Are not hierarchical, so giving access to ed.ac.uk does not automatically grant access to randomproject.ed.ac.uk

  10. member ed.ac.uk eduPersonScopedAffiliation User(Sue) Value(from IdP’s directory entry for Sue) Scope(from IdP’sresolver.xml config file, At SP, scope filtered using metadata fileHTTP_SHIB_EP_AFFILIATION="member@ed.ac.uk"(environment variable) (constructed value)

  11. Affiliation values

  12. Now it’s easy • Parse ePSA environmental back into value, scope • Is scope in “allowed” list for access to resource? E.g., {ed.ac.uk, ncl.ac.uk, lse.ac.uk} • No: redirect to “access refused” page • Is value allowed (member, student, etc.)? • Yes: grant access to resource • No (alum, affiliate): redirect to “access refused” page

  13. Scopes vs. EntityIDs • Scopes enable: • one outsourced IdP to serve many institutions • one IdP with multiple per-user scopes, ed.ac.uk, med.ed.ac.uk, law.ed.ac.uk (SP can discriminate) • multiple college or departmental IdPs within a single institution, without SPs needing to know about them • leverage SP’s intuitive understanding of DNS names • Scope + affiliation allows finer access control: • What if every alumnus has account on institution’s IdP? Do you want them to access your service? Can’t prevent it with authorisation by entityID

  14. Debugging problems • If user hits a Shibboleth access problem: • Look in SP log files, identify problem session • If cause not obvious, talk to IdP. EntityID identifies IdP; timestamp, session id identify opaque user • Organisation name, contact e-mail addresses for IdP entity are in metadata file • IdP needs to help resolve issue (can be made a licence condition) • Federation can’t help much: there is no central point

  15. IdP discovery • SP needs to implement some way to discover an arbitrary user’s IdP • UI may be built in to SP web site, e.g. ScienceDirect • SP that does not DIY can use fed.’s central WAYF as fallback UI (dropdown list of every IdP) • WAYF is unappetising and will become technically untenable with future Shibboleth protocol versions • See Future of Discovery poster for other possibilities

  16. ScienceDirect discovery UI

  17. SDSS WAYF

  18. Recommended attributes • TargetedID allows for personalisation by SP (you know the same user is calling, but not who they are) • Arbitrary entitlements allow part of authz decision to be made by the IdP (by agreement, e.g., EMOL) • Actual identity: principal name, fc@ed.ac.uk: • not (necessarily) an e-mail address • relates user across services (UKDA); less fragile, longer-lived persistent id than TargetedID (Digimap) • requires informed consent from user (data protection) • Other attrs (phone no. etc.) won’t be available from all IdPs

  19. Contacts • SDSS project: http://sdss.ac.uk • Contact: edina@ed.ac.uk

More Related