Managing access for EWS Managed API 2.0 applications
Last modified: December 10, 2012
Applies to: EWS Managed API | 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.
An Exchange server administrator can manage access to Microsoft Exchange Web Services (EWS) Managed API applications by using the Exchange Management Shell to control access globally, for each user, and for each application.
Configuring Access Control
Administrators can configure application access control for EWS Managed API client applications that connect to Exchange Web Services or for mailbox owners that connect to Exchange Web Services.
Administrators can control client application access to EWS in the following ways:
By blocking all client applications from connecting.
By allowing a list of client applications to connect.
By allowing any client application to connect except those that are specifically blocked.
By allowing any client application to connect.
Applications are identified by the client string that they send in the HTTP Web request.
.gif "Security note") Security Note |
|---|
Application-level blocking is not a security feature — the user-agent string is easily spoofed. If an application is allowed access to Exchange Web Services, the application must still present credentials that the server authenticates before the application is allowed to communicate with the EWS server. |
Administrators can also configure application access control for mailbox owners by allowing access to the following:
The entire organization.
A group of users identified by a role-based authentication scope that excludes owners who do not have access to Exchange Web Services.
An individual mailbox owner.
Specific access control settings override general access control settings. For example, if an organization denies EWS access but an individual mailbox owner is allowed EWS access, the individual setting prevails and access is allowed.
When both application and mailbox access control are used, both the application and the mailbox user must be allowed access; otherwise, the access is denied.
When a user or application is denied access to Exchange Web Services, the Web service sends an HTTP 403 Forbidden response.
Delegation and Impersonation
When the client application is used by a delegate mailbox owner, or when the application is impersonating a mailbox owner, the following restrictions apply.
Delegation
Delegate users are granted access based on the delegate's mailbox, not on the principal's mailbox. If the delegate mailbox does not have access to Exchange Web Services, the delegate will not be able to access the principal's mailbox, even if the principal user has Exchange Web Services access.
If the delegate user has Exchange Web Services access, the delegate will be able to access the principal user's mailbox even if the principal user does not have Exchange Web Services access.
Impersonation
Client applications that connect to Exchange Web Services on behalf of mailbox owners are limited by the access granted to the mailbox owner. Some applications, such as an application that archives e-mail for the company, must have access to Exchange Web Services regardless of what the mailbox user's settings are. Other applications, such as mail clients, are limited by the mailbox owner's Exchange Web Services settings.
Administrators should create an impersonation account for each application or application class that they use on the server. This will enable them to configure the role-based access control scope for all users that do not have Exchange Web Services permissions.
Exchange Management Shell Cmdlets for Configuring Access Control
Administrators use the following Exchange Management Shell cmdlets to configure Exchange Web Services access controls: