사용자 지정 속성 다중 테넌시 모범 사례

Amazon Cognito는 선택한 이름으로 사용자 지정 속성을 지원합니다. 사용자 지정 속성이 유용한 한 가지 시나리오는 공유 사용자 풀의 사용자 테넌시를 구분하는 것입니다. 사용자에게 와 같은 속성에 대한 값을 할당하면 custom:tenantID앱이 그에 따라 테넌트별 리소스에 대한 액세스를 할당할 수 있습니다. 테넌트 ID를 정의하는 사용자 지정 속성은 앱 클라이언트에서 변경할 수 없거나 읽기 전용이어야 합니다.

다음 다이어그램은 앱 클라이언트와 사용자 풀을 공유하는 테넌트를 보여줍니다. 사용자 풀의 사용자 지정 속성은 자신이 속한 테넌트를 나타냅니다.

사용자 지정 속성에 따라 테넌시가 결정되면 단일 애플리케이션 또는 로그인 을 배포할 수 있습니다URL. 사용자가 로그인하면 앱이 custom:tenantID 클레임을 처리하여 로드할 자산, 적용할 브랜딩 및 표시할 기능을 결정할 수 있습니다. 사용자 속성에서 고급 액세스 제어 결정을 내리려면 Amazon Verified Permissions에서 사용자 풀을 자격 증명 공급자로 설정하고 ID 또는 액세스 토큰의 콘텐츠에서 액세스 결정을 생성합니다.

사용자 지정 속성 다중 테넌시를 구현해야 하는 경우

테넌시가 표면 수준인 경우. 테넌트 속성은 브랜딩 및 레이아웃 결과에 기여할 수 있습니다. 테넌트 간에 상당한 격리를 달성하려는 경우 사용자 지정 속성이 최선의 선택이 아닙니다. MFA 또는 호스팅 UI 브랜딩과 같이 사용자 풀 또는 앱 클라이언트 수준에서 구성해야 하는 테넌트 간의 모든 차이점은 사용자 지정 속성이 제공하지 않는 방식으로 테넌트 간에 구분을 생성해야 합니다. 자격 증명 풀을 사용하면 ID 토큰의 사용자 지정 속성 클레임에서 사용자의 IAM 역할을 선택할 수도 있습니다.

노력 수준

사용자 지정 속성 다중 테넌시가 앱에서 테넌트 기반 권한 부여 결정의 의무를 이전하기 때문에 노력 수준이 높은 경향이 있습니다. OIDC 클레임을 구문 분석하는 클라이언트 구성 또는 Amazon Verified Permissions에 이미 정통한 경우 이 접근 방식에 가장 낮은 수준의 노력이 필요할 수 있습니다.