RE: [security-services] AuthnRequest Subject vs. NameIDPolicy usa ge

["Scott Cantor" <cantor.2@osu.edu>]

> I assume that since a different format is allowed by 
> specifying a NameIDPolicy Format along with a Subject in an 
> authn request, then the true meaning of matching Subjects 
> (line 2244), means that only the second bullet (related to 
> SubjectConfirmation) of 3.3.4 applies as there is no relation 
> at all in the Subject values sent and received.

Yes, I suppose it's questionable whether referring to that section was all
that helpful here.

> So if a provider handling AuthnRequest msgs recieves both a 
> Subject and a NameIDPolicy, they need to confirm the Subject 
> is the user that is authenticating (or has authenticated) and 
> then return an Assertion Subject with the NameID whose format 
> is defined by NameIDPolicy and with SubjectConfirmation as 
> defined by 3.3.4. (Note that for SSO Profile, 
> SubjectConfirmation would not be included in the requesting Subject).

Well, in core there's no explicit requirement that the "presenter" of an
AuthnRequest be matched against the resulting subject. Typically that is
what you do. If there's some kind of impersonation going on, then there may
be some relationship there, but it may not be one of equality.

The Liberty discovery/security model is something that resembles this
approach. You have an SP/WSC presenting a SAML assertion about the principal
as "evidence" that it has the right to obtain a new assertion for use at a
WSP that also has the principal as the subject. That doesn't use the SAML
2.0 authentication protocol today, but the idea is the same.

But the SSO profile is more constrained. It says specifically that if
there's a Subject in the request, it better be the principal.

-- Scott