Odoo часто містить інформацію, важливу для всієї організації: дані клієнтів, активність продажів, рахунки, відомості про працівників, проєкти, запаси та операційні документи. Доступ до цієї інформації заслуговує на таку саму увагу, як і доступ до електронної пошти, файлів та інших ключових бізнес-систем.
Втім, Odoo може стати окремим островом ідентичності. Співробітники можуть мати один пароль для Microsoft 365 і інший для Odoo. Адміністраторам може знадобитися керувати доступом у різних місцях. Коли хтось змінює роль або залишає компанію, процес може залежати від того, чи правильно виконано чеклист у кожному застосунку.
Microsoft single sign-on дає організаціям ще один варіант. Підключивши Odoo до Microsoft Entra ID, користувачі можуть проходити автентифікацію через свій обліковий запис Microsoft, а бізнес може застосовувати свої вже налаштовані контролі ідентичності Microsoft до процесу входу в Odoo.
Ваша основа ідентичності Microsoft, можливо, вже існує
Якщо ваша організація використовує Microsoft 365, зазвичай вона вже має робочий тенант Microsoft Entra. Microsoft пояснює, що робочий тенант створюється для працівників, внутрішніх застосунків і організаційних ресурсів, коли бізнес реєструється в хмарному сервісі Microsoft, такому як Microsoft 365. Це робить Entra природним провайдером ідентичності, який варто розглянути для Odoo, замість запровадження ще однієї окремої системи облікових записів. Дивіться пояснення Microsoft щодо конфігурацій робочого та зовнішнього тенанта.
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. Якщо доступ синхронізується під час входу, зміна набуде чинності під час наступного входу користувача, якщо інший контроль сеансу не втрутиться.
Також потрібно обережно ставитися до зіставлення електронної пошти. Microsoft попереджає, що адреси електронної пошти та user principal names можуть змінюватися або повторно використовуватися. Його рекомендації щодо claim-ів ID token рекомендують незмінні ідентифікатори, такі як sub або oid, з контекстом тенанта, де це потрібно, для довговічної ідентичності. Електронна пошта може бути корисною під час контрольного першого зв’язування, але не повинна бути постійним ключем ідентичності.
Для глибшого проєктування доступу прочитайте як централізувати доступ до Odoo за допомогою груп Entra та ролей застосунків.
Що Microsoft SSO не замінює
Microsoft SSO не замінює оновлення Odoo, ролі з принципом найменших привілеїв, правила записів, безпечний хостинг, резервні копії, моніторинг, контроль сеансів або реагування на інциденти. Офіційна документація Odoo також застерігає бази даних, розміщені на Odoo.com, від використання його задокументованого потоку OAuth для власника бази даних або адміністратора, оскільки це може вплинути на керування порталом. Перед розгортанням підтвердьте власника та аварійне адміністрування.
Безпечніший спосіб запровадити вхід через Microsoft
Почніть із невеликої тестової групи. Перевірте метадані виявлення Microsoft і ключі підпису, підтвердьте URL зворотного виклику, протестуйте зіставлення облікових записів і перевірте результати для нових і неавторизованих користувачів. Зберігайте аварійний шлях для адміністрування, доки процес не буде протестовано повністю від початку до кінця.
Далі задокументуйте політики, що застосовуються до Odoo, ліцензії Entra, які вони потребують, спосіб, у який зміни груп або ролей надходять до Odoo, і як служба підтримки реагуватиме, якщо вхід через Microsoft буде недоступний. Якщо клієнтам і партнерам потрібен доступ, розгляньте окрему модель ідентичності для клієнтів, а не трактуйте їх як співробітників. Наш посібник з Microsoft Entra External ID for Odoo customers and partners пояснює цю відмінність.
Запровадьте керований Microsoft SSO для Odoo 19
Наш модуль Microsoft Entra SSO for Odoo забезпечує кероване підключення для Odoo 19, включно з персоналом і зовнішніми аудиторіями, контрольованим першим входом, зіставленням груп і ролей застосунку, тестуванням входу та інтерактивним входом лише через Microsoft після перевірки. Він використовує потік авторизаційного коду OpenID Connect із PKCE.
Модуль не визначає вашу політику безпеки. Ваша організація й надалі відповідає за конфігурацію Entra, архітектуру доступу до Odoo та розгортання.