1 / 25

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

SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu. Background. SAML 2.0 Resources. InCommon SAML 2.0 FAQ https://spaces.internet2.edu/display/InCCollaborate/SAML+2.0+FAQ InCommon SAML 2.0 Profiles

dalila
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu

  2. Background

  3. SAML 2.0 Resources • InCommon SAML 2.0 FAQ • https://spaces.internet2.edu/display/InCCollaborate/SAML+2.0+FAQ • InCommon SAML 2.0 Profiles • https://spaces.internet2.edu/display/InCCollaborate/SAML+2.0+Profiles • Specifications and Errata • http://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

  4. 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

  5. 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

  6. 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

  7. Motivation

  8. 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.

  9. 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

  10. 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

  11. 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 (*)

  12. Cautions

  13. Shibboleth IdP Feature Gaps • IdP-initiated SSO • Logout, NameIDmgmt 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)

  14. 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

  15. 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

  16. 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?

  17. InCommon Support

  18. 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

  19. 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"> -->

  20. 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

  21. Feature Futures

  22. 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)

  23. 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

  24. 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

  25. 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

More Related