Microsoft 365 integration (formally Smart Calendar)
Condeco uses the latest Microsoft Azure technology and follows Microsoft’s best practice guidelines to ensure your data is completely secure. All data in transit is encrypted.
The Microsoft 365 integration service uses Microsoft Graph to receive notifications from user calendars and only processes the specific data required for a booking, such as the date, time, subject, and meeting attendees. You are in full control of which calendars send notifications and additionally, each user must provide explicit consent via the add-in before the Microsoft 365 integration can subscribe to their calendar.
Booking information is deleted from storage when a booking end time has passed. Condeco only stores calendar appointment information for bookings that occur in the future.
We understand the need for data security when integrating across platforms and have compiled a list of commonly asked questions to satisfy any concerns you may have.
FAQ – Graph API, data access, and security
What access does Condeco require?
The Microsoft 365 integration uses Microsoft Graph API to securely access user calendars. An Exchange administrator must grant consent for the following permissions:
|Permission||Type||Why it is needed?|
|Sign in and read user profile [User.Read]||Delegated permission||The Microsoft 365 integration needs to read the profile of the Exchange administrator who signs in and grants the consent, so it can get the Microsoft 365 tenant details.|
|Read all users full profile [User.Read.All]||Application permission||Required to fetch user’s complete profile (including GUID identifiers) which can be used while making subscription.|
|Read and write calendars in all* mailboxes [Calendars.ReadWrite.All]||Application permission||Read and write permissions on calendars are needed to manage bookings within users’ calendar appointments.|
|*Administrators can configure an application access policy to limit access to specific mailboxes even when the app has been granted Calendars.ReadWrite application permissions.|
|The Microsoft 365 integration uses Application Permissions over delegated permissions when accessing a user calendar, meaning consent is given on behalf of all users within the scope without the end-user needing to grant access themselves.|
Learn more about these topics at Microsoft:
- Graph API https://docs.microsoft.com/en-us/graph/overview
- Application access policy https://docs.microsoft.com/en-us/graph/auth-limit-mailbox-access
- Application permissions https://docs.microsoft.com/en-us/graph/permissions-reference#application-permissions-7
Is there a permission set for Graph API that allows further granular permissions than Calendar.ReadWrite?
Whilst this exists for emails as Mail.ReadBasic, there is no granular permission in Microsoft Graph API for Calendars other than Calendar.Read that allows access to the Body.
Why does the Microsoft 365 integration require access to User.Read.All when User.ReadBasic.All provides all the information required by Condeco?
User.ReadBasic.All permission is only available as a Delegated Permission using Graph API. As the Microsoft 365 integration uses Application Permissions, the permission available is User.Read.All. Microsoft 365 integration only accesses the user information required for the service.
Find out more about User Graph API permissions at Microsoft https://docs.microsoft.com/en-us/graph/permissions-reference#user-permissions
Why does the Microsoft 365 integration use Application Permissions and not Delegated Permissions for accessing Graph API?
The architecture of the Microsoft 365 integration service application relies on Application Permissions to receive user calendar notifications. This is because our service works in a wider context than just the user, and Delegated Permissions only works with the user context. Microsoft specifically developed Application Permissions to facilitate enterprise-level service applications to use Graph API. We continue to work in partnership with Microsoft to ensure that best practices are followed.
How do I ensure Condeco follows only specific users’ calendars and how do we prevent access to sensitive calendars?
Scope the permission of the Microsoft 365 Admin account so it has access only to a specific Active Directory User Group. Condeco only receives notifications from calendars belonging to members of the group.
Control access with a mail-enabled security group and an Application Access Policy. Two types of permissions can be applied to the Application Access Policy, depending on whether you wish to allow or deny access to the calendars of the users added to the mail-enabled security group.
a) Use DenyAccess to deny access to the calendars belonging to the group and allow access to all other user calendars.
b) Use RestrictAccess to allow access to the calendars belonging to the group and restrict access to all other calendars.
Learn more about scoping calendar access at Microsoft https://docs.microsoft.com/en-us/graph/auth-limit-mailbox-access
Does Condeco subscribe to notifications for every user calendar with the scope?
No. Condeco only subscribes to user calendars when the user agrees to grant access. Currently, the only way a user can agree is by launching the Condeco Outlook add-in from an Outlook calendar appointment and ticking a box agreeing for permissions to be granted.
How does Condeco receive notifications from users’ calendars?
The Microsoft 365 integration service uses Microsoft Graph to receive notifications from users’ calendars.
Which user calendars does Condeco subscribe to via the Microsoft Graph API?
Condeco can only subscribe to the calendars of users who have agreed to grant access!
The first time a user starts the Condeco Outlook add-in they are prompted to tick a box to grant access to their calendar. If the user grants access and their account is within the scope as defined by your organization, Condeco can subscribe to their calendar via the Microsoft Graph API. Condeco does not subscribe to calendars that are not within scope, or if the user does not agree to the access. A list of users who have allowed access is stored in a secure table for auditing purposes.
Can a user’s calendar be unsubscribed?
Yes, raise a ticket for the Condeco Support Team to unsubscribe a user’s calendar. A user is not able to do this themselves.
What additional information does Condeco store for the Microsoft 365 integration?
There are two scenarios where Condeco stores information for the Microsoft 365 integration as described below. If neither of the conditions is met, the notification from Graph API is ignored and no further details of the appointment are accessed or stored.
Scenario 1: When a notification of a new or edited appointment is received from Graph API, the notification is stored in a queue. Condeco creates a log that includes the following:
|iCalUId||Unique identifier shared by all instances of an event across different calendars.|
Scenario 2: When a Condeco meeting space is added to an appointment the following details are stored by Condeco:
|Attendees||The list of attendees for the event.|
|iCalUId||Unique identifier shared by all instances of an event across different calendars.|
|ChangeKey||The last booking state.|
|DateTimeFrom||The start date and time of the booking.|
|DateTimeTo||The end date and time of the booking.|
|LastModifiedDateTime||The date and time the booking was last modified.|
|Location||Location details for the booking.|
|Organizer||The email address of the organizer.|
|RecurrencePattern||Any recurrence details.|
|Sensitivity||Private meeting flag.|
|SeriesMasterId||ID for the master item of a recurring series.|
|Subject||Subject of the booking.|
|SingleValueExtendedProperties||Hidden attributes added by Condeco Outlook add-in. Full details in next table.|
SingleValueExtendedProperties: Condeco stores the following information for SingleValueExtendedProperties:
|Condeco Room and Desk Booking resource ID||The unique identifier of the resource in Condeco.|
|PropertyId(GUID) Name(manifestId)||The identifiers required to receive the custom properties of the event.|
|Location of the resource||Only the location of the Condeco resource, e.g. Meeting Room A, 8th Floor, Exchange Tower, UK, no other information within the location field of the appointment is captured.|
|Add-in version||To maintain backward compatibility.|
|Attributes||Selected during the search.|
|Capacity||Maximum capacity of the resource|
|Exchange mailbox email address||If paired to an Exchange mailbox. (For use with alternative search).|
|List of attendees||For future development to pass attendees and visitors to Condeco.|
|Email address||Calendar owner’s email address.|
Where is the information stored?
The information is stored in secure Azure cloud storage and follows Microsoft’s guidance and best practice for access control.
Learn more about data stored in Azure at Microsoft https://docs.microsoft.com/en-us/azure/storage/common/storage-introduction.
How long does Condeco keep the information?
Booking information is deleted from storage when a booking end time has passed. Condeco only stores information for bookings in the future.
How are bookings created in Condeco?
Microsoft 365 integration uses RESTful APIs to create meeting space bookings in Condeco.
Who can access the backend of the Condeco Microsoft 365 integration service?
Only the Condeco Systems team can access the backend of the Microsoft 365 integration service. Within the team, access is further controlled by a well-defined process.
How can I see what Condeco has accessed?
You can enable your own audit logs in Microsoft 365 and we strongly recommended that this is done.
What level of auditing is available in Office 365 and the Microsoft 365 integration?
The Office 365 compliance center has AD access logs as part of the Office 365 platform. The Microsoft 365 integration audits all interactions with Graph API. Only the Graph API calls are stored, not the returned data. Logs can be shared on a schedule.
What security measures are available for the Microsoft 365 integration to prevent unauthorized access?
- We use standard OAUTH 2.0 JWT tokens instead of credentials to ensure issues associated with basic authentication do not impact the Microsoft 365 integration.
- We use managed service identity to pass information from one Azure service to another, instead of service accounts.
- We use short-lived JWT tokens and Microsoft MSAL to access token information from Microsoft Graph. Microsoft MSAL ensures all best practices are in place. Token lifetime is controlled by your Azure AD administrator and can be reduced to minimize risk.
- All secrets are stored in the Azure Key Vault and can only be accessed by a secure automated process.
- We use an Azure AD app that has a service principal deployed in customer premises. This allows your Azure AD administrator to fully control access to Graph API. Access can be revoked from the Azure portal.
- Condeco use change control procedures certified by ISO27001 and CSA Star certificates.
We understand Condeco do not ask for body and attachment information from Graph API but is it possible for a query to be written to request this potentially sensitive information?
- Body and attachment information is never passed in the select query sent to Graph API and so Graph API cannot return this information. In addition, we perform unit tests and automation tests.
- All Graph API access is audited and Microsoft can provide audit logs to show queries that Condeco execute against a specific Graph API tenant.
- As part of our ISO27001 and CSA Star certificates, software engineering processes are defined for the entire lifecycle that prevent access to body and attachments:
- Separate branches to promote code to Development, QA, Staging, and Production.
- Pull requests are reviewed by two engineers to promote code to Development.
- Unit tests validate the use of body and attachment and fail the build in Development only.
- Sanity and automation suites in QA process prevent any calls to Body and Attachment, and there are similar controls in staging and production.