RE: saslAuthz{To|From}

["Pierangelo Masarati" <ando@sys-net.it>]

>> -----Original Message-----
>> From: owner-openldap-devel@OpenLDAP.org
>> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Kurt D.
>> Zeilenga
>
>> 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.
>
>> 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".
>
> I'm not sure I understand this discussion now either, or the last
> commits that resulted from it. In controls.c we now have a
> slap_parse_user() call in parseProxyAuthz, to break an incoming authzID
> into user, mech, and realm. I didn't expect that.

The initial use of slap_parse_user() in parseProxyAuthz
was intended to allow clients to specify a realm in the
proxyAuthz control, but no mech was allowed.

When we decided to condition the possibility of a realm
in a used ID specification on the presence of a mech,
this was making user realm specification impossible in
proxyAuthz, so I added the "fake" "AUTHZ" mech to proxyAuthz
control simply as a means to allow the possibility of a mech.

parseProxyAuthz() desn't need to break the incoming authzID
except for these sanity checks.

>
> I thought we agreed not to allow the proxyAuthz control to specify a
> mech. I.e., you cannot authorize to a different mech than is already in
> force, and the current mech is always known (defaulting to "SIMPLE" in
> absence of anything else). Since realm is subordinate to mech, this also
> means you cannot specify any other realm. Therefore, there should not be
> a
> slap_parse_user() call in parseProxyAuthz.
>
> I'm going to echo the above "I think it would be better to simply ignore
> realms." Also, the notion that user@realm1 and user@realm2 are the same
> user, just with different secret stores, sounds good, but doesn't make
> much sense here. If they are the same user for our purposes, then they
> must have the same DN. If they have the same DN, and there is an entry
> in the LDAP database corresponding to that entry, then they have the
> same secret. Of course none of this matters too much for proxyAuthz
> since no secrets are being referenced.
>
> Now, as to the "AUTHZ" pseudo-mech and where/when it gets used... I
> guess the purpose here is to distinguish proxying via SASL Bind from
> proxying via proxyAuthz control, yes? So in an LDAP user's entry, a
> saslAuthzTo rule for "u:joe.DIGEST-MD5" allows the user to SASL Bind
> using DIGEST-MD5 with the authzID set to "u:joe", but not for any other
> mechs, and not for proxyAuthz control. Whereas an unqualified rule
> allows all mechs and the proxyAuthz control. Yes?

I guess a preferabel behavior would be, in case "AUTHZ" is set in
the incoming ID, to replace it with the real mech.

Ando.

>
>   -- Howard Chu
>   Chief Architect, Symas Corp.       Director, Highland Sun
>   http://www.symas.com               http://highlandsun.com/hyc
>   Symas: Premier OpenSource Development and Support


-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it