This blog describes the Use Case when you have one IDCS or IAM Domain and want to provision another IDCS/IAM Domain(s) instance including an update for group memberships.
There are several articles, tutorials and blogs about the basic configuration available like these:
A-Team: https://www.ateam-oracle.com/post/managing-users-between-multiple-idcs-using-saml-and-scim
Tutorial: https://docs.oracle.com/en/cloud/paas/identity-cloud/tutorial-scim-template-sync-idcs/
The above described basic configs are assumed to be known. Although the configurations describe mostly IDCS they are 1:1 adaptable for IAM domains. Menuitems and field/fieldvalues are the same.
Motivation for this use case is that a straight forward IAM management should be implemented:
1. Defines a source IAM where users and group-memberships are managed and one or more IAM targetsystems are configured and changes applied
2. Control per User/Group in which targetsystem(s) the changes get transfered
3. As this is an extendable chain the source system can also be feeded by another IAM, like the OnPrem. This feed can even be done e.g. via synchronisation (Bridge) or SAML JIT (see further blog)
4. This works also for SaaS applications managed through target IAM (see further blog)
Overall it would like this:
Following steps are required:
starting point:
1. You have to be Identity Domain Admin (or User Admin + App Admin) in all IDCS/IAM Domain systems.
in (each) target:
2. Create and activate in target systems a confidential client with Role User Administrator (see previous links for HowTo)
3. Create or define one or more groups in target to be provisioned with memberships; remember these as you need them for configuration in step 8
in source:
4. Create and activate in source system per target a GenericSCIM App with Conf.Credentials (see previous links for HowTo)
5. After successful test of connection, configure provisioning except authorative source (this is standard setup)
6. Enable synch with schedule never and click Refresh Metadata (this will do only an internal metadata refresh needed for step 8, see screen at end of blog how this looks like)
7. In source per target system: Create or define groups in source where memberships should be propagated to targetsystem, define one group which will only do basic provsioning so without target group membership (needed for delete process)
8. Go for every created GenericSCIM App in section groups (see screen at end of blog how this looks like)
Assign the default source group, leave the template empty but do a save, group should then be listed
Assign further group(s) which is intended for target group membership: scroll down in template and press “add groups” – if none are shown either try after some minutes or repeat Refresh Metadata (step 6)
Select the target systems groups to get with this source group assigned
So in the end it should look like this with some groups:
For the test:
1. Create a user in source, do not assign a target mapped group: nothing in targets should happen
2. Assign the user one group which is assigned as accessgroup for SCIMClient or mapped to a target group: User should be created and optional group assigned
3. Deactivate User: user should be deactivated in target (same with activate)
4. Delete user with group in target: Error-message and should not work
5. Revoke a group which is associated in target: membership should be revoked except if it is the last group (seee Troubleshoot)
5. Revoke all groups from user in source which map to a target group, as last group remove the one without a target group association: User should be deleted
6. Delete user: User also deleted in source
Caveeat:
1. The user in target is not marked as federated, so it can be managed in target. To be not able to do a local login please adjust the target config & policies.
2. The license type might influence the intended behaviour, see section troubleshooting
3. Group assignments in target might affect delete of account, see section troubleshooting
Troubleshooting:
1. Changes get not propageted:
If changes for user attributes are not propagated check license type, as this works only with Standard (Dec 2022)
2. Activate/Deactivate does not work:
Check license type, as this works only with Standard (Dec 2022)
3. Remove of groups does not work
If the last remaining group in source will be removed and this groups contains an associated group in source this will fail
Add the source group with no associated target groups, then remove the source group with associated target group
4. Delete of User does not work
First see previous order of removing groups
Then check in target if the user has some access or groups assigned (like through All Tenant Users); remove these in target and retry delete
Documentation:
Screen Refresh Application Metadata (within Provisioning tab of SCIM App go for this button):
Assign Groups of target IAM (in SCIM App go for groups, select local/source group and scroll down in the new window for groups, use “add” -> in the new screen select group(s) from target system:
After Selection and Ok this should look like this, with Save it is applied (can be changed afterwards):
