Upload
owen-pitts
View
216
Download
3
Embed Size (px)
Citation preview
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