220 likes | 244 Views
Shibboleth. 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.
E N D
Shibboleth • 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):
Shibboleth - What is it? • an initiative to analyze and develop mechanisms(architectures, frameworks, protocols and implementations) for inter-institutional web access control • facilitated by Mace (a committee of leading higher ed IT architects) and Internet2 • “authenticate locally, act globally” the Shibboleth shibboleth • oriented towards privacy and complements corporate standards efforts • open solution • http://middleware.internet2.edu/shibboleth • vendor participation - IBM et al
Isn’t This What PKI Does? • PKI does 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 • 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...
Related Work • Previous DLF work • http://www.clir.org/diglib/presentations/cnis99/sld001.htm • OASIS Security Services Technical Committee (vendor activity, kicked off 1/2001) • http://www.oasis-open.org/committees/security/index.shtml • http://lists.oasis-open.org/archives/security-services/ • UK - Athens and Sparta projects • http://www.jisc.ac.uk/pub00/sparta_disc.html • Spain - rediris project • http://www.rediris.es/app/papi/index.en.html
Assumptions • Leverage vendor and standards activity wherever possible (OASIS) • (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 • Create a marketplace and reference implementations • Protect Personal Privacy!
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.
Architectural Model • Local Authentication • Local Entity Willing to Create and Sign Entitlement • 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 entitlements against ruleset associated with target object • Cross Domain Trust • Previously created between origin and target • Perhaps there is a contract (information providers..)
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
Shibboleth ArchitectureConcepts (detail) Browser Target Web Server Authorization Phase Authentication Phase Success! Entitlements Attribute Server Ent Prompt Req Ent Second Access - Authenticated Auth OK Pass entitlements for authz decision Web Login Server Redirect User to Local Web Login Pass content if user is allowed Authentication Ask to Obtain Entitlements First Access - Unauthenticated Target Site Origin Site
Charge -- OASIS Security Services Technical Committee • Standardize: • an XML format for "assertions” (authentication, authorization, authorization decision, access yes/no) • (maybe) a (stateless ?) request/response protocol for obtaining assertions • transport bindings for this protocol to HTTP, S/MIME, RMI, etc. • This will be accompanied by requirements/scenarios, compliance info, security considerations, etc • Out of Scope… • How authentication is done • Defining specific attributes (eg “member of community” • Establishing trust between origin and target • Note.. • Inter-product, not explicitly inter-domain
Component Relationship Model TARGET ORIGIN
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
Isn’t This What LDAP Does? • Since this doesn’t exist yet, it can do a lot more than LDAP! (-: • XML is so extensible that this is the last protocol that we’ll ever need! (-: • OK, tell me really….. • The key here is the CONTROLLED dissemination of attribute information, based on multiple factors.
Shibboleth Architecture -- Managing Trust • TRUST Shib engine Attribute Server Target Web Server Browser Target Site Origin Site
Personal Privacy • An Attribute Authority releases Personal Information to site X based on: • Site Defaults • Contract provisions • Business Rules • User control • myAA
Shibboleth vs OASIS Security Effort vs Products • OASIS Security Effort • Defining Standards to support inter-operation of web access control products • Vendor Products • Implement Standards • Add value in Authentication, Attribute Authority, PDP • Shibboleth • Open Source Implementation! • Create Trust Framework • Define Higher Ed specific Attributes • (hopefully) “Where are you from?” service
Campus and Resource Requirements • To Participate in Shibboleth, a site must have: • campus-wide authentication service • campus-wide identifier space (EPPN) • Implementation of Eduperson objectclass • Ability to generate attributes (eg “active member of the community”)
Issues • Personal Privacy (reasonable expectation, laws) • Relation to local weblogin (Single Signon) • Portals • Use of Shibboleth framework by services beyond the web • Grid resources and users
Relationship - Shibboleth to Portals Apps Web Resource Web Res Portal Portal Dir Shibboleth Shibboleth Shibboleth Shibboleth PDP AuthN Dir Web Login
Project Status/Next Steps • Requirements and Scenarios document nearly finished • IBM and Mace-Shibboleth are refining architecture and evaluating issues • IBM intends to develop an Apache web module • Internet2 intends to develop supporting materials (documentation, installation, etc) and web tools (for htaccess construction, filter and access control, remote resource attribute discovery). • Technical design complete - April, 2001 • Coding... • Pilot site start-up - Aug, 2001 • Public demo- Internet2 Fall Member Meeting 2001
Shibboleth, eduPerson, and everything else Middleware Inputs & Outputs Licensed Resources Embedded App Security Grids OKI JA-SIG & uPortal Inter-realm calendaring futures Shibboleth, eduPerson, Affiliated Dirs, etc. Enterprise authZ Campus web sso Enterprise Directory Enterprise Authentication Legacy Systems