権限

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

ユーザー権限

Developer Console のユーザーは、自動的に作成したアプリケーションの Owner に設定されます。アプリケーションの所有者は、他の開発者とアプリケーションを共有し、特定のユーザーに権限を付与できます。

アプリケーションのユーザーは、次のいずれかのロールを持つことができます：

• Viewer: アプリケーションの詳細を表示し、生成されたオントロジー SDK を使用してアプリケーションを開発できます。Viewer は、アプリケーション情報の編集、エンティティの追加または変更、新しいバージョンのオントロジー SDK の生成はできません。
• Editor: アプリケーション情報と OAuth パラメーターを編集し、エンティティを追加または変更し、新しいバージョンのオントロジー SDK を生成できます。
• Owner: Editor と同じ権限を持ち、他の開発者とアプリケーションを共有できます。

アプリケーションの作成

新しいアプリケーションを Developer Console で作成するには、Third-party application administrator ロールを持っている必要があります。アプリケーションが作成されると、他の開発者とアプリケーションを共有し、以下に説明するように Editor 権限を付与できます。

ウェブサイトホスティング

ウェブサイトホスティングを使用すると、Foundry でアプリケーションのファイルをホストおよび配信できます。詳細については、Deploy an Ontology SDK application on Foundry (Beta) ドキュメントを参照してください。

• Foundry でウェブサイトをデプロイするには、特定の Developer Console アプリケーションに対する Editor permission を持っている必要があります。詳細については、ユーザー権限 ドキュメントを参照してください。

• Information Security Officer ロールを持つ Foundry ユーザーは、ドメイン作成リクエストを承認または拒否することができます。

アプリケーション権限

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

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

同じアプリケーションには、Client-facing タイプと Backend タイプの両方を含めることができます。作成するアプリケーションのタイプに応じて、使用する権限のタイプと OAuth ワークフローが決まります。以下に説明します。

権限のタイプ

アプリケーションを作成する際に、アプリケーションデータにアクセスするために使用する権限タイプを選択する必要があります。2 種類の権限タイプが利用可能です：

• ユーザー権限: ユーザーの権限に基づいて、Foundry オントロジーに対して読み取りおよび書き込みができるかどうかが決まります。この権限タイプは、Authorization code grant OAuth ワークフローを使用します。
• アプリケーション権限: アプリケーションはユーザー権限を適用するのではなく、生成されたサービスユーザーを使用して権限を利用します。この権限タイプは、Client credentials grant OAuth ワークフローを使用します。

例

たとえば、車両データを表示するアプリケーションを作成しているとします。

ユーザーに Cars へのアクセス権限がある場合のみ表示させたい場合は、ユーザー権限を適用するように選択します。ユーザーに関係なくすべての Bikes を表示させたい場合は、アプリケーション権限を適用して、生成されたサービスユーザーを使用してアプリケーションに別の権限を付与します。

ユーザーにアクセス権のあるすべての Cars とすべての Bikes を表示させたい場合は、両方の権限オプションを使用するように選択します。

リソースアクセス範囲

アプリケーションの SDK にリソースを追加すると、そのリソースとその依存関係が自動的にアプリケーションのリソースアクセス範囲に追加されます。ユーザーはリソースに対して関連する権限を持っている必要がありますが、リソースアクセス範囲は、与えられた OAuth トークンを介してこのアプリケーションに承認されたリソースにのみユーザーがアクセスできるようにします。

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

アプリケーションが正しく機能するためには、依存関係が変更されたとき または リソースを削除するとき に範囲を手動で管理する必要がある場合があります。

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

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

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

古い依存関係を修正するためのワークフローの例。この場合、オブジェクトタイプのデータセットが欠落していることが表示されています。

リソースを削除するとき

以前に含まれていたリソースを削除する新しいバージョンのアプリケーション SDK を作成する場合、これらのリソースをリソースアクセス範囲から即座に削除すると、アプリケーションの現在のバージョンの使用が中断されます。これを防ぐために、SDK から以前に含まれていたリソースを削除し、それらのリソースをリソースアクセス範囲に保持して、すべてのクライアントが新しいバージョンのアプリケーションにアップグレードするまで待つ必要があります。その後、以前に含まれていたリソースを範囲から削除することが安全になります。

SDK からリソースを削除すると、Developer Console アプリケーションが警告を表示し、それらを範囲から削除するか保持するかを確認します。古いリソースは後で OAuth & Scopes ページからクリーンアップできます。

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

以前の SDK バージョンからリソースアクセス範囲に存在する古いリソースのクリーンアップワークフローの例。