Le 06/12/2017 à 14:16, Isenhour, Justin a écrit : > We have a use case where we need to have a custom status attribute for user > identities. We also have created a custom authentication interceptor that > will check the status attribute on bind, depending on the status we will > throw a LdapAuthenticationException and report the status in the message. > Our SSO solution is then using this during the authentication process. This > is all working as needed. The issue we run into is related to the caching > policies within ApacheDS.
My guess is that you are talking about the credentials cache, right ? The first time a user identity attempts to login into our SSO application the bind event is triggered and the status is checked, after that the result of the bind is cached,the next time the user logs in the bind event is not triggered,because of this if the users status is changed after they have logged in then that new status is not reported until the cache clears. After reviewing the ApacheDS code I see there is some logic within ApacheDS to remove the user object from cache when the users password is changed, is there a way to also do this for a custom attribute like we have for status either through configuration or through custom code? If we have to we will set the expectation with our customers that any changes to status could take up to x amount of time to take effect but I would prefer to have these changes be real time if possible. Also what is the caching time for authentication and does it use sliding expiration? Thank you in advance. There is a public invalidateCache() method declared in the Authenticator interface and implemented in the SimpleAuthenticator. The thing is that you have implemented your how interceptor, but still have the standard autheticationInterceptor running, which means when a BindRequest is proceced, this standard interceptor will kick in and use the cached credentials. If you disable the standard interceptor, that should work as you intend it to wrk, assuming you keep the features this standard interceptor brings. What you should also try to do is to move your interceptor *before* the default authn interceptor, so that it's called first, and you can check the status beforehand. I would need a bit more information on how your interceptor is working to give you more precise directions, though... -- Emmanuel Lecharny Symas.com directory.apache.org
