Learn how to scope the application permissions on specific mailboxes when using Basic authentication with Application Impersonation enabled, to integrate with Microsoft Exchange.
AskCody accesses data in Microsoft Exchange (both on-premises versions and Exchange Online as part of Office 365) through Exchange Web Services (EWS) using either Basic Authentication or Modern Authentication.
These authentication methods either require the username and password of a Service Account created in Exchange and connected through the AskCody Admin Center, or uses the widely used OAuth 2.0 protocol, which is more secure because Modern Authentication doesn’t require a service account, and therefore doesn’t involve a password that can be compromised.
Integrating AskCody with Microsoft Exchange, we need to make sure the used Service Account on the Microsoft Exchange Server (or Exchange Online) can create, edit, and delete meetings. This ability is done, by granting the Service Account the ApplicationImpersonation role. AskCody will use this permission to do things like end meetings early via the room display or remove abandoned events automatically, or simply to look up availability across the entire organizations meeting rooms, when using AskCody to search for available space.
ApplicationImpersonation allows the Service Account to manage events on behalf of your office's room resource calendars, regardless of who originally created the event, and gives you auditable logs for reference. ApplicationImpersonation is used in scenarios in which a single account needs to access many accounts, meaning line-of-business applications that work with mail or calendar events.
Scoping application access with Basic Auth to specific Exchange mailboxes (resources) and meeting rooms
Using Basic Authentication with ApplicationImpersonation, this authentication method uses the username and password of a Service Account created in Microsoft Exchange to integrate with AskCody and uses this Basic Authentication method for authenticating access.
Using Basic Authentication allows Exchange Administrators to use Application Scoping, meaning create a custom management scope of users that the service account can impersonate.
The service account will then only be allowed to impersonate other users within the specified scope. If no scope is specified, the service account is granted the ApplicationImpersonation role over users in an organization.
Why would you need scoping of application access to limited mailboxes?
Well, imagine SysCorp Group, an organization using Microsoft Exchange, Outlook, or Office 365, that has thousands of employees spread across multiple departments. SysCorp Group is deploying a meeting booking platform, AskCody, that helps their employees book meetings with other employees as well as meeting rooms within the company.
The AskCody Platform is built on top of Exchange and therefore leverage data in Exchange, using Exchange Web Services to identify free appointment times on the employees’ and rooms' calendars and uses these free times to book meetings and make reservations.
Because AskCody requires access to multiple meeting room resources (Exchange Mailboxes) at once to find availability or must be able to look up availability in a person's calendar, it must use ApplicationImpersonation access on Microsoft Exchange, enabling AskCody to access all calendars and mailboxes in the organization, not just the mailboxes belonging to an employee trying to book the meeting.
Using Application Scoping, Management Scoping, or Application Access Policies built into Microsoft Exchange, SysCorp Group administrators can now restrict AskCody access to only the employees’ and rooms' mailboxes via a security group and disallow its access to other mailboxes. Access can therefore be limited and restricted to only the meeting rooms that are integrated with AskCody, or specific user groups.
This means, that even though it's a requirement for AskCody to have ApplicationImpersonation enabled on the Service Account using Basic Auth, access can be completely limited to only certain users/user groups/meeting rooms within specific security groups managed entirely by the customer on their Exchange Admin Center with no ability for AskCody or the Service Account used to integrate AskCody and the Customer's Exchange Server, to compromise this or access any other users data.
Get started with Application Scoping for EWS applications
Application Scoping (Management Scope) is a standard Microsoft Exchange feature that Microsoft has described in the documentation of Exchange. A full explanation of Exchange Management Scopes or Application Scope is beyond our documentation and it's recommended that you familiarize yourself with the options available online on Microsoft’s library MSDN.
In Microsoft Exchange, creating and adding a Management Scope means that you define and identify which users, mailboxes, or meeting rooms, that a specific application (being AskCody) can access when leveraging the Impersonation Role used for authenticating and integration.
Put in another way; An application like AskCody needs a Service Account on Microsoft Exchange to establish the connection/integration between Microsoft Exchange and AskCody. That Service Account needs the ApplicationImpersonation to act as an application accessing user and mailbox data. To scope and limit access to specific data (mailboxes, rooms, users) a Management Scope is created in Microsoft Exchange for that Service Account. Now users, rooms, and mailboxes in that Management Scope are the only scoped mailboxes the Service Account with ApplicationImpersonation can access.
This is how organizations using AskCody (or other 3rd parties integrating with Microsoft Exchange) secures and limit access to mailboxes.
The following MSDN articles are a good starting point to learn how to configure Management Scope to define Application Scopes in Microsoft Exchange for EWS applications:
Understanding management role scope filters
- Management role scope filters can be used to define management scopes that are highly customizable. Using scope filters, you can create a scope that matches how you segment your recipients, databases, and servers so that administrators can manage only those objects they should have access to. Scope filters can use nearly any recipient, database, or server object property.
Understanding management role scopes
- Management role scopes enable you to define the specific scope of impact or influence of a management role when a management role assignment is created. When you apply a scope, the role assignee assigned to the role can only modify the objects contained within that scope. A role assignee can be a management role group, management role, management role assignment policy, user, or universal security group (USG). For more information about management roles, see Understanding Role-Based Access Control.
Understanding exclusive scopes
- Exclusive scopes are a special type of explicit management scope that can be associated with management role assignments. Exclusive scopes are designed to enable situations where you have a group of highly valuable objects, such as a CEO mailbox, and you want to tightly control who has access to manage those objects.
The abovementioned applies to Exchange Server and Exchange Online for Applications integrating with Exchange using EWS which is the case for AskCody being an EWS Application.
Audit trails and logging
If you suspect any abuse of the Impersonation with the Service Account, both Impersonation and Impersonation activity can be logged by both IIS and EWS native logging functionality, providing a full audit trail. This can be provided by both the IIS and EWS native logging functionality and by the Non-Owner Mailbox Access Report in Exchange Admin Center.
This means that you will be able to log and monitor how the Service Account is being used and immediately be aware if you suspect abuse of data or access to user’s accounts.
When turned on and enabled, mailbox audit logging for a mailbox with Microsoft Exchange, logs specific actions by non-owners, including both administrators and users, called delegated users, who have been assigned permissions to a mailbox.