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: Re: [security-services] Drafts for review: Kerberos & SAML profiles


Hi Ron,

> Is it too much of stretch to view the principal as the name of the
> shared secret that must be known in order to obtain and use a service
> ticket acquired from the kdc?

I take the view that Scott articulates in his response.

> yes, and I may be over the top wrt to this use-case, but I could see  
> SAML assertions as an XML replacement for kerberos service tickets,  
> where the confirmation method would include the xml equivalent of the
> EncTicketPart of a kerberos service ticket, and the assertion could
> carry various statements, attributes or claims pertaining to the  
> client
> at some target service. The assertion authority would in effect  
> become the kdc; which may or may not be practical, depending on  
> whether ther are sufficient api's and protocols to get tickets form  
> the authority.
> In the past when I looked at this, I wasn't quite sure that it was  
> clear how one would request an assertion for use by principal x at  
> some service y.

The Kerberos S4U extensions (http://msdn.microsoft.com/en-us/library/cc246071(PROT.10).aspx 
) allow this. They are implemented in the KDCs of MIT, Microsoft and  
Heimdal - so the APIs and protocols exist.

I believe that the use of these extensions to effect the scenario you  
describe above is quite practical, and I articulated a possible MEP a  
few weeks ago to this list. Scott observed that, in general, SAML does  
not concern itself with the protocols that are used to obtain data  
from backends (directories, databases, and so forth) and he suggested  
that the MEP should be re-factored into an Attribute Profile that  
could be composed with the SAML Assertion Q/R Protocol.

The Kerberos Attribute Profile draft (http://www.oasis-open.org/committees/download.php/33861/sstc-saml-attribute-kerberos-01.odt 
) allows a SAML Requester to specify the user and service principals  
that a SAML Issuer should provide a service ticket for.

My use-cases for this are to allow a SAML Requester to obtain a  
service ticket that could be subsequently used to access (1) a local  
kerberised service or (2) a remote kerberised service (using raw  
Kerberos or the K5 GSS mechanism - this is out of scope) or (3) a  
remote web service (using the WSS STP).

I'm not sure how the structure that I have in mind (a SAML assertion  
containing one or more statements, one of which is a Kerberos  
attribute statement taking one or more service ticket values) compares  
to the one that you describe above. Would it satisfy your use-case(s)?

best regards, josh.


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