Data access and security

Graph API, data access, and security FAQ

1. 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 is it 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 the basic profile details of all users[User.ReadBasic.All]	Application permission	Required to get a user’s basic details (including GUID identifiers) which is used when subscribing.
Read and write calendars in all* mailboxes [Calendars.ReadWrite]	Application permission	Read and write permissions on calendars are needed to manage bookings within users’ calendar appointments.
		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.
		*Administrators can configure an application access policy to limit access to specific mailboxes even when the app has been granted Calendars.ReadWrite application permissions.

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

2. Is there a permission set for Graph API that allows further granular permissions than Calendar.ReadWrite?

While Calendar.ReadBasic.All gives the access we need to read calendar appointments, it does not give us Write permissions which we require to manage and update your appointments automatically, for example when you change your booking in Condeco.

4. 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 work 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.

5. 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

6. Does Condeco subscribe to notifications for every user calendar with the scope?

No. Condeco only subscribes to the calendars of users who have launched the Condeco Outlook add-in. If the add-in is not started, the user's calendar is not subscribed.

7. How does Condeco receive notifications from users’ calendars?

The Microsoft 365 integration service uses Microsoft Graph to receive notifications from users’ calendars.

8. Which user calendars does Condeco subscribe to via the Microsoft Graph API?

Condeco only subscribes to calendars that are within scope. A list of users who have allowed access (by launching the add-in) is stored in a secure table for auditing purposes.

Learn more about scoping calendar access at Microsoft https://docs.microsoft.com/en-us/graph/auth-limit-mailbox-access

9. 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.

10. 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:

Property	Description
EventID	Event ID
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:

Property	Description
Attendees	The list of attendees for the event, including first name, last name, company name, and phone numbers.
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.
EventId	Event ID.
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:

SingleValueExtendedProperties	Description
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.

11. 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.

12. 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.

13. How are bookings created in Condeco?

Microsoft 365 integration uses RESTful APIs to create meeting space bookings in Condeco.

14. 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.

15. 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.

16. 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.

17. What security measures are available for the Microsoft 365 integration to prevent unauthorized access?

1. 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.
2. We use managed service identity to pass information from one Azure service to another, instead of service accounts.
3. 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.
4. All secrets are stored in the Azure Key Vault and can only be accessed by a secure automated process.
5. 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.
6. Condeco uses change control procedures certified by ISO27001 and CSA Star certificates.

18. We understand Condeco does 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?

1. 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.
2. All Graph API access is audited and Microsoft can provide audit logs to show queries that Condeco executes against a specific Graph API tenant.
3. 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:
   1. Separate branches to promote code to Development, QA, Staging, and Production.
   2. Pull requests are reviewed by two engineers to promote code to Development.
   3. Unit tests validate the use of body and attachment and fail the build in Development only.
   4. Sanity and automation suites in QA process prevent any calls to Body and Attachment, and there are similar controls in staging and production.

 

---

Condeco Microsoft 365 integration home