https://bugs.openldap.org/show_bug.cgi?id=10065
--- Comment #14 from sean@teletech.com.au --- (In reply to Ondřej Kuzník from comment #13)
On Mon, Jun 12, 2023 at 12:33:49PM +0000, openldap-its@openldap.org wrote:
You can always make this the first ACL in the list (in your analogy, putting a security guard/gate that checks people even get access to the building):
access to * by <your allowlist expressed as peername/sockname> break by * none
An awful lot of lines of code need to run to parse and interpret the ruleset, and parse and interpret LDAP commands, seems how the ruleset isn't applied until it is presented with a command. I'm not saying there IS anything wrong with that code, I just don't know. And I have the option of putting a proxy in front of it and then I can sleep better.
I think we're on the same page now, you want to use the DN of the client certificate but can't (yet) and propose acting on the PP2_SUBTYPE_SSL* TLVs, at the very least PP2_TYPE_SSL and PP2_SUBTYPE_SSL_CN.
Exactly.
Except that rereading the spec, we don't actually get to see the whole DN, just the CN part so that is not viable unless a new field were defined for it.
Yeah, I was worried about that too. Luckily for me at least, My client certificate's DN's only have a single CN - so no information lost. I'm sure this is not true in general. But so long as the CN's are unique, I could use the DN rewriting to fill in all the missing RDNs.
What is preventing you from exposing slapd to your clients directly?
I just couldn't convince myself that it would be sufficiently secure. Too many things have to just right, and I don't trust myself that much.