Hi All,
This is loosely related to issue 10065
https://bugs.openldap.org/show_bug.cgi?id=10065, but can be read
independently.
I have devised a work-around to slapd's inability to check client names
on Client certificates and am in the process of removing a proxy
(haproxy) I had in front of my slapd server. I have however come across
an annoying compromise and I'm offering here a suggestion on how to
remove it.
In particular, with the proxy, I could write rules targeting particular
clients that worked, even before their initial "bind" operation by using
the "sockname=" pattern in the access control rules. This does not seem
possible when slapd talks directly to the clients. before the initial
"bind" operation, only the IP address is available to tell clients
apart, which are not very reliable. IP addresses are easily spoofed.
It would be much better to use the client certificate to match against
the particular client. Currently the client ID on the certificate is
passed to the SASL layer with the
sasl_setprop(...,SASL_AUTH_EXTERNAL,...) call. There it remains until
the client performs a "bind" using the SASL EXTERNAL mechanism. At this
point, the EXTERNAL client ID is used to derive a distinguished name by
filtering it through the "olcAuthzRegexp". It should be noted that LDAP
v3 does not require the client to perform such a bind operation.
My Proposal is to expose the EXTERNAL identity to the ACL rules in a
similar way to how the "real" prefix exposes the authentication identity
- by creating an "external" prefix.
As such, the matching rules
externalanonymous
externalusers
externalself
externaldn
externaldnattr
Could be used to restrict access to clients, even before or without a
bind operation.
To maintain naming consistency, The name passed to SASL could have the
"olcAuthzRegexp" mapping applied before the ACL rule is applied. In this
case, the "external" identity would be the same as the unprefixed
identity, after a bind using SASL EXTERNAL mechanism had occured.
This arrangement would have several advantages including:
*) only exposing the userPassword to the particular client that needs it.
*) enforcing client/IP address associations in a rigorous manner.
*) general ACL rules for operations that do not need a "bind" operation.
*) restricting SIMPLE binds to particular clients.
Any Thoughts ?
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
