사용자와 그룹

Foundry는 하나 이상의 신원 제공자(IdP)를 통해 로그인하는 사용자를 확인합니다. 신원 제공자는 사용자뿐 아니라 그룹과 사용자 특성도 전달합니다. 조직에서 사용하는 Active Directory 같은 기존 시스템과 연결하면 계정과 그룹을 같은 관리 체계에서 운영할 수 있습니다.

사용자와 특성

개인 사용자는 인증을 마치고 Foundry에 접근합니다. 보통 외부 신원 제공자에 정의하며, 이름과 이메일, 직함 같은 구조화된 특성을 가집니다. 이 정보는 사용자 프로필과 접근 정책에서 사용합니다. 비밀값인 암호나 토큰을 사용자 특성으로 취급하지 않습니다.

User API는 개인 사용자와 서비스 계정을 모두 표현합니다. 타사 애플리케이션의 서비스 사용자는 기본 조직을 나타내는 organization 필드가 비어 있습니다.

사용자에게 연결된 인증 영역(Realm)은 인증 출처를 나타냅니다. 어떤 신원 제공자에서 정보가 들어오는지와 플랫폼의 어느 조직에 배정되는지는 서로 다른 설정입니다. 개인 사용자는 기본 조직 하나에 속하고, 필요하면 다른 조직의 게스트가 될 수 있습니다. 조직과 공간에 적용한 발견 가능성 규칙은 다른 조직의 사용자 정보를 어느 범위까지 볼 수 있는지에도 영향을 줍니다.

인증 구성과 조직 배정은 Control Panel에서 관리합니다. 로그인 성공은 신원 확인의 결과이며, 특정 데이터셋에 대한 읽기 권한까지 자동으로 부여하는 결과는 아닙니다.

그룹으로 권한 관리

그룹은 사용자 또는 다른 그룹의 집합입니다. 같은 프로젝트에 같은 역할이 필요한 사용자들을 그룹으로 묶으면 구성원 변경을 한 곳에서 관리할 수 있습니다. 프로젝트나 리소스의 접근 권한은 보통 개별 사용자보다 그룹에 부여합니다. 그룹은 여러 사용자의 Foundry 이용 환경을 함께 구성할 때에도 사용합니다.

예를 들어 분석 담당자 그룹에는 프로젝트의 Viewer, 파이프라인 유지보수 그룹에는 Editor를 부여할 수 있습니다. 구성원을 바꾸면 해당 그룹을 통한 역할 범위가 달라집니다. 직접 사용자에게 준 역할이나 다른 그룹을 통해 얻는 역할도 있을 수 있으므로, 한 그룹에서 사용자를 제거했다고 모든 접근이 사라졌다고 판단하지 않습니다.

그룹 역할은 프로젝트의 파일 계층을 따라 상속됩니다. 역할의 권한은 가산적으로 합쳐지며, 그룹에 낮은 역할을 추가해 다른 경로의 높은 권한을 취소할 수는 없습니다. 조직과 보안 표지 같은 강제적 접근 요건은 그룹 역할과 별도로 충족해야 합니다.

그룹 소속과 접근 신청

프로젝트 접근 신청에서 내부 그룹 가입을 선택하면 해당 그룹 관리자의 승인을 받습니다. 외부 그룹은 조직이 지정한 외부 신청 경로로 안내할 수 있습니다. 프로젝트에 그룹이 전혀 지정되지 않은 경우에는 프로젝트 소유자에게 직접 역할 부여를 요청할 수 있습니다.

어떤 사람에게 권한이 생겼는지 조사할 때에는 사용자 직접 역할, 내부 그룹 소속, 외부 그룹 소속과 중첩된 그룹 관계를 함께 확인합니다. 사용자에게 노출된 특성을 조건으로 읽기 정책을 구성했다면, 해당 특성의 출처와 값도 확인해야 합니다.