Technical Problem
Statement of Problem
Access policies have a particular anomaly with regard to "revoke when no longer applies" behavior. If the access policy didn't provision the resource, it will not revoke it when the policy no longer applies. This behavior typically happens when either the resource is provisioned manually by an administrator or when a non-trusted reconciliation is run and existing resources are "joined" to the OIM user. The latter scenario will certainly occur on initial data load as it is the most efficient way to map OIM users to their existing resources.
Analysis
The OIU table in the OIM database is the home of extended object instance data (beyond what is in OBI), including the service account flag, attestation data, and three columns that indicate the policy-based state for a resource. The 'obi_key' is the key that links back to the object instance data (OBI) table and the 'usr_key' links to the OIM user (USR) table. When resources are added via non-trusted reconciliation or manually provisioned, these columns have null values. When an access policy provisions the resource, these columns have specific values. The columns in play are as follows:
- pol_key
- oiu_policy_based
- oiu_policy_revoke
The first column contains the policy key, the second column contain a string '1' to indicate a policy-based provisioned state and if the access policy is set to "revoke when no longer applies" the last column will also contain a string '1'.
Solution
Solution
Create Java method to set the appropriate policy-based state of each resource, given the resource name. This can then be executed via scheduled task either as a one-time deal as part of initial data load or as a periodic catch-all to ensure that all resources specified are set to the policy-based state.
< EXPAND >