Use Microsoft Office Communications Server to create a trusted service for Unified Communications Managed API applications. There are two different types of trusted applications: registered and peer.

Configuring Trust of a Server Host with Office Communications Server

Use Office Communications Server to configure trust for registered applications and peer applications.

Configuring Trust for a Registered Application and Peer Application

For a Unified Communications Managed API application to take advantage of special permissions available to Office Communications Server trusted applications, use the Host Authorization tab on the Office Communications Server property page to configure the server to trust a connection to a specific application, and to treat traffic from the application as another server. The following permissions can be used to configure the authorized host entry:

Permission	Description
Treat As Authenticated	Select this option to allow the application to send requests to Office Communications Server without being challenged.
Throttling As Server	Select this option to substantially increase the maximum number of outstanding SIP requests for the endpoint at any given time. By default, Office Communications Server uses a limit of 20 outstanding SIP requests when enforcing client throttling for an endpoint.

For more information, in the Microsoft Office Communications Server 2007 Administration Guide, see "Configuring Authorized Hosts."

Note:
By default, Office Communications Server trusts the host that manages the computer running the Unified Communications Managed API trusted application. To improve security, administrators can use Mutual Transport Layer Security (MTLS) to implement a fully-qualified domain name (FQDN) for the host.

Using MTLS

For security reasons, we recommend that applications use MTLS which requires the administrator to supply the FQDN of the host for the Unified Communications Managed API trusted application. We recommend that the application pass the local FQDN rather than letting the Unified Communications Managed API platform choose the default, which is based on first entry using Domain Name System (DNS) directory assistance.

The administrator must also specify to the application which local certificate from the local computer certificate store to use. It is also assumed—to ensure that the certificate used by Office Communications Server is issued by an authority trusted by the application host—that the root certificate chain is adequate to deploy the application against Office Communications Server.

Configuring Registered Applications

To maximize trust and handle routing for a registered Office Communications Server application such as IM Bots, implement an Active Directory user object.

Configuring Routing for a Registered Application

The Office Communications Server administrator should create an Active Directory user object for the application and enable the user for Office Communications Server. This approach ensures that the user object gets replicated in the Office Communications Server database. The administrator may choose, for example, sip:Someone@Example.com as the address of record. For more information, in the Microsoft Office Communications Server 2007 Administration Guide, see "Enabling User Accounts for Office Communications Server."

After replicating in the Office Communications Server database, the application's registration creates an entry in Office Communications Server registrar. Office Communications Server full-state proxy can then reach the registered endpoint every time it is contacted by a user through the application's address of record, for example sip:Someone@Example.com.

Configuring Peer Applications

To optimize trust and handle routing for an Office Communications Server peer application, for example, the Broadcast IM sample, large scale chat rooms, or data federation, implement a SIP domain or create a static route.

Configuring Routing for a Peer Application

Routing to a Unified Communications Managed API Office Communications Server trusted peer application requires more configuration steps than a registered application, but gives the application more availability. In the case of a peer application, multiple Front End servers of a given Office Communications Server pool can route to it, while only one Front End server can route to a registered application.

Creating a SIP Domain

When a trusted peer application needs to receive incoming traffic, it needs Office Communications Server to route traffic to it. Conversely, the Broadcast IM sample is a peer application that is outbound only and does not need to receive inbound traffic. However, in the case of a large-scale chat room there will be incoming traffic.

Administrators typically create a dedicated SIP domain for an application that needs to be routed to by Office Communications Server. For more information, in the Microsoft Office Communications Server 2007 Administration Guide, see "Specifying Supported Internal SIP Domains."

Creating Static Routes

In Office Communications Server, the administrator can configure the static route by specifying the association of the SIP domain described previously in "Creating a SIP Domain" with the FQDN and port used by the trusted peer application. The administrator should select TLS for the Transport option. With this approach, the administrator can determine that an incoming request to, for example, sip:Someone@Example.com is routed to the remote tuple (FQDN, port, TLS) specified in the static route configuration. For more information, in the Microsoft Office Communications Server 2007 Administration Guide, see "Configuring Static Routes for Pools."