If you've worked with Exchange applications before, you're probably familiar with the different ways to manage permission. Robin's calendar syncing for Exchange connects via UserImpersonation on each of the managed room calendars.
Why does Microsoft recommend Impersonation for apps?
To understand the differences, here are a few explanations from Microsoft's developer blogs:
Via The importance of EWS Impersonation while using an application account:
Accordingly, Delegate access is a user-manager permission, as it presumes that the user/owner of the mailbox is explicitly granting access. Impersonation, on the other hand, has been designed to support enterprise applications, and is an administratively controlled access methodology that requires no intervention from the mailbox owner
One way to think of the differences is that Impersonation is access for applications, whereas Delegate access is access for users.
There's also support for better logging out of the box, which gives you much more power to audit how applications access your data:
Note that both Impersonation and Impersonation activity can be logged by both IIS and EWS native logging functionality, providing a full audit trail.
Via Exchange Impersonation vs. Delegate Access:
Exchange Impersonation is used in scenarios in which a single account needs to access many accounts. Line-of-business applications that work with mail typically use Exchange Impersonation.
Delegate access is used in scenarios in which there needs to be a one-to-one relationship between users.
We may support user delegation in the future, but it's unlikely to be the best way to connect.
"My organization doesn't allow Impersonation..."
If your organization has policies around impersonation, typically we see a few helpful clarifications. Generally there are two concerns:
- Service accounts shouldn't have the ability to impersonate people (i.e. your CEO).
- Logging requests made via Impersonation is challenging compared to delegate access.
In both cases, we'd clarify that Robin does not need any kind of user (i.e. human) impersonation access to work. You can see the specific roles in this guide.
The service account's impersonation rights can start and end at the room resources you intend for it to manage. Once this distinction is made, you'll generally find Impersonation access is easier to approach in your organization's security frameworks.