Learn how to migrate users and roles from Cortex XSOAR 6 to 8.
In Cortex XSOAR 6, management of users and roles is undertaken exclusively in the Cortex XSOAR instance. In Cortex XSOAR 8:
Users are created in the CSP.
Administrators can manage users, roles, user groups, and SSO in the instance and in the Cortex Gateway,
When migrating from Cortex XSOAR 6 to Cortex XSOAR 8, you should review and update your access management settings, user roles, and permissions to ensure they align with the new RBAC model and access management features.
For more information about how to manage users and roles in Cortex XSOAR 8, see Users and Roles Management .
Note
SAML-authenticated tasks are supported.
Self-service read-only users are not supported by Cortex XSOAR 8 and will not be migrated.
Users and Roles Differences between Cortex XSOAR 6 and 8
Feature | Cortex XSOAR 6 | Cortex XSOAR 8 |
|---|---|---|
Users | Can belong to multiple roles | Users can belong to only one role, but can belong to multiple user groups. |
Users | The primary identifier is the username. | The primary identifier is the email address. Usernames are not used in Cortex XSOAR 8. |
Users | Default Admin | There is no Default Admin in Cortex XSOAR 8. Some permissions granted to Default Admins in Cortex XSOAR 6 are now granted only to users with Instance Administrator or Account Admin roles. This includes access to:
|
User Groups | Not supported | Administrators can create and manage groups of users and assign them specific roles and permissions in a single operation. User groups can include multiple users and nested groups, which inherit the permissions of parent user groups. Administrators also can map groups from an organization's identity provider (IDP) and see details such as created date, updated date, and assigned roles. |
Roles | In server | Includes out-of-the-box roles, such as Instance Administrator, Account Admin, Analyst, and Read-Only, with specific access rights that cannot be changed. You can view and manage permissions in the instance or in the Cortex Gateway, |
User Management | In server | In the Cortex XSOAR 8 instance or in the Cortex Gateway, you can view and manage permissions, role-based access control (RBAC), and user group settings. In Cortex XSOAR 6, administrators may have the Users and Roles permission, which includes invitations and editing permissions. In Cortex XSOAR 8, only administrators have user editing permissions. |
User Migration
Cortex XSOAR 6 users are migrated as follows:
SSO users: Users will be created after they log in for the first time. When they log in, all their additional data is available such as dashboards, and preferences.
Cortex XSOAR 6 local users: Local users (including the default admin) with a defined email address are migrated to the Palo Alto Networks' CSP (unless already registered, or using a third-party integrated SAML). These users are designated the PANW IDP user type. All of these users are synced to the Cortex Gateway and set as disabled until the cutoff date.
Note
The PANW IDP user type is created during the migration process and cannot be recreated. If you delete the user with this user type, you cannot create a user with the PANW IDP user type, but instead create a regular user in the CSP with the same permissions.
Ensure that all local users that you want to migrate, including the default admin, have an email address in Cortex XSOAR 6. An email address is the primary identifier for the user in Cortex XSOAR 8. Without defined email addresses in Cortex XSOAR 6, local users (including the default admin) are not migrated. If you want to migrate users without a defined email address, add an email address before the migration process begins, or add them manually after migration, by creating a CSP account and then assigning them a relevant role.
If an invitation was sent to a user in Cortex XSOAR 6 and the user did not accept the invite before the migration, that user is not migrated to Cortex XSOAR 8.
After migration, the PANW IDP users (previously local users) receive an email asking them to complete their registration for the CSP, unless they are already registered, or use a third-party integrated SAML. Until the users accept the invitation email, they cannot access Cortex XSOAR 8, and will appear as grayed out in the UI. When the user accepts the invite, the user becomes an active user.
All users that were enabled in Cortex XSOAR 6, are enabled in Cortex XSOAR 8. Users that were configured as disabled in Cortex XSOAR 6, remain disabled in Cortex XSOAR 8. Any new users that were created in Cortex XSOAR 6 after the initial data sync are not migrated at cutoff and must be added manually.
Note
Users can access the Cortex XSOAR 8 instance if they are registered CSP users or if they have access through SSO to the instance with SAML. SAML users do not receive an invite email but have access to the Cortex XSOAR 8 instance after the migration is complete. Cortex XSOAR 6 local users receive an invitation email to the CSP when the migration is complete.
User Roles Migration
Both Cortex XSOAR 6 and 8 come out-of-the-box with predefined roles (Administrator, Analyst, and Read-only). In Cortex XSOAR 8 Administrators can be Instance Admins or Account Admins. Account Admins have access to all Cortex instances but the Instance Admin only has access to a specific instance.
Note
During the User Acceptance Testing (UAT) phase, only Admin roles can access the Cortex XSOAR 8 UAT instance. You can invite more users to access the UAT instance provided they have been assigned the Account Admin or Instance Admin user role. To give them access, go to → → → , select the user, and then select the Activate option. The user will then receive an email about how to log in.
You should review all users and roles and permissions.
User Groups
In Cortex XSOAR 6, a user can have multiple roles (there are no user groups). For example, a user can be an Analyst and a Content Developer. In Cortex XSOAR 8, a user can have a single role and belong to multiple user groups, where each group has a role. During the migration process, existing Cortex XSOAR 6 users with multiple roles are converted to assigned roles within a user group with corresponding roles. For example, in Cortex XSOAR 6, User A has three roles: Employee, Analyst, and Content Developer. When migrating, Cortex XSOAR 8 creates the following:
User groups: Employee, Analyst, and Content Developer
User Roles: Employee, Analyst, and Content Developer
User roles are assigned to the user groups, so the Employee role is assigned to the Employee user group, the Analyst role is assigned to the Analyst user group, and the Content Developer role is assigned to the Content Developer user group. User A is assigned to the Employee, Analyst, and Content Developer user groups.
Nested Roles
Roles are nested the same in Cortex XSOAR 6 and 8, but how nesting works is different.
Cortex XSOAR 6 uses basic role nesting, where the role with higher permissions includes the role with lower permissions. For example, the Admin role includes the Analyst role permissions.
Cortex XSOAR 8 uses group nesting, where the group with higher permissions includes the permissions of the group with lower permissions, but as a subset of the group with lower permissions. For example, the Admin user group is included as a subset of the Analyst user group, as shown in the following graphic. The Admin role includes the permissions of the Analyst role, the same as in Cortex XSOAR 6.
For example, from the user group example above, we have three roles:
Employee
Content Developer
Analyst
In Cortex XSOAR 6, the Employee role is nested in the Content Developer role and is also nested in the Analyst role.
In Cortex XSOAR 8, the Employee, Content Developer, and Analyst roles and user groups are created separately. The Content Developer and Analyst user groups are nested in the Employee user group rather than the Employee role being nested in Content Developer and Analyst roles as in Cortex XSOAR 6.
SAML and SSO
In Cortex XSOAR 6, to configure SAML 2.0, you need to create and enable a SAML 2.0 integration instance. In Cortex XSOAR 8, you no longer need to do this, as it is replaced by the SSO management configuration. See Configure Single Sign-On Using SAML 2.0.
The SSO management configuration is added to Cortex XSOAR 8, but is disabled during the UAT. You can enable the SSO settings and use the Switch to XSOAR 8 Configurations option to reconfigure it during the UAT or after the cutoff date. If you do not update the SSO settings during the UAT process, the settings will be enabled during the cutoff date.
SSO and authorization for communication tasks rely on the URL defined on the IDP, which points to the Cortex XSOAR 6 (AWS) URL. To avoid any issues, a migration proxy is automatically set up during the UAT phase and is available for six months from the cutoff date. To remove the dependency on the migration proxy, for SSO you need to configure the SSO settings in Cortex XSOAR 8. Although this can be done after migration, we recommend configuring and enabling the SSO settings in Cortex XSOAR 8 during the UAT phase.
Before changing your SSO configuration for Cortex XSOAR 8, confirm you have at least one active CSP user with the Instance Admin or Account Admin role, to prevent being locked out of Cortex XSOAR if there is an SSO configuration error.
To change your SSO configuration, go to → → → . By default, the SSO Integration (Imported from XSOAR 6) is enabled, but cannot be edited.
Switch to XSOAR 8 Configurations and follow the instructions to Configure Single Sign-On Using SAML 2.0. If you are using Okta or Azure AD as your IdP, follow the instructions specific to your IdP.
If you create a new application in your IdP (you need to use a new application if you perform a change during the UAT process) use the same settings as in the original application used by Cortex XSOAR 6, such as group filtering. The only differences are the URL and tokens/certificates.
If after switching, you have any issues with your Cortex XSOAR 8 SSO configuration, you have the option to revert to the Cortex XSOAR 6 configuration. This option is only available during the UAT and the six-month post-migration period, and should only be used while troubleshooting your Cortex XSOAR 8 SSO configuration.