RE: [security-services] Adjusted PE text for SSO profile

[Thomas Wisniewski <Thomas.Wisniewski@entrust.com>]

Title: RE: [security-services] Adjusted PE text for SSO profile

Scott, a couple of comments below.

Tom.

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Wednesday, August 17, 2005 10:35 AM
> To: security-services@lists.oasis-open.org
> Subject: [security-services] Adjusted PE text for SSO profile
>
>
> This is mostly the same as my original proposal plus some
> clarifications
> after email with Brian. One is fixing a typo (s/of/or). Along
> with that, I
> cleaned up some language around use of Issuer so that if you
> did sign the
> response, it must be included.
>
> The other I need to get confirmation on from the TC, but I
> don't remember
> whether we intended that you HAD to sign the assertions
> directly, or whether
> signing the response was allowed. I know we *permit* only signing the
> assertion(s), but I originally told Brian that I thought we
> meant to force
> it. Now that I re-read it, I think I'm mis-remembering.
>
> -- 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 issuing
> identity provider;
> the Format attribute MUST be omitted or have a value of
> urn:oasis:names:tc:SAML:2.0:nameid-format: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 and assertions without a bearer
> <SubjectConfirmation> MAY be included; processing of
> additional assertions
> or <SubjectConfirmation> elements is outside the scope of
> this profile.

Perhaps move the statement "assertions without a bearer subj conf MAY be included" along with "... Processing of additiona assertions ... is outside the scope of this profile" to its own paragraph. It doesn't seem to fit well in the above paragraph.

>

Change the first line below to be "At least one bearer ..."

Also, it's not clear what "intended for consumption using this profile" implies or adds to context. We are saying that at least one must pass the rules specified. So either one passes or it none of them pass. There is no way to know that if one passes and one does not, for example, that the one that passed was NOT intented for this profile and the one that didn't pass was intended for this profile. I would suggest removing this phrase.

> . A bearer <SubjectConfirmation> element intended for
> consumption using this
> profile MUST contain a <SubjectConfirmationData> element that
> contains 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 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."
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all
> your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php
>