Re: [security-services] Correction to my diatribe about assertion Subjects on last call

["Tom Scavo" <trscavo@gmail.com>]

On Thu, Nov 20, 2008 at 1:08 PM, Scott Cantor <cantor.2@osu.edu> wrote:
>
> So, the old profile DOES requires that every assertion returned refers to
> the same principal. Obviously the HoK profile should do the same, and I
> would suggest that it explicitly copy that text if it didn't already.

Makes sense.

> - 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.
>
> - 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.

All of that seems quite reasonable.  Things seem to get complicated,
however, when the request has an explicit <Subject> element.  What
happens, for example, if the request contains a holder-of-key
<SubjectConfirmation> element in ordinary Web Browser SSO or a bearer
<SubjectConfirmation> element in HoK Web Browser SSO?  In the latter
case, that seems to say that both bearer and holder-of-key
<SubjectConfirmation> elements MUST be included.

> I would suggest that the HoK profile use essentially the same language, just
> s/bearer/holder-of-key/g, and I'll leave it to Nate/Tom to work out the
> right way to tie that notion of HoK to the HoK profile.

I think it's really quite simple.  Using the text above as starter text:

"Any assertion issued for consumption using this profile MUST contain
a <saml:Subject> element with at least one <saml:SubjectConfirmation>
element containing a Method of
urn:oasis:names:tc:SAML:2.0:cm:holder-of-key.  Moreover, that
holder-of-key <saml:SubjectConfirmation> element MUST conform to the
SAML V2.0 Holder-of-Key Assertion Profile [ref].

If the request does not contain a <saml:SubjectConfirmation> element,
then every holder-of-key assertion in the response MUST contain a
<ds:X509Certificate> element as specified in [ref].  If, on the other
hand, the request contains an explicit <saml:SubjectConfirmation>
element, then every holder-of-key assertion in the response MUST
contain a <saml:Subject> element that strongly matches the
<saml:Subject> element in the request."

> While it might be nice to try to simplify the AuthnStatement rules, I think
> frankly it's more work than it's worth to come up with the right language,
> so my suggestion is just to drop it and copy the original (errata) text.

Agreed.

Thanks,
Tom