Tobias Franzén wrote:
Pierangelo Masarati wrote:
Tobias Franzén wrote:
I started fiddling around with regexp ACLs after I wrote my mail (I thought of it just as I was finishing the mail), and so far I have been able to limit access to the userPassword (and as such, simple binds) to users in ou=People who have a userPassword like regexp "{SASL}.+@REALM". However, I have yet to find a way to expand a regexp from the dn containing the uid, into the attrs regexp. My ACL looks something like this:
access to dn.regex="^uid=([^,]+),ou=People,dc=example,dc=com$" attrs=userPassword val.regex="{SASL}.+@EXAMPLE.COM" by self read by anonymous auth by * none
I have tried to use val.exact="{SASL}$1@EXAMPLE.COM" but it doesn't appear to expand the $1 from teh first dn.regex as I would like. Any ideas?
Your wish does not find any correspondence in the documentation. In fact, there's no possibility to have such expansion, nor it makes much sense, as there's no consequentiality implied in setting
access to dn=pattern attr=desc val=valuesince
access to val=value attr=desc dn=patternwould be exactly the same rule.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
I agree that order in which the dn= or attrs= parts of an access entry appear in slapd.conf is not important or relevant to OpenLDAP.
This is a fact.
However, one might argue that regex groupings could (and should) be expandable for any and all regexs that follows. Is it not (or should it not be) possible to expand regex groups when matching for "who" to give access?
The "who" is a separate clause from "what"; "who" expansion based on "what" contents is implemented and documented, in fact.
There is no mention of it in the online documentation, but man for slapd.access mentions the expandability for "what" groupings in "who" matchings.
Exactly.
When running slapd with -d 128 (ACLs), it shows how it first has to check if the requested DN is matched (and rightfully so), before it can move on to defined attrs. So when this first dn regex is done, it shouldn't be impossible to extract substrings from it into the second regex for attrs as well.
This is a "feature request". In general, you should safely assume that undocumented features are not documented because they do not exist.
Anyway, my point was to get an answer about other possible ways to make sure that if a DN like "uid=user_one,ou=People,dc=example,dc=com" has an attribute userPassword, it should be exactly "{SASL}user_one@EXAMPLE.COM", and only then should anonymous be permitted to authenticate as this user.
I'm not entirely sure how it is now, and I hope this following explanation is understandable. If you can only allocate substrings in a dn.regex for "what" to access, and later extract them in a dn.exact[,expand] fashion for the "who" can access, and not having substring allocation possible for the attrs=attr val.regex, then you should also be able to extract substrings from the initial dn.regex in the attrs=attr val.regex or exact[,expand].
Technically, I think there is no limitation: whatever you figure out can probably be implemented somehow. Semantically, I'd object that much like DN pattern matching can be substituted in VAL, the same should be true for VAL pattern matching in DN, but since DN and VAL have the same priority (to be AND-ed), this would probably require changing the semantics of the "what" clause.
The documentation for slapd configuration, and the man pages for slapd.conf and slapd.access, say nothing about the possibility to expand or not expand regex substrings to or from an attrs regex as far as I have been able to see.
As I said, when the docs say nothing about something, you can safely assume it's because that something is not possible/implemented. Feel free to file a feature request through the ITS http://www.openldap.org/its/.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------