Intro to Shibboleth and Federation…

1. Intro to Shibboleth and Federation… Ken Klingenstein Director, Internet2 Middleware and Security

2. Shibboleth • An architecture, consisting of both a payload definition (using SAML) of attributes and a set of privacy-preserving methods of exchanging such payloads. • A project that has managed the development of the architecture and code • A code package, running on a variety of systems, that implements the architecture. • Used to form federations…

3. Federations • Persistent enterprise-centric trust facilitators • Sector-based, nationally-oriented • Federated operator handles enterprise I/A, management of centralized metadata operations • Members of federation exchange SAML assertions bi-laterally using a federated set of attributes • Members of federation determine what to trust and for what purposes on an application level basis • Steering group sets policy and operational direction • Note the “discovery” of widespread internal federations

4. Federations … • Might support trust fabric maintenance • Operate a metadata distribution service • Might be the locus for attribute standards • Might be the locus for “minimum but sufficient” IdP and SP operational practice standards • Are not a party to the transactions between IdPs and SPs • Are not involved with entitling access to resources

5. Federated model • Enterprises and organizations provide local LOA, namespace, credentials, etc. • Uses a variety of end-entity local authentication – PKI, username/password, Kerberos, two-factor, etc. • Enterprises within a vertical sector federate to coordinate LOA’s, namespaces, metadata, etc. • Internal federations within large complex corporations have been “discovered”. • Privacy/security defined in the context of an enterprise or identity service provider

6. Federation Value Proposition • Set of cooperating IdPs and SPs forms a community needing agreement on: • Trust Fabric • X.509 certs • IdP and SP identifiers & other metadata • Community standard for attribute semantics • Community standards for IdP and SP operational practices • Strength of authentication • Confidentiality • For N IdPs and M SPs, which is easier? • N*M agreements • N+M agreements

7. Federations and PKI • The rough differences are payload format (SAML vs X.509) and typical length of validity of assertion (real-time vs long-term) • Federations use enterprise-oriented PKI heavily and make end-user PKI both more attractive and more tractable – adding privacy (secrecy), ease of verification, addition of role, etc. • The analytic framework (evaluation methodologies for risk in applications and strength of credentials) and infrastructure developed for PKI is useful for federations. • The same entity can offer both federation and PKI services

8. The Research and EducationFederation Space • Switch, Haka, JISC, BECTA, InCommon, etc. • Inqueue, becoming TestShib • USGov eAuthentication • State of Texas HE federation • Elsevier, OCLC, Lexis, CERN • ….

9. Virtual Organizations • Geographically distributed, enterprise distributed community that shares real resources as an organization. • Examples include team science (NEESGrid, HEP, BIRN, NEON), digital content managers (library cataloguers, curators, etc), a state-based life-long learning consortia, a group of researchers coordinating a launch vehicle payload, etc. • On a continuum from interrealm groups (no real resource management, few defined roles) to real organizations (primary identity/authentication providers) • Want to leverage enterprise middleware and external trust fabrics, as well as support centers

10. Virtual Organizations have… • Real resources that they share and manage • May be computational resources • May be scientific instruments • May be bandwidth • May be shared data and content • Economic data • Museum materials • Cultural and artistic works • A relatively small set of users who tend to travel in common circles • Often the need to have some accounting and regulatory compliance

11. Virtual organizations vary… • By lifetime of VO • Some are relatively short-term, perhaps 1-2 years • Some may persist for extended periods • By size • By cluster – at any one time, 15-20 experiments (virtual orgs) are active at Fermi Lab, CERN. A shuttle launch may need coordination among several vo’s that have equipment aboard. • By type of domain-specific tools • A number are using Grids • A number subscribe to major scientific data streams • Some have no domain-specific tools

12. Federating Software • SAML and Shibboleth • Liberty Alliance crowd…Netegrity, Oblix, Nokia, Chase, etc. • WS-*

13. SAML • Security Access Markup Language – an OASIS standard • SAML 1.0 current eAuth standard; SAML 1.1 widely embedded • SAML 2.0 ratified by OASIS earlier this year • Combines much of the intellectual contributions of the Liberty Alliance with materials from the Shibboleth community – a fusion product • Scott Cantor of Ohio State was the technical editor • Adds some interesting new capabilities, eg. privacy-preservation, actively linked identities • Possibly a plateau product

14. Shibboleth Athenticate at home org Authorize at resource without knowing user’s identity

15. Shibboleth Underpinnings • Elements of shibboleth infrastructure must identify and authenticate each other • Home org or Identity Provider (IdP) pieces • Resource or Service Provider (SP) pieces • Attribute assertions about authenticated principals are sent from IdPs to SPs • For it all to work, IdPs and SPs must agree about which attributes and values are tossed around, and their semantics

16. Shib Timeline • Project formation - Feb 2000 • Inception of SAML effort in OASIS – December 2000 • OpenSAML release – July 2002 • Shib v1.0 April 2003 • Shib v1.2 April 2004 • Shib v1.3 July 2005 – non web services, new fed metadata • Shib v1.3.a Sept 2005 – Federally certified • Shib v 1.3 b - WS-Fed compatible • OpenSAML 2.0 and futures – later camp talks…

17. Shibboleth v1.3 • Released -- July, 2005 • Certified by GSA for governmental use • Major New Functionality • Full SAML v1.1 support -- BrowserArtifact Profile and AttributePush • Support for SAML-2 metadata schema • Improved Multi-Federation Support • Support for the Federal Gov’t’s E-authn Profile • Native Java SP Implementation • Improved build process

18. WS-* • A collective of nine or so protocols and architectures to manage interrealm services • Owned by Microsoft, with subordinate status of IBM and BEA • Complex interactions among a different mapping of the problem space • Some published; some still in the white binder…

19. WS* - Shib Interop • Agreements to build WS-Fed interoperability into Shib • Contracts signed; work underway • WS-Federation + Passive Requestor Profile + Passive Requestor Interoperability Profile • Discussions broached, by Microsoft, in building Shib interoperabilty into WS-Fed; no further discussions • Devils in the details • Can WS-Fed-based SPs work in InCommon without having to muck up federation metadata with WS-Fed-specifics? • All the stuff besides WS-Fed in the WS-* stack

20. Federations Today and Tomorrow • Some countries fully operational • Scope of service varies from R&E to K-12 • Service models – central NREN, national IT, others… • Invites other collaborations • Others in development • VO support available via GridShib, etc.

21. Federation key issues • Peering, peering, peering • At what size of the globe? (Confederation?) How do sectors relate? How to relate to a government federation? • On what issues to peer

22. Other inter-federation issues