shibboleth 1.0: federations, metadata, and trust scott cantor ([email protected]) the ohio state...

Shibboleth 1.0:Federations, Metadata, and Trust

Scott Cantor ([email protected])

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.

Advanced CAMP - July 9-11, 2003 2

From Genesis…


…to Revelation

Trust

Metadata

Site

Metadata

Attribute

Resolution

Metadata

Attribute

Release

Policies

Origin

Origin Site Policy Federation / Bilateral / Site Policy

Target

Attribute

Acceptance

Policies

Target Site Policy

• (signed) XML

• HTTP

• LDAP

• ?


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)


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.”


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


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


Site Metadata: Example

<SiteGroup Name="urn:mace:inqueue"> <OriginSite Name="urn:mace:inqueue:example.edu“

ErrorURL="http://wayf.internet2.edu/InQueue/error.html"> <Alias>Example State University</Alias> <Contact Type="technical" Name="Alfred E. Neuman"/> <HandleService Name="wayf.internet2.edu“

Location="https://wayf.internet2.edu/InQueue/HS“/> <AttributeAuthority Name="wayf.internet2.edu“

Location=“https://wayf.internet2.edu/InQueue/AA“/> <Domain>example.edu</Domain> </OriginSite></SiteGroup>


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


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

Trust Metadata: Example<Trust xmlns="urn:mace:shibboleth:1.0" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <KeyAuthority> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>MIICpDCCAg2gAwIBAgICAm8wDQYJKoZIhvc………………………..</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> <Subject>shib2.internet2.edu</Subject> </KeyAuthority> <KeyAuthority> <ds:KeyInfo> <ds:X509Data>  <ds:X509Certificate>MIICNDCCAaECEAKtZn5ORf5eV288mBle3cAw…………………………</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> <Subject regexp="true">^urn:mace:inqueue:.+$</Subject> </KeyAuthority></Trust>


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


Attribute Resolution Metadata

• Attribute Authority is a “shell” that uses metadata about attributes and Java classes to find user attributes from different sources

<AttributeResolver><SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonEntitlement"><DataConnectorDependency requires="directory"/>

</SimpleAttributeDefinition><JNDIDirectoryDataConnector id="directory">

<Search filter="cn=%PRINCIPAL%"><Controls searchScope="SUBTREE_SCOPE" returningObjects="false" />

</Search><Property name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory" /><Property name="java.naming.provider.url" value="ldap://ldap.example.edu/dc=example,dc=edu" /><Property name="java.naming.security.principal" value="cn=admin,dc=example,dc=edu" /><Property name="java.naming.security.credentials" value="examplepw" />

</JNDIDirectoryDataConnector></AttributeResolver>


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

<AttributeReleasePolicy><Description>Simplest possible ARP.</Description><Rule>

<Target> <AnyTarget/></Target><Attribute name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation"> <AnyValue release="permit"/></Attribute>

</Rule></AttributeReleasePolicy>


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

AAP: Example<AttributeAcceptancePolicy>

<AttributeRule Name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation"

Header="Shib-EP-Affiliation" Alias="affiliation"> <AnySite>

<Value>member</Value><Value>faculty</Value><Value>student</Value><Value>staff</Value><Value>alum</Value><Value>affiliate</Value><Value>employee</Value>

</AnySite></AttributeRule>

<AttributeRule Name="urn:mace:dir:attribute-def:eduPersonPrincipalName"

Header="REMOTE_USER" Alias="user"> <AnySite>

<AnyValue/> </AnySite></AttributeRule>

</AttributeAcceptancePolicy>


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


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.


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.

shibboleth 1.0: federations, metadata, and trust scott cantor ([email protected]) the ohio state...

Documents