Shibboleth 1.2 Technical Overview “So you thought 1.1 was complicated…”

1. Shibboleth 1.2 Technical Overview“So you thought 1.1 was complicated…” Scott Cantor (cantor.2@osu.edu) The Ohio State University and Internet2

2. Implementation Inputs Attribute Resolution Metadata Trust Metadata Attribute Acceptance Policies Configuration by Relying Party Origin Operational Metadata Target Configuration by Application Attribute Release Policies Revocation Metadata Request Mapping Origin Site Policy Federation / Bilateral / Site Policy Target Site Policy

3. Origin Site Inputs:Attribute Resolution • Mostly similar to 1.1 and backward compatible • JDBC data connector revamped • Pooling fixed • Queries can be parameterized by other data • Large degree of control over result set size • Support for client-side failover/redundancy

4. Origin Site Inputs:Attribute Release Policies • 1.1 ARP expressed in terms of the requesting SHAR’s credential name • 1.2 supports older approach, but uses more abstracted “providerId” identifier for 1.2 requesters, using operational metadata to establish accepted credential names • “Resource” no longer part of the ARP model.

5. Origin Site Inputs:Configuration by Relying Party • New XML-based configuration of software settings, credential lookup, and policy: • Target requests for authentication and attributes mapped to “Relying Party” (1.1 requests map to a default “legacy” section) • Origin can vary key configuration settings on a per-relying-party basis: • Signing Credentials • Name Identifier Format

6. Shared Inputs:Operational/Site Metadata • 1.1 “Sites” format has been extended for 1.2. • Origin-related additions are backward-compatible and ignored by 1.1 targets. • New target-related metadata can be published in separate file for 1.2 origins to consume without affecting 1.1 targets. • Eventually a SAML 2.0-based format will be adopted and will be pluggable into 1.2 via replacement libraries.

7. Operational/Site Metadata Additions • <OriginSite> includes <AttributeAuthority> elements to allow 1.2 targets to properly find and validate the AA to contact. • Target always supported contacting multiple locations for redundancy, but metadata permits origins to actually publish these locations (1.1 origins could only specify one in band). • <DestinationSite> element identifies service providers in federation and identifies: • Assertion Consumer Service (SHIRE) locations • Credential Names usable during attribute queries

8. Shared Inputs:Trust Metadata • 1.2 uses an altered, but similar, XML format as 1.1 • Changes were made to better leverage <ds:KeyInfo> element and supporting code in XML libraries. • Regular expression matching eliminated to reduce complexity. • Supports external references to certificates in file system using <ds:RetrievalMethod>.

9. Shared Inputs:Revocation Metadata • Implementation focus is not on X.509 revocation, but some support is available for loading CRLs during certificate path validation. • CRLs can be placed inside trust metadata files or loaded from the file system. • Large CRL size = terrible OpenSSL performance. • Opportunity for research into OCSP / XKMS, but not really about revocation so much as trust.

10. Target Site Inputs:Request Mapping • Central tension is “integrate vs. duplicate”; strategy moving sharply toward duplication to achieve portability while adding features. • With 1.2, Apache 1.x/2.x and IIS share a common pluggable model for mapping web requests to Shibboleth configuration; Apache commands also supported (and required in some cases). • Control of “protection scope” and session establishment is now fully flexible.

11. Target Site Inputs:Configuration by Application • New XML-based configuration of software settings, credential lookup, and policy: • All browser requests input to RequestMapper to produce an “applicationId” that locates proper configuration. • Target can vary key configuration settings on a per-application basis: • Origin-visible “providerId” (basis of ARPs) • TLS and Signing Credentials (origin uses metadata to validate credentials against requester’s providerId • Metadata to use for sites, trust, revocation • Session behavior, cookie settings • Attributes to request, AAP filtering/export rules to apply

12. Target Site Inputs:Attribute Acceptance Policies • Uses same format as 1.1 • Supports exporting NameIdentifier from selected origins by “Format” • Supports mapping multiple attributes to a single request header

13. Shibboleth 1.2 SummaryOrigin • Architected around multiple 1.2 relying party definitions, with a legacy mode for 1.1 targets. • Does not use trust metadata, X.509 validation still handled by mod_ssl, so trust list is still global (1.3 will complete this transition). • Supports multiple NameIdentifier formats for wider variety of deployments.

14. Shibboleth 1.2 SummaryTarget • Target is multi-federation capable, can select credentials at runtime based on the origin site queried. • All cryptographic checks and validation are done dynamically based on each Application’s configuration. • Extends session model to go beyond vhosts to an “application” model using the Request Mapper to carve up the document space.

15. Shibboleth 1.2 SummaryTarget • Target implementation more C++-oriented, defines abstract plugin APIs for: • Apache/IIS – SHAR communication • Session Caching (and Session ID generation) • Request Mapper • Metadata, Trust, Revocation • AAP • Access Control (preliminary)