[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft #4 text for SSO profile
Another suggestion from Brian to clarify that multiple assertions must have the same issuer. I'm now labeling with numbers. No more "Final" until it's voted in. Also, pending a discussion on the call, I'm including a clarification to the signing rules that make it explicitly legal to sign the Response when using POST. I can't see any rationale for thinking we meant to insist on the assertion being signed directly, although we *permit* that now without signing the Response, unlike in 1.x. -- Scott Suggested clarifications to Profiles: Section 4.1.4.2, <Response> Usage, replace the list at lines 541-572, with the following list: . If the response is unsigned, the <Issuer> element MAY be omitted, but if present (or if the response is signed) it MUST contain the unique identifier of the issuing identity provider; the Format attribute MUST be omitted or have a value of urn:oasis:names:tc:SAML:2.0:nameid-format:entity . It MUST contain at least one <Assertion>. Each assertion's <Issuer> element MUST contain the unique identifier of the responding identity provider; the Format attribute MUST be omitted or have a value of urn:oasis:names:tc:SAML:2.0:nameid-format:entity. Note that this profile assumes a single responding identity provider, and all assertions in a response MUST be issued by the same entity. . If multiple assertions are included, then each assertion's <Subject> element MUST refer to the same principal. It is allowable for the content of the <Subject> elements to differ (e.g. using different <NameID> or alternative <SubjectConfirmation> elements). . Any assertion issued for consumption using this profile MUST contain a <Subject> element with at least one <SubjectConfirmation> element containing a Method of urn:oasis:names:tc:SAML:2.0:cm:bearer. Such an assertion is termed a bearer assertion. Bearer assertions MAY contain additional <SubjectConfirmation> elements. . Assertions without a bearer <SubjectConfirmation> MAY also be included; processing of additional assertions or <SubjectConfirmation> elements is outside the scope of this profile. . At lease one bearer <SubjectConfirmation> element MUST contain a <SubjectConfirmationData> element that itself MUST contain a Recipient attribute containing the service provider's assertion consumer service URL and a NotOnOrAfter attribute that limits the window during which the assertion can be delivered. It MAY also contain an Address attribute limiting the client address from which the assertion can be delivered. It MUST NOT contain a NotBefore attribute. If the containing message is in response to an <AuthnRequest>, then the InResponseTo attribute MUST match the request's ID. . The set of one or more bearer assertions MUST contain at least one <AuthnStatement> that reflects the authentication of the principal to the identity provider. Multiple <AuthnStatement> elements MAY be included, but the semantics of multiple statements is not defined by this profile. . If the identity provider supports the Single Logout profile, defined in Section 4.4, any authentication statements MUST include a SessionIndex attribute to enable per-session logout requests by the service provider. . Other statements MAY be included in the bearer assertion(s) at the discretion of the identity provider. In particular, <AttributeStatement> elements MAY be included. The <AuthnRequest> MAY contain an AttributeConsumingServiceIndex XML attribute referencing information about desired or required attributes in [SAMLMeta]. The identity provider MAY ignore this, or send other attributes at its discretion. . Each bearer assertion MUST contain an <AudienceRestriction> including the service provider's unique identifier as an <Audience>. . Other conditions (and other <Audience> elements) MAY be included as requested by the service provider or at the discretion of the identity provider. (Of course, all such conditions MUST be understood by and accepted by the service provider in order for the assertion to be considered valid. The identity provider is NOT obligated to honor the requested set of <Conditions> in the <AuthnRequest>, if any. In Section 4.1.4.3, <Response> Message Processing Rules: Line 576, change "any bearer" to "the bearer" Line 578, change "any bearer" to "the bearer" Line 583, change to: "Verify that any assertions relied upon are valid in other respects. Note that while multiple bearer <SubjectConfirmation> elements may be present, the successful evaluation of a single such element in accordance with this profile is sufficient to confirm an assertion. However, each assertion, if more than one is present, MUST be evaluated independently." Line 584, change "any bearer" to "the bearer" Append to paragraph ending on line 591: "Note that if multiple <AuthnStatement> elements are present, the SessionNotOnOrAfter value closest to the present time SHOULD be honored." Section 4.1.4.5, POST-Specific Processing Rules: Replace lines 600-601 with: "If the HTTP POST binding is used to deliver the <Response>, each assertion MUST be protected by a digital signature. This can be accomplished by signing each individual <Assertion> element or by signing the <Response> element."
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]