Internet Shibboleth Project

  • View
    1.180

  • Download
    3

Embed Size (px)

DESCRIPTION

 

Text of Internet Shibboleth Project

  • 1. Internet2 Shibboleth Project TERENA Networking Conference 2002, Limerick, Ireland RL Bob Morgan, Washington Steven Carmody, Brown Scott Cantor, Ohio State Marlena Erdos, IBM/Tivoli Michael Gettes, Georgetown Keith Hazelton, Wisconsin David Wasley, UCOP ... and many more Ken Klingenstein, Director Internet2 Middleware Initiative

2. Outline

  • BackgroundI2 Middleware Work; Shibboleth Goals, Assumptions, Timelines, Related Works.
  • Shibboleth Basicshow it works; demos.
  • Technical Topics
    • Shibboleth Technical Architecture
    • User and Institutional Attribute Authorities, Resource Managers
    • Applications and ShibbolethEBSCO, NSDL, Meteor, WebAssign
  • Non-technical topics
    • Software licensing and maintenance
    • Marketplace adoptionhigher ed, GXA, Liberty, etc.
    • Club Shib bylaws and operations
  • Wrap-upwhat it buys, and what it costs
  • http://middleware.internet2.edu/shibboleth

3. Interrealm authorization: current approaches

  • Lots of ad hoc, non-scalable, difficult to maintain, and restrictive approaches:
  • Single ID and shared passwords are distributed, perhaps widely, presenting significant accountability risks.
  • Content providers limit access by IP address, leaving campus users on DSL/cable modems at home frustrated
  • Campuses operate proxy services or VPNs that inconvenience users and present performance bottlenecks.
  • Sometimes campuses must load user identities into vendor databases, incurring additional cost, stale data, andpotential privacy violations.
  • Users get new userids and passwords in each realm, incurring huhge overhead (and they often set all their passwords to be the same )

4. Shibboleth Basics

  • Interrealm Attribute-based Authorization for Web Services
  • An initiative to develop an architecture, policy framework, and practical technologies to support inter-institutional sharing of resources
  • Based on a federated administration trust framework
  • Provides the secure exchange of interoperable attributes which can be used in access control decisions
  • Controlled dissemination of attribute information, based on administrative defaults and user preferences
  • Shifts the model from passive privacy towards active privacy
  • Developed with vendor participation - IBM/Tivoli
  • Standards Alignment - OASIS/SAML
  • Open solution (protocols and messages documented rfc-style, opensource implementation available)

5. Founding assumptions

  • Federated Administration Focus on inter-institutional issues, with each enterprise responsible for authentication and assertion of attributes.
  • Create mechanisms for lightweight federation operations.Disturb as littleof the existing campus infrastructure as possible but encourage good campus behaviors
  • Build a system thatsupports security but does not degrade privacy .
  • Leverage vendor and standards activitywherever possible (OASIS/SAML http://www.oasis-open.org/committees/security/ ), but recognize distinctive business needs.
  • Work with widespread campus technologies.
  • Learn through doing There is very little experience with systems that allow users tomanage the release of attribute information.
  • Create a marketplace and reference implementations.

6. Federated Administration

  • Leverage local authentication mechanisms (UID/PW to PKI)
  • Origin Site
    • Must have joined the appropriate communities
    • May have created reasonable default attribute release policies
    • Responsible for initial identification andregistration of users
    • Responsible for managing attributes (eg Affiliation)
    • Responsible for Authenticating users prior to resource access
  • Browser User
    • Only needs to know the name of his/her origin domain
    • May have created specific attribute release policies
  • Target Resource Manager
    • Must have joined the appropriate communities
    • Manage policiesgoverning access to the resource

7. Rethinking Privacy

  • Passive privacy- The current approach.
  • A user passes identity to the target, and then worries about the target s privacy policy.To comply with privacy, targets have significant regulatory requirements. The user has no control, and no responsibility.And no one is happy...
  • Active privacy- A new approach.
  • A user (through their security domain) can release the attributes to the target that are appropriate and necessary. If the attributes are personally identifiable. If the attributes are personally identifiable, the user decides whether to release them. The user has control, along with commensurate responsibility.All parties are happy

8. Attribute-based authorization

  • There is a spectrum of approaches available for attribute-based management of access to controlled resources,
  • At one end is the a ttribute-based approach,where attributes are exchanged about a prospective user until the controlled resource has sufficient information to make a decision. This approach does not degrade privacy.
  • At the other end is the i dentity-based approach,where 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. Since this leads with identity, this approach requires the user to trust the target to protect privacy.

9. 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-campus - crossing political boundaries
    • Controlled by unique identifiers (e.g. name)
  • 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 while respecting the content provider s need foraccountability .

10. Milestones

  • Project formation - Feb 2000 Stone Soup
  • Process - began late summer 2000 with Tivoli commitment (w/Marlena Erdos), project leadership in fall 2000 (w/Steven Carmody), bi-weekly calls to develop scenario, requirements and architecture.
  • Linkages to SAML established Dec 2000 (consistent architecture and distinguished territory)
  • Architecture and protocol completion - Aug 2001
  • Design - Oct 2001
  • Coding began - Nov 2001
  • Alpha releaseApril 2002 (!)

11. Roll-out plan

  • Three coding teams:
  • CMU - origin;IBM/Tivoli - target; OSU - libraries
  • Alpha codeavailablenow
  • Alpha pilotsApril - June
  • Beta code and beta pilotsJune 1 - Sept 1
  • Release September 1 with Apache/modified BSD license
  • Internet2 to operate CVS, bug tracking, etc.

12. Applications and Shibboleth

  • Currently working with:
  • NSDL (National Science Digital Library)
  • EBSCO (and other commercial information providers)
  • Meteor (Student Loan System)
  • WebAssign (Web Based Testing, Physics and Chemistry)

13. Shibboleth: How It Works

  • Technical Components
  • Demo

14. Technical Components

  • Origin Site
    • Handle Server
    • Attribute Authority
  • Target Site
    • SHIRE
    • SHAR
    • WAYF
    • Resource Manager
  • Existing assumed components:
  • for origins - Campus directory or attribute store; Web-ISO
  • for targets - web servers and resource managers

15. GotoTarget, SHIRE

  • Destination site component responsible for context/session establishment
  • Session establishment will commonly rely on traditional techniques (i.e. cookies).
  • With no session in place, the SHIRE knows nothing about the user, so must either ask directly (SHIRE==WAYF) or redirect the user to a location that will ask on its behalf (SHIRE!=WAYF)

16. WAYF Where are You From