Apologies for the late delay, I didn’t get a mail that there was a reply, so I only just checked and saw your reply.
Again a long story, so I will put a summary:
I am ok with current behaviour.
If you have many rules using LDAP connector, use cache.
If you have cache, you get a error after changing your LDAP password. (Exact steps are in longer story)
You can logout and login again and everything works.
I made recommendations to either change default setting of cache ttl. Or update documentation to more clearly explain the behaviour on the main page.
Longer story:
Stuff breaks:
What we saw without the cache and with default connection limit is that ROR tries to go to LDAP a whole lot of times, thereby locking the account.
User would get a white screen.
The user would then clear the session and cookies (I don’t think we tried logging out).
If the user would try to login again, he would fail, because his account is locked.
I just tried what you suggested, so now I have:
default connection pool limit.
cache ttl 60 seconds.
This (as you expected) indeed works.
In the same scenario now the flow works and there is indeed only one LDAP bind, that fails.
The user then gets an error page in Kibana.
User should then logout and login with his new password.
With regards to the auto logout, I don’t that is the way it currently works?
Also if we look at the discussion here:
The user gets thrown an error and should logout himself.
The error we got looked like this:
This is:
User A is logged in, in a discover.
User A changes password.
Wait for TTL to expire (60 seconds).
Try to browse to dashboard overview.
Get error.
Now user can logout and then login again with new password.
For me that is ok enough, we can sort this with an instruction.
May I recommend one of two things:
Option A: Change default cache from 0 to 60 seconds.
As the default behaviour seems to be disruptive and unnecessary (from my point of view, there might be valid use cases)
Option B: More clearly define the importance of caching in LDAP section of documentation.
Now it is written at the “addendum” like:
ReadonlyREST doesn’t enable caching by default. We leave that decision up to you. But in most cases, caching should be enabled to reduce external service calls. It’s very important when you look at it from the perspective of how the ROR’s ACL handles the request. And the rule of thumb is that caching at the service client definition level would be sufficient.
But on the main page this behaviour isn’t clear that this behaviour exists, there is this line:
Too many calls made by ROR to our LDAP service can sometimes be problematic (eg. when one LDAP connector is used in many rules)
But that doesn’t explain that by default an LDAP bind is attempted for every rule. We could rewrite that sentence like:
By default ROR doesn’t cache LDAP responses. This could cause problems when an LDAP connector is used in many rules. By default ROR does a LDAP bind for every rule. To prevent excessive calls to external services we recommend to enable cache.
And then in addendum we could add near here:
When someone calls
GET /my_index/_search, ReadonlyREST handles it by checking block by block if a block is allowed. Processing stops when the first block matches, or when no block matches. In the worst case, all blocks can be checked. As we can see, each block has theldap_auth' rule. This means that each block generates a call to LDAP which can be described asCheck using LDAP connector “ldap1” if user XYZ exists and can be authenticated`. It’s worth noting that every call looks exactly the same.
A section that explains about locking accounts if a password change is done.
Something like:
A combination of cache disabled and many rules using an LDAP connector can cause problems if a user changes his LDAP password while being logged in to Kibana. If the user tries to continue working in Kibana ROR will attempt a bind for every rule that is using the LDAP connector, this will be done with the old credentials and could cause the LDAP account to be locked (if account locking is enabled in the LDAP server).
Thanks for reading.
Like I said, I am ok with the current behaviour.
If LDAP incorrect credentials can somehow be more eleganty handled in Kibana, as in: User is logged out or gets a clear warning his credentials are invalid, it would be even better. But from the other topic and my understandig of ROR this isn’t always ideal/possible (you don’t want to be logged out if you try to access something you are not authorized for, for example).
If you want to dig further into the error/handling of Kibana and need any logs or input from my side please let me know. But for me it is ok enough as it currently is.