次の方法で共有

The importance of EWS Impersonation while using an application account.

  • [アーティクル]

Developers of applications which require access to user mailboxes often struggle with the choice between the Impersonation and Delegation access methods. While both provide programmatic rights to mailbox objects, they are designed to meet rather different needs, and for situations where a single account needs to access multiple mailboxes, Impersonation is the better choice. This post will provide an overview of why, and what the implications of using Impersonation are.

First, a point of clarification: Delegate access is geared to situations where an application needs access to mailbox items controlled by a user, and where it is likely that code will be run under the logged-on users permissions. Accordingly, Delegate access is a user-manager permission, as it presumes that the user/owner of the mailbox is explicitly granting access. Impersonation, on the other hand, has been designed to support enterprise applications, and is an administratively controlled access methodology that requires no intervention from the mailbox owner. One way to think of the differences is that Impersonation is access for applications, whereas Delegate access is access is for users.

In practice, applications using EWS Impersonation are more robust, as other applications or normal users cannot revoke permission settings on the fly as they can with Delegate settings. Furthermore, the setup and administration of Impersonation is significantly less complex and time consuming when dealing with large sets of users, as it can be set globally rather per mailbox. 

From a security perspective, Impersonation is preferable to Delegate access for the following reasons:

  • Access via EWS is not available to end-users, and EWS calls can (and should) be secured on the wire via SSL.
  • Role-based access permissions to enable or disable Impersonation rights are provisioned on the account level, and can be set only via the Exchange administrator.

Note that both Impersonation and Impersonation activity can be logged by both IIS and EWS native logging functionality, providing a full audit trail.

To summarize some of the reasons why EWS Application Impersonation is considered the best approach to application-level mailbox access for server/service type applications:

  • It is an administrator-managed, not user-managed permission, which means that a user or other application cannot change the permission settings.
  • It is inherently designed for one-to-many mailbox access, which means there’s less configuration complexity and overhead for managing new users that need to be added to the application scope.
  • It takes advantage of EWS features, such as Throttling, that are designed to help manage application access to user mailbox data.  For example, impersonation accounts can have their own throttling budget (as of Exchange 2010 SP2), which means that applications using impersonation can’t inadvertently lock user’s out of their mailboxes for exceeding their budget.
  • It can only be used through EWS, which means that users with access to an account with impersonation rights would need to write an EWS application to access a user’s mailbox and could not directly access the mailbox via a mailbox client such as OWA.

A good places to start reading:

Authentication and EWS in Exchange
https://msdn.microsoft.com/en-us/library/office/dn626019(v=exchg.150).aspx

Impersonation and EWS in Exchange
https://msdn.microsoft.com/en-us/library/office/dn722377(v=exchg.150).aspx
With Impersonation a service account has full access to a defined set of mailboxes. What it can access in those mailboxes (such as specific folders) cannot be filtered or defined.  Only an Exchange Admin can configure an EWS Impersonation account for impersonating and configure its mailboxes to allow the impersonation.

Delegate access and EWS in Exchange
https://msdn.microsoft.com/en-us/library/office/dn641957(v=exchg.150).aspx
Delegate access allows a user to access certain folders in another user's mailbox  Delegate permissions can be set by a mailbox owner or administrator using an app or other app code. 

For more information on the points discussed in this post, please see:

Comments

  • Anonymous
    October 22, 2013
    Really well written and easy to understand article. Thanks!

  • Anonymous
    July 01, 2014
    I know you wrote this some time ago, but it's been extremely useful to me today. Very well explained, thank you.

  • Anonymous
    November 18, 2014
    I mean it by the name... its an excellent grab.

  • Anonymous
    November 21, 2014
    Thanks!

  • Anonymous
    June 03, 2015
    When EWS Impersonation is used the X-AnchorMailbox always should be correctly set to the mailbox being accessed.  Without doing so you may get 500 or 503 errors at times. It is critical for performance and also for notifications.  Not setting it can double or more the time it takes to complete the call. In some cases you can also get timeouts.    Example:  service.HttpHeaders.Add("X-AnchorMailbox", targetSmtp);