-
Type: Task
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Server Security
Mongos' authzn cache is eventually consistent with the config shard's authorization stores. After an interval, configured in the mongos, the process will reach out to the config servers and check whether fresh state is available.
When using LDAP a config shard will, after a mongod configurable interval, reach out to the LDAP servers to check whether previously authenticated users are stale. If the users are stale, the config shard will refresh them. After a refresh, mongos will observe that its state is stale the next time it checks.
This behavior means that there are two separate refresh intervals which are configured separately. While stale user state has a bounded lifetime and will eventually purged, the exact number of seconds it can live is somewhat difficult to work out.
As an administrator, I want to configure my cluster to cache user data for a defined amount of time in order to manage the tradeoff between latency and security. I want to set a single value which controls this tradeoff.