How Do Session Policies Work?
From the /login administrative interface, create session policies to apply to objects within Bomgar. Once applied, these policies are layered each time a session starts, and the results of the layered policies determine the permissions for each session. To create session policies, see How Do I Set Up a Session Policy?.
Order for Applying Session Policies
Session policies are applied in a specific order. This order is hard-coded by Bomgar and cannot be changed, and higher priority policies cannot be overridden. The order in which policies are applied is:
- Jump Client
- Public Portal
- Global Default
The first applied session policy that defines a setting is used for that setting. If a lower policy also defines that setting, the second policy's setting is ignored.
Any permissions that are left undefined by the first applied policy may be defined by the next policy in the list. If the first applied policy defines all permissions, then none of the lower policies will define any permissions. If no policies are defined for the session, then the global default policy will define all permissions. Because the global default sets all undefined permissions, all permissions within the global default policy must be defined.
A session policy can be applied to a Jump Client. When a session is started through this Jump Client, the applied session policy sets the permissions that are available within this session. Any permissions that are not defined by the Jump Client session policy can be defined by a lower policy (i.e., public portal policy, representative policy, or global default policy).
Jump Clients deployed from the mass deployment wizard of the /login interface can be assigned a session policy during creation.
To assign a session policy to a Jump Client deployed within a support session, first customize the Jump Client.
You can change the session policy for a deployed Jump Client from the Jump Client interface of the representative console. View the Jump Client properties and select the session policy.
A session policy can also be applied to sessions that come through a specific public portal. This most notably affects ad-hoc sessions. If you have multiple public portals, then the session permissions may differ depending on which public portal your customer used to start a session with you.
Because Jump Clients and Bomgar Buttons are associated with public portals, this also affects sessions started through either of these methods.
A session policy is assigned to a public portal from the /login > Public Portals > Customer Client page.
When a Jump Client is deployed within a support session, the Jump Client is by default associated with the same public portal as the support session. To change this, first customize the Jump Client and select a public portal from the properties dialog. All future sessions started from this Jump Client will be associated with the selected public portal. Jump Clients deployed from the mass deployment wizard of the /login interface are also associated with a public portal, selected before deployment. You can change the public portal for a deployed Jump Client from the Jump Client interface of the representative console. View the Jump Client properties and select the public portal.
Note: According to the order of application, the Jump Client's session policy is applied before the public portal's session policy.
Bomgar Buttons can also be associated with a public portal. When deployed within a support session, the Bomgar Button is by default associated with the same public portal as the support session. Bomgar Buttons deployed from the mass deployment wizard of the /login interface are also associated with a public portal, selected before deployment. You can change the public portal for a deployed Bomgar Button from the Bomgar Button management interface of the representative console. Edit a Bomgar Button and select the public portal.
Note: Session policies cannot be directly associated with specific Bomgar Buttons. However, based on the order of application, the session policy for the Bomgar Button's public portal will be applied before any other session policies.
Jump To sessions (started via Jumpoint or local push) are also affected, although all Jump To sessions are associated with the default public portal and cannot be changed. However, if you have assigned a session policy to your default public portal, that session policy will by association be applied to Jump To sessions.
A session policy can be applied to a representative by means of his or her user account, group policy, embassy, embassy user account, or rep invite profile. For all user objects other than rep invites, you can define separate policies for attended and unattended sessions run by this representative. Attended session policies apply to customer-initiated sessions and sessions started via Bomgar Button. Unattended session policies apply to sessions started through a Jump Client, Jumpoint, or local Jump.
Finally, the global default session policy must be defined. All permissions undefined by more highly ranked policies (i.e., Jump Client policies, public portal policies, representative policies) will be set by the global default. Therefore, this policy cannot be deleted, and all permissions within this policy must be defined. Even if all of the policies applied to a session leave one or more permissions undefined, the global default policy ensures that those permissions will still be defined for the session. This policy comes pre-defined with all permissions set to the lowest possible permission level. You may modify these settings as appropriate for your organization.
Applying Session Policies
When configuring a representative (user account, group policy, embassy, or embassy user), the administrator has three options for applying a session policy. When configuring a public portal or Jump Client, only the first two options are available. When assigning a rep invite profile, only the first option is available.
- Use a previously-defined session policy.
- From /login > Users & Security > Session Policies, session policies can be created independently and can then be applied to objects within Bomgar. You may not set individual permission options for the object to which a session policy is applied.
- When applying a session policy to a representative within the /login interface (user account, group policy, embassy, or embassy user):
- Selecting a session policy displays its description and a read-only view of its permissions.
- If you wish to modify the selected policy, click Edit. This will take you to the Session Policies page, where you can edit the permissions set. Be aware that changing this policy will change the permissions for all objects that use this policy.
- If a permission is undefined within the session policy, then the lower policies set that permission. If no other assigned policies set that option for the session, then the global default policy's rule is applied.
- Do not associate a session policy.
- Because no session policy is set for this object, the lower policies must define the permissions for the session.
- If other session policies are defined but leave some permissions undefined, then the global default policy's rule is applied to those permissions.
- If no other session policies are defined, the system will fall back to the global default policy.
- Define custom session permissions that are valid only for the object currently being configured.
- No externally defined session policy applies. You set each permission individually.
- If a permission is undefined, then the lower policies set that permission. If no other assigned policies set that option for the session, then the global default policy's rule is applied.
- If no session policies are available to be assigned to user objects, then each permission must be defined.
Furthermore, when configuring a representative, you can choose to define one policy for attended sessions and another for unattended sessions. You can also choose to apply the same permissions to both. Additionally, if configuring custom settings for both attended and unattended policies, you can copy the settings from one to the other.
Note: Attended session policies apply to customer-initiated sessions and sessions started via Bomgar Button. Unattended session policies apply to sessions started through a Jump Client, Jumpoint, or local Jump.