Re: Result code for invalidated associations

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Jim Sermersheim writes:

> I agree that the best course of action when credentials become invalid
> is Notice of Disconnection,

I'm concerned that clients may not report such notices to the user.
How common is it to implement Notice of Disconnection on the client
side?

rfc2251 said Unsolicited Notifications are merely advisory, but it also
said this about Notice of Disconnection:
   After receiving this notice, the client MUST NOT transmit any further
   on the connection, and may abruptly close the connection.
It has been removed from [protocol] - do we need to reinstate that
clients SHOULD or MUST notice a Notice of Disconnection?

One unfortunate point is that there seems to be no 'natural' way for an
LDAP library to handle Notice of Disconnection without the client
explicitly asking for it.  So the client may instead have to handle the
"connection lost" error specially and explicitly ask about Notice of
Disconnection.  There will probably always be plenty of clients which
don't bother.

(I see several problems for the library, though I may be messing things
up a bit because I don't remember how TCP handles lost connections:

If the library gets "connection lost" to an attempt to send a
request, it can't always just read pending responses to see if there
is a Notice of Disconnection.  I expect the client could have another
thread which was reading responses.  In any case, it just doesn't
seem right to me to read anything in response to a "write" request.

Also, if the library does read the pending input, is there in practice
some absolute limit on how much input can be pending - both in TCP and
other transports which might implement LDAP?  Otherwise an attempt to
read it all could eat a lot of memory.

Finally, if the library does read the input and finds a Notice of
Disconnection, it needs to put the result code in some place which the
client will pay attention to.  Maybe the diagnosticMessage field would
be the best bet.  Or it could invent a bunch of private "connection
lost" result codes, indicating different result codes in the notice of
disconnection.)

> however, when the server chooses (for
> whatever reason) [NOT] to do this, I think (because the now invalidated
> credentials have changed the authorization state) the proper result code
> to return is insufficientAccessRights). This result code can be returned
> for any operation requiring a certain level of authorization, is
> typically indicative of the outcome of future (similar) operations, but
> can come and go as one's authZ state changes.

True, but it could be confusing if the sysadmin is not aware of having
configured the server to change the users' authZ states like that.  The
user complains that he has no access to an entry, the sysadmin says "yes
you have".  Though that could be fixed simply by sending an informative
diagnosticMessage.

> There's nothing currently in [protocol] though, that would indicate to
> the receiver of this error that the credentials have become invalid.

-- 
Hallvard