Connecting AskCody to Exchange
AskCody integrates with Exchange via Exchange Webservices Managed API
The connect to Exchange Data is done using two authentication methods depending on Exchange Server or Exchange Online. These are referred to as Basic and Modern Authentication.
With Modern Authentication, there is no Exchange service account and no credentials are shared with AskCody connecting AskCody with Exchange. Instead, a Global Administrator in your organization grants permissions to the AskCody EWS application through an OAuth 2.0 flow in Azure Active Directory. The AskCody EWS application can then access EWS using a certificate-based authentication flow.
Basic Authentication requires that you share a username and password of an Exchange service account with AskCody when connecting AskCody to Exchange (As mentioned above, the password is stored encrypted in Azure Key Vault.) These credentials are then used to connect to Exchange Web Services (EWS) to access data in Exchange.
With a connection to Exchange Server using a Service Account, the customer solely administers credentials to this service account and is responsible for entering these into the AskCody Management Portal. Credentials are subsequently end-to-end hashed and encrypted, so they never appear in plain text. The Service Account entered in the AskCody Management can thus be used solely by the AskCody platform to log in via EWS to access the calendar data listed below on the meeting room resources connected with the platform.
All access to Exchange (both using basic and modern auth) in the AskCody platform is done via a central service at AskCody, which communicates with Exchange through Exchange Web Services. All inquiries to the central service are logged. Thus, AskCody will be able to present which queries have been made. (Please note, that individual EWS queries are not logged.) All integration to Exchange is done through Exchange Web Services (EWS).
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).
What is needed to integrate AskCody with Exchange
The following articles explain the step-by-step connect process along with what is needed to do integrate AskCody with Exchange.
Accessible Meeting data
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.
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.
For connection using basic authentication with service account the 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.
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.