Add caching support for IdentityProviderStorageProvider.getForLogin operations

[akshayutture-augment]

Test 2

---

Replicated from ai-code-review-evaluation/keycloak-greptile#2

[akshayutture-augment]

@claude review this PR

[akshayutture-augment]

@claude review this PR

[claude]

Claude finished @akshayutture-augment's task —— View job

---

Code Review for PR: Add caching support for IdentityProviderStorageProvider.getForLogin operations

I've completed a thorough review of this PR. Overall, the implementation is well-structured and follows the existing caching patterns in the codebase. Here are my findings:

---

✅ Strengths

1. Consistent Architecture: The caching implementation for getForLogin() follows the same pattern as the existing getByOrganization() method, maintaining code consistency.

2. Comprehensive Test Coverage: The test file OrganizationCacheTest.java includes an excellent test case (testCacheIDPForLogin) with 170 new lines that thoroughly validates:

   • Cache population on first access
   • Cache preservation when non-login IDPs are modified
   • Cache invalidation when login-affecting changes occur
   • Different FetchMode scenarios (REALM_ONLY, ORG_ONLY, ALL)

3. Smart Cache Invalidation: The registerIDPLoginInvalidationOnUpdate() method (lines 403-418) implements intelligent invalidation logic that only clears caches when necessary, improving performance.

4. Proper Fallback Handling: Both new cached methods correctly fall back to the delegate when cache entries are missing or invalid (lines 247-249).

---

🔍 Issues and Concerns

1. Potential Cache Inconsistency (Medium Severity)

Location: InfinispanIdentityProviderStorageProvider.java:244-252

Set<IdentityProviderModel> identityProviders = new HashSet<>();
for (String id : cached) {
    IdentityProviderModel idp = session.identityProviders().getById(id);
    if (idp == null) {
        realmCache.registerInvalidation(cacheKey);
        return idpDelegate.getForLogin(mode, organizationId).map(this::createOrganizationAwareIdentityProviderModel);
    }
    identityProviders.add(idp);
}

Issue: When an IDP is deleted, the cached IDP ID list isn't immediately invalidated. The code detects this (line 247) and falls back to the delegate, but there's a timing window where stale data could be served.

Recommendation: Consider proactively invalidating login caches in the remove() method similar to how it's done for organization caches. The current registerIDPLoginInvalidation() call on line 111 only invalidates if the IDP qualifies as a login IDP, but there's no invalidation for organization-specific login caches.

2. Missing Organization Invalidation in getForLogin Cache

Location: InfinispanIdentityProviderStorageProvider.java:214-255

Issue: When an organization is updated or deleted, the getForLogin() caches aren't invalidated. The getByOrganization() method checks for organization invalidation (line 173), but getForLogin() doesn't.

Scenario: If an organization is disabled or deleted, cached login IDPs associated with that organization may still be returned until the cache naturally expires.

Recommendation: Add an organization invalidation check similar to line 173:

if (isInvalid(cacheKey) || (organizationId != null && isInvalid(organizationId))) {
    return idpDelegate.getForLogin(mode, organizationId).map(this::createOrganizationAwareIdentityProviderModel);
}

3. Code Duplication (Low Severity)

Location: InfinispanIdentityProviderStorageProvider.java:168-211 and 214-255

Issue: The getByOrganization() and getForLogin() methods have nearly identical caching logic (~80 lines of duplicated code).

Recommendation: Consider extracting a common method:

private Stream<IdentityProviderModel> getCachedIDPStream(
    String cacheKey, 
    String searchKey,
    java.util.function.Supplier<Stream<IdentityProviderModel>> delegateSupplier,
    String... additionalInvalidationKeys) {
    // Common caching logic here
}

4. Minor: Method Visibility Inconsistency

Location: InfinispanIdentityProviderStorageProvider.java:77

Issue: The cacheKeyForLogin() method is public static while similar methods like cacheKeyOrgId() (line 73) are also public. However, cacheKeyIdpAlias() (line 65) is private.

Recommendation: Review if cacheKeyForLogin() needs to be public or if it should be private like most other cache key methods.

---

🧪 Test Coverage Assessment

The test coverage is excellent:

• ✅ Tests cache creation on first access
• ✅ Tests cache preservation for irrelevant changes
• ✅ Tests cache invalidation for relevant changes
• ✅ Tests all three FetchMode values
• ✅ Tests with and without organization IDs
• ✅ Tests IDP create/update/delete scenarios

Missing test case: Test what happens when an IDP in the cache is deleted (the null check scenario on line 247).

---

📝 Minor Observations

1. Line 47: Consider adding a JavaDoc comment explaining when each FetchMode should be used.

2. Line 84: The registerIDPLoginInvalidation() call in create() is good, but consider if organization-specific caches need targeted invalidation.

3. Lines 58-75, 79: The getForLogin() method in OrganizationAwareIdentityProviderBean.java correctly uses the new cached method, maintaining consistency.

---

🎯 Recommendations Summary

High Priority:

• Add organization invalidation check in getForLogin() method (Issue Bump aquasecurity/trivy-action from 0.32.0 to 0.33.1 #2)

Medium Priority:

• Review cache invalidation strategy for the remove() method (Issue Bump snyk/actions from 28606799782bc8e809f4076e9f8293bc4212d05e to 9adf32b1121593767fc3c057af55b55db032dc04 #1)
• Add test case for deleted IDP scenario

Low Priority:

• Refactor to reduce code duplication (Issue Bump actions/download-artifact from 4.3.0 to 6.0.0 #3)
• Review method visibility consistency (Issue Bump actions/upload-artifact from 4.6.2 to 5.0.0 #4)

---

✅ Conclusion

This is a solid implementation that improves performance for a critical operation. The caching strategy is sound, the tests are comprehensive, and the code follows existing patterns. The main concerns are around cache invalidation edge cases that could lead to stale data in specific scenarios. I recommend addressing the organization invalidation issue (#2) before merging.

Approval Status: ✅ Approve with minor changes requested

---