EWS Managed API 2.0 security
Find information about security issues that must be addressed in applications that use the EWS Managed API.
Last modified: January 30, 2014
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.
In this article
Managing internal information
Maintaining data confidentiality
Establishing the identity of a server
Managing access to the server
Applications that use the Exchange Web Services (EWS) Managed API must address security issues that are common to web service–based applications. This includes doing the following:
Managing information that is internal to the application that must be kept secure, such as passwords.
Maintaining the confidentiality of the data that is sent between the application and EWS.
Establishing trust in the identity of the server that is responding to the EWS Managed API requests.
Managing access to the server for users and applications.
Because the EWS Managed API is based on Internet standards, you can use standard security practices to help secure your application. This topic includes recommendations that will help you secure EWS Managed API applications.
Managing internal information
Your application may have to store internal information, such as the password of the current user's account. Your application should use established techniques for managing internal information. For example, the Credentials property of the ExchangeService object is a System.Net.Credentials object, which uses a SecureString object to contain the account password. The SecureString object encrypts the password and holds it in memory until the object is no longer referenced, and then discards the string when it is released.
You should use similar techniques in your code to help secure internal information.
Maintaining data confidentiality
Applications that use the EWS Managed API often transfer confidential information to and from the server. For example, applications send passwords to connect to the server. E-mail messages that are sent from the server to the application may contain confidential information. Exchange Web Services uses established Internet standards to help maintain the confidentiality of private information that is sent over the public Internet.
To protect information during transmission over the Internet, Exchange Web Services and the EWS Managed API are configured by default to communicate only through HTTPS. It is possible that calling the AutodiscoverUrl method on the ExchangeService object will return redirection addresses that are not HTTPS connections. To make sure that your application is not redirected to a standard HTTP connection, create a method that implements the AutodiscoverRedirectionUrlValidationCallback delegate, and use this delegate when you call the AutodiscoverUrl method. In this delegate instance you can examine the URL that your application is redirected to to make sure that the proposed redirection uses HTTPS. You can also perform other validation checks, such as making sure that redirections are only allowed to a known group of servers.
For more information about how to use the AutodiscoverUrl method, see Working with the Autodiscover service by using the EWS Managed API 2.0.
Establishing the identity of a server
Exchange Web Services uses X509 certificates to establish the identity of the server that responds to a Web service request. The default Exchange server installation creates a self-signed certificate that the server will send in response to Web service requests. A self-signed certificate is typically rejected by most software because it does not provide a trust chain to a trusted root certificate on the client computer. You can create a custom validation callback that will validate self-signed certificates by setting the ServerCertificateValidationCallback property on the System.Net.ServicePointManager object.
For more information about how to create a custom certificate validation callback method, see Validating X509 certificates by using the EWS Managed API 2.0.
Managing access to the server
You can configure application access control for either the mailbox owners that connect to EWS or for the client applications that are used to connect to EWS. Access control can be used globally, for each user, and for each client application.
For more information about configuring EWS application access, see Managing access for EWS Managed API 2.0 applications.