Odoo 포털은 고객과 파트너에게 관련 문서, 거래 및 서비스에 대한 액세스를 제공합니다. 이는 ID 설계에 대한 질문을 만듭니다. 외부 사용자를 직원 디렉터리 및 액세스 모델과 공유해야 할까요?
경우에 따라 워크포스 테넌트의 비즈니스 게스트 계정이 적절할 수 있습니다. 하지만 더 큰 규모이거나 브랜드화된 고객 로그인과 셀프서비스 등록이 필요한 경우에는 Microsoft Entra External ID가 전용 고객 ID 및 액세스 관리 모델을 제공합니다.
이 모델을 Odoo에 연결하면 내부 사용자와 포털 사용자 사이의 경계를 더 명확하게 유지하는 데 도움이 될 수 있습니다. 다만 그 경계에는 여전히 명시적인 승인, 계정 생성, 그리고 Odoo 권한 부여 규칙이 필요합니다.
워크포스 및 외부 테넌트는 서로 다른 대상에 맞게 설계되었습니다
Microsoft는 워크포스 테넌트를 직원, 내부 비즈니스 애플리케이션 및 조직 리소스를 위한 환경으로 정의합니다. 여기에 초대된 비즈니스 파트너와 게스트도 포함될 수 있습니다. 외부 테넌트는 소비자와 비즈니스 고객에게 제공되는 애플리케이션을 위한 별도의 구성입니다. Microsoft는 이 차이를 its 테넌트 구성 가이드에서 설명합니다.
외부 테넌트에는 자체 고객 디렉터리와 애플리케이션 등록이 포함됩니다. External ID는 셀프서비스 등록, 로그인, 암호 재설정, 계정 관리 및 ID 공급자 연동을 추가합니다. External ID 개요에서 이 전용 모델을 설명합니다.
이러한 분리는 조직이 Odoo 서비스에 접근한다는 이유만으로 고객을 직원처럼 취급하는 일을 피하는 데 도움이 될 수 있습니다.
로그인을 구성하기 전에 대상을 먼저 정하세요
고려해야 할 Odoo 대상은 최소 세 가지입니다:
직원 및 내부 사용자
이 사용자들은 일반적으로 조직의 워크포스 테넌트에 속합니다. Odoo에 허용되는 경우, 일반적으로 세심하게 매핑된 액세스 그룹이 있는 내부 Odoo 사용자 계정이 필요합니다.
승인된 파트너 조직의 사용자
일부 기업은 정의된 고객 또는 파트너 Entra 테넌트 목록의 사용자를 허용하려고 합니다. 모든 조직이 알려져 있고 계약상 액세스가 승인된 경우에는 정확한 테넌트 허용 목록을 사용한 다중 테넌트 워크포스 연결이 적절할 수 있습니다.
테넌트 검증은 매우 중요합니다. 도메인과 이메일 주소는 변경될 수 있으므로 이메일 도메인만 일치하는 것으로는 충분하지 않습니다. 연결 설계에 따라 토큰의 테넌트와 변경 불가능한 주체 또는 개체 식별자를 검증하세요.
고객 및 외부 사용자
고객 대상 애플리케이션의 경우 External ID 테넌트가 별도의 디렉터리와 로그인 경험을 제공할 수 있습니다. 이 대상에 대해 생성된 Odoo 계정은 일반적으로 내부 사용자가 아니라 포털 사용자여야 합니다.
승인 방식과 Odoo 계정 규칙이 서로 다르다면 이 모델들은 별도의 연결로 구성해야 합니다. 하나의 광범위한 연결은 이해하기 어렵고 잘못 구성되기 쉽습니다.
External ID는 고객 로그인 여정을 지원합니다
External ID 사용자 흐름은 고객 인증 방법과 가입 중 수집되는 정보를 정의합니다. 흐름은 등록된 애플리케이션과 연결되어 가입 및 로그인을 활성화합니다. Microsoft는 이를 External ID 사용자 흐름에 애플리케이션 추가에서 문서화합니다.
External ID는 로컬 계정과 Microsoft Entra ID 및 사용자 지정 OpenID Connect 공급자를 포함한 ID 공급자와의 연동을 지원할 수 있습니다. Microsoft의 고객 특성 가이드에 설명된 대로, 가입 중에 기본 제공 및 사용자 지정 특성을 수집할 수 있습니다.
Odoo가 실제로 필요로 하는 정보만 수집하고, 각 특성의 목적, 보존 기간 및 개인정보 처리 방식을 문서화하세요.
기본 권한은 분리를 유지하는 데 도움이 됩니다
Microsoft는 외부 테넌트 사용자가 제한된 기본 권한으로 시작한다고 설명합니다. 일반적으로 애플리케이션에 액세스하고 자신의 프로필을 관리할 수 있지만, 광범위한 디렉터리 관리 권한은 받지 않습니다. 외부 테넌트의 기본 권한를 참조하세요.
이 디렉터리 경계가 Odoo 포털 권한을 자동으로 구성하지는 않습니다. Odoo는 자체 액세스 권한과 레코드 규칙을 통해 포털 사용자가 어떤 레코드를 볼 수 있는지 계속 제어합니다. 대표적인 고객 레코드와 두 개 이상의 회사 또는 계정으로 포털 경험을 테스트하여 데이터가 올바르게 분리되는지 확인하세요.
새로 생성된 외부 사용자를 별도의 승인된 비즈니스 프로세스 없이 내부 Odoo 사용자로 승격하지 마세요.
현대적이고 검증된 OpenID Connect 흐름을 사용하세요
Microsoft는 서버 기반 웹 애플리케이션에 대해 PKCE가 적용된 OAuth 2.0 권한 부여 코드 흐름과 OpenID Connect를 지원합니다. its 권한 부여 코드 흐름 문서에서 이 지원 조합을 설명합니다.
OIDC는 인증을 위해 OAuth 2.0을 확장합니다. Microsoft는 검색 메타데이터, 엔드포인트 세부 정보 및 공개 서명 키를 제공합니다. 또한 재생 위험을 줄이기 위해 반환된 토큰을 검증하고 nonce를 확인할 것을 권장합니다. Microsoft identity platform의 OpenID Connect를 참조하세요.
안전한 통합은 예상 발급자, 대상, 서명, 테넌트 컨텍스트 및 nonce를 검증해야 합니다. PKCE는 토큰 검증, 정확한 콜백 구성, TLS 또는 클라이언트 비밀 보호를 대체하지 않습니다.
기본 로그인은 openid, profile, email과 같은 표준 OIDC 범위를 요청할 수 있습니다. Microsoft는 이러한 범위가 Microsoft Graph에서 호스팅된다고 설명하며, 애플리케이션이 필요로 하는 권한만 요청할 것을 권장합니다. Microsoft identity platform 범위를 참조하세요. 따라서 정확한 제품 설명은, Graph가 전혀 관련되지 않는다는 포괄적 주장보다는 "표준 로그인에 고권한 Microsoft Graph API 권한이 없다"가 맞습니다.
외부 사용자가 Odoo에 도달하는 방식을 정하세요
첫 로그인 사용을 활성화하기 전에 다음을 정의하세요:
- 셀프 등록을 허용할지, 아니면 승인이 필요한지.
- 어떤 테넌트 또는 ID 공급자를 허용할지.
- 기존 Odoo 포털 계정을 연결할 수 있는지 여부.
- 링크 후 저장되는 변경 불가능한 Microsoft 식별자가 무엇인지.
- 사용자가 속한 Odoo 회사와 파트너 레코드가 무엇인지.
- 어떤 포털 그룹과 레코드 규칙이 적용되는지.
- 액세스가 철회되면 어떤 일이 발생하는지.
- 활성 Odoo 세션이 어떻게 취소되는지.
자동 계정 생성은 관리를 줄일 수 있지만, 식별자가 연결의 허용 규칙을 충족한 후에만 이루어져야 합니다. 성공적인 Microsoft 인증은 허용된 식별자에 대한 제어를 증명합니다. 그러나 그것만으로 특정 고객의 Odoo 레코드를 볼 수 있어야 한다는 사실을 증명하지는 않습니다.
고객 지원 및 복구 계획
외부 사용자는 내부 헬프데스크가 없을 수 있습니다. 지원 경로를 공개하고 식별자를 누가 관리하는지 명시하세요. 암호 재설정, 복구, 테넌트 제거 및 이메일 변경 시나리오를 테스트하세요. 진단 이벤트는 유용하되, 민감한 정보는 가려서 유지하세요.
즉시 필요한 것이 직원 액세스라면, 다음을 읽어보세요 Microsoft SSO로 Odoo 인스턴스를 보호해야 하는 이유. 내부 권한에 대해서는 다음을 참조하세요 Entra 그룹 및 앱 역할로 Odoo 액세스를 중앙화하기.
외부 대상 사용자를 Odoo 19에 연결
저희의 Odoo용 Microsoft Entra SSO 모듈은 직원, 승인된 조직, Microsoft Entra External ID 고객 대상에 대해 별도의 연결을 지원합니다. External ID 연결은 기본적으로 포털 사용자를 생성하며, 워크포스 연결은 내부 사용자를 생성합니다. 안내형 설정은 검색 정보와 서명 키를 검증한 뒤, Microsoft 로그인을 활성화하기 전에 대화형 테스트를 요구합니다.
이 모듈은 누가 허용되어야 하는지 또는 어떤 고객 레코드를 볼 수 있어야 하는지를 결정하지 않습니다. 이러한 사항은 여전히 비즈니스와 Odoo 액세스 결정에 속합니다. Microsoft 고객 식별자와 Odoo 19 포털 사이에 통제된 연결이 필요하고, 단일의 구분 없는 로그인 경로가 아닌 대상별 계정 처리가 필요하다면 이 모듈을 검토하세요.