I portali Odoo offrono a clienti e partner accesso a documenti, transazioni e servizi pertinenti. Questo pone una domanda di progettazione dell'identità: gli utenti esterni dovrebbero condividere la directory e il modello di accesso dei dipendenti?
A volte un account guest aziendale in un tenant workforce è appropriato. Su scala maggiore, o quando sono richiesti un accesso cliente con marchio e una registrazione self-service, Microsoft Entra External ID offre un modello dedicato di gestione delle identità e degli accessi per i clienti.
Collegare questo modello a Odoo può supportare un confine più chiaro tra utenti interni e utenti del portale. Il confine richiede comunque ammissione esplicita, creazione dell'account e regole di autorizzazione Odoo.
I tenant workforce e quelli esterni sono progettati per pubblici diversi
Microsoft definisce un tenant workforce come l'ambiente per dipendenti, applicazioni aziendali interne e risorse organizzative. Può anche contenere partner aziendali invitati e guest. Un tenant esterno è una configurazione separata per applicazioni offerte a consumatori e clienti business. Microsoft descrive la distinzione nella sua guida alla configurazione del tenant.
Un tenant esterno contiene la propria directory clienti e le proprie registrazioni delle applicazioni. External ID aggiunge registrazione self-service, accesso, reimpostazione della password, gestione dell'account e federazione con provider di identità. La panoramica di External ID spiega il modello dedicato.
Questa separazione può aiutare un'organizzazione a evitare di trattare un cliente come un dipendente solo perché entrambi devono accedere a un servizio Odoo.
Scegli il pubblico prima di configurare l'accesso
Ci sono almeno tre distinti pubblici Odoo da considerare:
Dipendenti e utenti interni
Questi utenti normalmente appartengono al tenant workforce dell'organizzazione. Se ammessi in Odoo, in genere hanno bisogno di account utente Odoo interni con gruppi di accesso mappati con attenzione.
Persone provenienti da organizzazioni partner approvate
Alcune aziende desiderano utenti provenienti da un elenco definito di tenant Entra di clienti o partner. Una connessione workforce multi-tenant con un allow-list preciso dei tenant può essere appropriata quando ogni organizzazione è nota e l'accesso è approvato contrattualmente.
La convalida del tenant è fondamentale. Corrispondere solo a un dominio email non è sufficiente perché domini e indirizzi email possono cambiare. Convalida il tenant del token e gli identificatori immutabili subject o object in base al design della connessione.
Clienti e utenti esterni
Per le applicazioni rivolte ai clienti, un tenant External ID può offrire una directory e un'esperienza di accesso separati. Gli account Odoo creati per questo pubblico dovrebbero normalmente essere utenti del portale, non utenti interni.
Questi modelli dovrebbero essere configurati come connessioni separate quando le loro regole di ammissione e di account Odoo differiscono. Una singola connessione ampia è più difficile da comprendere e più facile da configurare in modo errato.
External ID supporta un percorso di accesso per i clienti
I flussi utente di External ID definiscono i metodi di autenticazione dei clienti e le informazioni raccolte durante la registrazione. Un flusso è associato alle applicazioni registrate per attivare registrazione e accesso. Microsoft documenta questo in aggiunta di un'applicazione a un flusso utente di External ID.
External ID può supportare account locali e federazione con provider di identità, inclusi Microsoft Entra ID e provider OpenID Connect personalizzati. Attributi predefiniti e personalizzati possono essere raccolti durante la registrazione, come descritto nella guida agli attributi del cliente di Microsoft.
Raccogli solo le informazioni di cui Odoo ha realmente bisogno e documenta lo scopo, la conservazione e il trattamento della privacy di ogni attributo.
Le autorizzazioni predefinite aiutano a preservare la separazione
Microsoft afferma che gli utenti del tenant esterno iniziano con autorizzazioni predefinite limitate. In genere possono accedere alle applicazioni e gestire il proprio profilo, ma non ricevono ampi diritti di amministrazione della directory. Vedi autorizzazioni predefinite nei tenant esterni.
Quel confine della directory non configura automaticamente le autorizzazioni del portale Odoo. Odoo controlla comunque quali record un utente del portale può vedere tramite i propri diritti di accesso e le proprie regole di record. Testa l'esperienza del portale con record cliente rappresentativi e con più di una società o account per garantire che i dati siano isolati correttamente.
Non promuovere un nuovo utente esterno a utente interno Odoo a meno che non esista un processo aziendale separato e approvato.
Usa un flusso OpenID Connect moderno e convalidato
Microsoft supporta il flusso di autorizzazione OAuth 2.0 con Proof Key for Code Exchange e OpenID Connect per applicazioni web server-based. La sua documentazione sul flusso di autorizzazione code flow descrive questa combinazione supportata.
OIDC estende OAuth 2.0 per l'autenticazione. Microsoft pubblica metadati di discovery, dettagli degli endpoint e chiavi pubbliche di firma. Raccomanda inoltre di convalidare il token restituito e di controllare un nonce per ridurre il rischio di replay. Vedi OpenID Connect sulla Microsoft identity platform.
Un'integrazione sicura dovrebbe convalidare issuer, audience, firma, contesto del tenant e nonce attesi. PKCE non sostituisce la convalida del token, la configurazione esatta del callback, il TLS o la protezione del client secret.
L'accesso di base può richiedere scope OIDC standard come openid, profile ed email. Microsoft osserva che questi scope sono ospitati su Microsoft Graph e raccomanda di richiedere solo le autorizzazioni di cui l'applicazione ha bisogno. Vedi scope della Microsoft identity platform. Una descrizione precisa del prodotto è quindi "nessuna autorizzazione Microsoft Graph API ad alto privilegio per l'accesso standard", piuttosto che un'affermazione generica che Graph non sia coinvolto.
Decidi come gli utenti esterni accedono a Odoo
Prima di abilitare il primo accesso, definisci:
- Se la self-registration è aperta o se è necessaria l'approvazione.
- Quali tenant o provider di identità sono ammessi.
- Se un account portale Odoo esistente può essere collegato.
- Quale identificatore Microsoft immutabile viene archiviato dopo il collegamento.
- A quale azienda e quale record partner Odoo appartiene l'utente.
- Quali gruppi portal e regole di record si applicano.
- Cosa accade quando l'accesso viene revocato.
- Come viene revocata una sessione Odoo attiva.
La creazione automatica dell'account può ridurre l'amministrazione, ma dovrebbe avvenire solo dopo che l'identità soddisfa le regole di ammissione della connessione. Un'autenticazione Microsoft riuscita dimostra il controllo dell'identità accettata. Da sola, non dimostra che la persona debba vedere i record Odoo di un cliente specifico.
Pianifica il supporto clienti e il ripristino
Gli utenti esterni potrebbero non avere un help desk interno. Pubblica un canale di supporto e identifica chi gestisce l'identità. Verifica i scenari di reimpostazione della password, ripristino, rimozione del tenant e cambio di email. Mantieni gli eventi diagnostici utili ma redatti.
Se la tua esigenza immediata è l'accesso dei dipendenti, leggi perché dovresti proteggere la tua istanza Odoo con Microsoft SSO. Per i permessi interni, vedi centralizzare l'accesso Odoo con gruppi Entra e ruoli applicativi.
Collega il pubblico esterno a Odoo 19
Il nostro modulo Microsoft Entra SSO per Odoo supporta connessioni separate per dipendenti, organizzazioni approvate e pubblico clienti Microsoft Entra External ID. Le connessioni External ID creano utenti portal per impostazione predefinita, mentre le connessioni workforce creano utenti interni. La configurazione guidata convalida le informazioni di discovery e le chiavi di firma, poi richiede un test interattivo prima che l'accesso con Microsoft sia abilitato.
Il modulo non decide chi deve essere ammesso o quali record cliente debba vedere. Queste restano decisioni di business e di accesso Odoo. Esamina il modulo se ti serve un ponte controllato tra l'identità cliente Microsoft e un portale Odoo 19, con gestione degli account specifica per il pubblico invece di un unico percorso di accesso indifferenziato.