[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Solution proposal for W-5: Enhanced SSO Profiles (Updated)
This work item deals with the replacement/enhancement of the SAML 1.1 web browser profiles. It is a substantial and complicated enterprise that needs to be approached in stages. The SAML 1.1 web browser profiles are described entirely within the profile/bindings document. A sequence of canonical HTTP interactions leads a user from a "Source Site" to a "Destination Site". End of story. ID-FF 1.2 describes the profiles with more structure and sophistication. The protocols and schema document describes a pair of generic flows: one from the "Service Provider" to the "Identity Provider", and a second flow that reverses the order of providers. The bindings and profiles document next "maps" these flows into concrete realizations, at least three of which we plan to pursue in SAML 2.0: Browser Artifact, Browser POST, LECP. PROPOSAL: 1. The SSTC continue to work with the structure given in the ID-FF 1.2 materials. In other words, separate generic flows and schema extensions required to support Web SSO and federation from specific technology realizations. 2. Further, the SSTC accept the materials in Section 3.2 of the ID-FF 1.2 Protocols and Schemas document, contingent upon any changes proposed by: (1) W-2: Identity Federation (2) W-2a: SSO with Attribute Exchange (3) W-6: Proxied SSO (4) W-8: Authentication Context Note the following difference in approach between ID-FF 1.2 and SAML 1.1 realizations of an "authentication response": (a) In ID-FF 1.2, each returned Assertion may contain an "InResponseTo" element which must be set to the RequestID attribute of the original <AuthNRequest>. Each individual assertion MUST be signed but the response as a whole does not need to be signed. (b) In SAML 1.1, the "Response" element response includes a "InResponseTo" element which must be set to the RequestID attribute of the original request. Assertions carried within the response do not need to be signed.