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

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

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

Scott, thanks for the clarification.

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.

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

I would now agree with your sentiment that we should not contrain this in any way; even for the SSO profile.

Tom.

-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu]
Sent: Friday, June 03, 2005 1:32 PM
To: 'Thomas Wisniewski'; 'SAML'
Subject: RE: [security-services] AuthnRequest Subject vs. NameIDPolicy usage

> 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