RE: SAML attributes for Kerberos

[Thomas Hardjono <hardjono@MIT.EDU>]

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:jhutz@cmu.edu]
> Sent: Thursday, July 01, 2010 4:56 PM
> To: Scott Cantor; 'Josh Howlett'
> Cc: 'Thomas Hardjono'; security-services-comment@lists.oasis-open.org;
> 'Russell J. Yount'; Thomas Hardjono; jhutz@cmu.edu
> Subject: RE: SAML attributes for Kerberos
> 
> --On Thursday, July 01, 2010 04:37:10 PM -0400 Scott Cantor
> <cantor.2@osu.edu> 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