60.2 Introduction to Integration with Outlook Web Application

This section provides the following information to introduce the integration described in this chapter:

60.2.1 About Impersonation Provided by Microsoft Windows

Impersonation ensures that the server can or cannot do exactly what the client can or cannot do. When running in a client's security context, a service can to an extent become a client. After the user authenticates, the service can take on that user's identity through impersonation.

One of the service's threads uses an access token, known as an impersonation token, to obtain access to objects the client can access. The access token is a protected object that represents the client's credentials. The impersonation token identifies the client, the client's groups, and the client's privileges. The information in the token is used during access checks when the thread requests access to resources on the client's behalf. When the server is impersonating the client, any operations performed by the server are performed using the client's credentials.

Impersonation ensures that the server can or cannot do exactly what the client can or cannot do. Access to resources can be restricted or expanded, depending on what the client has permission to do. Impersonation requires the participation of both the client and the server. The client must indicate its willingness to let the server use its identity, and the server must explicitly assume the client's identity programmatically.

When impersonation concludes, the thread uses the primary token to operate using the service's own security context rather than the client's. The primary token describes the security context of the user account associated with the process (the person who started the application).

Services run under their own accounts and act as users in their own right. For example, system services that are installed with the operating system run under the Local System account. You can configure other services to run under the Local System account, or separate accounts on the local system or in Active Directory.

The IIS Web server provides impersonation capabilities. However, the OAM Server overrides IIS authentication, authorization, and impersonation functions. For more information, see "Access Manager 11g Support for Windows Impersonation" in the next section.

60.2.2 Access Manager 11g Support for Windows Impersonation

You can enable support for Windows impersonation to provide additional access control for protected applications.

You bind a trusted user to a Webgate and protect the application with a application domain that includes an impersonation action in the authorization rule. During the authorization process, the protected application creates an impersonation token.

For more information, see, Enabling Impersonation With a Header Variable It provides prerequisites and details about implementing impersonation using header variables.

60.2.3 Single Sign-On for Authenticated Access Manager Users into Exchange

Single Sign-On for Authenticated Access Manager Users into Exchange is also supported using the Windows Impersonation feature.

Outlook Web Access (OWA) provides Web access to Exchange mail services and may be configured on either of the following:

  • An IIS Web server that does not reside on the same host as the Exchange server, which is also known as a front-end server

  • An IIS Web server running on the same host as the Exchange server, which is also known as the back-end server

In a front-end server configuration, the front-end OWA server authenticates the user, determines the back-end Exchange server that hosts the user's mailbox, then proxies the request to the appropriate back-end Exchange server. No additional credential information is passed. No delegation is performed. Setting up Impersonation on the back-end Exchange server ensures that the Exchange server does not need to request credentials before granting access.

For more information, see Setting Up Impersonation for Outlook Web Application (OWA)

60.2.4 Confirming Requirements

Here is an example that illustrates setting up the impersonation feature for the OAM Server to Microsoft Exchange Server 2013 integration.

The principles are the same regardless of your application. Any references to specific versions and platforms in this chapter are for demonstration purposes. For the latest Access Manager certification information, see Oracle Technology Network at: