Shibboleth: Overview and Status

1. Shibboleth:Overview and Status • The Shibboleth Architecture Team Shibboleth:Overview and Status

2. Shibboleth Shibboleth http://middleware.internet2.edu/shibboleth

3. Introduction to Shibboleth • Shibboleth - What is it? Why? • Design Choices in Shibboleth • Internet2, MACE, NMI, SAML, Oasis, and XML • Project Status • For More Information…... • Addenda…... • What Will it be Like to Use Shibboleth? • Boxes and Arrows (Just How Does it Work?) • Club Shib (the Policy Side)

4. Shibboleth - What is It? • An initiative to develop an architecture, policy framework, and practical technologies to support inter-institutional sharing of resources • Facilitated by Internet2 and I2/Mace (a committee of leading higher ed IT architects) • Vendor participation - IBM/Tivoli • Standards Alignment - OASIS/SAML • Open solution(protocols and messages documented rfc-style, open source implementation available)

5. Shibboleth - What is it? • Will provide for the secure exchange of interoperable attributes which can be used in access control decisions • Oriented towards privacy (CONTROLLED dissemination of attribute information, based on multiple factors.) and complements corporate standards efforts • Federated Administration • Requires Trust Framework

6. Shibboleth - Why is it Needed? • Growing interest in collaboration and resource sharing among institutions • Provides ability to make access control decisions in a cross domain environment • Current approaches to problem (IP address filtering, identity matching, use of shared ids) have serious problems • Shibboleth will involve more than the architecture/implementation developed by the SAML participants (eg policy, trust, tribes)

7. Shibboleth - Why is it Needed? • Managing Privacy becoming more important • More mature understanding of meaning of privacy in this context • Managed dispersal of personal attribute information • Role of “discretion” • Higher Ed has privacy obligations • “FERPA” allows students to control release of attribute information (in some situations) • PKI isn’t ready

8. Assumptions • Leverage vendor and standards activity wherever possible (OASIS/SAML http://www.oasis-open.org/committees/security/ ) • Federated Administration • (Initially) disturb as little of the existing campus infrastructure as possible • Work with common, minimal authorization systems (eg htaccess) • Encourage good campus behaviors • Learn through doing • There is very little experience with systems that allow users to manage the release of attribute information • Create a marketplace and reference implementations • Protect Personal Privacy!

9. Stage 1 - Addressing Three 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) • 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.

10. Architectural Model • Browser User’s Origin Site Responsible for Authentication • Origin Site Entity Willing to Create and Sign Assertions • Set of assertions about the user (Attribute/value pairs) • User has control over disclosure • Identity optional • “active member of community”, “Associated with Course XYZ” • Target responsible for Authorization • Rules engine • Matches contents of assertions against ruleset associated with target object • Cross Domain Trust • Implemented by tribes • Previously created between origin and target • Perhaps there is a contract (information providers..)

11. Authorization Attributes • Typical Assertions in the Higher Ed Community • EPPN=gettes@georgetown.edu • “active member of the community” • “active in course X” • member of group “georgetown.giia” • ? • Signed by the institution! (optional in OASIS, required in Shib) • Other Possible Types of Assertions • UserEligibleContracts=“1739,2408” • Eligibility=“YES” (presumably derived from policy evaluation at the AA)

12. Implications of Shibboleth Design Choices • Support all 3 scenarios (not just the library problem) • -> need a mechanism to manage attribute release • Focus on Privacy Protection • Both sites and users need to manage attribute release • Assume Origin Site Authenticates User • Origin Site needs enterprise level authentication mechanism • Should have Web Single Signon system • Target Site Authorizes User • Need Trust Framework • Need agreement on syntax and semantics of attributes (eduPerson, custom agreements between pairs of sites) • Alignment with SAML • Vendor products may work within Club Shib

13. Federated Administration • Origin Site • Must have joined the appropriate tribes • May have created “reasonable” default attribute release policies • Responsible for Identifying and registering users • Responsible for Authenticating users • Browser User • May have created specific attribute release policies • Target Resource Manager • Manage policies governing access to the resource

14. Don’t Wait for Widespread PKI Deploy • PKI could do some of this and a whole lot more; as a consequence, PKI does very little right now • End-to-end PKI fits the Shibboleth model, but other forms of authentication do as well • Shibboleth uses a lightweight certificate approach for inter-institutional communications - uses the parts of PKI that work today (server side certs) and avoids the parts of PKI that don’t work today (eg client certs). • Allows campuses to use other forms of authentication locally • May actually have benefits over the end-user to target-site direct interactions...

15. Internet2, MACE, NMI, SAML, Oasis, and XML • Internet2 - Active in Several Areas • Network (Abilene) • Middleware • Applications • Middleware - MACE • Steering committee for mware activities • Initiate, review, track mware projects • Evangelize "architecture" issues • Establish "shared state" on complex topics • Create liaisons with European peers, "Grid" workers, Educause, etc

16. Internet2, MACE, NMI, SAML, Oasis, and XML • I2-MI Process • Standardization, best practice, integration • IETF-inspired: open, solution-oriented, energy-driven, self-organizing • Technical working groups with lists, phone calls, home pages, documentsI2 supplies flywheel, scribing support • Capture that thought!

17. What is the NMI? • NSF award for integrators to • Globus (NCSA, UCSD, University of Chicago, USC/ ISI, and University of Wisconsin) • Internet2, EDUCAUSE, and SURA • Build on the successes of the Globus project and the Internet2/MACE initiative • Multi-Year Effort • A practical (deployment) activity that necessitates some research • Separate awards to academic pure research “throw it long” components • http://archives.internet2.edu/guest/archives/I2-NEWS/log200109/msg00007.html

18. The Problem We’re Trying To Solve... • To allow scientists and engineers the ability to transparently use and share distributed resources, such as computers, data, and instruments • To develop effective collaboration and communications tools such as Grid technologies, desktop video, and other advanced services to expedite research and education, and • To develop a working architecture and approach which can be extended to Internet users around the world. • Middleware is the stuff that makes “transparently use” happen, providing consistency, security, privacy and capability

19. What Outcomes is it Trying to Achieve? • A model for managing • directories • identity • meta-directories • security • authentication • authorization • services • A model for achieving interoperability • A model for building applications

20. SAML in One Slide • Security Assertion Markup Language • specification from OASIS Security Services TC • supports interop among "web access management" products and deployments; other functions too • defines Assertions in XML for carrying Authentication, Attribute, Authz Decision statements • defines simple XML request/response protocol • bindings to common transports: HTTP, SOAP • could be security syntax for other XML-based protocols

21. SAML Scope, Structure • XML-format Assertions as fundamental tech • used for core authn/authz purposes • exchange of security info between systems/domains • also reusable for other XML-based assertions • e.g. OASIS XACML (ACLs in XML, sort of) TC • Bindings are where "security" lives • e.g., protection with SSL or XML-DSIG • Profiles specify use in application scenarios • e.g., web browser sign-on scenario

22. Project Status • Architecture definition finished (v0.9) • Design/Programming Stage had been delayed 90 days • Design/Programming now Underway • Team membership drawn from IBM/Tivoli, CMU, Ohio State • First Face-to-Face meeting on Sept 27, 28 at CMU • First Set of Pilot Sites Selected • Chosen to test all 3 scenarios • UK participation • Code Deployed to First Pilot Sites at end of January, 2002

23. Profile of Pilot Sites • Member of campus community accessing licensed resource • University hosting licensed DBs accessed from other universities • Talking to several commercial vendors (they need “their customers” asking for this functionality…) • Member of a course accessing remotely controlled resource • Web based testing • Clearinghouse for curriculum packages • Web based tools used in courses • Member of a workgroup accessing controlled resources • Multi-institution project teams • Are you interested in being a pilot? Email to mace-shib-comments@internet2.edu

24. For More Information….. • Project Web Site • http://middleware.internet2.edu/shibboleth/ • Shib Architecture - v3 (posted this afternoon) • Project Presentations- I2 Fall Member Meeting (video and slides) • http://www.internet2.edu/activities/html/vimm-middleware.html • What Will it be Like to use Shibboleth • Slides further along in this stack

25. Addenda….

26. Shibboleth ArchitectureConcepts - High Level Browser Pass content if user is allowed Target Web Server Authorization Phase Authentication Phase First Access - Unauthenticated Target Site Origin Site

27. Shibboleth Architecture - Components and Flow

28. Descriptions of services • (1) resource manager - may serve as control points for actual web page access • (1a) SHIRE - • (2) Where are you from service - one possible way to direct external users to their own local authn service • (3) handle service - • (3a) web login - typically works with local authn service to provide web single sign-on • local authn server - assumed part of the campus environment • (3c) SHAR - Shibboleth Attribute Requestor - used by target to request user attributes • (4) attribute authority - assembles/disassembles/validates signed XML objects using attribute repository and policy tables • attribute repository (DB) - an LDAP directory, or roles database or….

29. What Will it be Like to Use Shibboleth? • Sample Browser Screens are available at: • http://middleware.internet2.edu/shibboleth/mockups/index.html

30. Use - Go Directly To Target

31. Use - Specify Origin Site

32. Use - Local Authentication

33. Use - Target Page Displayed!

34. Use - Local Navigation Site

35. Use - “in the background”

36. Use - Target Page Displayed!

37. Club Shib (the Policy Side) • See slides at I2 Fall Meeting (Klingenstein)