Consent and Permissions
Since Altus is installed into the target M365 tenancy, it needs consent in order to operate.
Delegated permissions
The permissions below are known as delegated permissions:
Delegated permissions are the subset of both the current user permissions and the application permissions.
Granting delegated permissions:
- Does not grant the application any permission by itself, a user must always be present.
- Does not grant the user permission to do anything they couldn't already do without the app.
- Is a filter that controls what the application can do on the user's behalf.
- Doesn't change the security posture of the Microsoft 365 tenant other than to trust Altus software to work on behalf of the users to perform actions they could already do manually.
More information about delegated permissions.
Why do we need these permissions?
The reason that Altus needs these delegated permissions are:
- Dynamics CRM
- user_impersonation: Altus needs to connect to the Dataverse as the current user and read/write data on their behalf.
- Microsoft Graph
- Files.ReadWrite: When an Altus Project is added to a Microsoft Team, Altus uses the SharePoint Site provisioned with the Team to store documents related to the project. Altus uses this permission to read the list of files from the document library and present them to the user.
- Group.ReadWriteAll: Altus has the ability to facilitate adding Projects to existing Microsoft Teams, or offering to Create a new Team for an Altus project. This allows a trusted group of users to collaborate around the project, having facilities such as Chat, Files, Calendar for the project provided by the hosting Team. Many projects can be connected to Teams and Altus will create a dedicated channel in the Team for each Project.
- User.Read: This is a basic permission required to access the Microsoft Graph, it is required to read attributes of the current user.
- User.Read.All: This permission is used to read the profile pictures of people in the organisation to present at various places such as in the task assignments in the Gantt chart.
Authentication Pop-ups
When an application needs to perform actions on behalf of a user, it requires an Application identity in addition to the current user identity. This dual identity setup allows Microsoft Entra ID to determine whether the requested action should be permitted.
The Application identity is established through an "Application Registration." In this scenario, the application is registered as a multi-tenant application, meaning it can be utilised by multiple Microsoft 365 tenancies. This single application registration must include a fixed Return URL, which is essential for the authentication process to receive the access token. Given that each customer has a unique URL for their Altus instance under the *.dynamics.com domain, and the Return URL must be consistent across all customers, the URL must be hosted centrally. A browser pop-up to a page on the altus.pro domain can be expected on end-user machines to enable this authentication to occur.
Customers can be assured that all authentication processes occur client-side in the browser. Altus publishes this static page via a Content Delivery Network (CDN) to ensure efficient and secure access. The MSAL library passes the access token to the page via anchor method (using a # in the URL) which ensures the access token cannot be passed to an Altus server.
These requirements are dictated by the architecture of Microsoft Entra ID.