Connecting AskCody to Exchange
Access to Microsoft Exchange Data is done via a Service Account on the customer Exchange Server, either Exchange Server or Exchange Online using Exchange Web Services. The Customer is solely in control of this account along with the Service Account credentials needed to connect AskCody to Exchange. When connecting Exchange to the AskCody Management Portal, the credentials are inserted and saved using end-to-end hashes and encryption. By this AskCody never store any credentials in clear text format.
The Service Account used to connect, will only be used for connecting AskCody with Exchange via Exchange Web Services (EWS) to access calendar data in calendars connected to the AskCody Management Portal.
Login and accessing data is only done via an Application. Access to the Exchange login interface (GUI) can be removed, and at this moment the service account is limited to login via the Application. EWS Application Impersonation is considered the best approach to application-level mailbox access for server/service type applications, in combination with removing GUI access.
All access to Exchange via EWS from AskCody is done via a dedicated central AskCody Service that is built specifically for the purpose of accessing the Exchange data needed for AskCody Products to function.
All requests in the central AskCody Service is logged in Azure ApplicationInsights. Requests are logged in the European Azure Tennant for European Customers and the North American for our North American customers respectively. Azure ApplicationInsights enables AskCody to have a full audit trail on request and by this account for requests being made. (Please note that individual EWS requests are not being logged).
EWS authentication is done via the Service Account credentials (username and password) stored encrypted (AES-256-CTR) in the AskCody Platform and only decrypted in use. It is not possible to view the Service Account credentials in any AskCody Interface and credentials can't be accessed without access to both database and encryption key. Encryption and authentication are handled via Azure Keyvault.
What is needed to integrate AskCody with Exchange
The following list contains what is needed for AskCody to integrate with Exchange, both Server and Online
- Mailbox (Service Account) - user created in customers Exchange environment for the purpose of being used for AskCody to integrate with Exchange. The Service Account must be given the Exchange Role ApplicationImpersonation. ApplicationImpersonation and the need of this role is further described below.
- Username and Password (Service Account)
- EWS URL (This is generic when using Office 365)
This information is stored in the AskCody platform and encrypted via AES(rest) and via TLS 1.2+ (motion) when requests are being made via EWS. This setup gives the AskCody Platform access to connect to Exchange.
- Following the above AskCody also needs the "Public Name" and "Mailbox Adress" (The email address on the mailbox form where requests can be made.
- All meeting data on the Exchange Server (both Exchange Online and On-Prem), is requested via EWS on demand (when it is being used). No meeting data is synchronized and stored in an AskCody Database. When AskCody needs to access Exchange data, it is requested from Exchange directly and not form an AskCody database. If the connection to Exchange is disabled or removed AskCody will no longer have access to Exchange Data.
- Meeting data needed for a given product to function is requested via the AskCody Platform and the connection to Exchange via EWS - This is, for example, the case when showing meeting data on a Meeting Room Display or searching for the most suitable Room in AskCody RoomFinder. All meeting data stays in Exchange and is only displayed and used when needed for a certain product to function.
Accessible Meeting data
Meeting data that can be accessed (Exchange Online and On-prem via EWS)
|Meeting (Exchange)||Organizer name|
|Meeting (Exchange)||Organizer address|
|Meeting (Exchange)||Subject||Exact value depends on calendar system configuration.|
|Meeting (Exchange)||Start time|
|Meeting (Exchange)||End time|
|Meeting (Exchange)||Attendees||Name and email address of attendees.|
|Meeting (Exchange)||Resources||Name and email address of resources.|
|Meeting (Exchange)||Item ID||Exchange identifier for the meeting.|
|Meeting (Exchange)||Object ID||Immutable Exchange identifier for the meeting.|
|Meeting (Exchange)||Location||Location string from the meeting.|
|Meeting (Exchange)||Private||Whether the meeting is private. Will mask organizer, subject, location, and description on signage products.|
|Meeting (Exchange)||Description||Meeting Description.|
No access to personal mailboxes
AskCody only access calendar mailboxes and the Exchange data above. AskCody does not access personal mailboxes. AskCody has no interest in having access to data points that are not needed for the products to perform accordingly to the purpose.
Access to this data in further controlled in Data Processing Agreements between AskCody and the Customer.
AskCody is built with a strong foundation in information security. Learn more about AskCody and Security here.
The AskCody Information Security Policy and Rules are based on:
- Generally accepted standards as the Information Security standard ISO/IEC 27001/ 27002 and ISAE 3000 (ISAE 3000 is the standard for assurance over non-financial information. ISAE 3000 is issued by the International Federation of Accountants (IFAC). The standard consists of guidelines for the ethical behavior, quality management, and performance of an ISAE 3000 engagement)
- Data protection laws and GDPR.
AskCody holds an ISAE 3000 certification on ISO 27002.
Built on Azure
AskCody comes as a Software as a Service is built on Microsoft Azure and hosted in the Microsoft Azure cloud in either Europe or in the United States, or in any other country where Microsoft Azure has data centers used as Datacenter for Microsoft. To get a full list of compliance offering and to find audit information, go to the related certification on https://www.microsoft.com/en-us/trustcenter/compliance/complianceofferings
In Europe, AskCody utilizes the North Europe (Primary) and West Europe (Secondary) Azure regions. The service is fully managed by AskCody. Maintenance and updates are included in your AskCody subscription. The European data centers are placed in Dublin (Europe North) and Amsterdam (Europe West). Learn more about Azure Datacenter infrastructure here.
The primary data location for AskCody Customers in EU is Europe North with Europe West as secondary. EU West (Amsterdam) functions as a Geo-redundant backup if recovery is needed in a major outage. In case of major outage or disaster, the recovery time is maximum 12 hours.
In North America, we utilize East US (Primary) and West US (Secondary). Learn more about regions here - http://azuredatacentermap.azurewebsites.net/. Also, this service is fully managed by us. West US functions as a Geo-redundant backup if recovery is needed in a major outage. In case of major outage or disaster, the recovery time is maximum 12 hours.
Customer will never leave the Data Region on which the Customer Data is placed based on the location of the Customer, meaning the Customers in Europe will only be using Data Centers in Europe, and Customers in North America will only be using Data Centers in North America.
All secondary datacenters (West Europe and West U.S.) works as a storage and geographically redundant backup.
In the case of emergency and disaster recovery is needed, the recovery time is 12 hours maximum. Loss of data will be limited to the latest 15 minutes (Microsoft SLA).
Replication between primary and secondary datacenters in a Region is happening at a maximum delay of 15 minutes.
EWS ApplicationImpersonation is considered the best approach to application-level mailbox (including meeting room mailboxes) access for server/service type applications. Impersonation and Delegated access is the only way to get programmatic rights to mailbox objects. To clarify the differences and why AskCody requires Application impersonation, please take a look at the following article.
One example of how AskCody uses ApplicationImpersonation is in AskCody Meeting+ where the roles are used for loading meeting data and supporting notifications on changes to calendars. This enables Meeting+ to do changes to catering deliveries based on the status of the meeting (If the meeting is moved the catering delivery time is moved accordingly).
When meeting data is loaded, a request is made to the organizer's calendar to get a full picture of the meeting and its instances; This is not possible with just requesting information on the meeting in the room calendar and an example why AskCody needs ApplicationImpersonation.
ApplicationImpersonation is required to avoid throttling of EWS
ApplicationImpersonation is also required to avoid throttling of EWS requests and accessing meeting data as in the case of the example above. In normal use, the EWS requests are not done in large numbers, but during initialization of notifications needed to get the full picture of the meeting, it can result in a larger number of requests that can cause throttling issues.
This makes ApplicationImpersonation a requirement.
Articles on AskCody integration with Exchange
The following articles will elaborate further on how AskCody integrates with Exchange and go in-depth on why ApplicationImpersonation is needed.
How to prepare your Exchange Server for AskCody: https://help.onaskcody.com/hc/enus/articles/115000655589-How-to-prepare-your-Exchange
How to connect Exchange to the AskCody Management Portal: https://help.onaskcody.com/hc/enus/articles/115000599869-Connect-Exchange-to-the-AskCody-
Manager The difference between Impersonation and Delegation, and the need for Impersonation with AskCody: https://help.onaskcody.com/hc/en-us/articles/115004456345-The-difference-betweenImpersonation-and-Delegation-and-the-need-for-Impersonation-with-AskCody
The last Article on the "The difference between Impersonation and Delegation" also contains relevant information on the built-in audit trail in Office 365 that can increase insights in security-related matters.
All access is application access for calendar data - not email data. AskCody only access calendar data via the application (EWS integration). AskCody does not access any email data in mailboxes when integrating with Exchange using the Service Account provided by the customer.
In a customer implementation, a Data Processing Agreement is also signed that also clarifies what data is being accessed and processed. AskCody also refers to using Microsoft Exchange's comprehensive logging and full audit trail setup.