>>>>> "Cantor," == Cantor, Scott <[email protected]> writes:
Cantor,> On 10/18/11 5:57 PM, "Sam Hartman" <[email protected]> wrote:
>>
>As a recollection while working on draft-hartman-gss-eap-naming which
>> became draft-ietf-abfab-gss-eap-naming I introduced the concept
>> of a naming extensions context. The idea is that two attributes
>> are different depending on some broad context of their
>> interpretation. The idea is for example that Kerberos attributes
>> in an enterprise context probably want to be interpreted
>> differently than SAML attributes in a federated context.
Cantor,> And I think the proposal is that the context appear inside
Cantor,> the naming extension attribute name as a modifier?
Right.
>> It's probably a different context if you have third-party
>> assertions including attribute query results or somehow multiple
>> authentication statements.
Cantor,> My current implementation of that doesn't distinguish that
Cantor,> case (the attributes end up in the same bucket), but it's
Cantor,> an easy fix.
Well, note that anything coming out of attribute mapping in your SP is
completely separate and is unprefixed; the administrator is assumed
to know their own policy.
I'm not sure the most intuitive ECP implementation on top of Shibboleth
SP would expose this at all. I'd encourage people to do so; see below.
>> First, have I got the context right?
Cantor,> Much of the time the use of third party sources tends to be
Cantor,> for "local" sources associated with the domain of the
Cantor,> application, but I agree in principle with the need to
Cantor,> distinguish that. I suppose in that sense the cases I've
Cantor,> seen would match what you were referring to for Kerberos,
Cantor,> the enterprise scenario.
right.
>> Second, what URN do we want to use. The current
>> URNurn:ietf:params:gss-eap:saml-aaa-assertion has gss-eap and aaa
>> in it both of which are wrong.
Cantor,> Is it necessary that the value be fixed? If the
Cantor,> application-specific names of the attributes themselves
Cantor,> aren't fixed, do the contexts have to be?
So, I think there are two cases here. The first and probably more
common is that an administrator uses some mechanism like your attribute
mapping mechanism to map attributes. We don't care much about that case
in the IETF.
The second case is that someone is specifying a protocol--either in the
IETF, or some community, where you do want the attributes to be
standardized.
To refer to an attribute in a protocol you need to know its context
and name.
I do think there are some realistic cases for this, although not many
involve SAML attributes:
1) I want those RADIUS attributes. For example there is a draft for SNMP
over ssh and another draft for RADIUS SNMP authorization. It seems
entirely reasonable to me to want to implement that draft for gss-eap
and in that case to want to access the specific RADIUS attributes that
the RADIUS mapping draft says to use.
2) It seems entirely reasonable to want to ask for the raw assertion
from your GSS EAP or ECP mechanism to go do something with it with your
own SAML library.
So, I'd prefer the context be fixed. I think we need it to be fixed for
GSS-EAP. If the use cases for ECP are going to be different then we
should consider that. However it would be valuable if you could plug one
in case of the other.
--Sam
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
