Єдиний вхід відповідає на питання автентифікації: чи підтвердила Microsoft цього користувача відповідно до політики організації? Але він не відповідає на всі питання авторизації всередині Odoo.
Автентифікованому користувачу може знадобитися доступ до продажів, але не до бухгалтерії, до проєктів, але не до зарплати, або до клієнтського порталу, але не до внутрішнього інтерфейсу. Такі рішення залишаються відповідальністю Odoo. Групи Microsoft Entra та ролі застосунку можуть надати надійні вхідні дані, щоб робити їх послідовнішими.
Групи та ролі застосунку мають різні призначення
Групи Microsoft Entra належать до орендаря. Вони можуть позначати відділи, функції посад, проєкти або межі безпеки. Ролі застосунку належать до конкретної реєстрації застосунку і описують ролі, які мають значення саме для цього застосунку.
Microsoft документація щодо ролей застосунку пояснює, що ролі застосунку можна призначати користувачам або групам. Коли призначений користувач входить у систему, Entra може включати надані ролі до claims ролей. Microsoft також зазначає, що ролі застосунку та групи не є взаємовиключними.
Це дає для моделі доступу Odoo два основні підходи:
- Безпосередньо зіставляйте стабільні Object ID груп безпеки Entra з вибраними групами Odoo.
- Визначте орієнтовані на Odoo ролі застосунку в реєстрації Entra, призначайте користувачів або групи до цих ролей і зіставляйте отримані значення ролей із групами Odoo.
Безпосереднє зіставлення добре працює з керованими групами безпеки. Ролі застосунку можуть забезпечити чіткішу межу застосунку, оскільки їхній зміст пов'язаний із реєстрацією застосунку, а не залежить від назв, специфічних для орендаря.
Почніть із фактичної моделі доступу Odoo
Не починайте з копіювання кожної групи Microsoft до Odoo. Почніть із дозволів Odoo, які справді потрібні бізнесу.
Перелічіть групи Odoo, які надають суттєві можливості. Для кожної зафіксуйте:
- Бізнесову мету доступу.
- Особа, відповідальна за його схвалення.
- Група Entra або роль застосунку, що позначає схвалення.
- Як швидко зміна має дійти до Odoo і що відбувається з активною сесією після видалення.
Дотримуйтеся принципу найменших привілеїв. Широка група відділу може бути зручною, але вона може надавати більше доступу до Odoo, ніж потрібно кожному її учаснику. Менша специфічна для Odoo група безпеки або роль застосунку часто легше піддається аудиту.
Розглядайте прив'язку ідентичності як контроль безпеки
Багато систем спочатку зіставляють наявний обліковий запис за адресою електронної пошти. Це зручно, особливо коли Odoo і Microsoft уже використовують ту саму корпоративну адресу. Але це не стійкий ключ ідентичності.
Microsoft попереджає у своїй довідці з claims ID-токена що адреси електронної пошти, номери телефонів і user principal names можуть змінюватися та можуть повторно використовуватися. Microsoft рекомендує незмінні claims, такі як sub або oid, а також tid, коли потрібен контекст орендаря, для надійної ідентифікації.
Безпечніший підхід такий:
- Допускайте лише очікуваного орендаря та схвалену аудиторію.
- Використовуйте електронну пошту для контрольованого першого зіставлення, коли це доречно.
- Відхиляйте неоднозначні або дубльовані збіги.
- Після прив'язування зберігайте незмінні ідентифікатор Microsoft і ідентифікатор орендаря.
- Використовуйте ці незмінні значення для майбутніх входів.
Для доступу з кількох орендарів контекст орендаря є важливим. Та сама людина може мати різні object identifiers у різних орендарях, і доступ з одного орендаря не повинен мовчки успадковувати дозволи, пов'язані з іншим.
Зрозумійте випадок надлишку group claim
Group claims зручні, але вони не безмежні. Microsoft документує ліміт у 200 Object ID груп у JWT. Коли членство користувача перевищує ліміт, Entra не включає звичайний список груп і повертає індикатор надлишку, який спрямовує застосунок до запиту до Microsoft Graph. Дивіться пояснення щодо groups overage.
Це важливо, якщо інтеграція заявляє зіставлення груп без підвищених дозволів Microsoft Graph API. Користувач із великою кількістю груп може не отримати очікуваний набір group claim.
Перш ніж покладатися на пряме зіставлення груп, перевірте, як обробляється надлишок. Варіанти включають менші специфічні для застосунку групи, ролі застосунку, фільтрацію claims або пошук через Graph з наданням дозволів за принципом найменших привілеїв.
Синхронізація під час входу не є підготовкою в реальному часі
Модуль SSO може порівнювати поточні claims Entra з налаштованими зіставленнями Odoo, коли користувач входить у систему. Це корисно, тому що доступ можна узгоджувати під час звичайної події автентифікації.
Це не те саме, що безперервна підготовка. Якщо працівника видаляють із групи 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.
Події входу мають допомагати адміністраторам діагностувати результати claims і зіставлення, не розкриваючи токени, облікові дані чи секрети. Журнали мають ідентифікувати підключення та результат, але чутливі значення слід редагувати.
Поєднайте зіставлення з політикою автентифікації
Зіставлення груп і ролей керує авторизацією в 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. Якщо ці основи зрозумілі, модуль надає керований спосіб їх поєднати.