I due oggetti: application object e service principal

Il punto più frainteso di questo dominio è la relazione tra app registration e enterprise application. Quando registri un’applicazione in Microsoft Entra ID crei un application object (il tipo Application in Microsoft Graph): è la definizione globale dell’app, vive una sola volta nel tenant di origine (home tenant) e descrive identità, redirect URI, credenziali (secret/certificati), permessi richiesti e se l’app è single- o multi-tenant. È il “template”.

Il service principal (tipo ServicePrincipal in Graph) è invece l’istanza locale per tenant: rappresenta l’app dentro un tenant specifico e definisce cosa quell’app può effettivamente fare lì (permessi concessi, ruoli, assegnazioni utente, policy di SSO). Nel portale Entra il service principal è ciò che vedi sotto Enterprise applications.

Come si materializzano gli oggetti

  • Registri un’app nel tuo tenant → nasce 1 application object + 1 service principal nello stesso tenant.
  • Un’app multi-tenant (o della gallery) usata da un’altra organizzazione → nel tenant “ospite” viene creato solo un service principal, collegato all’unico application object che resta nel tenant di origine.
  • Le workload identity (app, service principal, managed identity) sono identità non umane: vanno governate come le utenze, con Conditional Access for workload identities e revisione delle credenziali.

Regola pratica: modifichi il comportamento dell’app (SSO, chi la usa, consensi) → lavori sull’enterprise application/service principal; modifichi la definizione (API permissions richieste, redirect URI, credenziali) → lavori sull’app registration.

Per le app della gallery aggiunte come enterprise application scegli il metodo SSO adatto al protocollo supportato dall’app:

  • SAML-based SSO e OIDC/OAuth: federazione moderna, claim mapping, provisioning SCIM.
  • Password-based SSO: Entra memorizza e inietta le credenziali (app legacy senza federazione).
  • Linked: solo un collegamento nel My Apps, nessuna gestione identità.

Delegated vs application permissions

La scelta del tipo di permesso dipende dal contesto di esecuzione:

  • Delegated permissions: l’app agisce per conto di un utente autenticato. Il permesso effettivo è l’intersezione tra ciò che l’app richiede e i privilegi reali dell’utente. Tipico di web app e SPA interattive.
  • Application permissions: l’app agisce come sé stessa, senza utente (daemon, job in background, servizio backend via client credentials flow). Non c’è utente che “presti” i propri diritti, quindi il permesso è pieno e potenzialmente elevato.

Conseguenza chiave: le application permissions richiedono SEMPRE l’admin consent. Un utente non può mai auto-concederle.

Il consent framework governa come vengono concessi i permessi OAuth. L’admin consent è il consenso tenant-wide, concesso una volta da un ruolo abilitato (Global Administrator, Privileged Role Administrator, Cloud Application Administrator, Application Administrator) e valido per tutti gli utenti.

Per ridurre il rischio di illicit consent grant (app malevole che ottengono token abusando del consenso utente), configura le user consent settings (Enterprise applications → Consent and permissions):

  • Do not allow user consent — massima restrizione.
  • Allow user consent per verified publishers e permessi a basso impatto — bilanciamento consigliato.
  • Allow for all apps — sconsigliato.

Abbina l’admin consent workflow: quando un utente incontra un permesso che non può auto-concedere, invia una richiesta a reviewer designati, che approvano o rifiutano dal portale. Così blocchi il consenso indiscriminato mantenendo la produttività.

Trappole tipiche d’esame

  • “Devo cambiare il metodo SSO / disabilitare l’accesso utenti a un’app della gallery” → agisci sull’enterprise application (service principal), NON sull’app registration.
  • “Un’app daemon deve leggere tutte le mailbox senza utente” → serve una application permission, che richiede admin consent: nessuna user consent setting la renderà auto-concedibile.
  • “Ridurre il rischio di illicit/illegal consent grant” → restringi le user consent settings (verified publishers + low-impact) e attiva l’admin consent workflow; non basta l’MFA.
  • “App multi-tenant usata da un partner: dove sta l’oggetto nel loro tenant?” → nel tenant del partner esiste solo il service principal; l’application object resta nel tuo home tenant.
  • “Chi può dare admin consent?” → Global Admin, Privileged Role Admin, Cloud Application Admin o Application Admin — non un utente standard, neanche con user consent abilitato.