Single sign-on отговаря на въпрос за удостоверяване: потвърдил ли е Microsoft този потребител според политиката на организацията? Той не отговаря на всеки въпрос за авторизация в Odoo.
Удостоверен потребител може да се нуждае от достъп до продажби, но не и до счетоводство, проекти, но не и до заплати, или клиентски портал, но не и до вътрешния интерфейс. Тези решения остават отговорност на Odoo. Групите и application roles в Microsoft Entra могат да осигурят надеждни входни данни, за да бъдат те по-последователни.
Групите и app ролите служат за различни цели
Групите в Microsoft Entra принадлежат на наемателя. Те могат да представляват отдели, длъжности, проекти или граници на сигурността. Application roles принадлежат на конкретна app registration и описват роли, които са значими за това приложение.
Документацията на Microsoft за app-role обяснява, че app roles могат да бъдат присвоявани на потребители или групи. Когато присвоен потребител влезе, Entra може да включи предоставените роли в roles claim. Microsoft също така посочва, че app roles и групите не се изключват взаимно.
Това дава на дизайна за достъп до Odoo два основни модела:
- Съпоставете стабилни Object ID на Entra security group директно с избрани Odoo групи.
- Определете Odoo-ориентирани app роли в приложението Entra, присвоявайте потребители или групи към тези роли и съпоставете получените стойности на ролите с Odoo групи.
Директното съпоставяне работи добре с управлявани security групи. App ролите могат да осигурят по-ясна граница на приложението, защото тяхното предназначение е част от app registration, вместо да зависи от имена, специфични за наемателя.
Започнете с реалния модел за достъп на Odoo
Не започвайте, като копирате всяка Microsoft група в Odoo. Започнете с правата в Odoo, от които бизнесът наистина се нуждае.
Избройте Odoo групите, които предоставят съществени възможности. За всяка от тях документирайте:
- Бизнес целта на достъпа.
- Лицето, отговорно за одобрението му.
- Entra групата или app ролята, която представлява одобрението.
- Колко бързо промяната трябва да достигне до Odoo и какво се случва с активната сесия след премахване.
Използвайте принципа на най-малките привилегии. Широка група по отдел може да е удобна, но може да предоставя повече достъп до Odoo, отколкото всеки член има нужда. По-малка security група или app role, специфична за Odoo, често е по-лесна за одит.
Третирайте обвързването на самоличността като контрол за сигурност
Много системи първоначално съпоставят съществуващ акаунт чрез имейл адрес. Това е удобно, особено когато Odoo и Microsoft вече използват един и същ корпоративен имейл. Това не е устойчив ключ за самоличност.
Microsoft предупреждава в своя ID token claims reference , че имейл адреси, телефонни номера и user principal names могат да се променят и могат да бъдат използвани повторно. Microsoft препоръчва неизменяеми claims като sub или oid, с tid, когато е необходим контекст на наемателя, за надеждна идентификация.
По-безопасен модел е:
- Допускайте само очакван наемател и одобрена audience.
- Използвайте имейл за контролирано първоначално съпоставяне, когато е подходящо.
- Отхвърляйте двусмислени или дублирани съпоставяния.
- Съхранявайте неизменяемия Microsoft идентификатор на самоличността и идентификаторите на наемателя след свързване.
- Използвайте тези неизменяеми стойности за бъдещи влизания.
За достъп при множество наематели контекстът на наемателя е от съществено значение. Един и същи човек може да има различни object identifiers в различни наематели, а достъпът от един наемател не трябва безшумно да наследява разрешения, свързани с друг.
Разберете случая с превишаване на group claim
Group claims са удобни, но не са неограничени. Microsoft документира лимит от 200 group Object IDs в JWT. Когато членството на потребителя надвиши лимита, Entra пропуска нормалния списък с групи и връща overage индикатор, който насочва приложението да направи заявка към Microsoft Graph. Вижте насоките за groups overage.
Това е важно, ако интеграцията рекламира съпоставяне на групи без разширени Microsoft Graph API разрешения. Потребител с обширно членство в групи може да не получи очаквания набор от group claims.
Преди да разчитате на директно съпоставяне на групи, потвърдете как се обработва overage. Опциите включват по-малки app-specific групи, app роли, филтриране на claims или Graph-базирано търсене с consent с най-малки привилегии.
Синхронизацията при влизане не е provisioning в реално време
SSO модул може да сравнява текущите Entra claims с конфигурираните Odoo съпоставяния, когато потребител влезе. Това е полезно, защото достъпът може да бъде изравнен по време на нормално удостоверяване.
Това не е същото като непрекъснато provisioning. Ако служител бъде премахнат от Entra група, докато Odoo сесията е активна, тази сесия може да продължи до излизане, изтичане или прилагане на друг контрол за отнемане. Ако бивш служител никога не влезе отново, процесът на синхронизация при влизане сам по себе си не архивира Odoo акаунта.
Microsoft Entra ID Governance предлага Lifecycle Workflows за процесите joiner, mover и leaver, включително деактивиране на акаунти и премахване на assignments за достъп. Вижте насоките на Microsoft за Lifecycle Workflows. Тези възможности изискват лицензиране Microsoft Entra ID Governance или Microsoft Entra Suite.
Автоматизацията на жизнения цикъл може да подобри състоянието на изходната самоличност, но все още не актуализира Odoo, освен ако интеграция не използва промяната. Вашата процедура за offboarding трябва изрично да обхваща отнемането на Odoo сесията и състоянието на акаунта.
Изградете одитируем модел за съпоставяне
Запазете броя на съпоставянията разбираем. За всяка група или роля използвайте стабилен идентификатор и описание, разбираемо за човек. Запишете защо съответният достъп до Odoo съществува, кой го е одобрил и кога е бил прегледан последно.
Тествайте поне тези случаи:
- Съществуващ потребител с едно очаквано съпоставяне.
- Потребител без одобрено съпоставяне или с недопустим наемател.
- Нов потребител, допуснат за първо влизане.
- Потребител, премахнат от съпоставена група или с много членства в групи.
- Преименуван потребител, чиято непроменяема самоличност не се е променила.
- Деактивиран Microsoft акаунт със съществуваща Odoo сесия.
Събитията за влизане трябва да помагат на администраторите да диагностицират резултатите от заявките и съпоставянето, без да разкриват токени, идентификационни данни или тайни. Журналите трябва да идентифицират връзката и резултата, но чувствителните стойности трябва да бъдат заличени.
Комбинирайте съпоставянето с политиката за удостоверяване
Контролите за съпоставяне на групи и роли управляват Odoo авторизацията. Microsoft Entra Conditional Access контролира дали Microsoft ще завърши удостоверяването при текущите условия. Двата слоя се допълват взаимно.
Например Entra роля на приложение може да се съпостави с Odoo финансова група, докато Conditional Access изисква устойчив на фишинг силен метод за удостоверяване за потребителите, на които е присвоена тази роля. Прочетете как Microsoft Entra Conditional Access засилва Odoo влизането от страната на политиката за удостоверяване.
За клиенти и партньори не използвайте автоматично повторно съпоставянията на служители. Отделна аудитория и ориентиран към портал дизайн може да са по-безопасни. Вижте Microsoft Entra External ID за Odoo клиенти и партньори.
Съпоставяне на одобрен Microsoft достъп в Odoo 19
Нашият Microsoft Entra SSO for Odoo модул поддържа съпоставяне на конфигурирани Entra Object ID на защитни групи или роли на приложения към избрани Odoo групи за достъп. Той може да синхронизира тези съпоставяния при влизане, да свърже контролирано съществуващо акаунт и да създава одобрени служебни или портални потребители според типа на връзката.
Модулът не замества управлението на достъпа, отнемането на сесии или документирана стратегия за превишаване. Прегледайте мащаба на вашите групи, изискванията за обвързване на самоличността и модела на разрешения в Odoo, преди да активирате съпоставянията. Ако тези основи са ясни, модулът предоставя насочен начин да ги свържете.