How about the use case where a user interacts with a browser-based application that triggers a chain of non-browser-based sub-processes, one of which wants to verify the user's authentication before acting on his behalf? In this case, that sub-process might not have access to the authn assertion provided during browser authn/access to the web app, but would be able to initiate a SOAP request to obtain a new assertion.
::Ari
> -----Original Message-----
> From: Scott Cantor [mailto:]
> Sent: Thursday, April 28, 2005 10:38 AM
> To: 'Alistair Young';
> Subject: RE: [saml-dev] AuthnQuery
>
>
> > 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>
>
