Reading this thread, am I correct in concluding
that much of what Jeff & Russell require
are in fact implementation-specific?
- Was there any specific changes that need
to be done on the Kerberos attribute profile?
- Is there a need or benefit for the Attribute profile
to support all the Krb related messages/structures
as defined in Section 5 of RFC4120?
/thomas/
__________________________________________
> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:]
> Sent: Thursday, July 01, 2010 4:56 PM
> To: Scott Cantor; 'Josh Howlett'
> Cc: 'Thomas Hardjono'; ;
> 'Russell J. Yount'; Thomas Hardjono;
> Subject: RE: SAML attributes for Kerberos
>
> --On Thursday, July 01, 2010 04:37:10 PM -0400 Scott Cantor
> <> wrote:
>
> >> 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?
> >
> > One issue with that would be the requirement for the SP to have a
> > Kerberos identity that it could use against the IdP. I don't think
> > just shipping the service ticket + key to the SP strictly requires
> > that the SP itself have an independent identity in Kerberos.
>
> No, it shouldn't require that, and even if the SP does have a Kerberos
> identity, there may not be a Kerberos authentication path between the
> SP and IdP. Consider, for example, a case where I operate email
> servers but outsource webmail to a third party. The third party SP
> needs tickets to access my mail servers as the user, but does not
> itself have any relationship with my Kerberos realm (yes, this is a
> contrived example with a number of other practical issues).
>
> -- Jeff
