Session Policy Use Cases

Diverse Group of Clients

In this use case, your organization supports a diverse group of clients. Among your clients are a warehouse and a bank, which have very different security requirements. The primary support goal of the warehouse is for you to resolve their issues as quickly as possible, which means that they want you to have full control of their systems with only one prompt. On the other hand, the bank's primary goal is security, which means they want you to have view-only access and to prompt for each permission.

While you could assign specific representatives to handle each client, doing so would be an inefficient use of your support staff. It is more effective to allow your entire support staff to interact with all of your clients.

With session policies, a representative can handle sessions with permissions assigned from the support portal through which the session originated. Configure session permissions for the warehouse in one policy and permissions for the bank in another. Then apply the first policy to the warehouse portal and the second policy to the bank portal. Now, any session coming through the warehouse portal will have the warehouse permissions applied, and any session coming from the bank portal will have the bank permissions applied.

These portal-specific permissions will override representative permissions. Any undefined permissions will fall through to be defined first by representative permissions and then by the global default session policy.

Desktop and Server Jump Clients

In this use case, you have a number of Jump Clients installed on two different types of machines: servers and end-user computers. Company policy requires that end-users are always prompted before representatives can gain access. However, prompting prohibits access to servers because no end-user is there to respond to the prompt.

Configure two session policies: one that requires prompting and one that never prompts. Apply the first session policy to end-user Jump Clients and the second to server Jump Clients. Now, when a representative Jumps to an end-user system, the user will be prompted for permission. When the same representative Jumps to a server, no prompting will occur.

These Jump Client-specific permissions will override public portal permissions and representative permissions. Any undefined permissions will fall through to be defined first by public portal permissions, then by representative permissions, and finally by the global default session policy.