Shibboleth

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)