1 / 11

e-Infrastructure Workshop 28 th March 2006, University of Leeds

e-Infrastructure Workshop 28 th March 2006, University of Leeds. Shibboleth Nigel Bruce ISS, University of Leeds N.Bruce@leeds.ac.uk. What is Shibboleth (1).

tavi
Download Presentation

e-Infrastructure Workshop 28 th March 2006, University of Leeds

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. e-Infrastructure Workshop28th March 2006, University of Leeds Shibboleth Nigel Bruce ISS, University of Leeds N.Bruce@leeds.ac.uk

  2. What is Shibboleth (1) • Shibboleth is an initiative to develop an open, standards-based solution to meet the needs for organisations such as Universities to exchange information about their users in a secure and privacy-preserving manner. • It provides the means by which a person using a web browser can be given authorised access to a website using information housed at the user's own institution. • It allows resource providers to easily control access to content based on user characteristics. Moving from identity-based access control to role-based access control. • Not a single product or a piece of software but a set of protocols for the secure exchange of identity information

  3. What is Shibboleth (2) • Devolves the process of authentication and authorisation - thus making it scaleable and manageable. Imagine the administrative overheads without it! • Responsibility of user’s home institution to perform process of authentication. • Responsibility of the service provider to perform authorisation - based on trusted information sent by user’s home institution. • The privacy of the user is safeguarded. User can in theory control what personal information about them is released. Only minimum information required is actually sent. • Unless necessary the service provider shouldn’t be able to track what a user has been accessing. However, some applications may have a requirement to do so.

  4. What is Shibboleth (3) • Uses the Security Assertion Markup Language (SAML) to pass all authN and authZ information. • An open standards-based protocol for securely transferring attributes between user’s home site and the service provider. • HTTP over SSL used to pass identity information • It doesn’t use ‘Web Services’ - doesn’t use SOAP. • NOT an authentication scheme. It relies on home site infrastructure to do this. e.g. at Leeds we use Active Directory for authentication. • NOT an authorisation scheme. Leaves this to the resource provider. The user’s home site merely sends what it knows and allows the SP to make the authZ decisions. • At Leeds University we use LURCIS - a SQL Server based repository as our attribute store. This is fed from SAP HR and our Banner SIMS • LURCIS contains more information about users than we’d ever want to keep in the AD. • Don’t need to extend the schema of your LDAP server to use Shibboleth

  5. ShibbolethMain Components • Two main components to Shib architecture – Identity Providers (IdPs) & Service Providers (SPs). • IdP previously known as a Shibboleth ‘Origin’. • SP previously referred to as a Shibboleth ‘Target’. • IdP is responsible for authenticating users & sending out attribute information. • Shibboleth is very flexible and doesn’t dictate how authentication is actually achieved - LDAP, Kerberos, certificates, CSV. • Once authenticated, IdP generates a pseudonymous token called a ‘Handle’ which is sent to the SP. • SP uses this ‘handle’ to request further information about the user from the IdP (if necessary). • Based on attribute information received, SP then makes an authorisation decision. • For Shibboleth to work the SP and IdP must both be members of the same Federation.

  6. Federations • A federation is not a technological entity. It’s an agreement between organisation where membership is restricted to certain types of organisations, e.g. HE and FE bodies • Members share a common set of agreed policies and rules in order to establish trust between members, e.g. members must ensure that …… • Only legitimate members of their respective institutions get accounts within their Authentication system • Accounts are lapsed within a reasonable timeframe after people leave. • Information held about users within their Attribute Store must be accurate and timely. • Password issuing process and security policies must be acceptable to all Service Providers. • Federations may have a legal status in the future • US HE Federation is called InCommon. UK Universities not allowed to join. • Existing test UK Federations include SDSS and the Athens’ Touchstone • JISC aims to establish a production UK HE Federation in September 2006 • An IdP can be a member of multiple federations. • Federations can be internal to an organisation, i.e. one SP and one IdP within the same University.

  7. Attributes • SPs make authorisation decisions based on attributes released to them. • Federation members must agree on the format of the role-based information that is being passed between them. • EduPerson Object Class has been defined for this purpose. • EduPersonAffiliation, e.g. member, student, faculty, affiliate • EduPersonScopedAffiliation e.g. member@leeds.ac.uk • EduPersonEntitlement, e.g. “EAST1703, EAST1704, EAST1789, etc” (enrolled modules) or “Mechanical Engineering”, “Fine Arts” • EduPersonPrincipalName, e.g. “ecl6nb” • EduPersonTargetID, e.g. “ecl6nb@leeds.ac.uk”, or “6204” • Ideal if all SPs and IdPs within a Federation agreed to use the same type of value. • In principal it’s possible to develop Custom Attribute Processors within the IdP which will send whatever information the SP requires in whatever format they want it. • An IdP can be a member of multiple Federations – each with its own requirements. • Attribute Release Policy – System-wide and user-defined.

  8. OK, I will redirect your request now to the Handle Service of your institution. Please tell me where are you from? I don’t know you. Not even which institution you are from. I will redirect your request to the WAYF Service I don’t know you. Please authenticate 2 3 4 5 6 1 7 Credentials SHIRE HS 8 Handle USER DB Handle Resource Manager Handle 9 AA SHAR OK, I know you now. I will redirect your request to the SP, together with a handle Attributes 10 Attributes I don’t know the attributes of this user. Let’s ask the Attribute Authority Let’s pass over the attributes the user has allowed me to release OK, based on the attributes, I grant access to the resource Shibboleth ArchitectureAcknowledgements to John Paschoud, LSE for this slide WAYF Users Institutional IdP ServiceProvider Resource

  9. GridShib Project • Shibboleth originally envisaged for role-based access control to web-based resources only. • Not inherently suited to Grid users but is now being extended to non-web resources • GridShib is a project which aims to integrate the Globus Toolkit with Shibboleth. See http://gridshib.globus.org/about.html • Consists of plugins for both GT and Shibboleth which enable the Grid SP to securely request user attributes from a Shibboleth IdP. • Attribute information can be pulled by the Grid SP or chosen and intentionally pushed out by the user during the authentication stage, e.g. “Software Developer”, “Chemist”, “Physicist”, etc. • Doesn’t use the Handle Service within Shibboleth for authentication. Instead the PKI certificate is sent and examined by the Attribute Authority • Aim is to make it easier for Grid administrators. Access to resources can be granted on the basis of a user’s role within the VO rather than their specific identity. • WRG members will need to have their own institutional IdP to participate • WRG members will need an IdP for many other reasons, e.g. JISC wants every University to move to Shibboleth by 2008. Will have to pay for Athens after that.

  10. Shibboleth at Leeds • Funding from JISC as an early adopter • Institutional IdP now in production using AthensIM • Plan to move to the Internet2 implementation when Shibboleth version 2 is released. • Fortunate starting position with LURCIS & Active Directory. • Sorting out identity management issues within your institution is the hardest part of implementing a Shib infrastructure. • Leeds is a member of SDSS & Touchstone Federations • We’re also federated with Penn State University • Currently piloting use of Eduserv’s Athens-Shibboleth Gateway. Plan is to go live in September. • Developed a number of resources as Shibboleth Targets, e.g. British Education Index (BEI) & mvForum. • We want to Shibbolise our VLE. • No experience of using Shibboleth in GRID environment.

  11. Shibboleth Questions?

More Related