Developer Console의 사용자와 앱 권한

Developer Console 앱을 관리하는 사용자 권한, 연결 OAuth 클라이언트의 관리 권한 및 앱이 데이터에 접근하는 실행 권한은 서로 다릅니다. Foundry Settings의 Roles와 조직 Control Panel에서 해당 작업을 구성합니다.

Compass 관리 권한, Beta

Compass-managed user permissions는 CBAC가 있는 플랫폼 인스턴스 및 일부 다른 인스턴스에 제공하는 Beta 기능입니다. 앱은 부모 프로젝트 또는 폴더의 역할, 보안 표지와 조직 접근 요건을 상속합니다.

기본 역할 집합은 다음과 같으며 사용자 지정할 수 있습니다.

Developer Console 홈 목록에 보이려면 최소 View application configuration 작업(third-party-application:view-application-config)이 필요합니다. 기본 Viewer가 이를 포함합니다.

LMS 기반 함수의 프런트엔드 호출

OSDK 프런트엔드가 액션을 통해 Language Model Service 기반 Logic 함수를 호출하면 로그인 사용자는 Developer Console 앱에 최소 Viewer가 필요합니다. 없으면 PERMISSION_DENIED 또는 missing can:attribute 오류가 발생할 수 있습니다.

이 조건은 OSDK 프런트엔드에 대한 것입니다. 같은 액션이 Object Explorer나 Workshop에서 동작할 수 있으며 그 실행 경로의 권한 흐름과 구분해야 합니다.

연결 OAuth 클라이언트

앱에는 항상 OAuth 클라이언트가 연결됩니다. 인증 설정을 바꾸려면 조직 Control Panel의 Enable third-party applications 및 Manage third-party application secret 같은 작업 권한이 필요합니다. 기본적으로 Third-party application administrator 역할이 해당 범위를 포함하며 새 앱에 필요한 연결 OAuth 클라이언트 생성도 허용합니다.

앱 Sharing & tokens에서 OAuth2 client 역할 문맥을 사용하여 개별 클라이언트 권한을 줄 수도 있습니다. 예를 들어 Rotate third-party application client secret(multipass:rotate-client-secret)만 가진 사용자 지정 역할로 특정 앱의 비밀값 회전만 맡길 수 있습니다.

Sharing & tokens의 Manage OAuth client 탭에서 조직, 사용자와 그룹에 해당 클라이언트를 공유합니다.

앱 리소스 관리 권한과 OAuth 클라이언트 관리 권한이 자동으로 하나가 된다고 가정하면 안 됩니다.

앱 관리 위임과 생성

조직의 모든 OAuth 클라이언트를 관리하는 권한 없이 앱 관리를 위임하려면 Developer Console 관련 작업만 가진 사용자 지정 역할을 구성하고 특정 앱을 생성하여 공유할 수 있습니다. 광범위한 Manage OAuth 2.0 clients 권한은 제외합니다.

새 앱 생성에는 두 범위가 모두 필요합니다.

• 선택 폴더의 Create application(third-party-application:create-application). 기본 Owner 또는 Editor 역할에 포함합니다.
• 선택 조직의 Create third-party applications 작업 권한 묶음. 일반적으로 Third-party application administrator가 제공합니다.

웹사이트 권한

설정 화면은 보지 못하고 웹사이트만 보게 하려면 프로젝트 사용자 지정 역할에 View application website만 부여합니다.

데이터 실행 주체와 OAuth

한 앱에 프런트엔드와 백엔드 구성을 함께 둘 수 있지만 각 실행 경로의 인증을 구분합니다. Application permissions는 생성 서비스 사용자에게 부여한 데이터 권한으로 실행합니다.

가상의 차량 앱에서 사용자가 접근할 수 있는 Cars만 보여 주려면 User permissions를 사용합니다. 사용자의 권한과 별개로 서비스 사용자가 접근할 수 있는 Bikes를 백엔드가 제공하려면 Application permissions를 사용합니다. 이때 서비스가 어떤 데이터를 어느 사용자에게 제공할지 앱이 통제해야 합니다. 두 범위가 필요하면 해당 인증 경로를 함께 구성합니다.

리소스 의존성과 제한

SDK에 리소스를 추가하면 그 리소스와 필요한 기반 데이터셋 및 관련 리소스도 앱의 접근 제한에 추가합니다. 사용자의 실제 권한은 여전히 필요하며 제한은 OAuth 토큰이 앱에서 허용한 대상만 사용할 수 있게 합니다.

의존성 변경

이미 가져온 객체 유형의 기반 데이터셋이 바뀌는 등 의존성이 달라지면 접근 제한도 갱신해야 합니다. Application SDK의 오래된 의존성 경고에서 확인합니다.

안내된 수정 절차에서 빠진 데이터셋과 리소스를 추가합니다.

리소스 제거 순서

SDK에서 엔터티를 제거한 직후 접근 제한에서도 지우면 이전 버전의 앱이 실패할 수 있습니다. 새 SDK에서 제거하되 이전 클라이언트가 모두 업그레이드될 때까지 접근 제한에는 남겨 둡니다.

모든 소비자가 옮긴 뒤 OAuth & restrictions에서 오래된 리소스를 정리합니다.

기존 독립 앱 권한

Compass 관리 기능이 없는 기존 방식은 생성자를 앱 Owner로 두고, 생성자가 Sharing & tokens에서 개발자에게 권한을 줍니다. 프로젝트 권한을 자동 상속하지 않습니다.

기존 앱은 Overview > Danger zone에서 삭제하며 이 삭제는 복원할 수 없습니다. Compass 리소스의 휴지통 이동과 다릅니다.

Compass로 이전

이전에는 Migrate legacy application to Compass(third-party-application:migrate-application-to-compass) 작업이 필요하며 기본 Owner가 제공합니다.

기존 앱의 권한 구조는 이전하지 않습니다. 대상 프로젝트의 권한으로 대체되므로 웹사이트를 볼 수 있는 사람이 늘거나 줄 수 있습니다. 먼저 대상 프로젝트 권한을 확인합니다.

1. 앱에서 Migrate application to project를 선택합니다.

2. Migration to Compass resource에서 대상 위치를 선택합니다.

3. 바뀔 권한을 검토한 뒤 Submit으로 확정합니다.

이전 뒤에는 해당 위치의 Compass 리소스로 이동, 공유와 휴지통 작업을 수행합니다.

웹사이트 전용 열람자 유지

기존 앱은 Sharing & tokens에서 웹사이트만 공유할 수 있었습니다.

같은 경계를 유지하려면 이전 전에 대상 프로젝트 또는 폴더에 웹사이트 보기 전용 사용자 지정 역할을 부여합니다. 기본 프로젝트 역할을 그대로 쓰면 설정 화면의 접근도 함께 달라질 수 있습니다.

Marketplace 설치

새 Marketplace 앱은 다른 설치 리소스와 같은 지정 위치에 생성합니다. 제품 원본 앱을 이전해도 과거 설치본은 자동 이전하지 않으므로 설치마다 별도로 이전해야 합니다.

설치가 잠겨 있으면 앱을 옮기기 전에 잠금 해제를 요구할 수 있습니다.

이전 원본과 아직 이전하지 않은 설치 상태가 달라도 기존 설치를 막지는 않고 경고를 표시합니다. 필요한 설치를 순서대로 이전합니다. 앱 제한은 사용자 역할과 별도로 적용되는 범위입니다.