RE: saslAuthz{To|From}

["Howard Chu" <hyc@highlandsun.com>]

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

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?

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