At 08:36 AM 12/14/2006, Howard Chu wrote: >The new mechanism wouldn't behave a whole lot differently... If we were to >make this a control I would only define it for Bind operations, thus >identifying an entire session to be a server-to-server interaction.
I would hesitate a bit on making this a bind control. First, bind controls are not protected by the Bind's authentication mechanism. Second, there are likely cases where a client was to act as a DSA and act as a client. Adding a simple control (no control data) doesn't add much overhead... >It doesn't make sense to me to attach such a control on a per-operation basis. >But once we've established that the peer is a server, we can simplify a lot of >other checks. (E.g., set a boolean in the Connection structure, instead of >having to compare DNs all the time.) We, of course, could do this with updatedn. That is, check the authzDN after the bind completes and set a flag (and clear it in connection2anonymous()). >This would give us the freedom to do a bit more along the lines of X.500 DSP >without the ambiguity that the current chaining/proxyauth/etc. approaches >suffer from.
