Odoo порталите дават на клиенти и партньори достъп до релевантни документи, транзакции и услуги. Това поражда въпрос за дизайна на идентичността: трябва ли външните потребители да споделят директорията и модела за достъп на служителите?

Понякога акаунт за бизнес гост в workforce tenant е подходящ. При по-голям мащаб, или когато са необходими брандирано влизане на клиенти и self-service регистрация, Microsoft Entra External ID предоставя специализиран модел за управление на клиентска идентичност и достъп.

Свързването на този модел с Odoo може да подпомогне по-ясна граница между вътрешни потребители и portal потребители. Тази граница все пак изисква изрично допускане, създаване на акаунт и правила за Odoo авторизация.

Workforce и external tenant са предназначени за различни аудитории

Microsoft определя workforce tenant като средата за служители, вътрешни бизнес приложения и организационни ресурси. Той може също да съдържа поканени бизнес партньори и гости. External tenant е отделна конфигурация за приложения, предлагани на потребители и бизнес клиенти. Microsoft описва разликата в своето ръководство за конфигуриране на tenant.

External tenant съдържа собствена директория за клиенти и регистрации на приложения. External ID добавя self-service регистрация, влизане, нулиране на парола, управление на акаунти и федерация с доставчици на идентичност. Прегледът на External ID обяснява този специализиран модел.

Това разделение може да помогне на организацията да не третира клиент като служител само защото и двамата се нуждаят от достъп до Odoo услуга.

Изберете аудиторията преди да конфигурирате влизането

Поне три различни Odoo аудитории трябва да се разгледат:

Служители и вътрешни потребители

Тези потребители обикновено принадлежат към workforce tenant на организацията. Ако бъдат допуснати до Odoo, те обикновено се нуждаят от вътрешни Odoo потребителски акаунти с внимателно съпоставени групи за достъп.

Хора от одобрени партньорски организации

Някои бизнеси искат потребители от определен списък с клиентски или партньорски Entra tenants. Multi-tenant workforce връзка с точен allow-list на tenants може да е подходяща, когато всяка организация е известна и достъпът е договорно одобрен.

Проверяването на tenant е критично. Съвпадение само по имейл домейн не е достатъчно, защото домейните и имейл адресите могат да се променят. Валидирайте token-а, tenant-а и неизменяемите subject или object идентификатори според дизайна на връзката.

Клиенти и външни потребители

За клиентски приложения External ID tenant може да предостави отделна директория и преживяване при влизане. Odoo акаунтите, създадени за тази аудитория, обикновено трябва да са portal потребители, а не вътрешни потребители.

Тези модели трябва да се конфигурират като отделни връзки, когато правилата за допускане и Odoo акаунтите се различават. Една единствена, широка връзка е по-трудна за анализ и по-лесна за грешно конфигуриране.

External ID поддържа път за влизане на клиенти

External ID user flow-овете определят методите за удостоверяване на клиенти и информацията, събирана по време на регистрация. Един flow е свързан с регистрирани приложения, за да активира регистрация и влизане. Microsoft документира това в добавяне на приложение към External ID user flow.

External ID може да поддържа локални акаунти и федерация с доставчици на идентичност, включително Microsoft Entra ID и custom OpenID Connect providers. Вградени и custom атрибути могат да се събират по време на регистрация, както е описано в Microsoft ръководство за клиентски атрибути.

Събирайте само информацията, която Odoo реално изисква, и документирайте целта, съхранението и обработката на поверителността за всеки атрибут.

Потребителските права по подразбиране помагат да се запази разделението

Microsoft посочва, че потребителите в external tenant започват с ограничени права по подразбиране. По принцип те могат да достъпват приложения и да управляват собствения си профил, но не получават широки права за администриране на директорията. Вижте правата по подразбиране във external tenants.

Тази граница на директорията не конфигурира автоматично Odoo portal разрешенията. Odoo все още контролира кои записи може да вижда portal потребител чрез собствените си права за достъп и record rules. Тествайте portal преживяването с представителни клиентски записи и повече от една компания или акаунт, за да се уверите, че данните са изолирани правилно.

Не превръщайте новосъздаден external потребител във вътрешен Odoo потребител, освен ако няма отделен, одобрен бизнес процес.

Използвайте модерен, валидиран OpenID Connect flow

Microsoft поддържа OAuth 2.0 authorization code flow с Proof Key for Code Exchange и OpenID Connect за уеб приложения на сървърна страна. Неговата документация за authorization code flow описва тази поддържана комбинация.

OIDC разширява OAuth 2.0 за удостоверяване. Microsoft публикува discovery metadata, детайли за endpoint-и и публични signing keys. Той също препоръчва да се валидира върнатият token и да се проверява nonce, за да се намали рискът от replay атака. Вижте OpenID Connect в Microsoft identity platform.

Сигурната интеграция трябва да валидира очаквания issuer, audience, signature, tenant context и nonce. PKCE не замества валидирането на token, точната конфигурация на callback, TLS или защитата на client secret.

Основното влизане може да изисква стандартни OIDC scopes като openid, profile и email. Microsoft отбелязва, че тези scopes се хостват в Microsoft Graph и препоръчва да се искат само разрешенията, от които приложението се нуждае. Вижте scopes на Microsoft identity platform. Следователно по-точното продуктово твърдение е „без високопривилегировани Microsoft Graph API разрешения за стандартно влизане“, а не общо твърдение, че Graph не участва.

Решете как външните потребители достигат до Odoo

Преди да активирате първото влизане, определете:

  • Дали self-registration е отворена или се изисква одобрение.
  • Кои tenants или доставчици на идентичност са допуснати.
  • Дали съществуващ Odoo portal акаунт може да бъде свързан.
  • Кой неизменяем Microsoft идентификатор се съхранява след свързването.
  • Коя Odoo компания и кой партньор принадлежи на потребителят.
  • Кои портални групи и правила за записите се прилагат.
  • Какво се случва, когато достъпът бъде отнет.
  • Как се отнема активна Odoo сесия.

Автоматичното създаване на акаунти може да намали административната работа, но то трябва да се извършва само след като идентичността изпълни правилата за допускане на връзката. Успешното Microsoft удостоверяване доказва контрол над приетата идентичност. Само по себе си то не доказва, че човекът трябва да вижда конкретните Odoo записи на даден клиент.

Планирайте поддръжка на клиенти и възстановяване

Външните потребители може да нямат вътрешен help desk. Публикувайте канал за поддръжка и посочете кой управлява идентичността. Тествайте сценарии за нулиране на парола, възстановяване, премахване на tenant и промяна на имейл. Запазвайте диагностичните събития полезни, но редактирани.

Ако непосредствената ви нужда е достъп за служители, прочетете защо трябва да защитите вашата Odoo инстанция с Microsoft SSO. За вътрешни разрешения вижте централизиране на Odoo достъпа с Entra групи и app роли.

Свързване на външни аудитории с Odoo 19

Нашият Microsoft Entra SSO for Odoo модул поддържа отделни връзки за служители, одобрени организации и аудитории от клиенти на Microsoft Entra External ID. Връзките с External ID създават портални потребители по подразбиране, докато връзките за workforce създават вътрешни потребители. Насочената настройка валидира информацията за discovery и signing keys, след което изисква интерактивен тест, преди да бъде активиран Microsoft sign-in.

Модулът не решава кой трябва да бъде допуснат или кои клиентски записи трябва да вижда. Това остават бизнес и Odoo решения за достъп. Разгледайте модула, ако ви е нужен контролиран мост между Microsoft customer identity и Odoo 19 portal, с обработка на акаунтите според аудиторията, а не с един недиференциран вход.