Odoo часто хранит информацию, важную для всей организации: данные клиентов, продажи, счета, сведения о сотрудниках, проекты, запасы и операционные документы. Доступ к этой информации заслуживает того же внимания, что и доступ к электронной почте, файлам и другим ключевым бизнес-системам.

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

Microsoft single sign-on даёт организациям ещё один вариант. Подключив Odoo к Microsoft Entra ID, пользователи могут проходить аутентификацию через свою учётную запись Microsoft, а компания может применять уже настроенные средства управления идентификацией Microsoft к процессу входа в Odoo.

У вас уже может быть основа идентификации Microsoft

Если ваша организация использует Microsoft 365, у неё обычно уже есть рабочий tenant Microsoft Entra. Microsoft объясняет, что рабочий tenant создаётся для сотрудников, внутренних приложений и ресурсов организации, когда компания регистрируется в облачном сервисе Microsoft, таком как Microsoft 365. Это делает Entra естественным поставщиком идентификации, который стоит рассмотреть для Odoo, вместо внедрения ещё одной отдельной системы учётных записей. См. объяснение Microsoft о конфигурациях рабочих и внешних tenant.

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

Главное преимущество в том, что Microsoft становится точкой, где организация может применить политику аутентификации до начала сеанса Odoo.

Добавьте более сильную аутентификацию к пути входа в Odoo

Многофакторная аутентификация Microsoft Entra может требовать двух или более способов проверки. Эти факторы могут включать то, что пользователь знает, чем он обладает или чем он является. Microsoft описывает, как это происходит в рамках процесса входа Entra, в своём обзоре MFA.

Когда Odoo делегирует вход в Entra, организация может требовать утверждённый метод MFA. Она также может переводить отдельных пользователей на устойчивые к фишингу методы, такие как passkeys, ключи безопасности FIDO2, Windows Hello for Business или аутентификация на основе сертификатов. Microsoft рекомендует эти методы в своих рекомендациях по аутентификации.

Это различие важно. Обычная MFA, как правило, безопаснее, чем доступ только по паролю, но не каждый метод MFA устойчив к фишингу. NIST указывает, что пароли не устойчивы к фишингу и что вручную вводимые одноразовые коды тоже не устойчивы к фишингу, поскольку злоумышленник может их ретранслировать. NIST считает WebAuthn, используемый аутентификаторами FIDO2, примером устойчивости к фишингу благодаря привязке к домену. Подробности приведены в NIST SP 800-63B-4.

Интеграция SSO даёт компании возможность использовать эти возможности Entra для Odoo. При этом компании всё равно нужно включить и принудительно применять нужные политики.

Принимайте решения о доступе с большим контекстом

Microsoft Entra Conditional Access может оценивать такие сигналы, как пользователь, группа, приложение, местоположение, состояние устройства и риск входа. Затем он может блокировать доступ или требовать дополнительные меры, включая MFA, определённую силу аутентификации или соответствующее требованиям устройство. Microsoft называет Conditional Access своим движком политики Zero Trust и документирует доступные сигналы и решения в обзоре Conditional Access.

Для развёртывания Odoo это может поддерживать такие политики, как:

  • Требование MFA для администраторов Odoo и пользователей финансового отдела.
  • Требование устойчивой к фишингу силы аутентификации для привилегированных ролей.
  • Блокировка входа в Odoo из местоположений, которые компания не обслуживает.
  • Требование соответствующего требованиям или управляемого устройства для чувствительного внутреннего доступа.
  • Применение более строгой политики для внешних или более рискованных входов.

Это примеры, а не универсальные настройки. Политика, подходящая для внутренней финансовой команды, может быть непригодна для клиентского портала. Прочитайте как Conditional Access усиливает вход в Odoo перед выбором средств контроля.

У Conditional Access также есть лицензионные требования. Для Conditional Access требуется Microsoft Entra ID P1, а для политик на основе риска нужен P2. Microsoft 365 Business Premium включает возможности Conditional Access. Лицензирование и актуальную доступность функций следует проверять по официальной документации Microsoft.

Сблизьте идентификацию и доступ в Odoo

Аутентификация отвечает на вопрос, кто является пользователем. Авторизация Odoo по-прежнему определяет, что этот пользователь может делать.

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

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

Сопоставление по email тоже требует осторожности. Microsoft предупреждает, что адреса электронной почты и user principal names могут изменяться или повторно использоваться. В его рекомендациях по claims ID token для устойчивой идентификации рекомендуются неизменяемые идентификаторы, такие как sub или oid, с контекстом tenant при необходимости. Email может быть полезен при контролируемом первом связывании, но не должен быть постоянным ключом идентичности.

Для более глубокой схемы доступа прочитайте о централизации доступа Odoo с помощью групп Entra и ролей приложения.

Что Microsoft SSO не заменяет

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

Более безопасный способ внедрить вход через Microsoft

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

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

Добавьте управляемый вход Microsoft SSO в Odoo 19

Наш модуль Microsoft Entra SSO для Odoo предоставляет управляемое подключение для Odoo 19, включая сотрудников и внешние аудитории, контролируемый первый вход, сопоставление групп и ролей приложений, тестирование входа и интерактивный вход только через Microsoft после проверки. Он использует поток авторизации OpenID Connect authorization code flow с PKCE.

Модуль не определяет вашу политику безопасности. Ваша организация по-прежнему несет ответственность за конфигурацию Entra, настройку доступа в Odoo и внедрение.