Communication Channels
This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.
In a session, there are three types of Communicator Web Access Server requests. Each corresponds to a communication different channel:
Communication channel for signing on
A client uses the sign-in channel to log on to a Communicator Web Access Server by sending a logon request. When form-based authentication is used, the URL for this channel is:
https://<server>/forms/logon.html
Here <server> is the server name of the Communicator Web Access Server. An example would be sales.us.contoso.com. When a client signs in using integrated Windows authentication, the channel URL becomes:
https://<server>/iwa/logon.html
The Unified Communications AJAX API client can choose to sign in using SSO if the Communicator Web Access Server has been configured for SSO. The channel URL becomes:
https://<server>/sso/logon.html
Single Sign On
Single sign-on is the feature that enables a user to receive a single challenge for credentials within a certain realm, regardless of whether she is accessing different independent applications. When using SSO, the authentication ticket is provided by the SSO logon process. This ticket is to be used for further requests to Communicator Web Access Server. When the user is authenticated after the logon Request, the server returns an authentication ticket to the client, in the CWA-Ticket header, as part of the corresponding HTTP response. The client must cache the ticket and supply it to the server in every command or event request that follows. This is done by putting the authentication ticket into the HTTP header of all subsequent requests. To implement SSO, a Single Sign On server must be configured as a proxy of the Communicator Web Access Server. This SSO server is responsible for validating the credentials passed to it by the client application. In addition, the SSO server may challenge the user initiating a session with a logon form. In this event, a client application must be able to display the HTML of the SSO logon form, allow the user to enter her credentials, and post a response back to the SSO server. Communicator Web Access Server has been tested with several popular SSO servers. Those SSO servers that have been tested are supported by Communicator Web Access Server. These custom authentication modules can be used to support 2FA and SSO.
Custom Authentication
This feature allows the ISV application developer to provide authentication for the Unified Communications AJAX API Client user using a custom authentication process. Custom Authentication is typically used when the Unified Communications AJAX API Client users are not utilizing either Microsoft Windows computers and the associated Integrated Windows Authentication, or forms-based authentication. Custom Authentication solutions typically function by storing a cookie on client computers with an authentication token from a prior logon. This cookie, if present allows the logon request to pass through to the Communicator Web Access Server. When this cookie is absent from the client computer, the Custom Authentication solution redirects the logon request to a custom logon page. A browser-based Unified Communications client solution is able to handle this issue by simply displaying the Custom Authentication logon page. A desktop-based client solution requires that the Custom Authentication mechanism accept logon credentials programmatically through an HTTP GET.
Communication channel for posting methods
This is also known as the command channel. A client uses it to post method requests to the server by making an HTTP POST request containing the Unified Communications service methods (except for the logon request) in the message body. The URL is:
https://<server>/cwa/MainCommandHandler.ashxCommunication channel for polling events
This is also known as the data channel or event channel. A client uses it to poll for updates or requested method results from the server by making an HTTP GET request. Unified Communications service uses an open GET method, which means that the Unified Communications service holds the channel open for 35 seconds. Any request methods that complete in that time period are added to the cwaEvents response. This is done to minimize the number of individual GET operations done by the client. The data, if any, is returned as the message body in the corresponding HTTP response. The URL for this is:
https://<server>/cwa/AsyncDataChannel.ashx?Sid=<sid>&AckId=<ackId>&UA=<ua>where sid is a session ID value generated by the server when the sign-in time initiateSession method is executed, ackId is a sequence number used by the client and server to synchronize the update steps so that the server maintains a means to ensure that the client gets all the updates it expects the client to receive. UA stands for user activity. This parameter is used as a security feature when a client connects to a Unified Communications service from outside of an enterprise network. When the UA value is not set to true, the server closes the session if the user remains inactive for a time period longer than the server-configured time-out period.
The authentication ticket has a server-specified expiration time. When a ticket is expired, the server creates a new ticket and returns it to the client, still in the CWA-Ticket header, as part of an HTTPS response to either the command request or event request. This means that the client must watch for the new ticket, cache it locally, and supply it to the server in the ensuing HTTPS requests.