소비자 조직, 역할과 공간 구성

이 구성은 소비자가 Foundry의 사용자 인증과 권한을 이용하는 내부 앱 및 OAuth 앱을 위한 것입니다. 외부 Client credentials 앱은 자신의 사용자 관리 체계를 사용하므로 서비스 사용자 앱 설정을 따릅니다.

Control Panel과 Enrollment Administrator 권한, 소비자 인증 요건에 대한 이해가 필요합니다. 조직 수준의 역할, 인증과 앱 설정에는 해당 범위의 관리 권한도 충족해야 합니다. 플랫폼 인스턴스와 조직의 관리 권한은 독립적입니다.

1. 소비자 조직 생성

Control Panel > Organization management > Create organization에서 내부 사용자와 구분할 조직을 만듭니다. 예시 이름은 Customer Portal Users입니다.

조직 관리자나 관리 그룹을 지정합니다. Collaboration에는 내부 조직을 추가해 내부 조직의 역할 집합을 발견할 수 있게 하되, 조직 간 사용자 및 그룹 발견 확인란은 끕니다. 이 단계의 Private space는 No로 선택합니다. 기본 조직 한도는 인스턴스당 5개입니다.

2. 구성원 발견 제한

소비자 조직의 Actions > Manage member discovery에서 Discover users와 Discover groups를 끕니다.

B2B 협업에서 Workshop 댓글처럼 다른 사용자나 그룹을 찾아야 한다면 필요한 발견 기능을 유지할 수 있습니다. 어느 쪽을 선택하더라도 리소스와 행 수준 데이터 권한은 따로 구성합니다.

3. 신원 제공자와 조직 배정

Authentication의 Providers에서 제공자를 추가하거나 기존 제공자를 편집합니다.

SAML 또는 OIDC를 선택하고 실제 IdP의 메타데이터와 사용자 특성, 필요한 egress 정책을 구성합니다. Foundry 사용자 접근의 MFA 요구는 IdP 또는 Foundry가 충족해야 합니다.

Organization assignment에서는 모두 같은 소비자 조직으로 보낼 Default organization 또는 이메일, 그룹 및 특성별 Advanced 규칙을 정합니다. 고급 규칙에는 적절한 기본 귀속을 정하고 일치하지 않는 사용자가 의도하지 않은 조직에 들어가지 않도록 확인합니다.

세부 식별자와 배정 조건은 인증 설정 및 조직과 그룹 배정을 참조합니다.

4. 소비자 그룹과 개발 및 관리 그룹

소비자 조직마다 자동 갱신되는 규칙 기반 그룹을 하나 이상 구성합니다. 모든 소비자가 한 조직에 속하면 그 조직의 구성원을 포괄하는 하나의 그룹을 만들고, 조직이 여러 개이면 조직별로 만듭니다.

제공자의 Group assignment에서 + Add rule을 선택합니다. Select group의 Create new rule-based group에서 이름, 설명과 해당 소비자 조직을 지정하고 조직 배정 규칙과 맞는 조건을 넣습니다.

개발자용 Builder 그룹과 관리자용 Administrator 그룹도 분리하는 것이 권장됩니다. 외부에서 그룹을 관리한다면 IdP에 만들고, 그렇지 않으면 Foundry에서 적절한 그룹을 만듭니다.

5. 소비자 역할 집합

계정 Settings의 Roles에서 Create role set을 선택합니다.

• 이름과 설명을 지정합니다. 예: Consumer roles.
• Copy roles from은 Project defaults입니다.
• 소유 조직은 내부 조직으로 지정합니다.

새 집합에서 New role로 Consumer를 만듭니다. 설명을 입력하고 Includes는 비워 둡니다.

기본 소비자 기능을 위한 작업 권한 목록은 다음과 같습니다.

carbon:view-workspace
eddie:view-aip-logic
foundry:read-data
function-executor:execute-function
function-registry:read-contract
function-registry:read-function
hubble:object-view:view
lime:search
object-set-service:read-versioned-object-set
objects:read-data
ontology:view-action-type
ontology:view-datasource
ontology:view-object-type
ontology:view-relation
salt:blobster:read
slate:run-query-v2
slate:view-document
slate:view-stylesheet
third-party-application:view-application-website
workshop-server:view-module

실제 워크플로에 따라 추가 작업 권한이 필요할 수 있습니다. 역할을 넓히기 전에 어떤 리소스와 작업에서 부족한지 확인합니다.

6. 소비자 공간

Control Panel의 Space management에서 공간을 만듭니다. 내부 조직과 소비자 조직을 Access requirements에 포함하고 기본 권한을 정합니다.

앞서 만든 Consumer 역할을 사용하려면 공간의 Role set에도 Consumer roles를 선택해야 합니다. 프로젝트 역할 집합은 공간 단위로 적용되므로 새 역할을 만들기만 하고 공간의 기본 Project defaults를 그대로 두면 그 역할을 사용할 수 없습니다.

7. 프로젝트 템플릿

Control Panel의 Project templates에서 Create template을 선택합니다. 예시 이름은 Consumer Application Template입니다.

Name 템플릿 변수는 유지합니다. Project information의 Organizations는 Selected on project creation으로 정합니다. Project roles는 다음처럼 구성합니다.

조직은 접근 요건이고 역할은 사용자나 그룹의 작업 범위입니다. 조직을 선택한 것과 소비자 그룹에 역할을 부여하는 것을 같은 동작으로 취급하지 않습니다.

8. 선택적인 소비자 도메인

Domains & certificates에서 고객 도메인을 만들 수 있습니다. 이어 Authentication > Hosts에서 대상 도메인의 Actions > Manage를 열고 Default provider를 지정하면 로그인 제공자로 바로 이동할 수 있습니다.

한 도메인에 여러 IdP가 있으면 다음 형태로 realm을 지정합니다.

https://consumer.yourdomain.com/workspace/application/[rid]?_realm=auth0-realm-id

호스트, 리소스 RID와 realm은 실제 값을 사용합니다. Realm ID는 Control Panel > Authentication > [Provider Name] > Advanced Settings > Realm에서 확인합니다.

9. 플랫폼 화면 제한

Application access의 Foundry Platform > Manage에서 소비자 규칙 기반 그룹의 넓은 플랫폼 접근을 제한합니다. Builder와 Administrator가 관리 화면 접근을 잃지 않도록 남겨 둡니다.

Workshop, Slate, AIP Threads와 Carbon 등도 실제 소비자 업무에 필요하지 않으면 앱 접근을 제한합니다. 필요한 소비용 앱을 차단하지 않도록 사용자가 이용할 앱을 먼저 확인합니다. 이 설정은 화면 범위이며 소비자 역할의 API 및 데이터 권한을 대신하지 않습니다.

10. 기본 앱과 표시 설정

Platform experience에서 소비자 조직을 선택하고 로그인 후 보낼 Home page URL을 지정합니다.

사용 언어와 브라우저 언어 우선순위, 조직 제목, 정적 배너와 버전 선택기 접근을 정합니다. 기본 버전은 Stable 또는 지정 그룹의 Beta로 구성합니다. Prior는 잠시 이전 화면을 보는 선택이며 지속적인 기본 버전으로 사용하는 기능은 아닙니다.

운영 전 확인

다음은 담당자가 승인된 시험 계정과 리소스로 수행할 확인 절차입니다.

1. 소비자 공간에서 템플릿으로 프로젝트를 만들고 역할이 자동 적용되는지 확인합니다.
2. 시험용 Workshop 리소스로 필요한 동작과 접근 조건을 준비합니다.
3. 소비자 IdP의 시험 계정으로 로그인해 조직 및 그룹 자동 배정과 기본 앱 리다이렉트를 확인합니다.
4. 관리자 계정의 프로젝트 Access > Check access에서 소비자 프로젝트에는 필요한 권한이 있고 내부 프로젝트에는 접근하지 못하는지 확인합니다.

조직 배정이 틀리면 규칙, 그룹 조건과 실제 IdP 특성을 확인합니다. 리다이렉트 문제는 도메인 DNS, 기본 IdP 및 필요한 CORS와 CSP를 확인합니다. 권한이 지나치게 좁거나 넓으면 실제 소비자 계정의 필요한 동작을 기준으로 역할을 조정합니다.

배포할 앱은 플랫폼 내부 및 OAuth 앱에서 이어서 구성합니다.