How Do I Set Up a Session Policy?
Note: When upgrading from a version of Bomgar previous to 14.1, some session policies may be auto-generated to maintain your existing functionality. For more information, see I'm Upgrading. What Has Changed?.
To create or edit a session policy, navigate to /login > Users & Security > Session Policies.
The Session Policies section lists available policies. Click the arrow by a policy name to quickly see where that policy is being used; its availability for users, rep invites, and Jump Clients; the support tools configured; and the prompting configured. To create a session policy, click Create New Policy, or Copy an existing policy.
Create a unique name to help identify this object. This name helps when assigning a session policy to representatives, public portals, and Jump items. Set a code name for integration purposes. If you do not set a code name, one will be created automatically. Also give this policy a description to further detail the permissions available in this policy. The description is seen when applying a policy to user accounts, group policies, embassies, embassy users, and rep invites.
In the Availability section, choose if this policy should be available to assign to users (user accounts, embassies, and group policies). Also select if it should be available for representatives to use when inviting an external representative to join a session and if it should be available to assign to Jump Clients. If this session policy is already in use, you will see the number of users, public portals, and Jump Clients using this policy.
For all of the permissions that follow, you can choose to enable or disable the permission, or you can choose to set it to Not Defined. Session policies are applied to a session in a hierarchical manner, with Jump Clients taking the highest priority, then support portals, then representatives, and then the global default. If multiple policies apply to a session, then the policy with the highest priority will take precedence over the others. If, for example, the policy applied to a Jump Client defines a permission, then no other policies may change that permission for the session. To make a permission available for a lower policy to define, leave that permission set to Not Defined.
Set which support tools should be enabled or disabled with this policy, as well as which tools should prompt the customer for permission. Permissions and support tools are described in more detail in the Bomgar Administrative User Guide.
Click Save Policy to make this policy available.
Additionally, you can export a session policy from one site and import those permissions into a policy on another site. Edit the policy you wish to export and scroll to the bottom of the page. Click Export Policy and save the file.
You may now import those policy settings to any other Bomgar site that supports session policy import. Create a new session policy and scroll to the bottom of the page. Browse to the policy file and then click Import Policy. Once the policy file is uploaded, the page will refresh, allowing you to make modifications. Click Save Policy to make the policy available.
Policies for Specific Object Types
You may find it helpful to create session policies for specific types of objects. For example, create a session policy to be used only for certain Jump Clients and another only for a particular support portal. To help you remember which policies are created for which objects, preface the name of the session policy with the object type for which you have created the policy (e.g., "[Jump Client] Screen Sharing Only").
Only Essentials Defined
When defining session policies, set only the permissions you know are required for a given scenario. Be careful which permissions you allow, especially when defining policies for Jump Clients or support portals. Remember that allowing a permission for a higher-ranking session policy means that permission is available in the session, even if the representative's account disallows that permission. This effectively grants the representative permission to perform an action he or she is not normally allowed to do.
The contrary also holds true. For example, if you deny a Jump Client a permission unnecessarily, then even a highly privileged representative will be unable to perform that action.
Specifically when configuring Jump Client or support portal session policies, set only what you know needs to be set, and leave all other permissions undefined. This allows those permissions to fall through to the next level, where the next applied session policy can allow or deny those permissions as appropriate.
Lowest Privileges for Global Policy
Ideally, a session's permissions should be set by its applied policies and should never reach the global default policy. However, because the global default session policy is the fallback policy for all sessions, set the permissions in this policy to the lowest privileges you would wish to allow. Any permissions which should be available for every representative in every possible session may be set to Allow. However, for any permissions which should be denied to some representatives or which should be disallowed for some end-users, set the policy to Deny.