-
Notifications
You must be signed in to change notification settings - Fork 73
Cache Refresh Redesign
Cache Refresh is a service built-in to oxTrust. With the move to Janssen, we need to factor out this code. This presents an opportunity to improve Cache Refresh.
Cache Refresh uses "brute force" synchronization and only supports LDAP as the source identity silo. It performs searches on the backend LDAP server (not one big search, but a bunch of smaller searches), creates a hash value for each source identity, and writes it to a disk. A certain amount of time later, it does the same. With two snapshots of the source data, Cache Refresh performs a Set operation: Set A - Set B to find the delta, and then iterates through the delta, updating the entire entry for each changed identity. During the update process, Cache Refresh looks for attribute name transformation (e.g. samAccountName -> uid), and runs the Cache Refresh interception script. Cache Refresh also relies on an LDAP suffix (o=site), to help map the source and destination primary keys.
- No filesystem persistence
- Plugin architecture
- Support for non-LDAP backends: build user profile mapping file?
- Optional use of MQ for assured messaging
- Better audit logging
- Better tools to compare a the backend data or force refresh of a specific user (including running transformations and interception scripts)
- Pure java interception script (Get rid of Jython)
Currently, we detect changes by comparing hash values. It would be more efficient if we could listen for changes via other mechanisms. For example, opendj has a changelog, or a database could use triggers. I think we should abstract this change detection interface, and allow third parties to write plugins to extend it.
How do we know if the source data gets out of sync with the data in the cache? If there is an error, there is the potential for the data to get out of sync.