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.