Odoo често съдържа информация, която е важна за цялата организация: записи на клиенти, продажбена активност, фактури, данни за служители, проекти, наличности и оперативни документи. Достъпът до тази информация заслужава същото внимание като достъпа до имейл, файлове и други основни бизнес системи.
И все пак Odoo може да се превърне в отделен остров на идентичността. Персоналът може да има една парола за Microsoft 365 и друга за Odoo. Администраторите може да трябва да управляват достъпа на отделни места. Когато някой смени длъжността си или напусне фирмата, процесът може да зависи от това дали контролният списък е изпълнен правилно във всяко приложение.
Microsoft single sign-on дава на организациите още една възможност. Като свържете Odoo с Microsoft Entra ID, потребителите могат да се удостоверяват чрез своя Microsoft акаунт, а бизнесът може да приложи установените си Microsoft контроли за идентичност към процеса на влизане в Odoo.
Вашата Microsoft основа за идентичност може вече да съществува
Ако организацията ви използва Microsoft 365, тя обикновено вече има Microsoft Entra workforce tenant. Microsoft обяснява, че workforce tenant се създава за служители, вътрешни приложения и организационни ресурси, когато фирма се регистрира за Microsoft cloud услуга като Microsoft 365. Това прави Entra естествен доставчик на идентичност, който да се обмисли за Odoo, вместо да се въвежда друг самостоятелен акаунтен система. Вижте обяснението на Microsoft за конфигурациите на workforce и external tenant.
Odoo също разпознава този сценарий. Официалната документация за влизане в Odoo 19 с Microsoft Azure описва как потребителите на Odoo могат да влизат с Microsoft акаунти. Тя също така ясно посочва, че е необходима конфигурация и от двете страни на интеграцията.
По-голямото предимство е, че Microsoft се превръща в мястото, където организацията може да приложи политика за удостоверяване, преди да започне Odoo сесия.
Добавете по-силно удостоверяване към пътя за влизане в Odoo
Мултифакторното удостоверяване в Microsoft Entra може да изисква два или повече метода за проверка. Тези фактори могат да включват нещо, което потребителят знае, нещо, което притежава, или нещо, което е. Microsoft описва как се обработва предизвикателството като част от процеса на влизане в Entra в своя преглед на MFA.
Когато Odoo делегира влизането към Entra, организацията може да изисква одобрен MFA метод. Тя може също да насочи избрани потребители към устойчиви на фишинг методи като passkeys, FIDO2 security keys, 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 policy engine и документира наличните сигнали и решения в прегледа на 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 access groups. Това може да намали дублираното администриране и да направи решенията за достъп по-лесни за преглед.
Важно е да се запази границата между идентичност и авторизация. Премахването на някого от Entra група трябва да засегне Odoo картографирането според документираното поведение на синхронизация на интеграцията, но не е задължително незабавно да прекрати съществуваща Odoo сесия. Ако достъпът се синхронизира при влизане, промяната влиза в сила при следващото влизане на потребителя, освен ако друг контрол на сесията не се намеси.
Съпоставянето по имейл също изисква внимание. Microsoft предупреждава, че имейл адресите и user principal names могат да се променят или да се използват повторно. Неговите насоки за ID token claims препоръчват неизменяеми идентификатори като sub или oid, с контекст на tenant, когато е необходимо, за трайна идентичност. Имейлът може да е полезен при контролирано първоначално свързване, но не трябва да бъде постоянният ключ за идентичност.
За по-задълбочен дизайн на достъпа прочетете централизиране на достъпа до Odoo с Entra групи и app roles.
Какво Microsoft SSO не замества
Microsoft SSO не замества актуализации на Odoo, роли с минимални привилегии, правила за записи, сигурен хостинг, резервни копия, мониторинг, контроли на сесиите или реакция при инциденти. Официалната документация на Odoo също предупреждава базите данни, хоствани в Odoo.com, да не използват неговия документиран OAuth поток за собственика на базата данни или администратора, защото управлението на портала може да бъде засегнато. Потвърдете собственика и аварийното администриране преди внедряване.
По-безопасен начин за въвеждане на Microsoft sign-in
Започнете с малка тестова група. Проверете метаданните за Microsoft discovery и подписващите ключове, потвърдете callback URL адреса, тествайте съпоставянето на акаунти и проверете резултатите за нови и неоторизирани потребители. Поддържайте авариен административен път, докато потокът не бъде тестван от край до край.
След това документирайте политиките, които се прилагат за Odoo, лицензите за Entra, които изискват, как промените в групи или роли достигат до Odoo и как поддръжката ще реагира, ако влизането с Microsoft не е достъпно. Ако клиентите и партньорите се нуждаят от достъп, обмислете отделен дизайн за клиентска идентичност, вместо да ги третирате като служители. Нашето ръководство за Microsoft Entra External ID за клиенти и партньори на Odoo обяснява това разграничение.
Въведете насочен Microsoft SSO за Odoo 19
Нашият модул Microsoft Entra SSO for Odoo осигурява насочено свързване за Odoo 19, включително за служители и външни аудитории, контролирано първо влизане, съпоставяне на групи и ролеви права на приложение, тестване на влизането и интерактивно влизане само с Microsoft след валидиране. Той използва OpenID Connect flow за authorization code с PKCE.
Модулът не определя вашата политика за сигурност. Вашата организация остава отговорна за конфигурацията на Entra, дизайна на достъпа до Odoo и внедряването.