Limit Cronofy's access by Role-Based Access Control (RBAC)

Read as Markdown

Microsoft plans to deprecate Application Access Policies and replace them with Role Based Access Control (RBAC), but has not announced a timeline.

For now, Application Access Policies are the recommended way to scope Cronofy’s access for Graph-based Enterprise Connect connections. We’re working on RBAC support and will update this documentation when it’s available.

Setting up Role Based Access Control #

The purpose of configuring Role Based Access Control is to limit the Calendars.ReadWrite scope of the Cronofy Entra application to a specific set of users.

The process of setting up Role Based Access Control will involve the following steps:

Creating a Service Principal - This is a representation of the Entra application within your tenant that you wish to limit the access of.
Creating a Management Scope - This is used to define the set of users you wish to limit the application to based on the properties of these objects.
Creating a Management Role Assignment - This ties together a principal, role, and custom resource scope of access. This assignment acts as the permissions assignment for a service principal performing a role across a scope.

You can set up Role Based Access Control and limit the scope of Cronofy’s application permissions by following the below steps:

Connect to Exchange Online PowerShell. For details, see Connect to Exchange Online PowerShell
Identify the Cronofy application’s Object ID and Application ID: 10bb7e5b-b80b-4e6e-a209-f78581dbc79e. You may confirm this by visiting the Azure Active Directory Enterprise application portal as seen below.

Create a Service Principal. Run the below command, replacing the arguments for ObjectID and DisplayName:

 New-ServicePrincipal -AppId 10bb7e5b-b80b-4e6e-a209-f78581dbc79e -ObjectId CRONOFY_APP_OBJECT_ID -DisplayName "Cronofy Service Principal"

Create a mail-enabled security group or use an existing one.
4.1 In our example, we created a mail-enabled security group with the name ‘Application Security Group’. You will need the DistinguishedName of the security group you have created in order to create the new Management Scope in the following step. You can get this by running the following command, replacing the argument for Identity:
```
Get-DistributionGroup -Identity  "Application Security Group" | Format-List DistinguishedName
```
4.2 Once you have the DistinguishedName you can then create a new Management Scope by running the following command, replacing the argument for Name and MemberOfGroup:
```
New-ManagementScope -Name "ApplicationCalendarScope" -RecipientRestrictionFilter {MemberOfGroup -eq 'DISTINGUISHEDNAME'}
```

Currently, mail-enabled security groups must be created from Exchange Admin center or Classic Exchange Admin Center to take action. Security groups created from Azure itself won’t get reflected on Exchange Online and therefore, you wouldn’t be able to use those groups for Role Based Access Control.

Create a New Management Role Assignment for the role ‘Application Calendars.ReadWrite’ associated with the previously created Resource Scope, replacing the argument for CustomResourceScope:
```
New-ManagementRoleAssignment -App 10bb7e5b-b80b-4e6e-a209-f78581dbc79e -Role "Application Calendars.ReadWrite" -CustomResourceScope "ApplicationCalendarScope"
```
In order for this limitation to take effect you will need to ensure that you’ve removed the tenant-wide unscoped permissions you assigned in Microsoft Entra ID. This is because the permissions assigned using RBAC act in addition to grants you make in Microsoft Entra ID. It is mentioned in the FAQ section of Microsoft RBAC page. You can do this via the below steps:
6.1 Navigate to the Azure Active Directory Enterprise application portal.
6.2 Click on the Application “Cronofy Enterprise for Office 365” and under the Security heading on the left hand side click on Permissions.
6.3 Under the heading Admin consent click on the three dots to the right of the Claim value “Calendars.ReadWrite” and select Revoke Permission. Then click ‘Yes, revoke’.

Revoke only the Calendars.ReadWrite permission and leave the application’s other permissions in place. The application can’t operate without them, and revoking all of them will make Microsoft prompt for admin consent again the next time you connect or reauthorize.

Please note that going back through the authorisation flow (or reauthorizing) re-grants all tenant-wide scopes, including Calendars.ReadWrite, so you’ll need to revoke Calendars.ReadWrite again (following the steps above) to keep only your RBAC permissions in place.

You can test the authorisation to see whether specific users show as being part of the scope you have just defined by running the below command, replacing the argument for Resource:
```
Test-ServicePrincipalAuthorization -Identity 10bb7e5b-b80b-4e6e-a209-f78581dbc79e -Resource "EMAIL ADDRESS"
```
The result will include the parameter InScope which will return either True or False, where True indicates Cronofy has access to their calendar data.

If you need to restore or re-grant permissions (for example, to switch from RBAC back to an Application Access Policy), you can reauthorize your service account at any time. Sign in to the Enterprise Connect portal for your data center:

Once signed in, go to Managed Accounts and select the Reauthorize the service account link at the bottom of the page. On the page that opens, click the Reauthorize button to start the flow.

Reauthorizing re-runs Microsoft’s admin consent for this tenancy. It must be completed by an administrator of the same Microsoft 365 tenant as the service account, and it will not change how your connected applications reach Cronofy.

Please note: this flow always grants Cronofy’s application the Calendars.ReadWrite permission across your whole tenant. This is a tenant-wide grant that is not filtered by an RBAC policy. There is no calendar-access-mode choice on this path, so it cannot do a partial or scoped grant. Because Calendars.ReadWrite allows access to all calendars, reauthorizing will override an RBAC restriction you are managing yourself:

If you are switching to an Application Access Policy, make sure that policy is in place so Cronofy’s access stays limited to the intended mailboxes.
If you want to keep your RBAC policy, you can still use this flow, but you must revoke the Calendars.ReadWrite permission again in the Azure portal, following the revocation steps above, once you have completed it.