Single Sign-on/Custom Authentication

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.

Single Sign On

Single Sign-On (SSO) is the feature that enables a user to receive a single challenge for credentials within a certain realm, and use the returned authentication token for access to other applications which require user authentication. The token is used to both uniquely identify and authenticate the user.

When using SSO, the authentication token is provided by a user-authentication process running on the SSO server. This token is used to gain access to Microsoft® Office Communicator Web Access and other applications. The token is cached on a user workstation when supplied by the authentication process.

The authenticated user is redirected by the SSO server to the SSO logon page. Communicator Web Access server will return an authentication ticket to the client in the CWA-Ticket header, as part of the corresponding HTTP response. This authentication ticket is specific to Office Communicator Web Access and not to be confused with the authentication token provided by the SSO server user-authentication process.

To implement SSO, an SSO 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 which have been tested are supported by Office Communicator Web Access. 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 Office Communicator Web Access user using a custom authentication process. Custom Authentication (CA) is typically used when the Office Communicator Web Access users are not utilizing either Microsoft Windows® computers and the associated Integrated Windows Authentication, or forms-based authentication. CA solutions typically function by generating an authorization token as a result of the user authentication process. The token is passed to the client computer in the form of a cookie.

The user authentication process run on an SSO/CA server will follow one of two paths:

Initial logon to SSO/CA server without a valid authentication token.

In this case, the user is challenged for her credentials (user name and password) by a browser redirection to a CA logon page. After supplying her credentials, the user will receive an authentication token to be used to logon to the SSO/CA server again.

Subsequent logon to CA server using the authentication token provided to the user when she initially logged on. In this case, the CA server will examine the token for validity. If valid, the client browser will be redirected to the SSO/CA logon page.

The figure below depicts a scenario where the Office Communicator Web Access client is not authenticated. If the user has previously logged on to Office Communicator Web Access and then logged off, the client authentication token should have been cleared.

Logon with a Valid Authentication Token. The Office Communicator client has been authenticated by a prior logon through the SSO/CA server.

The prior logon may have accessed another application in the realm using the SSO/CA server.

The SSO/CA logon page does not display on client browser. The purpose of the SSO/CA page is to process the logon request, pass it to the Communicator Web Access server and return the Office Communicator Web Access authentication ticket to the client computer.

Single Sign-On Server Logoff

The authentication token provided by the SSO/CA server is stored on the client computer in the form of a cookie. If the Office Communicator client is browser based, closing the browser will delete the cookie. Otherwise, the expiration time value of the cookie will enforce its invalidation. It is strongly suggested that at the time a user has logged off Office Communicator, they visit the URL designated as the logoff page by the SSO/CA server. A visit to this page will result in the clearing of any authentication cookies stored on the client. This step is particularly important when the Office Communicator client is not browser based. The desktop based Office Communicator client application is responsible for clearing the authentication cookie with a visit to the logoff page.

See Also

Concepts

Testing Authentication Implementations