--On Wednesday, July 20, 2005 9:03 AM +0200 Pierangelo Masarati <[EMAIL PROTECTED]> wrote:
I'll try to answer all points in this mail: slapo-rwm goes in the right direction, because you can condition events based on stored knowledge of previous events; however slapo-rwm is not the solution to your problem right out of the box, because attribute mapping and DN rewriting are entirely decoupled, so you cannot use the knowledge of the bindDN to alter attribute mapping. I guess you should rather use a custom solution, inspired by slapo-rwm, that does some pattern->action (regex?) in rewriting attributes. Or, since it is not exactly clear how DN info should influence attribute mapping, you may perhaps solve your riddle by having different users treated by different virtual databases, each based on back-relay^* and with a different mapping pattern, all pointing to the same real database. *^I write back-relay under the assumption that the real database and the virtual databases are in the same slapd instance; if they are not, then use back-ldap instead. If you want to play with DN rewriting/attribute mapping with 2.2 you don't actually need the slapo-rwm because in 2.2 it i embedded in back-ldap and back-meta (in 2.3 it's still embedded in back-meta but it has been decoupled from back-ldap into an overlay to be usable with other backends, significantly back-relay; I've figured out a way to reuse it for back-meta as well...).
Hm... In my case, this most likely going to all be done for anonymous binds (Outlook email client comes to mind). My though here is to create a fake branch in the DIT (cn=outlook,dc=stanford,dc=edu) that rewrites Stanford's custom schema into what Outlook (or another email client) wants.
To answer Quanah's question, I think your ITS, as answered by Kurt, is now entirely fulfilled by 2.3 code, by using back-relay and slapo-rwm; the only thing it doesn't allow is to use the requested name instead of the canonical one, e.g. returning "userid" instead of "uid" when "userid" is requested (this was a long debated question; I see the issue and I agree with the common answer that the current behavior is preferable; for those that still wish this to be possible, the answer is that it cannot be done with an overlay, so there's very little chance that it will ever be possible with OpenLDAP, except by hacking the code).
I myself actually don't need the uid/userID thing anymore (someone else @ Stanford had asked the question, but it never became an issue).
--Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
