Единый вход отвечает на вопрос аутентификации: подтвердила ли Microsoft этого пользователя в соответствии с политикой организации? Он не отвечает на все вопросы авторизации внутри Odoo.
Аутентифицированному пользователю может потребоваться доступ к продажам, но не к бухгалтерии, к проектам, но не к зарплате, или к клиентскому порталу, но не к внутреннему интерфейсу. Эти решения остаются в зоне ответственности Odoo. Группы Microsoft Entra и роли приложений могут стать доверенными входными данными для того, чтобы делать их более единообразными.
Группы и роли приложений служат разным целям
Группы Microsoft Entra принадлежат тенанту. Они могут представлять отделы, должностные функции, проекты или границы безопасности. Роли приложений принадлежат конкретной регистрации приложения и описывают роли, значимые для этого приложения.
Документация Microsoft по ролям приложений объясняет, что роли приложений могут назначаться пользователям или группам. Когда назначенный пользователь входит в систему, Entra может включать предоставленные роли в утверждение roles. Microsoft также указывает, что роли приложений и группы не исключают друг друга.
Это дает для модели доступа Odoo два основных подхода:
- Напрямую сопоставлять стабильные Object ID групп безопасности Entra с выбранными группами Odoo.
- Определить ориентированные на Odoo роли приложений в приложении Entra, назначать пользователей или группы этим ролям и сопоставлять полученные значения ролей с группами Odoo.
Прямое сопоставление хорошо работает с управляемыми группами безопасности. Роли приложений могут обеспечить более четкую границу приложения, потому что их назначение связано с регистрацией приложения, а не зависит от имен, специфичных для тенанта.
Начните с реальной модели доступа Odoo
Не начинайте с копирования каждой группы Microsoft в Odoo. Начните с тех разрешений Odoo, которые действительно нужны бизнесу.
Составьте список групп Odoo, которые дают значимые возможности. Для каждой из них зафиксируйте:
- Бизнес-цель доступа.
- Ответственного за его утверждение.
- Группу Entra или роль приложения, которая означает утверждение.
- Как быстро изменение должно попасть в Odoo и что происходит с активным сеансом после удаления доступа.
Применяйте принцип наименьших привилегий. Широкая група отдела может быть удобной, но она может предоставлять больше доступа Odoo, чем нужно каждому участнику. Более маленькая группа безопасности или роль приложения, ориентированная на Odoo, часто проще для аудита.
Рассматривайте привязку идентичности как средство безопасности
Многие системы сначала сопоставляют существующую учетную запись по адресу электронной почты. Это удобно, особенно когда Odoo и Microsoft уже используют один и тот же корпоративный email. Но это не устойчивый идентификатор личности.
Microsoft предупреждает в своем справочнике по утверждениям ID token о том, что адреса электронной почты, номера телефонов и user principal names могут меняться и могут использоваться повторно. Для надежной идентификации Microsoft рекомендует неизменяемые утверждения, такие как sub или oid, а также tid, если нужен контекст тенанта.
Более безопасный подход такой:
- Разрешать только ожидаемый тенант и одобренную аудиторию.
- Использовать email для контролируемого первого сопоставления, где это уместно.
- Отклонять неоднозначные или дублирующиеся совпадения.
- Сохранять неизменяемую Microsoft identity и идентификаторы тенанта после связывания.
- Использовать эти неизменяемые значения для последующих входов.
Для доступа из нескольких тенантов контекст тенанта имеет решающее значение. Один и тот же человек может иметь разные object identifiers в разных тенантах, и доступ из одного тенанта не должен незаметно наследовать разрешения, связанные с другим.
Поймите случай превышения лимита group-claims
Group claims удобны, но они не безграничны. Microsoft документирует лимит в 200 Object ID групп в JWT. Когда членство пользователя превышает этот лимит, Entra опускает обычный список групп и возвращает индикатор overage, который направляет приложение к запросу Microsoft Graph. См. руководство по overage для групп.
Это важно, если интеграция заявляет сопоставление групп без повышенных разрешений Microsoft Graph API. Пользователь с большим числом групп может не получить ожидаемый набор group claim.
Прежде чем полагаться на прямое сопоставление групп, проверьте, как обрабатывается overage. Возможные варианты: более маленькие app-specific группы, роли приложений, фильтрация утверждений или поиск через Graph с согласием на минимально необходимые права.
Синхронизация при входе в систему не является обновлением в реальном времени
Модуль SSO может сравнивать текущие утверждения Entra с настроенными сопоставлениями Odoo, когда пользователь входит в систему. Это полезно, потому что доступ можно согласовать во время обычного события аутентификации.
Это не то же самое, что непрерывное provisionering. Если сотрудник удален из группы Entra, пока сеанс Odoo активен, этот сеанс может продолжаться до выхода из системы, истечения срока действия или применения другого механизма отзыва. Если бывший сотрудник больше никогда не входит в систему, процесс синхронизации при входе сам по себе не архивирует учетную запись Odoo.
Microsoft Entra ID Governance предлагает Lifecycle Workflows для процессов joiner, mover и leaver, включая отключение учетных записей и удаление назначений доступа. См. руководство по Lifecycle Workflows. Эти возможности требуют лицензирования Microsoft Entra ID Governance или Microsoft Entra Suite.
Автоматизация жизненного цикла может улучшить состояние исходной идентичности, но она все равно не обновляет Odoo, если изменение не потребляет интеграция. Ваша процедура увольнения должна явно охватывать отзыв сеанса Odoo и состояние учетной записи.
Постройте аудируемую модель сопоставления
Сохраняйте число сопоставлений понятным. Для каждой группы или роли используйте стабильный идентификатор и понятное человеку описание. Фиксируйте, зачем существует связанный доступ Odoo, кто его утвердил и когда он был последний раз пересмотрен.
Проверьте как минимум такие сценарии:
- Существующий пользователь с одним ожидаемым сопоставлением.
- Пользователь без одобренного сопоставления или с запрещенным тенантом.
- Новый пользователь, допущенный для первого входа.
- Пользователь, удаленный из сопоставленной группы, или пользователь с большим числом членств в группах.
- Переименованный пользователь, неизменяемая идентичность которого не изменилась.
- Отключенная учетная запись Microsoft с существующей сессией Odoo.
События входа должны помогать администраторам диагностировать результаты утверждений и сопоставления, не раскрывая токены, учетные данные или секреты. Журналы должны идентифицировать подключение и результат, но конфиденциальные значения должны быть скрыты.
Совместите сопоставление с политикой аутентификации
Управление сопоставлением групп и ролей контролирует авторизацию Odoo. Условный доступ Microsoft Entra контролирует, завершит ли Microsoft аутентификацию при текущих условиях. Эти два уровня дополняют друг друга.
Например, роль приложения Entra может сопоставляться с финансовой группой Odoo, а Условный доступ требует фишинг-устойчивый уровень аутентификации для пользователей, которым назначена эта роль. Читайте как Microsoft Entra Conditional Access усиливает вход в Odoo в части политики аутентификации.
Для клиентов и партнеров не следует автоматически повторно использовать сопоставления сотрудников. Отдельная аудитория и дизайн, ориентированный на портал, могут быть безопаснее. См. Microsoft Entra External ID для клиентов и партнеров Odoo.
Сопоставляйте одобренный доступ Microsoft в Odoo 19
Наш модуль Microsoft Entra SSO для Odoo поддерживает сопоставление настроенных Object ID групп безопасности Entra или ролей приложения с выбранными группами доступа Odoo. Он может синхронизировать эти сопоставления при входе, связывать управляемую существующую учетную запись и создавать одобренных пользователей для сотрудников или портала в зависимости от типа подключения.
Модуль не заменяет управление доступом, отзыв сеанса или документированную стратегию на случай превышения. Перед включением сопоставлений проверьте масштаб групп, требования к привязке идентичности и модель разрешений Odoo. Если эти основы ясны, модуль предоставляет удобный способ их связать.