OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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]