権限

このセクションでは、Developer Console とオントロジー SDK を使用するために必要な各種権限について説明します。これらのロールと権限は、Foundry 設定のロールセクションで管理できます。

ユーザー権限

Developer Console で作成したアプリケーションは、ロール、マーキング、組織によって適用される権限などを、親のプロジェクトまたはフォルダーから自動的に継承します。

プロジェクトでデフォルトロールセットを使用している場合、Developer Console アプリケーションのユーザーには以下のいずれかのロールを割り当てられます。これらのロールはすべて設定を変更できます。

• 閲覧者： アプリケーションの詳細と、アプリケーションが Foundry でホストされている場合はホストされている Web サイトを閲覧でき、生成されたオントロジー SDK を使用してアプリケーションを開発できます。閲覧者は、アプリケーション情報の編集、エンティティの追加や変更、オントロジー SDK の新しいバージョンの生成はできません。
• 編集者： アプリケーション情報と OAuth パラメーターの編集、エンティティの追加や変更、オントロジー SDK の新しいバージョンの生成ができます。
• 所有者： 編集者と同じ権限を持ち、ほかの開発者とアプリケーションを共有できます。

アプリケーションが Developer Console のホームページのリストに表示されるのは、そのアプリケーションに対して、少なくともアプリケーション設定を閲覧（third-party-application:view-application-config）操作権限がある場合のみです。この権限は、デフォルトで閲覧者ロールを通じて付与されます。

リンクされた OAuth クライアント

Developer Console は、カスタムアプリケーションを必ず OAuth クライアントにリンクします。このクライアントは、Control Panel で組織レベルで管理できます。OAuth クライアントの認証設定を変更するには、サードパーティアプリケーションを有効にするやサードパーティアプリケーションのシークレットを管理するなどのワークフローへのアクセス権限が必要です。通常、これらは Control Panel の組織権限拡張機能で、サードパーティアプリケーション管理者ロールの下で付与されます。このロールでは、リンクされた OAuth クライアントを作成する権限も付与されます。この権限は、Developer Console でカスタムアプリケーションを作成するために必要です。

Developer Console アプリケーションの共有とトークンセクションでは、OAuth2 クライアントのロールコンテキストを使用して、クライアントごとに OAuth クライアントを管理することもできます。たとえば、サードパーティアプリケーションのクライアントシークレットをローテーションする（multipass:rotate-client-secret）操作権限のみを持つカスタムロールを設定し、特定のアプリケーションのクライアントシークレットをローテーションする権限のみを持つべきユーザーに付与できます。

アプリケーションの編集時に、共有とトークンセクションの OAuth クライアントを管理するタブを使用して、クライアントを組織、ユーザー、グループと共有します。

リンクされた OAuth クライアントの権限は、将来、アプリケーションの権限と統合される可能性があります。

アプリケーション管理を委任する

組織内のすべての OAuth クライアントに対する広範なサードパーティアプリケーション管理者権限を付与せずに、ユーザーが自身の Developer Console アプリケーションを作成および管理できるようにしたい場合があります。これを実現するには、次の手順を実行します。

1. カスタムロールセットを作成します。third-party-application:create-application や third-party-application:view-application-config など、Developer Console に関連する権限のみを付与し、OAuth 2.0 クライアントの管理などの広範な OAuth クライアント管理権限は付与しません。
2. ユーザーに代わってアプリケーションを作成し、共有とトークンセクションを通じてそのアプリケーションをユーザーと共有します。これにより、ユーザーはアクセス権限を付与された特定のアプリケーションのみを管理できます。

アプリケーションを作成する

新しいアプリケーションを作成するには、次の権限が必要です。

• 選択したフォルダーに対するアプリケーションを作成する（third-party-application:create-application）操作権限。デフォルトでは、所有者または編集者ロールを通じて付与されます。
• 選択した組織に対するサードパーティアプリケーションを作成するワークフロー。前述のとおり、通常は Control Panel のサードパーティアプリケーション管理者ロールを通じて付与されます。

Web サイトホスティング

• Foundry でホストされている Web サイトを閲覧するには、Developer Console アプリケーションに対する Web サイトを閲覧（third-party-application:view-application-website）操作権限が必要です。この権限は、デフォルトで閲覧者ロールを通じて付与されます。Developer Console のアプリケーション設定にはアクセスできない状態でユーザーが Web サイトを閲覧できるようにしたい場合は、この操作権限のみを付与するカスタムプロジェクトロールを作成できます。

• Foundry に Web サイトをデプロイするには、Developer Console アプリケーションに対する Web サイトをデプロイ（third-party-application:deploy-application-website）操作権限が必要です。この権限は、デフォルトで編集者ロールを通じて付与されます。

• 情報セキュリティ責任者ロールを持つ Foundry ユーザーは、ドメイン作成リクエストを承認または拒否できます。

Foundry でオントロジー SDK アプリケーションをホストする方法について詳しくはこちら。

アプリケーションの権限

Developer Console は、2種類のアプリケーションをサポートしています。

• クライアント向け： Web、デスクトップ、モバイルアプリケーションなどのフロントエンドサービスです。これらのアプリケーションをクライアント資格情報の保存に使用してはいけません。
• バックエンドサービス： アプリケーションサービスやデーモンなど、バックエンドのワークフローをサポートするアプリケーションです。これらのアプリケーションは、クライアント資格情報を安全に保存するために使用できます。

同じアプリケーションに、クライアント向けとバックエンドの両方の種類を含めることもできます。以下で説明するように、作成するアプリケーションの種類によって、使用できる権限の種類と OAuth ワークフローが決まります。

権限の種類

アプリケーションを作成するときは、アプリケーションのデータへのアクセスに使用する権限の種類を選択する必要があります。次の2種類の権限を利用できます。

• ユーザー権限： ユーザーが Foundry オントロジーで読み書きできる内容は、そのユーザーの権限によって決まります。この種類の権限では、Authorization code grant OAuth ワークフローを使用します。
• アプリケーションの権限： アプリケーションは、ユーザー権限を適用する代わりに、生成されたサービスユーザーの権限を使用します。この種類の権限では、Client credentials grant OAuth ワークフローを使用します。

例

車両データを表示するアプリケーションを作成するとします。

ユーザーがアクセス権限を持つ Cars のみを閲覧できるようにする場合は、ユーザー権限の適用を選択します。ユーザー権限にかかわらず、すべての Bikes をユーザーが閲覧できるようにする場合は、アプリケーションの権限の適用を選択し、生成されたサービスユーザーを使用してアプリケーションに別の権限を付与します。

ユーザーが閲覧権限を持つすべての Cars、かつすべての Bikes を閲覧できるようにする場合は、両方の権限の選択肢を使用します。

リソースアクセス制限

アプリケーションの SDK にリソースを追加すると、そのリソースとそれに依存するリソースが、アプリケーションのリソースアクセス制限に自動的に追加されます。ユーザーはリソースに対する適切な権限を持っている必要がありますが、リソースアクセス制限によって、指定された OAuth トークンを通じてユーザーがアクセスできるのは、このアプリケーションで承認されたリソースのみに限定されます。

たとえば、新しいオブジェクトタイプ、リンクタイプ、アクションタイプ、または関数を SDK の設定に追加すると、必要な基盤となるデータセットや関連リソースがリソースアクセス制限に追加されます。

アプリケーションが正常に機能するように、依存関係が変更されたときやリソースを削除するときに、制限を手動で管理する必要がある場合があります。

依存関係が変更されたとき

アプリケーションの SDK にリソースを追加した後で、そのリソースに必要な依存関係が変更された場合は、変更された依存関係を含めるようにアプリケーションのリソースアクセス制限を更新してください。この更新は Developer Console で行えます。Developer Console では、アプリケーションの制限が最新でない場合に警告が表示され、修正のためのガイド付きワークフローを利用できます。たとえば、アプリケーションの SDK にすでに含まれているオブジェクトタイプに対して、新しい元データセットが設定された場合に、この更新が必要になることがあります。

最新でない依存関係が検出されたときに、アプリケーションの SDK ページに表示される警告の例。

最新でない依存関係の修正ワークフローの例。この例では、オブジェクトタイプに必要なデータセットがないことが表示されています。

リソースを削除するとき

以前含まれていたリソースを削除した新しいバージョンのアプリケーション SDK を作成する場合、そのリソースをリソースアクセス制限からすぐに削除すると、現在のバージョンのアプリケーションが正常に動作しなくなります。これを防ぐには、以前含まれていたリソースを SDK から削除しても、すべてのクライアントを新しいバージョンのアプリケーションにアップグレードするまでは、リソースアクセス制限にそのリソースを保持する必要があります。アップグレード後は、以前含まれていたリソースを制限からも安全に削除できます。

SDK からリソースを削除すると、Developer Console アプリケーションに警告が表示され、そのリソースを制限からも削除するか、制限に保持するかを確認されます。古いリソースは、後で［OAuth と制限］ページから整理できます。

リソースを削除するときに、アプリケーションの SDK ページに表示される警告の例。

以前の SDK バージョンからリソースアクセス制限に残っている古いリソースを整理するワークフローの例。

Compass 管理のユーザー権限に移行する

ユーザー権限 [レガシー]

アプリケーションがプロジェクトの権限を継承する代わりに、Developer Console のユーザーは、作成したアプリケーションの所有者として自動的に設定されます。その後、アプリケーションの所有者は、アプリケーションの共有とトークンセクションから、ほかの開発者とアプリケーションを共有し、対象のユーザーに権限を付与する必要があります。

Developer Console のアプリケーションは、そのアプリケーションの概要セクションにある危険パネルで削除できます。Compass リソースをゴミ箱に移動するワークフローとは異なり、削除されたアプリケーションは復元できません。

Developer Console のアプリケーションが Compass で管理されるようにするには、以下の移行手順に沿って進めてください。

移行手順

アプリケーションを移行するには、レガシーアプリケーションを Compass に移行（third-party-application:migrate-application-to-compass）操作権限が必要です。この権限は、デフォルトで所有者ロールを通じて付与されます。

1. アプリケーションを開き、アプリケーションをプロジェクトに移行を選択します。

2. Compass リソースへの移行ポップアップモーダルの指示に沿って、場所を選択します。

3. 権限の変更を確認し、確定を選択して確定します。

移行後、アプリケーションは選択した場所に表示されます。これで、ほかの Compass リソースと同様に、アプリケーションの移動、共有、ゴミ箱への移動などの操作を実行できます。

Web サイトの閲覧者権限

以前は、アプリケーションの共有とトークンセクションを使用して、ホストされている Web サイトを閲覧する権限をユーザーに付与しつつ、アプリケーションの設定を閲覧する権限は付与しないようにできました。

Compass 管理のアプリケーションでは、デフォルトでこの機能を利用できなくなりましたが、カスタムプロジェクトロールを作成して、閲覧権限を個別に維持できます。既存のワークフローが機能しなくなることを防ぐため、移行前にプロジェクトまたはフォルダーでこのロールを割り当ててください。これにより、対象のユーザーグループは Web サイトにアクセスできる一方で、Developer Console でアプリケーションの設定を閲覧できないようになります。

Marketplace アプリケーション

以前は、Marketplace を通じてデプロイされた Developer Console のアプリケーションは、ほかのインストールリソースと同じ場所には作成されませんでした。Compass 管理のユーザー権限への移行に伴い、Marketplace を通じてインストールされる新しいアプリケーションも、指定した場所に作成されるようになります。

Marketplace 製品のパッケージ化済みアプリケーションを移行しても、以前にデプロイされたそのインストールは自動的には移行されません。各インストールも、移行手順を使用して個別に移行する必要があります。インストールがロックされている場合、アプリケーションをその場所に移動できるように、事前にロックを解除するよう求められることがあります。