Just as driving simulator helps with driving, provisioning job simulator helps with provisioning.
By using driving simulators, you gain confidence on the road, experience the consequences of your actions (without risk of real damage) and ultimately learn how to avoid accidents.
With the latest new feature of Identity Provisioning – the Simulate job, it’s pretty much the same. Running it makes you better prepared for the provisioning results. You experience the consequences of your configurations (without risk of real mess up in the target system) and ultimately learn how to adapt and avoid undesired results.
More precisely, the Simulate job does the following:
The simulation is based on the Identity Provisioning operational data from previously provisioned entities using the same source and target system configurations.
Let’s try out some common create, delete, update and skip scenarios. Expect numbers. At this point, the job can only give you numbers, not the reason behind them. See: Simulate Provisioning Jobs.
We assume that you use MS Azure AD as a user store, and you want to provision the users and groups to Identity Authentication (IAS). In Identity Provisioning (IPS) admin console, MS Azure AD is configured as a source system and IAS as a target. Both systems use default transformations and no filtering.
Let’s see how many users and groups in MS Azure AD would be provisioned to IAS with your first run of a provisioning job.
Select the Jobs tab of the source system and run the Simulate Job.
As this is the first time when IPS will provision entities as part of the configured flow, the expected result is that all retrieved users and groups from the source system will be created in the target.
So, you get the following predicted numbers:
In case that 69 groups are too much, and you want to provision only one group, add filtering.
Select the Properties tab of MS Azure AD and add: aad.group.filter=displayName eq ‘Finance’.
The autocompletion makes it so much easier for you to configure properties, doesn’t it? This useful tool is also among the latest IPS enhancements. It is enabled by default and shows you only the relevant properties for the given system, plus some common ones.
Run the Simulate Job.
One group would be read, and one would be created. You are good to go. Run the Resync job.
The Resync job did exactly what the Simulate one predicted – 1 group and 203 users are created in IAS. This time, it was real.
Note that if some of the entities already exists on the target system, the simulation won’t detect them. In such cases, during the real provisioning IPS will detect them and try to update them, so they may appear as updated entities.
What if you now want to reduce the number of users? For example, provision only the users from USA who are members of the Finance group.
Set the aad.user.filter=country eq ‘USA’ and aad.user.filter.group.filter.combine=true
Run the Simulate Job.
Oh, no! The Simulate job predicts that adding this filter would delete all your newly created users in the target system. Fortunately, it wasn't a real provisioning.
Verify the user filter. (The correct value turned out to be 'US', not 'USA'.)
Change it and run the Simulate Job again.
Now we get it right. According to the Simulate job, 8 out of 203 provisioned users match both filters. The rest 195 users would be deleted.
This is exactly what happened after running the Resync Job:
A new member from USA is assigned to the Finance group. He matches both the user and the group filter.
Run the Simulate Job and see whether it will predict the update.
Yes, 1 more user is read and created, and the group is updated. The Resync job “confirms” it:
Now, let’s skip group updates by using skipOperations expression in the IAS write transformations and still try to update the group with a new member.
The recently implemented transformations color coding and autocompletion are here to help you, too. What’s more, a JSON validator is doing great job and detects the lines containing errors.
Run the Simulate Job.
As the new user matches the user and the group filter, the Simulate job predicts that it will be read from the source, it will be created in the target, but the group update will be skipped. The group will still have 9 members.
This is exactly what happened after running the Resync Job:
The numbers in Identity Authentication admin console prove it. There are 10 users provisioned from MS Azure AD (plus 1 IAS admin user) and 1 group.
You probably noticed that it is the Resync job that follows the Simulate one and produces the same results. Why is that?
The Simulate job provides the expected results of a Resync job - a job that reads all entities from the source system and provisions all entities to the target system. For comparison, the Read job reads all entities from the source system and provisions only new or updated entities to the target system.
Therefore, in some cases the predicted results of a Simulate job and the actual results of a Read job might differ in the statistics. For example, after provisioning those 10 users above to IAS, if you later update 3 of them (you modify their cell phones), expect the following statistics:
The Simulate job predictions come true. Now, you make yours.
P.S. There is one important precondition for using the Simulate job, the properties autocompletion and transformations color coding – all demonstrated above. Your Identity Provisioning tenant must run on SAP Cloud Identity Services infrastructure. If it runs on Neo environment, it’s time to get your hands on the Migrate Identity Provisioning Tenant documentation and just do it.
It's so much worth it.
By using driving simulators, you gain confidence on the road, experience the consequences of your actions (without risk of real damage) and ultimately learn how to avoid accidents.
With the latest new feature of Identity Provisioning – the Simulate job, it’s pretty much the same. Running it makes you better prepared for the provisioning results. You experience the consequences of your configurations (without risk of real mess up in the target system) and ultimately learn how to adapt and avoid undesired results.
More precisely, the Simulate job does the following:
- It reads the data from the source system.
- It applies the source and the target system transformations.
- It provides the expected results in the target system without modifying it.
The simulation is based on the Identity Provisioning operational data from previously provisioned entities using the same source and target system configurations.
Let’s try out some common create, delete, update and skip scenarios. Expect numbers. At this point, the job can only give you numbers, not the reason behind them. See: Simulate Provisioning Jobs.
We assume that you use MS Azure AD as a user store, and you want to provision the users and groups to Identity Authentication (IAS). In Identity Provisioning (IPS) admin console, MS Azure AD is configured as a source system and IAS as a target. Both systems use default transformations and no filtering.
Create
Let’s see how many users and groups in MS Azure AD would be provisioned to IAS with your first run of a provisioning job.
Select the Jobs tab of the source system and run the Simulate Job.
As this is the first time when IPS will provision entities as part of the configured flow, the expected result is that all retrieved users and groups from the source system will be created in the target.
So, you get the following predicted numbers:
In case that 69 groups are too much, and you want to provision only one group, add filtering.
Select the Properties tab of MS Azure AD and add: aad.group.filter=displayName eq ‘Finance’.
The autocompletion makes it so much easier for you to configure properties, doesn’t it? This useful tool is also among the latest IPS enhancements. It is enabled by default and shows you only the relevant properties for the given system, plus some common ones.
Run the Simulate Job.
One group would be read, and one would be created. You are good to go. Run the Resync job.
The Resync job did exactly what the Simulate one predicted – 1 group and 203 users are created in IAS. This time, it was real.
Note that if some of the entities already exists on the target system, the simulation won’t detect them. In such cases, during the real provisioning IPS will detect them and try to update them, so they may appear as updated entities.
Delete
What if you now want to reduce the number of users? For example, provision only the users from USA who are members of the Finance group.
Set the aad.user.filter=country eq ‘USA’ and aad.user.filter.group.filter.combine=true
Run the Simulate Job.
Oh, no! The Simulate job predicts that adding this filter would delete all your newly created users in the target system. Fortunately, it wasn't a real provisioning.
Verify the user filter. (The correct value turned out to be 'US', not 'USA'.)
Change it and run the Simulate Job again.
Now we get it right. According to the Simulate job, 8 out of 203 provisioned users match both filters. The rest 195 users would be deleted.
This is exactly what happened after running the Resync Job:
Update
A new member from USA is assigned to the Finance group. He matches both the user and the group filter.
Run the Simulate Job and see whether it will predict the update.
Yes, 1 more user is read and created, and the group is updated. The Resync job “confirms” it:
Skip
Now, let’s skip group updates by using skipOperations expression in the IAS write transformations and still try to update the group with a new member.
The recently implemented transformations color coding and autocompletion are here to help you, too. What’s more, a JSON validator is doing great job and detects the lines containing errors.
Run the Simulate Job.
As the new user matches the user and the group filter, the Simulate job predicts that it will be read from the source, it will be created in the target, but the group update will be skipped. The group will still have 9 members.
This is exactly what happened after running the Resync Job:
The numbers in Identity Authentication admin console prove it. There are 10 users provisioned from MS Azure AD (plus 1 IAS admin user) and 1 group.
You probably noticed that it is the Resync job that follows the Simulate one and produces the same results. Why is that?
The Simulate job provides the expected results of a Resync job - a job that reads all entities from the source system and provisions all entities to the target system. For comparison, the Read job reads all entities from the source system and provisions only new or updated entities to the target system.
Therefore, in some cases the predicted results of a Simulate job and the actual results of a Read job might differ in the statistics. For example, after provisioning those 10 users above to IAS, if you later update 3 of them (you modify their cell phones), expect the following statistics:
- The Simulate job will read 10 users and will update 10 users.
- The Resync job will read 10 users and will update 10 users.
- The Read job will read 10 users and will update 3 users.
The Simulate job predictions come true. Now, you make yours.
P.S. There is one important precondition for using the Simulate job, the properties autocompletion and transformations color coding – all demonstrated above. Your Identity Provisioning tenant must run on SAP Cloud Identity Services infrastructure. If it runs on Neo environment, it’s time to get your hands on the Migrate Identity Provisioning Tenant documentation and just do it.
It's so much worth it.
- SAP Managed Tags:
6 Comments
