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 Scott Cantor (cantor.2@osu.edu) The Ohio State University and Internet2

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

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 includes 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). 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 element and supporting code in XML libraries. Regular expression matching eliminated to reduce complexity. Supports external references to certificates in file system using.

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 Summary Origin 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 Summary Target 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 Summary Target 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)