feat(fiat) - Cache fetched LDAP roles to speed up role syncs.

[kirangodishala]

• BaseUserRolesProvider: New class to enable caching layer for concrete UserRolesProvider implementations.
• LdapUserRolesProvider: Update class to consume caching layer.
• When call for roles is initiated, now the local cache responds with cached roles else LDAP is contacted and the result gets cached.
• This feature can be enabled by adding the below configuration:

auth:
  groupMembership:
    ldap:
      cache:
        enabled: true
        expireAfterWriteSeconds: 600        

• Cached entries expire after expireAfterWriteSeconds seconds. This is an optional configuration whose default value is 600(i..e, 1hour).

• Addressed the spinnaker issue: Fiat - local cache for ldap spinnaker#6845

[dbyron-sf]

FWIW we've been running this for ~2 years at Salesforce.

[dbyron-sf]

@Mergifyio update

[mergify]

update

✅ Branch has been successfully updated

[mattgogerly]

I don't use the LDAP provider, but I'm curious about the side effects of this. If user A is added to a new AD group with permissions on an application, does this mean they have to wait until cache expiry to start using it?

Alternatively, if a user is removed from an AD group, will they still have access until cache expiry?

[kirangodishala]

I don't use the LDAP provider, but I'm curious about the side effects of this. If user A is added to a new AD group with permissions on an application, does this mean they have to wait until cache expiry to start using it?

@mattgogerly - No. Since the entry of user A is not present in the cache, the request goes to LDAP. Expiry is at the entry level.

Alternatively, if a user is removed from an AD group, will they still have access until cache expiry?

Yes, this is possible as with any caching mechanism (unless there is a way to invalidate explicitly).

[jasonmcintosh]

#804 MIGHT have been of interest FYI

Ignoring that... this is minor and not requesting changes, just more of. "hey here's another custom cache system." Is there a reason NOT to use standard spring cache system? Just using @Cachable with the advantage of being able to pick the cache implementation.

[dbyron-sf]

@Mergifyio update

[mergify]

update

✅ Branch has been successfully updated

[dbyron-sf]

this is minor and not requesting changes, just more of. "hey here's another custom cache system." Is there a reason NOT to use standard spring cache system? Just using @Cachable with the advantage of being able to pick the cache implementation.

You're right @jasonmcintosh. No doubt our ignorance when we implemented this. Since we've been running this code for awhile and have good confidence in it, I'm gonna go ahead and merge it and treat using something more standard as a future improvement.