Prerequisites
ReportMesh does not manage its own identities. It signs people in against services your organisation already runs, and reads report content using identities registered in those same services. Those registrations have to exist before the portal is deployed, because the application reads them at start-up and there is nothing in the product that can create them for you.
Who this is for: Whoever is standing the portal up. Most of the work below happens in Microsoft's and Duo's administration consoles rather than in ReportMesh, and several parts need someone holding a directory administrator role, who may well be a different person.
The registrations on this page are the usual reason a deployment slips. Each needs an administrator's consent in a system you may not control, and requests for that consent sit in someone else's queue. Begin them on day one, in parallel with the infrastructure build, rather than discovering on deployment day that consent was never granted.
What has to exist
| Service | What it does for ReportMesh | Required? |
|---|---|---|
| Entra ID | Signs internal staff in, and syncs the user directory | Always |
| Duo | Second factor for internal staff, after Entra sign-in | Where MFA is wanted for staff |
| Cognito | Signs external guests in, with authenticator-app MFA | Only if external guests are in scope |
| Power BI workspaces | Lets ReportMesh read and embed reports | If Power BI reports are in scope |
| SharePoint sites | Lets ReportMesh read Excel workbooks | If Excel workbooks are in scope |
Entra is not optional even when internal sign-in is not. A separate Entra identity is what reads Power BI reports and SharePoint workbooks, so an Entra registration is required regardless of how your people sign in. Cognito adds a second sign-in path; it does not remove the need for Entra.
Access you need
| Where | What | For |
|---|---|---|
| Entra ID | Application Administrator or Global Administrator | Granting admin consent, which an ordinary user cannot do |
| Duo | Administrator on the Duo Admin Panel | Creating the application and enrolling users |
| AWS | Permission to create Cognito and IAM resources | The external-user pool and its instance role |
| Fabric / Power BI | Tenant administrator, plus workspace administrator on each workspace | Tenant settings and workspace membership |
| SharePoint | SharePoint or Global Administrator | Granting access to each site, one at a time |
If you hold none of these yourself, identify the people who do before you start. The SharePoint grant in particular cannot be delegated to the application: Microsoft requires a signed in administrator with full control of the site, and offers no way for an application to do it on their behalf.
Two hostnames, one parent domain
Decide both public hostnames before creating any registration, because they are registered as redirect URIs in Entra and Duo and changing one afterwards means editing several places.
- The portal itself, for example
app.example.com - The API, for example
api.example.com - If external guests are in scope, their sign-in site, for example
portal.example.com
All of them must be subdomains of the same parent domain. They are then different origins but the same site, which is what lets the session cookie reach the API from the portal. Hosting the portal on a default CloudFront address instead makes it a different site, and the browser stops sending the session cookie: sign in appears to succeed and every subsequent request fails, with nothing in any log to explain why.
Secrets
Every registration below produces a client secret, and each is shown once and cannot be retrieved afterwards. Record them in a password manager as you go, not in a ticket or a chat message.
Put each secret's expiry in a calendar. When the Entra sign in secret lapses, sign in and directory sync stop; when the content secret lapses, every embedded report stops rendering at once. Neither fails gracefully, and neither warns you first.
Where to go next
Work through them in this order. Entra first, because the others reference values it produces.
- Entra ID — internal sign in, directory sync, and the content identity
- Duo — the second factor for internal staff
- Cognito — external guests, if they are in scope
Then give the content identity reach over the content itself. The two pages below are written for the people holding the relevant administrator roles, and can be handed over as they stand:
- Granting Power BI workspace access — for a Fabric administrator and each workspace administrator
- Granting SharePoint site access — for a SharePoint or Global administrator, once per site