1. Shibboleth 1.0: Federations, Metadata, and Trust Scott Cantor (cantor.2@osu.edu) The Ohio State University and Internet2 © Scott Cantor 2003. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

2. Advanced CAMP - July 9-11, 2003 2 From Genesis…

3. Advanced CAMP - July 9-11, 2003 3 …to Revelation Trust Metadata Site Metadata Attribute Resolution Metadata Attribute Release Policies Origin Origin Site PolicyFederation / Bilateral / Site Policy Target Attribute Acceptance Policies Target Site Policy (signed) XML HTTP LDAP ?

4. Advanced CAMP - July 9-11, 2003 4 Federations Lots of non-technical definitions, policies, contracts, risk and liability, dispute resolution, etc. In software, federations provide aggregation (and distribution) of machine-readable policy and trust. Scales bilateral agreements to NxN meshes. Software must permit deployments that cross federations (especially for inter- and intra- use)

5. Advanced CAMP - July 9-11, 2003 5 Federations: Technical Layer Control over naming goes hand-in-hand with any form of security. –Naming of sites, system entities, attributes Vouching for and distribution of site and trust metadata offloads significant roles and decisions to the federation as trusted third party. “The powers not delegated to the Federation by the Agreement, nor prohibited by it to the sites, are reserved to the sites respectively.”

6. Advanced CAMP - July 9-11, 2003 6 Federations: Examples InQueue (urn:mace:inqueue) –An insecure testbed for piloting the software in the Internet2 community with selected vendors. –Fairly open membership. InCommon (urn:mace:incommon) –A secure federation (probably a single CA) with light-weight policy obligations of its members. –Relatively restricted membership? ClubBuckeye (urn:mace:osu.edu:shibboleth) –Intra-domain federation of Ohio State sites with a single OSU CA

7. Advanced CAMP - July 9-11, 2003 7 Site Metadata Operational and technical “stuff” to enable the user experience to be as seamless as possible in the face of a dynamic, multi- organizational environment Mix of mandatory site identifying information and informal names, contact and resolution handling pointers Currently in a proprietary XML format, but APIs used between the provider and consumer to hide details

8. Advanced CAMP - July 9-11, 2003 8 Site Metadata: Example <OriginSite Name="urn:mace:inqueue:example.edu“ ErrorURL="http://wayf.internet2.edu/InQueue/error.html"> Example State University <HandleService Name="wayf.internet2.edu“ Location="https://wayf.internet2.edu/InQueue/HS“/> <AttributeAuthority Name="wayf.internet2.edu“ Location=“https://wayf.internet2.edu/InQueue/AA“/> example.edu

9. Advanced CAMP - July 9-11, 2003 9 Site Metadata: Multiple Federations Metadata keyed by site name Any number of metadata sources may be fed into a target as long as each site name is unique across them all Security of metadata is critical, but this is left up to providers

10. Advanced CAMP - July 9-11, 2003 10 Trust Metadata Identifies keys and authorities to use for securing message exchanges between system entities Binds keys to system entities for direct trust Binds PKI authorities to one or more system entities to permit indirect trust Separate from site metadata to more naturally parallel technologies like X.509 Currently in a proprietary XML format, but APIs used between the provider and consumer to hide details

11. Advanced CAMP - July 9-11, 2003 11 Trust Metadata: Example MIICpDCCAg2gAwIBAgICAm8wDQYJKoZIhvc……………………….. shib2.internet2.edu MIICNDCCAaECEAKtZn5ORf5eV288mBle3cAw………………………… ^urn:mace:inqueue:.+$

12. Advanced CAMP - July 9-11, 2003 12 Trust Metadata: Multiple Federations Metadata keyed by system entity name May be provided by federation, but is essentially a distinct function that could be provided by standard operating system services (if they exist) Security of metadata is critical, but this is left up to providers

13. Advanced CAMP - July 9-11, 2003 13 Attribute Resolution Metadata Attribute Authority is a “shell” that uses metadata about attributes and Java classes to find user attributes from different sources

14. Advanced CAMP - July 9-11, 2003 14 Attribute Release Policies Act as a filter on the release of attributes based on the requester’s identity (via SSL) and possibly the resource being accessed by the principal Simplest possible ARP.

15. Advanced CAMP - July 9-11, 2003 15 Attribute Acceptance Policies In a universe of infinite attributes, a target/consumer defines: –the attributes it cares about –is willing to trust specific sites to provide to it –how it wants to consume them A mix of potentially externally imposed policy and local decision-making Currently in a proprietary XML format, but APIs used between the provider and consumer to hide details

16. Advanced CAMP - July 9-11, 2003 16 AAP: Example <AttributeRule Name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation" Header="Shib-EP-Affiliation" Alias="affiliation"> member faculty student staff alum affiliate employee <AttributeRule Name="urn:mace:dir:attribute-def:eduPersonPrincipalName" Header="REMOTE_USER" Alias="user">

17. Advanced CAMP - July 9-11, 2003 17 Shibboleth 1.0 Summary Origin is architected around a single federation, expects to be multi-hosted as workaround Target is considerably but not fully multi- federation capable yet C++ APIs insulate target libraries from the sources of metadata, trust, and attribute policy

18. Advanced CAMP - July 9-11, 2003 18 Shibboleth 1.0 Summary Three system entities require credentials –Handle Service (signs XML) –Attribute Authority (SSL Server, optionally signs XML) –SHAR (Attribute Requester) (SSL Client) Credentials either exchanged in advance via trust metadata or verified via credible authorities Weakness of 1.0 is that SSL exchanges rely on monolithic hierarchical trust that weakens deployment across multiple federations.

19. Advanced CAMP - July 9-11, 2003 19 Liberty ID-FF 1.2 Metadata Latest spec includes an extensive metadata schema for exposing all the operational aspects of a Liberty system entity. Includes a DDDS-based resolution mechanism for finding someone’s metadata. Embeds point to point trust inside the metadata (here’s my public key…) May be donated to SAML 2.0, currently isn’t.