1 / 29

Shibboleth

Shibboleth. Authenticate Locally, Act Globally A Penn State Case Study. Agenda. Shibboleth - Background and Status Technical Review -- how does it work? Shibboleth - Why? Penn State Background “Shibbified” Penn State Applications Integrating Shibboleth with the PSU infrastructure

thad
Download Presentation

Shibboleth

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. Shibboleth Authenticate Locally, Act Globally A Penn State Case Study

  2. Agenda • Shibboleth - Background and Status • Technical Review -- how does it work? • Shibboleth - Why? • Penn State Background • “Shibbified” Penn State Applications • Integrating Shibboleth with the PSU infrastructure • Future

  3. What is Shibboleth? • An initiative to develop an architecture and policyframework supporting the sharing – between domains -- of secured web resources and services • Built on a “Federated” Model • A project delivering an open source implementation of the architecture and framework Deliverables: • Software for Origins (campuses) • Software for targets (vendors) • Operational Federations (scalable trust)

  4. Shibboleth Goals • Use federated administration as the lever; have the enterprise broker most services (authentication, authorization, resource discovery, etc.) in inter-realm interactions • Provide security while not degrading privacy. • Attribute-based Access Control • Foster inter-realm trust fabrics: federations and virtual organizations • Leverage campus expertise and build rough consensus • Influence the marketplace; develop where necessary • Support for heterogeneity and open standards

  5. Attribute-based Authorization • Identity-based approach • The identity of a prospective user is passed to the controlled resource and is used to determine (perhaps with requests for additional attributes about the user) whether to permit access. • This approach requires the user to trust the target to protect privacy. • Attribute-based approach • Attributes are exchanged about a prospective user until the controlled resource has sufficient information to make a decision. • This approach does not degrade privacy.

  6. Stage 1 - Addressing Four Scenario’s • Member of campus community accessing licensed resource • Anonymity required • Member of a course accessing remotely controlled resource • Anonymity required • Member of a workgroup accessing controlled resources • Controlled by unique identifiers (e.g. name) • Intra-university information access • Controlled by a variety of identifiers • Taken individually, each of these situations can be solved in a variety of straightforward ways. • Taken together, they present the challenge of meeting the user's reasonable expectations for protection of their personal privacy.

  7. So… What is Shibboleth? • A Web Single-Signon System (SSO)? • An Access Control Mechanism for Attributes? • A Standard Interface and Vocabulary for Attributes? • A Standard for Adding AuthN and AuthZ to Applications?

  8. Shibboleth Status • Software Availability • Version 1.1 available August, 2003 • Version 1.2 available March, 2004 • Version 1.3 available Summer, 2003 • Target implementation - works with Apache and IIS targets • Campus Adoption accelerating… • Working with second round of information vendors • Java target implementation underway • Work underway on some of the essential management tools such as attribute release managers, target resource management, etc.

  9. Shibboleth Status • Likely to coexist well with Liberty Alliance and may work within the WS framework from Microsoft. • Growing development interest in several countries, providing resource manager tools, digital rights management, listprocs, etc. • Used by several federations today – NSDL, InQueue, SWITCH and several more soon (JISC, Australia, etc.)

  10. High Level Architecture • Federations provide common Policy and Trust • Destination and origin site collaborate to provide a privacy-preserving “context” for Shibboleth users • Origin site authenticates user, asserts Attributes • Destination site requests attributes about user directly from origin site • Destination site makes an Access Control Decision • Users (and origin organizations) can control what attributes are released

  11. Technical Components • Origin Site – Required Enterprise Infrastructure • Authentication • Attribute Repository • Origin Site – Shib Components • Handle Server • Attribute Authority • Attribute Release Policy • Target Site - Required Enterprise Infrastructure • Web Server (Apache or IIS) • Target Site – Shib Components • SHIRE • SHAR • WAYF • Resource Manager

  12. OK, I redirect your request now to the Handle Service of your home org. Please tell me where are you from? I don’t know you. Not even which home org you are from. I redirect your request to the WAYF I don’t know you. Please authenticate Using WEBLOGIN 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 redirect your request to the target, 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 AA Process WAYF Users Home Org Resource Owner Resource

  13. Shibboleth Architecture (still photo, no moving parts)

  14. Attribute Authority --Management of Attribute Release Policies • The AA provides ARP management tools/interfaces. • Different ARPs for different targets • Each ARP Specifies which attributes and which values to release • Institutional ARPs (default) • administrative default policies and default attributes • Site can force include and exclude • User ARPs managed via “MyAA” web interface • Release set determined by “combining” Default and User ARP for the specified resource

  15. Typical Attributes in the Higher Ed Community

  16. Trust, and Identifying Speakers • Federations distribute files defining the trust fabric • Individual sites can create bilateral trust • When a target receives a request to create a session, the Authn Assertion must be signed by the origin (PKI validation), and the origin must be a member of a common Federation. • When an Origin receives a request for attributes, it must be transported across SSL. • The name of the Requestor (from the certificate) and the name of the user (mapped from the Handle) are used to locate the appropriate ARP.

  17. Target – Managing Attribute Acceptance • Rules that define who can assert what….. • MIT can assert student@mit.edu • Chicago can assert staff@argonne.gov • Brown CANNOT assert student@mit.edu • Important for entitlement values

  18. Managing Authorization • Federations will NOT require members to do business with each other • Target manages Access Control Policy specifying • what attributes must be supplied • and from which origins • in order to gain access to specific resources • Rules are attribute based

  19. What are federations? • Associations of enterprises that come together to exchange information about their users and resources in order to enable collaborations and transactions • Built on the premise of • Initially “Authenticate locally, act globally” • Now, “Enroll and authenticate and attribute locally, act federally.” • Federation provides only modest operational support and consistency in how members communicate with each other • Enterprises (and users) retain control over what attributes are released to a resource; the resources retain control (though they may delegate) over the authorization decision. • Over time, this will all change…

  20. Shibboleth -- Next Steps • Full implementation of Trust Fabric • Supporting Multi-federation origins and targets • Support for Dynamic Content (Library-style Implementation in addition to web server plugins) • Sysadmin GUIs for managing origin and target policy • Grid, Virtual Organizations • ? Saml V2.0, Liberty, WS-Fed • NSF grant to Shibboleth-enable open source collaboration tools • LionShare - Federated P2P

  21. Penn State Background • 24 campus locations • Distributed Computing Environment (DCE) • 184,556 Principals • User managed groups • MIT Kerberos V • Fully populated, production 4/1 • IBM’s LDAP 5.1 • eduPerson

  22. Why Shibboleth? • True collaborative effort • Open Source/Open Standards • Solves today’s problems • Leverages existing infrastructure • Authentication agnostic • Emphasis on privacy (FERPA) • Position to co-exist/support other federated identity solutions on the horizon • We like Ken….

  23. Pilot with WebAssign • Summer 2002 • ~ 20 students, 2 weeks, 1 course • Fall 2002 • ~200 students • 3 courses • Spring 2003 • ~1800 students • Successful login: 63,026 • All courses at UP location can use Shibboleth • Now in “Limited Production”

  24. WebAssign • Historically, first two weeks - • 25 to 30 questions/day • Almost all are login problems • This semester - • Numbers of queries in the “Shibbilized” courses …..~1 or 2/day • A reduction of ~85% • Numbers of queries in the normal courses remain at ~15/day

  25. Napster • Requirement to “Authenticate locally, Act Globally”. Sound Familiar…. • Created 2 teams of PSU/Napster staff • MDS • Caching Server, Networking, etc • Authentication/Registrationprocess • Shibboleth

  26. Penn State Origin Site • 7 Origin servers • 2 WebAssign • 5 Napster • Load balance using SLB • Software • Shibboleth 1.1 • Hardware • IBM Blade HS20 proc 2.4GHz mem 2.5Gig

  27. Penn State Origin Site • Currently member of InQueue • Will join InCommon ASAP • Not using WAYF • Used to access external web resources

  28. Future • Shibboleth Meteor Gateway • AT&T Wireless • Use Shibboleth to access PHEAA from student web applications • Use Shibboleth Phase II for non Web applications such as LionShare (P2P) • Continue to pilot with library vendors • Currently working with JSTOR, OCLC • eZProxy • Incorporate University of Michigan’s Cosign (WebISO) with our origin site

  29. THE END • Acknowledgements: • Design Team: David Wasley (U of C); RL ‘Bob’ Morgan (U of Washington); Keith Hazelton (U of Wisconsin (Madison));Marlena Erdos (IBM/Tivoli); Steven Carmody (Brown); Scott Cantor (Ohio State) • Important Contributions from: Ken Klingenstein (I2); Michael Gettes (Duke), Scott Fullerton (Madison) • Coding: Derek Atkins (MIT), Parviz Dousti (CMU), Scott Cantor (OSU), Walter Hoehn (Columbia)

More Related