[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
>>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:
>>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).

done.  I don't thonk we need much escaping, since we can:
- strrchr(':') to isolate the user
- strchr('/') to isolate the realm
- strchr('.') to isolate the mech

this assumes the user cannot contain ':' and the mech
cannot contain '/'; if this is not true, then we need
to escape these chars in the respective parts.

>>> Maybe we should just have
>>>         u:userid[@realm]
>>then we could do
>>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.

Agree.  But as you can see in ITS#2871, someone is using them
to differentiate user DNs...

>>> 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.

What I meant is if there is no mech associated to the
authentication exchange.

Currently (after Howard's latest commit) there is always
a mech, the bottom line is "SIMPLE", so this is now a moot

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

I'm not sure I understand this.


Pierangelo Masarati