Портали Odoo надають клієнтам і партнерам доступ до потрібних документів, транзакцій і послуг. Це ставить запитання щодо моделі ідентичності: чи мають зовнішні користувачі ділити каталог співробітників і модель доступу?
Іноді доречний гостьовий обліковий запис у робочому орендодавці. На більшому масштабі, або коли потрібні брендований вхід клієнта та самостійна реєстрація, Microsoft Entra External ID надає окрему модель керування ідентичностями та доступом для клієнтів.
Підключення цієї моделі до Odoo може допомогти чіткіше розмежувати внутрішніх користувачів і користувачів порталу. Проте це розмежування все одно потребує явного допуску, створення облікового запису та правил авторизації Odoo.
Робочі та зовнішні орендодавці призначені для різних аудиторій
Microsoft визначає робочий орендодавець як середовище для співробітників, внутрішніх бізнес-застосунків і організаційних ресурсів. Він також може містити запрошених ділових партнерів і гостей. Зовнішній орендодавець, це окрема конфігурація для застосунків, що пропонуються споживачам і бізнес-клієнтам. Microsoft описує цю відмінність у своєму керівництві з конфігурації орендодавця.
Зовнішній орендодавець містить власний каталог клієнтів і реєстрації застосунків. External ID додає самостійну реєстрацію, вхід, скидання пароля, керування обліковим записом і федерацію постачальників ідентичності. Огляд External ID пояснює цю окрему модель.
Таке розмежування може допомогти організації не сприймати клієнта як співробітника лише тому, що обом потрібен доступ до служби Odoo.
Визначте аудиторію перед налаштуванням входу
Слід розглянути щонайменше три окремі аудиторії Odoo:
Співробітники та внутрішні користувачі
Ці користувачі зазвичай належать до робочого орендодавця організації. Якщо їх допускають до Odoo, їм, як правило, потрібні внутрішні облікові записи Odoo з ретельно зіставленими групами доступу.
Люди з затверджених партнерських організацій
Деякі компанії хочуть, щоб користувачі з визначеного списку клієнтських або партнерських орендодавців Entra мали доступ. Багатоорендодавецьке підключення робочого середовища з точним списком дозволених орендодавців може бути доречним, коли кожна організація відома, а доступ погоджено контрактно.
Валідація орендодавця має критичне значення. Зіставлення лише за доменом електронної пошти недостатнє, оскільки домени та адреси електронної пошти можна змінювати. Перевіряйте орендодавця в токені та незмінні 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 підтримує потік authorization code OAuth 2.0 з Proof Key for Code Exchange та OpenID Connect для серверних вебзастосунків. Його документація з потоку authorization code описує цю підтримувану комбінацію.
OIDC розширює OAuth 2.0 для автентифікації. Microsoft публікує метадані discovery, відомості про кінцеві точки та публічні ключі підпису. Вона також рекомендує перевіряти повернутий токен і перевіряти nonce, щоб зменшити ризик повторного відтворення. Див. OpenID Connect на платформі ідентичностей Microsoft.
Безпечна інтеграція має перевіряти очікуваного видавця, аудиторію, підпис, контекст орендодавця та nonce. PKCE не замінює перевірку токена, точну конфігурацію зворотного виклику, TLS або захист секрету клієнта.
Базовий вхід може запитувати стандартні OIDC-обсяги, такі як openid, profile та email. Microsoft зазначає, що ці обсяги розміщені в Microsoft Graph і рекомендує запитувати лише ті дозволи, які потрібні застосунку. Див. обсяги платформи ідентичностей Microsoft. Отже, точне формулювання для продукту таке: "жодних високопривілейованих дозволів Microsoft Graph API для стандартного входу", а не загальне твердження, що Graph не залучений.
Визначте, як зовнішні користувачі отримують доступ до Odoo
Перед увімкненням першого входу визначте:
- Чи відкрита самореєстрація, чи потрібне схвалення.
- Які орендодавці або постачальники ідентичності допускаються.
- Чи можна пов’язати наявний обліковий запис порталу Odoo.
- Який незмінний ідентифікатор Microsoft зберігається після зв’язування.
- Які компанія Odoo та запис партнера належать користувачу.
- Які портальні групи та правила записів застосовуються.
- Що відбувається, коли доступ відкликають.
- Як відкликається активна сесія Odoo.
Автоматичне створення облікового запису може зменшити адміністративне навантаження, але воно має відбуватися лише після того, як ідентичність відповідає правилам допуску з’єднання. Успішна автентифікація Microsoft підтверджує контроль над прийнятою ідентичністю. Вона сама по собі не доводить, що ця особа має бачити певні записи Odoo клієнта.
Плануйте підтримку клієнтів і відновлення
Зовнішні користувачі можуть не мати внутрішньої служби підтримки. Опублікуйте канал підтримки та визначте, хто керує ідентичністю. Перевірте скидання пароля, відновлення, видалення тенанта та сценарії зі зміненим email. Зберігайте діагностичні події корисними, але знеособленими.
Якщо вам насамперед потрібен доступ для співробітників, прочитайте чому варто захистити ваш екземпляр Odoo за допомогою Microsoft SSO. Для внутрішніх дозволів дивіться централізацію доступу Odoo за допомогою груп Entra та ролей застосунку.
Підключіть зовнішні аудиторії до Odoo 19
Наш модуль Microsoft Entra SSO для Odoo підтримує окремі з’єднання для співробітників, затверджених організацій та аудиторій клієнтів Microsoft Entra External ID. З’єднання External ID за замовчуванням створюють портальних користувачів, тоді як з’єднання для робочої сили створюють внутрішніх користувачів. Кероване налаштування перевіряє інформацію для виявлення та ключі підпису, а потім вимагає інтерактивного тесту перед увімкненням входу через Microsoft.
Модуль не вирішує, кого слід допускати або які записи клієнтів вони мають бачити. Це залишаються бізнес-рішення та рішення доступу Odoo. Перегляньте модуль, якщо вам потрібен контрольований міст між ідентичністю клієнта Microsoft і порталом Odoo 19, з обробкою облікових записів відповідно до аудиторії, а не єдиним недиференційованим шляхом входу.