240 likes | 256 Views
Shibboleth is an architecture and policy framework that enables the sharing of secured web resources and services across domains. It provides federated administration, attribute-based access control, and support for heterogeneity and open standards.
E N D
Shibboleth Update Michael R Gettes, Duke University On behalf of the shib project team January 28, 2004 TIP2004
What is Shibboleth? (Biblical) • A word which was made the criterion by which to distinguish the Ephraimites from the Gileadites. The Ephraimites, not being able to pronounce “sh”, called the word sibboleth. See --Judges xii. • Hence, the criterion, test, or watchword of a party; a party cry or pet phrase. Webster's Revised Unabridged Dictionary (1913)
What is Shibboleth? (modern era) • An initiative to develop an architecture and policyframework supporting the sharing – between domains -- of secured web resources and services • 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)
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 interrealm trust fabrics: federations and virtual organizations • Leverage campus expertise and build rough consensus • Influence the marketplace; develop where necessary • Support for heterogenity and open standards
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.
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.
How Does it Work? Hmmmm…. It’s magic. :-)
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
Technical Components • Origin Site – Required Enterprise Infrastructure • Authentication • Attribute Repository • Origin Site – Shib Components • Handle Server • Attribute Authority • Target Site - Required Enterprise Infrastructure • Web Server (Apache or IIS) • Target Site – Shib Components • SHIRE • SHAR • WAYF • Resource Manager
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
From Shibboleth Arch doc Origin Target
From Shibboleth Arch doc Origin Target
Local Navigation Page SHIRE 3b 3 1 4 Handle Service Attribute Authority From Shibboleth Arch doc Origin Target
Demo! • http://shibboleth.blackboard.com/
University Resource Provider Local Navigation Page SHIRE 3b Authentication System HTTP Server 3 1 4 Handle Enterprise Service Directory 6 5 Attribute Authority From Shibboleth Arch doc Origin Target 3c
Shibboleth Architecture -- Managing Trust TRUST Shib engine Attribute Server Target Web Server Browser
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
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
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
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?
THE END • Acknowledgements: • Design Team: David Wasley UCOP; 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)