Порталы Odoo предоставляют клиентам и партнёрам доступ к нужным документам, операциям и сервисам. Это поднимает вопрос по проектированию идентификации: должны ли внешние пользователи использовать тот же каталог и ту же модель доступа, что и сотрудники?

Иногда уместна гостевая бизнес-учётная запись в рабочем тенанте. Но на большем масштабе, либо когда нужен фирменный вход для клиентов и самостоятельная регистрация, Microsoft Entra External ID предоставляет выделенную модель управления идентификацией и доступом для клиентов.

Связь этой модели с Odoo может помочь чётче разделить внутренних пользователей и пользователей портала. При этом граница всё равно требует явного допуска, создания учётной записи и правил авторизации в Odoo.

Рабочие и внешние тенанты рассчитаны на разные аудитории

Microsoft определяет рабочий тенант как среду для сотрудников, внутренних бизнес-приложений и организационных ресурсов. В нём также могут быть приглашённые партнёры и гости. Внешний тенант, это отдельная конфигурация для приложений, предлагаемых потребителям и бизнес-клиентам. Microsoft описывает это различие в своём руководстве по конфигурации тенанта.

Внешний тенант содержит собственный каталог клиентов и регистрации приложений. External ID добавляет самостоятельную регистрацию, вход, сброс пароля, управление учётной записью и федерацию с поставщиками идентификации. Обзор External ID объясняет эту выделенную модель.

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

Определите аудиторию до настройки входа

Есть как минимум три разные аудитории Odoo, которые следует учитывать:

Сотрудники и внутренние пользователи

Эти пользователи обычно должны находиться в рабочем тенанте организации. Если им предоставляется доступ к Odoo, им, как правило, нужны внутренние учётные записи Odoo с тщательно сопоставленными группами доступа.

Пользователи из одобренных партнёрских организаций

Некоторые компании хотят разрешить вход пользователям из определённого списка клиентских или партнёрских тенантов Entra. Многотенантное рабочее подключение с точным allow-list по тенантам может быть уместно, когда каждая организация известна и доступ одобрен по договору.

Проверка тенанта критически важна. Одного совпадения домена электронной почты недостаточно, потому что домены и адреса электронной почты могут меняться. Проверяйте тенант в токене и неизменяемые идентификаторы subject или object в соответствии с дизайном подключения.

Клиенты и внешние пользователи

Для приложений, ориентированных на клиентов, тенант External ID может предоставить отдельный каталог и отдельный сценарий входа. Учётные записи Odoo, созданные для этой аудитории, обычно должны быть портал-учётными записями, а не внутренними пользователями.

Эти модели следует настраивать как отдельные подключения, если у них различаются правила допуска и правила учётных записей Odoo. Одно широкое подключение сложнее понять и легче неправильно настроить.

External ID поддерживает сценарий входа для клиентов

Потоки пользователей External ID определяют методы аутентификации клиентов и сведения, собираемые при регистрации. Поток связывается с зарегистрированными приложениями, чтобы включить регистрацию и вход. Microsoft документирует это в статье добавление приложения в поток пользователей External ID.

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

Собирайте только те сведения, которые действительно нужны Odoo, и документируйте цель, срок хранения и обработку конфиденциальности для каждого атрибута.

Права по умолчанию помогают сохранить разделение

Microsoft указывает, что пользователи внешнего тенанта изначально имеют ограниченные права по умолчанию. Обычно они могут получать доступ к приложениям и управлять своим профилем, но не получают широких прав администрирования каталога. См. права по умолчанию во внешних тенантах.

Однако эта граница каталога автоматически не настраивает права портала Odoo. Odoo по-прежнему определяет, какие записи может видеть пользователь портала, через собственные права доступа и правила записей. Проверьте работу портала на типовых клиентских записях и более чем одной компании или учётной записи, чтобы убедиться, что данные изолированы корректно.

Не переводите нового внешнего пользователя во внутреннего пользователя Odoo, если для этого нет отдельного утверждённого бизнес-процесса.

Используйте современный, проверенный поток OpenID Connect

Microsoft поддерживает поток авторизационного кода OAuth 2.0 с Proof Key for Code Exchange и OpenID Connect для серверных веб-приложений. Его документация по потоку авторизационного кода описывает эту поддерживаемую комбинацию.

OIDC расширяет OAuth 2.0 для аутентификации. Microsoft публикует метаданные обнаружения, сведения о конечных точках и открытые ключи подписи. Она также рекомендует проверять возвращаемый токен и nonce, чтобы снизить риск повторного воспроизведения. См. OpenID Connect на платформе Microsoft identity.

Безопасная интеграция должна проверять ожидаемый issuer, audience, подпись, контекст тенанта и nonce. PKCE не заменяет проверку токена, точную настройку callback, TLS или защиту client secret.

Базовый вход может запрашивать стандартные OIDC scopes, такие как openid, profile и email. Microsoft отмечает, что эти scopes размещены в Microsoft Graph, и рекомендует запрашивать только те разрешения, которые нужны приложению. См. scopes платформы Microsoft identity. Поэтому точное утверждение о продукте будет таким: «для стандартного входа не требуются высокопривилегированные разрешения Microsoft Graph API», а не общее утверждение, что Graph не участвует.

Определите, как внешние пользователи будут получать доступ к Odoo

Перед включением первого входа определите:

  • Будет ли самостоятельная регистрация открыта или потребуется одобрение.
  • Какие тенанты или поставщики идентификации допускаются.
  • Можно ли связать существующую учётную запись портала Odoo.
  • Какой неизменяемый идентификатор Microsoft сохраняется после связывания.
  • К какой компании Odoo и к какой записи партнера относится пользователь.
  • Какие портальные группы и правила доступа к записям применяются.
  • Что происходит при отзыве доступа.
  • Как отзывается активная сессия Odoo.

Автоматическое создание учетных записей может снизить административную нагрузку, но оно должно происходить только после того, как идентичность соответствует правилам допуска подключения. Успешная аутентификация Microsoft подтверждает контроль над принятой идентичностью. Сама по себе она не подтверждает, что этому человеку следует видеть конкретные записи Odoo клиента.

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

У внешних пользователей может не быть внутренней службы поддержки. Опубликуйте маршрут поддержки и укажите, кто управляет идентичностью. Проверьте сценарии сброса пароля, восстановления, удаления арендатора и смены адреса электронной почты. Сохраняйте диагностические события полезными, но с удаленными конфиденциальными данными.

Если вам в первую очередь нужен доступ для сотрудников, прочитайте почему стоит защитить вашу инстанцию Odoo с помощью Microsoft SSO. Для внутренних разрешений см. централизация доступа Odoo с помощью групп Entra и ролей приложений.

Подключите внешние аудитории к Odoo 19

Наш модуль Microsoft Entra SSO for Odoo module поддерживает отдельные подключения для сотрудников, одобренных организаций и аудиторий клиентов Microsoft Entra External ID. Подключения External ID по умолчанию создают портальных пользователей, а подключения рабочей среды создают внутренних пользователей. Мастер настройки проверяет сведения для обнаружения и ключи подписи, а затем требует интерактивного теста перед включением входа через Microsoft.

Модуль не определяет, кого следует допускать и какие записи клиентов они должны видеть. Это по-прежнему бизнес-решения и решения доступа Odoo. Ознакомьтесь с модулем, если вам нужен контролируемый мост между идентичностью клиента Microsoft и порталом Odoo 19, с обработкой учетных записей с учетом аудитории, а не единый недифференцированный путь входа.