SAML 2.0An InCommon Perspective

Scott CantorThe Ohio State University / Internet2

cantor.2@osu.edu

Background

SAML 2.0 Resources

InCommon SAML 2.0 FAQhttps://spaces.internet2.edu/display/InCCollaborate/SAML+2.0+FAQ

InCommon SAML 2.0 Profileshttps://spaces.internet2.edu/display/InCCollaborate/SAML+2.0+Profiles

Specifications and Erratahttp://saml.xml.org/saml-specifications

Executive Overview (high-level)http://www.oasis-open.org/committees/download.php/13525

Technical Overview (draft, fairly detailed)http://www.oasis-open.org/committees/download.php/14361

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:

• http://wiki.oasis-open.org/security

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• https://wiki.aai.niif.hu/index.php/Single_Logout_in_Shibboleth_IdP

• 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

<!-- <SessionInitiator type="SAML2"> -->

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• https://spaces.internet2.edu/x/n4Sg

• 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