Role conflicts

A role conflict means that the synchronization process has found that the system it is currently attempting to federate has at least one role name in common with the system to which it is being federated. The wizard presents the following choices.

  • Ignore all conflicts: The default behavior is applied to all conflicts.

    In this case, the default behavior results in the roles being merged so that they contain all security classes for the role on each system. All users from both systems are assigned the role.

    Take this action if you know that the role provides access to classes that users on both systems should have.

    This action could have potential security risks. For example, if you have a role on System A called "AppAdmin" that gives access to all programs and data in the AP system. On System A this role is assigned to the AP department managers. On System B, you also have a role called "AppAdmin" that gives access to all programs and data in the Talent Management system that is assigned to HR managers. If you selected "Ignore all conflicts" in this case, the AP managers would be able to see confidential HR information and HR managers would have access to enterprise vendor payment tools.

  • Rename the role on the "local" machine (the machine that you are federating to)

    Or

    Rename the role on the "remote" machine (the machine that you are federating)

    Using the AppAdmin role as an example again and assuming that System B is the remote machine in this case, if you select Rename the role on the remote machine (new name = HRAppAdmin), the federated machines would retain the role AppAdmin role (full access to enterprise vendor payment tools) and System B users would be removed from the role. The role HRAppAdmin would also exist on the federated systems and only the users of the "old" AppAdmin role would be attached to it.

    Role conflicts example