Proxy Architecture Extends Microsoft IM Platform’s Reach

Proxy Architecture Extends Microsoft IM Platform’s Reach
With Live Communications Server 2005, Microsoft Corp. has developed a proxy architecture that gives administrators a means of connecting users outside the corporate network to the instant messaging network.

One of the key uses of this proxy architecture is to create federated domains. Using Live Communications Server access proxies, users on separate instant messaging networks and separate domains can communicate as if on the same network.
In addition to these federated relationships, the access proxies can be used to give users working at a remote location access to Live Communications Server without requiring them to run a VPN client; the proxies can also allow a server at a remote location to access the network without being on the WAN.

In either case, administrators have to establish a certificate authority and configure certificates on Live Communications Server and the access proxy. A company could configure a server in a remote location, such as a branch office, so that the server is both a Live Communications Server for local users and a point of connection to a Live Communications Server in another location. In the latter instance, companies should use a third-party certificate because there would not be an access proxy providing an additional layer of security.

After configuring certificates, administrators must configure Mutual Transport Layer Security between Live Communications Server and the access proxy server on Port 5061. Administrators will need to configure traffic running inbound to Live Communications Server and outbound to another proxy, Live Communications Server or the Messenger client on separate network interfaces.

Inbound communication must be routed to a next-hop server that provides authentication. In the most secure configuration, administrators should set up an access proxy to act as a system called a Director. The Director’s sole purpose is to route an external user’s access to an internal Live Communications Server for authentication.

Live Communications Server supports three types of federation: direct, clearinghouse and limited-clearinghouse. In the direct-federation model, companies establish one-to-one trusted relationships by configuring the access proxy to connect to a single domain by entering the fully qualified domain name. In the clearinghouse and limited-clearinghouse models, administrators create smaller groups of trusted relationships.

In a clearinghouse federation, the administrator points the access proxy to the domain of an external organization that provides routing services for a community, such as a trade group. A limited clearinghouse provides the same shared trusted community but also allows an organization to have a direct-federation relationship with another member of the community.