[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: saslAuthz{To|From}



Ando,

At 12:32 PM 12/13/2003, Pierangelo Masarati wrote:
>> At 11:20 AM 12/13/2003, Howard Chu wrote:
>>>I think adding a mech specifier is a really bad idea.
>>
>> Quite likely.
>
>Hold on, what we're talking about is NOT specifying the mech
>in the "u:" of, say, a proxyauthz control.  I agree this has
>to be related to the mech that was actully used to get to that
>point.
>What I'm talking about is how to put the mech into the
>sasluthz(To|From) attribute of an entry.  This can be
>useful when deciding to authorize identities that are
>specified thru the "u:" syntax based on the mech as well.

I think we're saying that we might as well just imply a
pseudo mechanism here. 

The admin can, through the mapping policy, say which
mechanisms are equivalent.

>What I came out, and currently implemented, is:
>
>u[.<realm>][;<mech>]:<user>
>
>if this is acceptable, I'll commit it in a moment.

I'm not particular happy with that format:
        u[.mech][/realm=REALM]:userid

This is consistently Most-to-Least significant, realms are
a feature of some mechanisms which userids are generally
grouped by.

But given that realm can contain most any character, some
escaping would be needed to disambiguate the separator (':'
in my format, ':' and ';' in yours).


>>
>> Maybe we should just have
>>         u:userid[@realm]
>
>then we could do
>
>u[.<mech>]:<user>["["<realm>"]"]
>
>I guess you mean "literal" square brackets around the realm.
>I still favour my solution, but I've nothing against this latter.

At present, I think it would be better to simply ignore realms.
Except for mechanisms like GSSAPI (which they are part of the
principal name), realms should be viewed as just causing a
database switch during authentication.  For DIGEST-MD5, we
can simply declare "userid@example@REALM1" and "userid@REALM2" to
referring to the same identity, but different secret stores.

>> and just imply a mech of "authz" when authzid comes from policy
>> information.  Otherwise, the mech associated with the authentication is
>> implied.
>
>If no mech is associated to the operation, then use
>the "AUTHZ" mech.

No, if no mech is associated with the operation, the asserted
u:foo has same mech as the authentication exchange.  

But the u:foo in the policy information (the directory) is
treated as having mech "AUTHZ".

Kurt