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

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

> All, I'm trying to understand Profiles section 4.1.4.1 
> (<AuthnRequest> Usage). Specifically the fact that Subject is 
> allowed and how this related to NameIDPolicy.  I assume the 
> reason Subject is allowed is to because the requesting 
> service provider may know the subject's identity and wants 
> the identity provider to match this against the user being 
> authenticated.

Possibly, but it's perfectly legal to build an environment that allows SPs
to ask for assertions about other people. I don't know whether anybody
would, but it's not outlawed.

Subject is really there because my goal for the protocol was to be able to
reasonably tailor an assertion, and obviously Subject is one of the things
worth tailoring.

> It would seem that this should imply that 
> NameIDPolicy's Format and SPNameQualifier attributes MUST be 
> omitted in this case. The AllowCreate attribute could be used 
> as it currently is. Is that the intent? If not and both are 
> used such that the Format and/or SPNameQualifier attributes 
> are defined in both (and of course possibily different), what 
> would be the processing rules?

This is already in core, line 2244:

"If the <saml:Subject> element in the request is present, then the resulting
assertions' <saml:Subject> MUST strongly match the request <saml:Subject>,
as described in Section 3.3.4, except that the identifier MAY be in a
different format if specified by <NameIDPolicy>. In such a case, the
identifier's physical content MAY be different, but it MUST refer to the
same principal."

The point was to enable a request to say "I know this ID for the principal,
but I'd like the assertion to give me a different type of ID for the same
one."

It allows name mapping to happen during authentication, to some degree. One
use case:

An SP wants to access a web service on behalf of a principal, but the web
service only knows the user's identity in terms of a federation between it
and the IdP. So the SP needs an encrypted "persistent" NameID with
SPNameQualifier set to the web service, when all it has is the ID it knows.

With this, you can do that. At least you can if you define the billion other
things involved in such a use case. But it's a building block.

> I'm proposing that these two attributes in NameIDPolicy not 
> be used when using Subject.

I wouldn't favor that, it definitely wasn't my intent.

As Rob noted, if somebody wants to constrain the browser SSO profiles,
that's fine, but I'm inclined to term it more "are there aspects of this
protocol that should be optional for SPs and IdPs to support in those
profiles?" I was fully willing to do that, but I think the problem is nobody
spent the time to really investigate what the protocol could do.

I think with the enhanced client profile, and others one could imagine,
we'll see people that want to do this sort of stuff. If not, I think all
that WS-* stuff must be a giant waste of time, since it claims to tackle
many of the same use cases. It's a "many to many" translation model instead
of a "many to SAML" model.

-- Scott