Il single sign-on risponde a una domanda di autenticazione: Microsoft ha verificato questo utente in base alla policy dell'organizzazione? Non risponde a tutte le domande di autorizzazione all'interno di Odoo.

Un utente autenticato potrebbe aver bisogno di accesso alle vendite ma non alla contabilità, ai progetti ma non alle buste paga, oppure a un portale clienti ma non all'interfaccia interna. Queste decisioni restano responsabilità di Odoo. I gruppi Microsoft Entra e i ruoli applicativi possono fornire input affidabili per renderle più coerenti.

Gruppi e ruoli app hanno scopi diversi

I gruppi Microsoft Entra appartengono al tenant. Possono rappresentare reparti, funzioni lavorative, progetti o confini di sicurezza. I ruoli applicativi appartengono a una specifica registrazione app e descrivono ruoli significativi per quell'applicazione.

La documentazione Microsoft sui ruoli app spiega che i ruoli app possono essere assegnati a utenti o gruppi. Quando un utente assegnato accede, Entra può includere i ruoli concessi in un claim roles. Microsoft afferma anche che ruoli app e gruppi non si escludono a vicenda.

Questo offre a un design di accesso Odoo due modelli principali:

  • Mappare direttamente gli Object ID dei gruppi di sicurezza Entra stabili ai gruppi Odoo selezionati.
  • Definire ruoli app orientati a Odoo nella registrazione app Entra, assegnare utenti o gruppi a tali ruoli e mappare i valori dei ruoli risultanti ai gruppi Odoo.

La mappatura diretta funziona bene con gruppi di sicurezza governati. I ruoli app possono offrire un confine applicativo più pulito perché la loro intenzione segue la registrazione app invece di dipendere da nomi specifici del tenant.

Parti dal modello di accesso reale di Odoo

Non iniziare copiando ogni gruppo Microsoft in Odoo. Parti dalle autorizzazioni Odoo di cui l'azienda ha davvero bisogno.

Elenca i gruppi Odoo che concedono capacità rilevanti. Per ciascuno, documenta:

  • Lo scopo aziendale dell'accesso.
  • La persona responsabile dell'approvazione.
  • Il gruppo Entra o il ruolo app che rappresenta l'approvazione.
  • Quanto rapidamente una modifica dovrebbe arrivare a Odoo e cosa accade a una sessione attiva dopo la rimozione.

Usa il principio del privilegio minimo. Un gruppo di reparto ampio può essere comodo, ma potrebbe concedere più accesso a Odoo di quanto serva a ogni membro. Un gruppo di sicurezza o un ruolo app più piccolo e specifico per Odoo è spesso più facile da verificare.

Tratta il binding dell'identità come un controllo di sicurezza

Molti sistemi inizialmente associano un account esistente usando un indirizzo email. È comodo, soprattutto quando Odoo e Microsoft usano già la stessa email aziendale. Non è però una chiave di identità durevole.

Microsoft avverte nella sua referenza ai claim del token ID che indirizzi email, numeri di telefono e user principal name possono cambiare e possono essere riutilizzati. Microsoft raccomanda claim immutabili come sub o oid, con tid quando è richiesto il contesto del tenant, per un'identificazione affidabile.

Un modello più sicuro è:

  1. Accetta solo un tenant atteso e un audience approvato.
  2. Usa l'email per una corrispondenza iniziale controllata, quando appropriato.
  3. Rifiuta corrispondenze ambigue o duplicate.
  4. Archivia l'identità Microsoft immutabile e gli identificatori del tenant dopo il collegamento.
  5. Usa questi valori immutabili per gli accessi futuri.

Per l'accesso multi-tenant, il contesto del tenant è essenziale. La stessa persona può avere identificatori oggetto diversi in tenant diversi, e l'accesso da un tenant non dovrebbe ereditare silenziosamente le autorizzazioni associate a un altro.

Comprendi il caso di eccedenza dei group claim

I group claim sono comodi, ma non sono illimitati. Microsoft documenta un limite di 200 Object ID di gruppi in un JWT. Quando l'appartenenza di un utente supera il limite, Entra omette il normale elenco dei gruppi e restituisce un indicatore di eccedenza che indirizza l'applicazione a interrogare Microsoft Graph. Consulta la guida all'eccedenza dei gruppi.

Questo è importante se un'integrazione pubblicizza la mappatura dei gruppi senza permessi elevati per Microsoft Graph API. Un utente con un'appartenenza ampia a gruppi potrebbe non ricevere il set atteso di group claim.

Prima di fare affidamento sulla mappatura diretta dei gruppi, conferma come viene gestita l'eccedenza. Le opzioni includono gruppi più piccoli specifici per l'app, ruoli app, filtraggio dei claim oppure una lookup basata su Graph con consenso al minimo privilegio.

La sincronizzazione al momento dell'accesso non è provisioning in tempo reale

Un modulo SSO può confrontare i claim Entra correnti con le mappature Odoo configurate quando un utente accede. È utile perché l'accesso può essere allineato durante un normale evento di autenticazione.

Non è la stessa cosa del provisioning continuo. Se un dipendente viene rimosso da un gruppo Entra mentre una sessione Odoo è attiva, quella sessione può continuare fino al logout, alla scadenza o a un altro controllo di revoca. Se un ex dipendente non accede mai più, un processo di sincronizzazione all'accesso non archivia di per sé l'account Odoo.

Microsoft Entra ID Governance offre Lifecycle Workflows per i processi di joiner, mover e leaver, incluso il disabilitare gli account e rimuovere le assegnazioni di accesso. Consulta la guida ai Lifecycle Workflows. Queste funzionalità richiedono una licenza Microsoft Entra ID Governance o Microsoft Entra Suite.

L'automazione del ciclo di vita può migliorare lo stato dell'identità sorgente, ma non aggiorna comunque Odoo a meno che un'integrazione non consumi la modifica. La procedura di offboarding dovrebbe coprire esplicitamente la revoca della sessione Odoo e lo stato dell'account.

Costruisci un modello di mappatura verificabile

Mantieni comprensibile il numero di mappature. Per ogni gruppo o ruolo, usa un identificatore stabile e una descrizione leggibile. Registra perché esiste il relativo accesso Odoo, chi lo ha approvato e quando è stato rivisto l'ultima volta.

Testa almeno questi casi:

  • Utente esistente con una mappatura prevista.
  • Utente senza mappatura approvata o con un tenant non consentito.
  • Nuovo utente ammesso per il primo accesso.
  • Utente rimosso da un gruppo mappato o con molte appartenenze a gruppi.
  • Utente rinominato la cui identità immutabile non è cambiata.
  • Account Microsoft disabilitato con una sessione Odoo esistente.

Gli eventi di accesso dovrebbero aiutare gli amministratori a diagnosticare gli esiti delle attestazioni e delle mappature senza esporre token, credenziali o segreti. I log dovrebbero identificare la connessione e il risultato, ma i valori sensibili dovrebbero essere redatti.

Combina la mappatura con la policy di autenticazione

I controlli di mappatura di gruppi e ruoli governano l'autorizzazione in Odoo. Microsoft Entra Conditional Access controlla se Microsoft completerà l'autenticazione nelle condizioni attuali. I due livelli si completano a vicenda.

Ad esempio, un ruolo app di Entra può essere mappato a un gruppo finanziario Odoo, mentre Conditional Access richiede una robusta autenticazione resistente al phishing per gli utenti assegnati a quel ruolo. Leggi come Microsoft Entra Conditional Access rafforza l'accesso a Odoo per la parte relativa alla policy di autenticazione.

Per clienti e partner, non riutilizzare automaticamente le mappature dei dipendenti. Un pubblico separato e un design orientato al portale potrebbero essere più sicuri. Vedi Microsoft Entra External ID per i clienti e partner di Odoo.

Mappa l'accesso Microsoft approvato in Odoo 19

Il nostro modulo Microsoft Entra SSO per Odoo supporta la mappatura di Object ID dei gruppi di sicurezza Entra o dei ruoli applicativi configurati verso i gruppi di accesso Odoo selezionati. Può sincronizzare tali mappature al momento dell'accesso, collegare un account esistente controllato e creare utenti approvati della forza lavoro o del portale in base al tipo di connessione.

Il modulo non sostituisce la governance degli accessi, la revoca delle sessioni o una strategia documentata per i casi di eccedenza. Esamina la scala dei tuoi gruppi, i requisiti di associazione dell'identità e il modello dei permessi di Odoo prima di abilitare le mappature. Se queste basi sono chiare, il modulo offre un modo guidato per collegarle.