RE: [saml-dev] AuthnQuery

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

> The <AuthnQuery> message MUST NOT be used as a request for a new 
> authentication using credentials provided in the request
> 
> I'm curious about the "credentials provided in the request" 
> part. Does this mean user credentials, such as username/password?

I'm not so thrilled about that wording now that you quote it, but the gist
is the same as in 1.1, AuthnQuery is not for "authenticating for the purpose
of getting an assertion", it's for asking an authority about a past act.
Whether there's a use case for that is not clear. Some of us have tried and
failed to come up with one, but that's beside your question.

> Could such credentials be sent as part of an <AuthnRequest> message?

I don't think they would be "inside" it, there's never been any place to put
them. That isn't really the idea. The SAML protocol in all its bindings
supports essentially any means of authentication you want below the level of
the SAML message. So it's up to you. If the binding is over HTTP, then you
could do basic-auth, client TLS, etc.

If it's a SOAP binding, then you could do WSS, even authenticating with one
SAML assertion to get another.

> Would that be frowned upon in general, as a Requester would have to get 
> hold of them in the first place.

As I said, there's no place for the "requester" to put them. The "presenter"
of the AuthnRequest, OTOH, is expected to authenticate somehow. That might
be the requester, or it might be a service requesting authentication,
handing the AuthnRequest to the client, who then passes it to the IdP along
with his credentials. That is, essentially, what the SSO profile is.

However, any flow in which the user is expected to give his credentials to
an SP is simply broken. It defeats the entire point of using SAML.

-- Scott