• Article

Working with impersonation by using the EWS Managed API 2.0

You can use the Microsoft Exchange Web Services (EWS) Managed API to work with impersonation. Impersonation enables an account on an Exchange server to perform actions by using the permissions that are associated with another account.

Last modified: October 13, 2012

Applies to: EWS Managed API | Exchange Server 2007 Service Pack 1 (SP1) | Exchange Server 2010

Note: This content applies to the EWS Managed API 2.0 and earlier versions. For the latest information about the EWS Managed API, see Web services in Exchange.

Impersonation differs from delegation in that a delegate account performs actions on behalf of a primary account; an impersonating account performs actions as if it were the primary account.

Security noteSecurity Note

You must configure the Exchange server to allow impersonation before your application can use impersonation. For more information, see Configuring Exchange Impersonation (Exchange Web Services).

To impersonate a user

  1. Instantiate a new ExchangeService object. Set the credentials of the object to the credentials that are associated with the impersonating account.

    ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2010);
service.Credentials = new NetworkCredential(appName, appPassword, emailDomain);
service.AutodiscoverUrl(appEmail);

  2. Set the ImpersonatedUserId property of the ExchangeService object to identify the impersonated user. This example uses the user's SMTP email address.

    service.ImpersonatedUserId = new ImpersonatedUserId(ConnectingIdType.SmtpAddress, userEmail);

The application can change the ImpersonatedUserId property to impersonate multiple accounts. If the ImpersonateUserId property is set to null, any actions taken will be associated with the impersonating account.

Example

The following example shows how to use impersonation to create a folder in the impersonated user's Inbox.

    void ImpersonationSample()
    {
      ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2007_SP1);
      service.Credentials = new NetworkCredential(appName, appPassword, emailDomain);
      service.AutodiscoverUrl(appEmail);

      service.ImpersonatedUserId = new ImpersonatedUserId(ConnectingIdType.SmtpAddress, user1Email);

      Folder newFolder = new Folder(service);
      newFolder.DisplayName = "TestFolder1";

      newFolder.Save(WellKnownFolderName.Inbox);

      service.ImpersonatedUserId = new ImpersonatedUserId(ConnectingIdType.SmtpAddress, user2Email);

      Folder newFolder2 = new Folder(service);
      newFolder2.DisplayName = "TestFolder1";

      newFolder2.Save(WellKnownFolderName.Inbox);

    }

The ImpersonationSample method creates a NetworkService object and binds the object to an application account. The ImpersonateUserId property is then set to the SMTP email address of a target account and a new folder is created in the target account's Inbox. The ImpersonateUserId property is set to a second SMTP email address and the process is repeated.

Compiling the code

For information about compiling this code, see Getting started with the EWS Managed API 2.0.

Robust programming

  • Write appropriate error handling code for common search errors.

  • Review the client request XML that is sent to the Exchange server.

  • Review the server response XML that is sent from the Exchange server.

  • Set the service binding as shown in Setting the Exchange service URL by using the EWS Managed API 2.0. Do not hard code URLs because if mailboxes move, they might be serviced by a different Client Access server. If the client cannot connect to the service, retry setting the binding by using the AutodiscoverUrl(String) method.

  • Set the target Exchange Web Services schema version by setting the requestedServerVersion parameter of the ExchangeService constructor. For more information, see Versioning EWS requests by using the EWS Managed API 2.0.

Security

  • Use HTTP with SSL for all communication between client and server.

  • Always validate the server certificate that is used for establishing the SSL connections. For more information, see Validating X509 certificates by using the EWS Managed API 2.0.

  • Do not include user names and passwords in trace files.

  • Verify that Autodiscover lookups that use HTTP GET to find an endpoint always prompt for user confirmation; otherwise, they should be blocked.