RE: [security-services] RE: AuthenticationMethod / NameIdentifier andKerberos authentication

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

> As it is currently used, AuthnRequest allows a requestor to ask that some
> other entity (generally that presenting the AuthnRequest)b eauthenticated.
> If some entity (client or otherwise) is going to use a Kerberos ticket to
> authenticate to a SAML Authority, the AuthnRequest will have been composed
> by some other entity (the eventual relying party of the assertion) but
> likely presented by the Kerberos client.

That's one possibility, but it's equally possible for a client to create
it's own AuthnRequest and send it. The message is designed to support either
approach, because it is separate from the means you use to authenticate the
client to the SAML authority, which is where the real security bits for the
issuing of the assertion take place.

Any use case in which the client authenticates to something and gets back a
SAML assertion for itself is essentially the "credentials collector" use
case. An example is the browser profile (and the profiles in 1.1), even
though we never described it in those terms.

As to the rest, I agree that it sounds like while you *could* put preauth
information into RequestedAuthnContext, it can't be trusted or verified
against the ticket used to authenticate to the authority, so that seems like
a bad idea. If you put it there, it would be to say to the authority that
you *want* an assertion only if the AuthnContext matches that pre-auth type,
which is perfectly reasonable, but there has to be an independent way of
determining that.

-- Scott