SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2

Background

SAML 2.0 Resources InCommon SAML 2.0 FAQ InCommon SAML 2.0 Profiles Specifications and Errata Executive Overview (high-level) Technical Overview (draft, fairly detailed)

Maturity and Initial Feature Set Roughly 6 years old, standardization March 2005 Browser and “smart client” SSO for HTTP apps Logout protocol, primarily for HTTP apps LDAP-like, but more limited, attribute query Management protocol for ID changes and de- provisioning Metadata for configuration / trust management

Post-Standard Additions Metadata profiles and extensions for older protocols, explicit trust management, attaching attributes to IdPs/SPs Protocol for SP-centric browser discovery of IdP Request Initiation protocol to aid cross-org links Expressing delegation of identity in assertions Profiles for combining client PKI and SAML Miscellaneous and sundry:

Backward Compatibility Largely evolutionary design But incompatible with SAML 1.x at an XML and message encoding level Routinely implemented alongside earlier versions in federation endpoints (as in Shibboleth) Also simple to translate between protocols at a gateway, if features are confined to LCD

Motivation

Why Care? You get it for free (nearly) by moving to supported software. Migration isn’t a “big bang” project. Interoperability is an upward curve with SAML 2.0, flat or non-existent with 1.x. Microsoft ADFS 2.0 Facilitates movement toward simpler flows between systems and important new use cases.

Initial “Wins” Front channel only w/o loss of confidentiality Fewer components and less runtime state Avoids mutual SSL authentication configuration Impersonation of production systems via /etc/hosts SP input to Authn/SSO process Tends to be an intra-enterprise requirement Close coordination between SP/IdP Enforcement by application-layer code Custom error handling

Initial “Wins” Improved cross-product interoperability Eliminates most protocol-level problems A “going” concern for at least some vendors, so bugs might get fixed Doesn’t fix metadata/trust management limitations, but may improve for SAML 2.0, won’t for anything else

Longer Term “Wins” Industry “acceptance” of a SAML 2.0 profile consistent with higher ed conventions Capability of consent-based SSO for low assurance, collaborative services Interfederation Additional protocols and scenarios Delegation Identifier management Logout (*)

Cautions

Shibboleth IdP Feature Gaps IdP-initiated SSO Logout, NameID mgmt protocols SAML proxying Attribute query for specific attributes or values Non-exact AuthnContext matching Encryption of individual Attributes Easily adjusting signing/encryption algorithms Inbound artifact binding (message by reference)

Directionality of SSO Large source of hassles for deployers Shibboleth IdPs cannot initiate SAML 2.0 SSO; require a request from an SP (or a request that looks like one) A lot of one-off SPs don’t support issuing requests and require IdPs to push SSO to them Rock, meet hard place Eventual resolution: support for “third party” request extension, plus simple scripts to generate requests

Single Logout Well-defined protocol for front and back channel logout messages Entirely undefined user experience / UI Supported by Shibboleth SP Unsupported by Shibboleth IdP contributed extension from Hungary Rare in one-off implementations Non-existent in alternative protocols

Single Logout Back channel easy to deploy, unusable by many SAML implementations and by most applications Good front channel UI impossible to implement without assuming third party cookie support, and still requires application involvement Is termination of IdP session what you really want?

InCommon Support

Initial Support Site registration wizards extended to include SAML 2.0 profiles and bindings for SSO, Discovery, and Attribute Query Sites “enable” SAML 2.0 by implicitly adding endpoints supporting new bindings SP credentials are assumed to be usable for encryption when SAML 2.0 is enabled Per FAQ, IdPs should enable SSO via Redirect, SPs should enable SSO ACS via POST

Things to Note If you’re migrating an older IdP “in place”, add SAML 2.0 to your metadata only after migration is past the point of no return. Per FAQ, SPs (upgraded or new) MUST do one of: enable SAML 2.0 in their metadata disable use of SAML 2.0 by their SP -->

Future Plans “Wizarding” full range of protocols, options, extensions, future additions is fruitless, limits participant innovation Submission/import/manipulation of XML directly provides complete flexibility, but with definite costs: Shifts technical burden to participant or to TBD tools Needs extensive development and testing to protect metadata from invalidation, maintain federation- managed content, filter extensions InCommon committed to capability, but community testing will be critical

Feature Futures

Consent-Based SSO Move policy, and sometimes trust, decisions to the user Acceptance likely to vary by regulatory regime, organization/culture Absolute necessity for scaling of federation Service is asymmetric in value between user (high) and organization (low)

Consent (Technical Reqs) Expression of service policy/needs during SSO or in metadata Trust decision may be as now or left to user Some decisions on data to provide left to user Attributes? Individual Values? Some left to institutional control? What do users need to decide? Storage and maintenance of user choices

Delegation Beta-level code available now to address multi-tier HTTP applications Federated version of CAS proxy tickets Significant simplification expected for developers in subsequent releases

Interfederation Scale federations beyond national/geographic boundaries Relieve SPs of need to join and contract with a dozen or more federations Insulate from technical details while enabling policy controls Hardest problems seem to be economic