|
I agree that the best course of action when credentials become invalid is Notice of Disconnection, however, when the server chooses (for whatever reason) 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.
There's nothing currently in [protocol] though, that would indicate to the receiver of this error that the credentials have become invalid.
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 10/31/04 10:03:29 PM >>> At 09:27 AM 10/31/2004, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: > >> It's my view that result codes are only indicative of >> why the server was unwilling or unable to successfully >> complete the requested operation. The result codes >> are not indicative of the outcome of subsequently >> requested operations. > >Well, the entire point of invalidated associations is that they do >indicate to the client that future operations may fail unless it takes >appropriate action. Though if we could find some result code to use for >this, the definition of what the result code means to the client need >not be a promise that future operation will fail, only advice that it >cannot expect them to succeed (until it fixes the association), and that >it might need to check the current TLS and SASL layer state in case the >server invalidated the association due to e.g. a TLS cipher >renegotiation. Right, one could define some new result code which could be indicative of the outcome of subsequent operations. Or one could add controls (e.g., password policy controls), or unsolicited notifications. But we cannot redefine existing codes, nor can we (as part of the LDAPBIS work) add new codes. >> One could return Notice of Disconnect with either an >> strong[er]AuthRequired or invalidCredentials to indicate >> the credentials are no longer considered valid. > >If you mean to close the connection afterwards, it seems a bit like >surrender but maybe it is the cleanest solution (when it is not handled >by some extension). Trying to continue after unexpected failures/compromises takes special care. Termination is simple and often the best. >If you mean to not close the connection, I mean close the connection. |