You 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.
External users must obtain, at minimum, the snc_external role. The
snc_external role indicates that the user is external to your organization and 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:
- Scripted REST API resources that are not marked external.
- Tables without the role that inherits the snc_external role or the
public role.
- Non-record type resources, such as processors and UI pages
without the snc_external role or a role that inherits the snc_external
role.
- Analytics, Intelligence, and Reporting dashboards.
Do not mark the snc_internal role as elevated. Otherwise,
internal users cannot access the instance.
Note: You can
Set up encryption
contexts with the snc_internal and snc_external roles. However, adding
encryption contexts to more detailed roles is recommended.
Recommended CSM roles for internal and external users
Customers (external users) using the Customer Service Management application should be
assigned either the sn_customerservice.customer or the sn_customerservice.consumer role.
Customer service agents (internal users) should be assigned either the
sn_customerservice_agent or sn_customerservice_consumer_agent role. Make sure that the same
user is not assigned both a customer (external) and agent (internal) role.
Note: Assigning
both external and internal roles to external users can create security issues as well as
performance issues.
Explicit Roles plugin
The Customer Service plugin (com.sn_customerservice) activates the Explicit Roles plugin
(com.glide.explicit_roles), which adds the snc_external and snc_internal roles. When the
plugin is activated:
Do not move System update sets among instances with and without the Explicit Roles plugin
enabled.
The glide.security.explicit_roles.internal_user_blacklist property
The Explicit Roles plugin assumes that all existing users in the sys_user table at the time
the plugin is installed are internal customers. A fix script assigns the snc_internal role
to all existing users and to any ACL that does not have a role.
The fix script may fail or may not finish in time for a user who has not been updated with
the role and who attempts to access a resource. To bridge this potential gap, the Contextual
Security Manager (CSM) auto-assigns the snc_internal role to any user who logs in and does
not have an explicit role (either internal or external).
Additionally, CSM has a business rule process that assigns the snc_external role to a
classification of their users. However, when importing large sets of CSM external customers,
workflow is set to false, so business rules don't run. As those users attempt to access a
resource, they do not have any explicit roles. The Contextual Security Manager assigns the
snc_internal role through a scheduled job called On-Call Gaps Conflicts Report that runs
every 7 days. When the Explicit Roles plugin is active, this job assigns the snc_internal
role to the CSM external user, since the user does not have either the snc_internal or
snc_external role.
To prevent inadvertently providing the snc_internal role to external users, the
Explicit Roles plugin includes a
glide.security.explicit_roles.internal_user_blacklist property to
blacklist user types from ever becoming snc_internal. If there are no users types in
the glide.security.explicit_roles.internal_user_blacklist table, the Contextual Security
Manager assigns all users the snc_internal role by default. If there are classnames in the
blacklist table, and if the sys_user class type is in the blacklist table, CSM assigns the
snc_external role. Otherwise, CSM assigns the default snc_internal role as usual.
For Orlando Patch 5 and later releases, this property is disabled by
default.
The hasRoles() method
The hasRoles()
method is still available, but is deprecated in the Geneva release. Use the
hasRole(role name)
method instead.
If you do use the
hasRoles()
method, note these changes:
- 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.
- If the user has the snc_external role, the method returns false
because the instance considers external users to be without a role.