SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2...
-
Upload
owen-pitts -
Category
Documents
-
view
218 -
download
3
Transcript of SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2...
![Page 2: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/2.jpg)
Background
![Page 3: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/3.jpg)
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
![Page 4: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/4.jpg)
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
![Page 5: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/5.jpg)
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
![Page 6: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/6.jpg)
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
![Page 7: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/7.jpg)
Motivation
![Page 8: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/8.jpg)
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.
![Page 9: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/9.jpg)
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
![Page 10: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/10.jpg)
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
![Page 11: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/11.jpg)
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 (*)
![Page 12: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/12.jpg)
Cautions
![Page 13: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/13.jpg)
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)
![Page 14: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/14.jpg)
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
![Page 15: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/15.jpg)
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
![Page 16: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/16.jpg)
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?
![Page 17: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/17.jpg)
InCommon Support
![Page 18: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/18.jpg)
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
![Page 19: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/19.jpg)
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"> -->
![Page 20: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/20.jpg)
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
![Page 21: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/21.jpg)
Feature Futures
![Page 22: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/22.jpg)
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)
![Page 23: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/23.jpg)
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
![Page 24: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/24.jpg)
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
![Page 25: SAML 2.0 An InCommon Perspective Scott Cantor The Ohio State University / Internet2 cantor.2@osu.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062722/56649f305503460f94c4ad43/html5/thumbnails/25.jpg)
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