The connection broker is a key component of any desktop virtualization (VDI) solution. Consequently a lot is being written about connection brokers, including detailed comparisons and high-level overviews. And yet, I could not find a clear-cut definition online of what a connection broker actually is. I, therefore, set out to provide such a definition in a series of articles, of which this is the first. In this series I will specify what a connection broker is, which services it must provide, and which additional capabilities to look for when selecting one.
At this point I must disclose that I work for Ericom Software, and that our flagship product PowerTerm WebConnect is a connection broker. The information provided in this article is a result of the research we conducted while developing this product.
The fundamental role of the connection broker is, of course, to broker connections. The connection broker maintains a list of available virtual desktops, and when a client makes a request it provides the client with the connection information for the most appropriate virtual desktop, or a response which indicates that an appropriate virtual desktop is not currently available. In many cases there are more than one appropriate virtual desktop, in which case the connection broker will provide the client with a list of possible candidates. The client will generally display this list to the user so that she or he can make a selection. The connection information provided by the connection broker to the client must contain the address of the virtual desktop, but may contain additional configuration information, such as which communication protocol to use and settings for that protocol.
One of the main benefits of virtualized environments is improved utilization of hardware resources. In the case of VDI this usually means that virtual desktops should be powered down or suspended when not in use in order to free up resources for other virtual desktops. The connection broker performs this task by monitoring the virtual desktops after they have been assigned, and instructing the virtualization host (hypervisor) to power them down or suspend them when they are idle or logged off. Conversely, the connection broker will also be required to instruct the hypervisor to power-up or resume a virtual desktop before providing its connection information to a client.
Most connection brokers do not present all the clients with an identical list of virtual desktops. Instead a specific, customized list is provided to each client. This means that the connection broker must be able to distinguish between clients both during configuration – when different virtual desktops are assigned to distinct clients – and at runtime when a client makes a request. This distinction is usually based on the identity of the user utilizing the client, for example by assigning a certain type of virtual desktop based on the user’s Active Directory / LDAP group associations. Another form of assignment, which is not always provided by connection brokers, but can be very useful, is assignment based on properties of the client device, such as its name or MAC address. This enables the association of a client device with a specific virtual desktop regardless of which user is utilizing that client.
The end-user identification process can also be used for authentication purposes. This enhances overall system security as it filters out unauthorized access requests before any connection to a virtual desktop is established. Connection brokers can also provide extended authentication services beyond those provided the virtual desktops themselves, such as two-factor authentication. If this is required then choose a connection broker that supports the RADIUS protocol, and is certified by a security provider such as RSA.
In upcoming articles I will continue this discussion and describe additional services that connection brokers must provide so stay tuned.