Re: Read Entry control not applicable to Bind Operations
Kurt Zeilenga <[email protected]> Fri, 20 Apr 2012 18:10:29 -0700
| Newsgroups | gmane.ietf.ldapext |
|---|---|
| Message-ID | <[email protected]> |
On Apr 20, 2012, at 9:47 AM, Michael Ströder wrote: > HI! > > I wonder why RFC 4527 limits the use of the Read Entry control to update > operations (Add, Delete, Modify, ModifyDN). Because to solve the problem I had at the time, I only needed pre- and post-read entry on update capabilities. > E.g. the pre-read control could be also useful to read the last login time and > number of failed authc attempts and display it to the user *after* a > successful bind. There's lots of issues here which make this not so simple. * There is a bad assumption that there is a one and only entry associated with the user. * There is a bad assumption that the information desired is held in that entry. * The request and response controls are not protected by the SASL layers established, if any, during the Bind. * Proper semantics in multi-step SASL bind gets messy. Lastly, it kind of overlaps with the purposes of the draft password policy control... which arguely should be capable of return a wide range of authentication and service authorization information to the client. So, even if I was now writing the read-entry spec, I would have strongly opposed including non-update coverage, especially bind coverage, in the spec. If someone really wants this, they can write a separate spec, reuse all the syntaxes (just define a "feature" for the extension to this control extension). -- Kurt