RE: Comments on draft-sstc-solution-profile-kerberos-01.pdf

["John Hughes" <john.hughes@entegrity.com>]

Scott,

your reading of the document is correct.

In any case the proposal also suggests that the SAML protocol is extended so
that distinct messages are supported to request an Assertion - or an
Artifact reference


John



> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: 13 January 2004 16:32
> To: 'SAML'
> Cc: 'John Hughes'
> Subject: Comments on draft-sstc-solution-profile-kerberos-01.pdf
>
>
> John,
>
> If my reading of this is correct, what I see you proposing here are four
> variant use cases that all boil down to a credentials converter
> that maps a
> Kerberos ST to a SAML bearer assertion (either by value or reference) that
> fits the existing browser profile semantics.
>
> If I may, I'd like to suggest that a better way to cast such a solution
> would be not so much in terms of an explicit protocol message for this one
> case but as simply an example where the bearer profiles (maybe
> that's even a
> better name than browser profiles?) are used by a client that can
> speak the
> SAML protocol, and happens to authenticate to the SAML authority in a
> particular way.
>
> I'd like to further propose that as we move forward with the SSO
> work item,
> we will find that the proper way to cast the ID-FF AuthnRequest message is
> in the context of the SAML protocol anyway, and that in doing so,
> we end up
> with a samlp:Request message that can be delivered either directly in SOAP
> (Tony's use case, and to a lesser extent, the LECP case) or via a
> dumb HTTP
> client (a browser).
>
> If we think about it this way, I think what we get is a general
> model where
> a single message (roughly an AuthnRequest) can be carried over either
> binding of the protocol and results in the same thing: a bearer assertion
> delivered in a samlp:Response or by single-use reference, the artifact.
>
> The specific case of authenticating the SAML request with
> Kerberos seems to
> be addressable in various obvious ways that would operate at or below the
> SOAP layer, including WSS of course.
>
> -- Scott