Re: [KAML] Chicago bar-BOF summary

Josh Howlett wrote:
>> The use-cases:
>>
>> 1. Was a smart-card used?
>>     
>
> Just to clarify; is this use-case describing 1) "LoA" for Kerberos or 2)
> extending SAML LoA to permit richer expressions?
>   
If you're asking about expressing LoA as attributes or in the
SAML authentication context I guess it depends on who is
consuming the LoA.
>  
>   
>> 2. The standarized PAC
>>
>> An AD domain controller includes data about the groups a user 
>> is a member of in the PA-DATA field of the KDC-REP. A 
>> generalization of this concept might be to include a SAML 
>> authentication response in the PA-DATA.
>>     
>
> ...presumably this could be further generalised to allow assertions in
> general, or even lower-level constructs such as an artifact (pointing to
> an assertion)?
>   
That would be my hope too.
>   
>> Hope this is enough to get things started. I know the
>> smart-card use- case was discussed on the heimdal 
>> list (although possibly not in the generality I 
>> presented above). Other use-cases have been discussed
>> on other lists.
>>     
>
> I'm curious whether we can use SAML, and the trust fabrics that are
> realised through SAML federation metadata, to support some kind of
> cross-realm Kerberos operation - perhaps using a SAML-based profile for
> inter-KDC communication (following PKCROSS' example)?
>
> The use-case would be a visitor requiring access to some local
> Kerberos-protected network resource, but no local credentials.
>   
Did you read draft-sakane-krb-cross-problem-statement? It looks
like you may be describing something related to 5.6 (in version 03)
> However, such a profile might also provide a way to avoid using the Web
> SSO Profile (in a browser context, obviously) and therefore side-step
> the associated IdP "discovery problem". The browser could authenticate
> using Negotiate (anonymously/pseudonymously) to the SP; authorisation
> could subsequently be performed using the familiar SAML-based
> mechanisms; perhaps boot-strapped through an artifact returned in the
> PAC (which is used as the discovery 'cue').
>
> best regards, josh.
>   
I guess its not so much side-stepping IdP discovery as it is using
the IdP discovery which has already happened. When the user
logs into the workstation she typically has to pick a realm to
authenticate to which is a form of IdP discovery - the metadata
beeing the DNS SRV records pointing to the KDC.

    Cheers Leif


_______________________________________________
KAML mailing list
KAML@ietf.org
https://www1.ietf.org/mailman/listinfo/kaml