A customer recently started using Identity Governance for reviews of the resources granted to users. Initially, the customer did not have any problems and campaign data reflected the actual situation with users and their resources. Nevertheless, after the first certification the customer started seeing differences for some users in actual resources granted to users and the resources they had inside the certification campaigns. The customer also noticed that Master and Model configurations were different even after import. The customer concluded that it was a bug in the product.
vApp IG 14.5
The customer had unreasonable expectations on the product.
The Master and the Model become the same only in the following cases:
1. When a universe is imported first time.
2. When in the existing universe, on its configuration page, Master and Model are reset to new, not existing names, and then the universe is imported (very similar to 1).
3. When the Model configuration is forcefully replaced with a copy of the Master configuration using IG ClientTools.
4. When the universe is exported via an export connector.
5. When difference of Master and Model is exported via a third party script, then that difference is applied to the endpoint(s) and then immediately the universe is imported again with the new data from the updated endpoints.
Indeed, the customer only performed step 1. If steps 2 - 5 are not executed, Master and Model configurations will likely be different forever.
Master and Model can become the same in some other cases but they are not practical or rare.
Below, there is a scenario which gives some details on how IG works.
IG, in standard vApp configuration, is connected to IM and it takes data from there into a universe to analyze.
Every universe has Master and Model configurations. Configurations are datasets. Initially, when data is imported from the IM, these datasets are identical and contain a snapshot of users, their roles and privileges in IM.
When a campaign is run, the third dataset (configuration) is coming into consideration. This dataset is a snapshot of Model data and it is used to run the campaign. This campaign snapshot is immutable and is not affected by any changes in the Master/Model configurations.
When campaign is run, reviewers make changes to the snapshot, thus this snapshot becomes different to Master and Model configurations.
When campaign is over, and changes are submitted, they are applied to the Model. At this stage Master and Model configurations become different. Model contains changes coming from the campaign. At this stage Master does not.
When the changes are exported, the differences between Master and Model configurations are sent to IM and, when it is done, Master becomes Model and the configurations become identical again.
Above is a standard, very simple scenario. Real-life scenarios can be more complicated. For example, multiple campaigns can be run at the same time. Or, when campaigns are run, the universe can be undated by running another import from IM.
Let us consider the case when a campaign is run, but another import is executed before the campaign is over. In this case, changes from the IM are applied to Master and Model configurations. If they were the same, they will stay the same and will reflect the state of the IM. If they were different, they will stay different as import applies to Model only the changes happened in the IM since last import. On the other hand, campaign data stays the same.
Q: How Master and Model can become different?
Every time a campaign is run and the changes are submitted, they are applied to Model, but not to Master (until export is performed). When export is performed, differences between Model and Master are applied to IM and Master, thus Master becomes the Model.
All in all, taking all above into account, it is quite normal that Master, Model and potentially multiple campaign snapshots have different sets of data (and, for example, a customer will see different roles and resources assigned to a user).