OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]