[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]