Selective User Cache Invalidation Enhancement

[Rishav9852Kumar]

Description

Currently, our system only allows for the invalidation of the entire user authentication cache, which can lead to numerous cache misses and inefficiencies. When dealing with LDAP user updates, this global cache invalidation affects all users unnecessarily.

Solution

This PR introduces a new REST endpoint that enables selective cache invalidation at the individual user level. This allows for more precise cache management, particularly useful when handling LDAP user updates where only specific user entries become stale.

Key Changes

• Introduces new REST endpoint /api/security/authcache/users/{username} for selective cache invalidation
• Adds integration tests to verify the behavior with LDAP authentication
• Implements proper authentication and security controls for the new endpoint

Benefits

• Prevents unnecessary cache misses for unaffected users
• Improves system efficiency by maintaining cache integrity for other users
• Provides better handling of LDAP user updates without impacting the entire cache

Developer Note

This issue was aimed as an excellent introduction to the plugin development workflow, touching all crucial aspects including REST API development, integration testing, unit testing, and authentication handling with external providers - making it an ideal "good first issue" for new contributors.

Acknowledgments

This work builds upon the contributions of:

• @prabhask5 (PR [FEATURE] Endpoint to purge cache entries for specific users #4571)
• @dlin2028 (PR Flush user cache #4314)
• @cwperks ( 7cbd113)

Related Work

• Building upon changes from [FEATURE] Endpoint to purge cache entries for specific users #4571
• Extends functionality from [FEATURE] Endpoint to purge cache entries for specific users #5325

Issues Resolved

#2829

Is this a backport? If so, please add backport PR # and/or commits #, and remove backport-failed label from the original PR.

Do these changes introduce new permission(s) to be displayed in the static dropdown on the front-end? If so, please open a draft PR in the security dashboards plugin and link the draft PR here

Testing

IntegrationTest

LdapAuthenticationCacheTest.java

FlushCacheApiIntegrationTest.java

Unit tesing

FlushCacheApiTest.java

Check List

• [ x] New functionality includes testing
• New functionality has been documented
• New Roles/Permissions have a corresponding security dashboards plugin PR
• API changes companion pull request created
• [ X] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[codecov]

Codecov Report

Attention: Patch coverage is 67.16418% with 22 lines in your changes missing coverage. Please review.

Project coverage is 72.08%. Comparing base (a1717ee) to head (f1ef7d4).
Report is 6 commits behind head on main.

Files with missing lines	Patch %	Lines
...ch/security/dlic/rest/api/FlushCacheApiAction.java	60.71%	9 Missing and 2 partials ⚠️
...urity/action/configupdate/ConfigUpdateRequest.java	69.23%	1 Missing and 3 partials ⚠️
...tion/configupdate/TransportConfigUpdateAction.java	69.23%	0 Missing and 4 partials ⚠️
.../org/opensearch/security/auth/BackendRegistry.java	76.92%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5337      +/-   ##
==========================================
+ Coverage   72.06%   72.08%   +0.01%     
==========================================
  Files         381      381              
  Lines       23608    23654      +46     
  Branches     3621     3632      +11     
==========================================
+ Hits        17014    17050      +36     
- Misses       4798     4799       +1     
- Partials     1796     1805       +9     

Files with missing lines	Coverage Δ
.../org/opensearch/security/auth/BackendRegistry.java	77.51% <76.92%> (-0.03%)	⬇️
...urity/action/configupdate/ConfigUpdateRequest.java	83.33% <69.23%> (-10.79%)	⬇️
...tion/configupdate/TransportConfigUpdateAction.java	87.09% <69.23%> (-12.91%)	⬇️
...ch/security/dlic/rest/api/FlushCacheApiAction.java	69.23% <60.71%> (+1.37%)	⬆️

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[cwperks]

Thank you @Rishav9852Kumar. This change looks good to me! From an end-user perspective, the /_plugins/_security/cache/user/{username} makes sense to me.

I know there is still some discussion on the organization around the internal transport action, but since that's not user facing I think that can be addressed in a separate PR and I see that there's already a comment in the code explaining the re-use of the action.

[shikharj05]

Thanks @Rishav9852Kumar - as a follow-up, can you try and improve coverage for the changes? For e.g. see https://github.com/opensearch-project/security/pull/5337/checks?check_run_id=42888662886 for missing coverage