{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":41166,"path":"platform-security/explicit-roles.md","title":"Explicit Roles","bundle":null,"doc_type":null,"release":"australia","body":"\n# Explicit Roles\n\nYou can give both internal users and external users access to your instance. However, you might not want both types of users to have the same level of access. To provide added security, every user must have at least one role so that the instance can distinguish between internal and external users.\n\nAs of the Paris release, no user can have both of the explicit roles \\(snc\\_internal and snc\\_external\\). Groups and role containment cannot include both roles, either, since that would cause any group member or user who is assigned to such a group or such a role to automatically have both roles. The ServiceNow AI Platform aborts any operation that would create such a scenario.\n\n**Note:** You cannot add any other roles as contained roles to the \"**snc\\_external**\" or \"**snc\\_internal**\" roles.\n\nExternal users must obtain, at minimum, the snc\\_external role. The snc\\_external role indicates that the user is external to your organization. They should not have any access to resources unless explicitly allowed through ACLs for the snc\\_external role or additional roles that inherit the snc\\_external role. By default, users with the snc\\_external role cannot access:\n\n- Tables without the role that inherits the snc\\_external role or the public role.\n- Non-record type resources, such as processors and UI pages without granting access to the snc\\_external role or a role that inherits the snc\\_external role.\n- Platform Analytics dashboards.\n\nDo not mark the snc\\_internal role as elevated. Otherwise, internal users cannot access the instance.\n\n## Explicit Roles plugin\n\nWhen the Explicit Roles plugin is activated:\n\n- All users must have the snc\\_internal role to access internal resources or the snc\\_external role to access external resources. Users without either explicit role can access only public resources.\n- All existing users are automatically assigned the snc\\_internal role. This role does not change existing access levels or system behavior. Instead, it provides a category to differentiate internal users from external users. All internal users maintain the same level of access as before the plugin was activated.\n\n **Tip:** To prevent changing existing functionality for users, activating the Explicit Roles plugin assigns the snc\\_internal user role to all existing users in the instance. This includes any external users added before the Explicit Roles plugin was activated. After the Explicit Roles plugin is activated, do the following for all external users added before the Explicit Roles plugin was activated:\n\n - Remove the snc\\_internal role.\n - Add the snc\\_external role.\n Doing the preceding ensures that external users added before activating the Explicit Roles plugin do not have access to internal resources that should be available only to internal users.\n\n- Newly created users are automatically assigned the snc\\_internal role when they first attempt to log in to the instance, unless they have been explicitly assigned the snc\\_external role. You can add the snc\\_external role to a new user before they first log in to the instance to provide external user rights.\n\n **Important:**\n\n Activate this plugin during a maintenance window or when few users are logged in. Users currently logged in when the plugin is activated will not be dynamically assigned the snc\\_internal role. Rather, users must log out and log back in to be assigned the snc\\_internal role. Once the plugin is activated, you can add or remove the snc\\_internal and snc\\_external roles at any time to change user rights.\n\n After the plugin is activated, any time a user logs in, the user is given the snc\\_internal role if the account does not already have that role, or the snc\\_external role. This includes users logged in via impersonation.\n\n- All existing ACLs that do not have a role requirement are automatically assigned the snc\\_internal role. Because both existing ACLs and users are assigned the snc\\_internal role, existing access levels do not change.\n- Newly created ACLs that do not have a role requirement are automatically assigned the snc\\_internal role. This role assignment does not apply to a newly created ACL with a role assigned.\n- For all existing Processor \\[sys\\_processor\\] records or newly created Processor \\[sys\\_processor\\] records with **Type=script**, the snc\\_internal role is automatically added to the **Roles** field if the field is empty.\n- To restrict access to UI pages to internal users, the plugin automatically assigns the snc\\_internal role to the **\\*** ACL with a **Type** of **ui\\_page**.\n- To restrict access to processors to internal users, the plugin automatically assigns the snc\\_internal role to the **\\*** ACL with a **Type** of **processor**.\n- External users must obtain, at minimum, the snc\\_external role to access the instance. This role must be manually granted to external users. Access to records is granted through ACLs.\n\nDo not move system update sets among instances with and without the Explicit Roles plugin enabled. For more information, see [System update sets](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/application-development/system-update-sets.md).\n\n**Note:** This plugin also requires the [Contextual Security Manager](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/platform-security/access-control/r_ContextualSecurity.md) plugin.\n\n## glide.security.explicit\\_roles.do\\_not\\_fix behavior\n\nAs of the Xanadu release the `glide.security.explicit_roles.do_not_fix` has been adjusted with changes to snc\\_internal. The snc\\_internal role is now the same both in memory and in sys\\_user\\_has\\_role. The new behavior for `glide.security.explicit_roles.do_not_fix` is:\n\n|Value|Result|\n|-----|------|\n|False|Add snc\\_internal role both in memory and sys\\_user\\_has\\_role|\n|True|Do not add snc\\_internal role in memory or sys\\_user\\_has\\_role|\n\nTo exclude snc\\_internal role for certain users, use the `glide.security.explicit_roles.ignore.snc_internal.exclude_role_list` property.\n\n**Tip:** To revert to previous `glide.security.explicit_roles.do_not_fix` behavior use the `glide.security.explicit_roles.do_not_fix_in_memory` property.\n\n## Providing table access to external users\n\nYou can provide external users access to a table by adding a role to the table that inherits the snc\\_external role. For more information, see [Provide external users access to a table](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/customer-service-management/t_ProvideExternalUsersAccessToTables.md).\n\n## The hasRoles\\(\\) method\n\nThe `hasRoles()` method is still available, but is deprecated in the Geneva release. Use the `hasRole(role name)` method instead.\n\nIf you do use the `hasRoles()` method, note these changes:\n\n- This method automatically excludes the default snc\\_internal role when it checks for roles. This means that if a user has only the snc\\_internal role, the `hasRoles()` method still returns **false**.\n- If the user has the snc\\_external role, the method returns **false** because the instance considers external users to be without a role.\n\n## Mutual exclusion: snc\\_external versus snc\\_internal\n\nThe ServiceNow AI Platform prevents users from having both the snc\\_external role and the snc\\_internal role. The ServiceNow AI Platform applies this mutual exclusion everywhere in the system and writes error messages to the logs for each conflict.\n\n**Note:** ACLs can have both roles if the ACL resources should be accessible to all users.\n\nExample: Adding both explicit roles to a user \\(direct collision\\):\n\n1. Assign user Abel Tuter the snc\\_internal role.\n2. Assign user Abel Tuter the snc\\_external role.\n\nResult: Adding the snc\\_external role fails because Abel Tuter has the snc\\_internal role.\n\nExample: Adding both explicit roles to a group \\(direct collision\\):\n\n1. Consider a group called Test Group that currently has no explicit roles assigned to the group.\n2. Add Abel Tuter to the Test Group.\n3. Add the snc\\_external role to Test Group.\n\nResult: Adding the snc\\_external role fails because Abel Tuter already has the snc\\_internal role and can't have both roles.\n\nExample: Adding an explicit role to a group where a group member has the conflicting explicit role \\(indirect collision\\):\n\n1. Assign user Abel Tuter the snc\\_internal role.\n2. Consider a group called Test Group that currently has no explicit roles assigned to the group.\n3. Add Abel Tuter to the Test Group.\n4. Add the snc\\_external role to the Test Group.\n\nResult: Adding the snc\\_external role to the group fails because Abel Tuter would inherit the snc\\_external role through group membership. Both explicit roles would be assigned to the same user, which isn't allowed.\n\nFor other examples, see the following table:\n\n\n
\n\nRole\n\n\n\nAttempted action\n\n\n\nResult\n\n
\n\nDirect collision\n\n
\n\nThe user has the snc\\_internal role.\n\n\n\nAdd the snc\\_external role.\n\n\n\nThe action is aborted.\n\n
\n\nThe user has the snc\\_external role.\n\n\n\nAdd the snc\\_internal role.\n\n\n\nThe action is aborted.\n\n
\n\nThe user has no explicit role.\n\n\n\nAdd the snc\\_internal or snc\\_external role.\n\n\n\nThe role is added.\n\n
\n\nThe user has both explicit roles \\(existing collision\\).\n\n\n\nAdd the user to a group with no roles.\n\n\n\nThe action is aborted.\n\n
\n\nA role not associated with any users contains the snc\\_internal role.\n\n\n\nAdd the snc\\_external role.\n\n\n\nThe action is aborted.\n\n
\n\nA role not associated with any users contains the snc\\_external role.\n\n\n\nAdd the snc\\_internal role.\n\n\n\nThe action is aborted.\n\n
\n\nA role contains both explicit roles \\(existing collision\\).\n\n\n\nAdd the role to a user, role, or group.\n\n\n\nThe action is aborted.\n\n
\n\nA group with no members has the snc\\_internal role.\n\n\n\nAdd the snc\\_external role.\n\n\n\nThe action is aborted.\n\n
\n\nA group with no members has the snc\\_external role.\n\n\n\nAdd the snc\\_internal role.\n\n\n\nThe action is aborted.\n\n
\n\nA group with no members has no roles.\n\n\n\nAdd the snc\\_internal or snc\\_external role.\n\n\n\nThe role is added.\n\n
\n\nIndirect collision\n\n
\n\nRole containment with collision\n\n\n\n1. Grant a role called Test Role to a user with the snc\\_internal role.\n2. Add the snc\\_external role Test Role.\n\n\n\nThe action is aborted.\n\n
\n\nRole containment without collision\n\n\n\n1. Grant a role called Test Role to a user with no roles.\n2. Add the snc\\_external role to Test Role.\n\n\n\nThe role is added to both the user and Test Role.\n\n
\n\nGroup containment with collision\n\n\n\n1. Add a user who has the snc\\_internal role to a group called Test Group 2 \\(child of Test Group 1\\).\n2. Add the snc\\_external role to Test Group 2.\n3. Add the snc\\_external role to a parent group called Test Group 1 \\(parent of Test Group 2\\).\n\n\n\nThe action is aborted.\n\n
\n\nGroup containment without collision\n\n\n\n1. Add a user with no roles to a group called Test Group 2 \\(child of Test Group 1\\).\n2. Add the snc\\_external or snc\\_internal role to Test Group 1 \\(parent of Test Group 2\\).\n\n\n\nThe role is added to the parent group, the child group, and the user.\n\n
\n\nGroup containment plus role containment with collision\n\n\n\nAdd contains\\_external to Test Group 1, the parent of Test Group 2.\n\n\n\nTest Group 1 and Test Group 2 both get contains\\_external, but don't explicitly get the snc\\_external role.\n\n
\n\nAdd the snc\\_internal role to Test Group 2, the child of Test Group 1.\n\n\n\nThe action is aborted.\n\n
\n\nGroup parent change plus group containment\n\n\n\n1. Remove Test Group 1 as the parent of Test Group 2.\n2. Add the snc\\_internal role to Test Group 1.\n3. Add the snc\\_external role to Test Group 2.\n4. In Test Group 2, set Test Group 1 as the parent group and save.\n\n\n\nThe action is aborted.Repeat for already nested groups, with the same expectation.\n\n
The cause of an aborted action appears in the error message and must be addressed before another attempt succeeds.\n\nFor direct cases, such as adding an explicit role to an individual user, verify which explicit role the user should have. If the user has the wrong explicit role, it must first be removed, and then the correct explicit role must be added.\n\nFor indirect cases,such as adding an explicit role to a group \\(so that a group member would be assigned both explicit roles\\), evaluate whether that user should be in the group. Also determine whether the group should be given the explicit role, including any inheritance through group hierarchy and role containment.\n\nNote that the ServiceNow AI Platform reports only the first potential collision encountered. If repeated attempts continue to fail after remediation, with a new root cause each time, re-evaluate the relevant user/group/role interdependence more broadly. You may want to rethink how groups and role containments are structured.\n\n## Request Explicit Roles\n\nActivate Explicit Roles by requesting the Explicit Roles plugin \\(com.glide.explicit\\_roles\\) through the Now Support Service Catalog.\n\n### Before you begin\n\nRole required: admin\n\n**Important:** Activate this plugin during a maintenance window or when few users are logged in. Users currently logged in when the plugin is activated will not be dynamically assigned the snc\\_internal role. Rather, users must log out and log back in to be assigned the snc\\_internal role. Once the plugin is activated, you can add or remove the snc\\_internal and snc\\_external roles at any time to change user rights.\n\n### Procedure\n\n1. Navigate to **All** > **System Applications** > **All Available Applications** > **All**.\n\n2. Select **Request plugin** to open the **Activate Plugin** form on Now Support.\n\n3. On the **Activate Plugin** form, provide the following information.\n\n\n
\n\nField\n\n\n\nDescription\n\n
\n\nWhat is your target instance\n\n\n\nSelect the instance that you want to activate the plugin on.\n\n
\n\nWhich plugin would you like to activate\n\n\n\nSelect the name of the plugin to activate.\n\n **Note:** If the plugin isn't listed, or if you're activating on an OEM or on-premise instance, select the **Plugin I'm looking for is not listed** check box. Enter the plugin name in the field that appears.\n\n
\n\nSelect Maintenance Date and Time\n\n\n\nSelect the date and time to activate the plugin.\n\n
For example, see the following form to activate the Event Management plugin on an instance named SNC Instance.\n\n4. Select **Submit**.\n\n After the maintenance window, the system installs the plugin on your instance. To confirm the installation, go to the Installed tab in the Application Manager.\n\n\n"}}