싱글 사인온은 인증에 대한 질문 하나에 답합니다. Microsoft가 조직의 정책에 따라 이 사용자를 확인했는가? 하지만 Odoo 내부의 모든 권한 부여 질문에 답하는 것은 아닙니다.

인증된 사용자는 영업에는 접근할 수 있지만 회계에는 접근하지 못해야 할 수 있고, 프로젝트는 가능하지만 급여는 불가능해야 하며, 고객 포털은 가능하지만 내부 인터페이스는 불가능해야 할 수 있습니다. 이러한 결정은 여전히 Odoo의 책임입니다. Microsoft Entra 그룹과 애플리케이션 역할은 이를 더 일관되게 만드는 신뢰할 수 있는 입력값이 될 수 있습니다.

그룹과 앱 역할은 서로 다른 목적을 가집니다

Microsoft Entra 그룹은 테넌트에 속합니다. 부서, 직무, 프로젝트 또는 보안 경계를 나타낼 수 있습니다. 애플리케이션 역할은 특정 앱 등록에 속하며, 그 애플리케이션에 의미 있는 역할을 설명합니다.

Microsoft의 앱 역할 문서에서는 앱 역할이 사용자나 그룹에 할당될 수 있다고 설명합니다. 할당된 사용자가 로그인하면 Entra는 부여된 역할을 roles 클레임에 포함할 수 있습니다. Microsoft는 또한 앱 역할과 그룹이 상호 배타적이지 않다고 밝힙니다.

이렇게 하면 Odoo 액세스 설계에 두 가지 주요 패턴이 생깁니다:

  • 안정적인 Entra 보안 그룹 Object ID를 선택한 Odoo 그룹에 직접 매핑합니다.
  • Entra 애플리케이션 안에 Odoo 중심 앱 역할을 정의하고, 사용자나 그룹을 해당 역할에 할당한 뒤, 결과 역할 값을 Odoo 그룹에 매핑합니다.

직접 매핑은 관리되는 보안 그룹과 잘 맞습니다. 앱 역할은 테넌트별 이름에 의존하지 않고 앱 등록과 함께 의도가 전달되므로 더 깔끔한 애플리케이션 경계를 제공할 수 있습니다.

Odoo의 실제 액세스 모델부터 시작하세요

모든 Microsoft 그룹을 Odoo로 그대로 복사하는 것부터 시작하지 마세요. 비즈니스가 실제로 필요한 Odoo 권한부터 시작하세요.

중요한 기능을 부여하는 Odoo 그룹을 나열하세요. 각 항목마다 다음을 문서화합니다:

  • 해당 액세스의 비즈니스 목적.
  • 승인 책임자.
  • 승인을 나타내는 Entra 그룹 또는 앱 역할.
  • 변경이 Odoo에 반영되어야 하는 속도와 제거 후 활성 세션에서 어떤 일이 일어나는지.

최소 권한 원칙을 사용하세요. 넓은 부서 그룹은 편리할 수 있지만, 모든 구성원이 필요로 하는 것보다 더 많은 Odoo 액세스를 부여할 수 있습니다. 더 작은 Odoo 전용 보안 그룹이나 앱 역할이 종종 감사하기 쉽습니다.

ID 바인딩을 보안 통제로 다루세요

많은 시스템은 처음에 이메일 주소를 사용해 기존 계정을 일치시킵니다. 특히 Odoo와 Microsoft가 이미 같은 회사 이메일을 사용할 때 편리합니다. 하지만 이는 지속 가능한 ID 키가 아닙니다.

Microsoft는 ID 토큰 클레임 참고 문서에서 이메일 주소, 전화번호, 사용자 주체 이름은 변경될 수 있고 재사용될 수도 있다고 경고합니다. Microsoft는 신뢰할 수 있는 식별을 위해 tenant context가 필요한 경우 tid와 함께 sub 또는 oid 같은 변경 불가능한 클레임을 권장합니다.

더 안전한 패턴은 다음과 같습니다:

  1. 예상된 테넌트와 승인된 audience만 허용합니다.
  2. 적절한 경우 통제된 최초 일치에 이메일을 사용합니다.
  3. 모호하거나 중복된 일치는 거부합니다.
  4. 연결 후에는 변경 불가능한 Microsoft ID와 테넌트 식별자를 저장합니다.
  5. 이후 로그인에는 그 변경 불가능한 값을 사용합니다.

멀티 테넌트 액세스에서는 테넌트 컨텍스트가 필수입니다. 같은 사람이라도 테넌트마다 다른 object identifier를 가질 수 있으며, 한 테넌트의 액세스가 다른 테넌트에 연결된 권한을 암묵적으로 상속해서는 안 됩니다.

그룹 클레임 초과 사례를 이해하세요

그룹 클레임은 편리하지만 무제한은 아닙니다. Microsoft는 JWT에서 그룹 Object ID를 200개까지로 문서화합니다. 사용자의 멤버십이 이 한도를 초과하면 Entra는 일반 그룹 목록을 생략하고, 애플리케이션이 Microsoft Graph를 조회하도록 안내하는 overage 표시를 반환합니다. groups overage guidance를 참고하세요.

이 점은 통합이 Microsoft Graph API 고급 권한 없이 그룹 매핑을 제공한다고 안내할 때 특히 중요합니다. 그룹 멤버십이 많은 사용자는 예상한 그룹 클레임 집합을 받지 못할 수 있습니다.

직접 그룹 매핑에 의존하기 전에 overage 처리 방식을 확인하세요. 더 작은 앱별 그룹, 앱 역할, 클레임 필터링, 또는 최소 권한 동의를 사용한 Graph 기반 조회가 대안이 될 수 있습니다.

로그인 시 동기화는 실시간 프로비저닝이 아닙니다

SSO 모듈은 사용자가 로그인할 때 현재 Entra 클레임과 구성된 Odoo 매핑을 비교할 수 있습니다. 이는 일반적인 인증 이벤트 중에 액세스를 맞출 수 있다는 점에서 유용합니다.

하지만 이는 지속적인 프로비저닝과 같지 않습니다. 직원이 Odoo 세션이 활성화된 상태에서 Entra 그룹에서 제거되면, 해당 세션은 로그아웃, 만료 또는 다른 철회 통제가 적용될 때까지 계속될 수 있습니다. 퇴사한 직원이 다시 로그인하지 않으면, 로그인 동기화 과정만으로 Odoo 계정이 보관되지는 않습니다.

Microsoft Entra ID Governance는 joiner, mover, leaver 프로세스를 위한 Lifecycle Workflows를 제공하며, 계정 비활성화와 액세스 할당 제거를 포함합니다. Microsoft의 Lifecycle Workflows guidance를 참고하세요. 이러한 기능에는 Microsoft Entra ID Governance 또는 Microsoft Entra Suite 라이선스가 필요합니다.

수명 주기 자동화는 원본 ID 상태를 개선할 수 있지만, 통합이 그 변경을 소비하지 않으면 Odoo는 여전히 업데이트되지 않습니다. 오프보딩 절차에는 Odoo 세션 철회와 계정 상태를 명시적으로 포함해야 합니다.

감사 가능한 매핑 모델을 구축하세요

매핑 수는 이해하기 쉽게 유지하세요. 각 그룹 또는 역할마다 안정적인 식별자와 사람이 읽을 수 있는 설명을 사용하세요. 연결된 Odoo 액세스의 이유, 승인자, 마지막 검토 시점을 기록하세요.

최소한 다음 사례를 테스트하세요:

  • 예상한 매핑 하나를 가진 기존 사용자.
  • 승인된 매핑이 없거나 허용되지 않은 테넌트를 가진 사용자.
  • 첫 로그인용으로 허용된 신규 사용자.
  • 매핑된 그룹에서 제거되었거나 많은 그룹 멤버십을 가진 사용자.
  • 변경되지 않은 고유 식별자를 가진 이름이 변경된 사용자.
  • 기존 Odoo 세션이 있는 비활성화된 Microsoft 계정.

로그인 이벤트는 토큰, 자격 증명 또는 비밀 정보를 노출하지 않으면서 관리자가 클레임과 매핑 결과를 진단하는 데 도움이 되어야 합니다. 로그는 연결과 결과를 식별해야 하지만, 민감한 값은 마스킹해야 합니다.

매핑과 인증 정책을 결합하기

그룹 및 역할 매핑은 Odoo 권한 부여를 제어합니다. Microsoft Entra 조건부 액세스는 현재 조건에서 Microsoft가 인증을 완료할지 여부를 제어합니다. 이 두 계층은 서로 보완적입니다.

예를 들어, Entra 앱 역할은 Odoo 재무 그룹에 매핑될 수 있으며, 조건부 액세스는 해당 역할이 할당된 사용자에게 피싱 방지 인증 강도를 요구할 수 있습니다. Microsoft Entra 조건부 액세스가 Odoo 로그인 보안을 강화하는 방법을 인증 정책 측면에서 읽어보세요.

고객과 파트너의 경우, 직원 매핑을 자동으로 재사용하지 마세요. 별도의 대상과 포털 중심 설계가 더 안전할 수 있습니다. Odoo 고객 및 파트너를 위한 Microsoft Entra External ID를 참고하세요.

승인된 Microsoft 액세스를 Odoo 19에 매핑하기

당사의 Odoo용 Microsoft Entra SSO 모듈은 구성된 Entra 보안 그룹 Object ID 또는 애플리케이션 역할을 선택한 Odoo 액세스 그룹에 매핑하는 기능을 지원합니다. 로그인 시 이러한 매핑을 동기화하고, 제어된 기존 계정을 연결하며, 연결 유형에 따라 승인된 내부 직원 또는 포털 사용자를 생성할 수 있습니다.

이 모듈은 액세스 거버넌스, 세션 해지 또는 문서화된 초과 사용 전략을 대체하지 않습니다. 매핑을 활성화하기 전에 그룹 규모, ID 바인딩 요구 사항 및 Odoo 권한 모델을 검토하세요. 이러한 기반이 명확하다면, 이 모듈은 이를 연결하는 안내된 방법을 제공합니다.