[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: SAML attributes for Kerberos
On 1 Jul 2010, at 18:20, Jeffrey Hutzelman wrote: > We're specifically looking at a multi-tier system in which an SP > needs Kerberos credentials in the user's name for some backend > service. By "credentials" here, I mean a ticket plus the > information the SP needs to use that ticket in the role of a client; > most notably, the session key. The required credentials must be > forwarded to the SP by the IdP, only when a user attempts to use the > service in question and according to policy set at the IdP. Using > S4U2Proxy at the SP is not an acceptable solution That's not what I was suggesting; but I agree that the IdP should mediate the credential request/response and that the IdP <-> KDC interaction is immaterial (S4U or otherwise) and should be decoupled form the SP <-> IdP exchange. > Fortunately, Kerberos does provide a standardized way of conveying > credentials from one place to another, in the form of the KRB-CRED > message. This is described in RFC4120, sections 3.6 and 5.8. > Unfortunately, construction of a correct KRB-CRED message requires > encryption of some parts of the message, using a Kerberos enctype > and a key shared by the two parties involved; in this case, the IdP > and SP. This poses an interesting challenge if there is not already > a shared secret; for example, if the IdP and SP are operated by > different members of a federation. However, I'm confident we can > find a solution. Scott's proposal sounds very practical if it is reasonable for the parties to obtain the key in the way he suggests. Alternatively, use HTTP Negotiate and the K5 mechanism at the transport layer during the SP's request to the IdP in order to establish the key? josh.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]