Cloud Software Group, Inc. EBX®
ドキュメント > リファレンスマニュアル > その他
ナビゲーションモードドキュメント > リファレンスマニュアル > その他

権限

権限は、各ユーザーがデータとアクションにアクセスできるかどうかを決定します。

概要

権限は、アクションが許可されているかどうかに関連しています。これらは、アクセス権限、つまり、エンティティが非表示、読み取り、または読み取り/書き込みのいずれであるかにも関連しています。権限によって制御される主なエンティティは次のとおりです。

ユーザー、ロール、プロファイル

権限の定義と解決には、ユーザーまたはロールに適用される一般的な用語であるプロファイルの概念が広く使用されています。

各ユーザーは複数のロールに参加でき、ロールは複数のユーザーで共有できます。

これらの関係は、ユーザーおよびロールディレクトリで定義されます。ユーザーとロールのディレクトリを参照してください。

特別な定義

権限ルール

権限ルールは、特定のエンティティのプロファイルに付与される認証を定義します。

ユーザー定義の権限ルールは、ユーザーインターフェイスを介して作成されます。ユーザー定義ルールの定義セクションを参照してください。

動的権限ルールは、開発者が作成したプログラムルール、または管理者が作成したスクリプトルールのいずれかです。動的ルールの定義セクションを参照してください。

権限の解決

権限は常に認証されたユーザーセッションのコンテキストで解決されるため、権限は主にユーザープロファイルに基づいています。

一般に、権限の解決は、特定のレベルとその親レベルの間で制限的に実行されます。したがって、どのレベルでも、ユーザーは親レベルで解決された権限よりも高い権限を持つことはできません。

動的な権限は常に制限的であると見なされます。

注意

Java API では、クラス SessionPermissions が解決された権限へのアクセスを提供します。

以下も参照してください。

所有者と管理者の特別な権限

データセット上

ビルトインの管理者またはデータセットの所有者は、次のアクションを実行できます。

注意

権限の定義により、ビルトインの管理者またはデータセット所有者がデータを表示したり特定のアクションを実行したりする権限を制限できますが、権限管理へのアクセス権限は常にあるため、自分のアクセス権限を変更することは可能です。

データスペース上

データスペースのスーパーオーナーになるには、ユーザーは次のいずれかを行う必要があります。

ビルトインの管理者またはデータスペースのスーパーオーナーは、次のアクションを実行できます。

さらに、ワークフローでは、「データスペースの作成」または「スナップショットの作成」ビルトインスクリプトタスクを使用する場合、解決された権限は、現在のセッションではなく、スクリプトタスクの構成で定義された所有者を使用して計算されます。これは、これらの場合、現在のセッションがシステムユーザーに関連付けられているためです。

注意

権限の定義により、ビルトインの管理者またはデータスペース所有者がデータを表示したり特定のアクションを実行したりする権限を制限できますが、権限管理へのアクセス権限は常にあるため、自分のアクセス権限を変更することは可能です。

権限に対するマージの影響

データスペースがマージされると、ユーザーがマージプロセス中に指定した場合にのみ、子データセットの権限が親データセットの権限とマージされます。親データスペースの権限が影響を受けることはありません。

マージを実行しようとしているプロファイルに対して一部のエレメントが非表示になっている場合、データに対するマージの影響が完全に表示されないため、続行できません。

権限に関する重要な考慮事項

このセクションには、権限を操作する際に留意する必要のあるいくつかの非常に重要な情報がリストされています。

高い権限を付与するアクションとユーザーサービス

次のアクションとそれに関連するユーザーサービスは、信頼できる管理者にのみ許可する必要があります。

注意

これらのプロファイルに付与される権限の詳細については、所有者と管理者の特別な権限セクションを参照してください。

権限チェックなしの API アクセス

開発者と管理者は、API の一部が権限チェックなしで実行できることに注意する必要があります。一般に、コードがセッションが指定されたコンテキストで実行される場合、権限がチェックされることを意味します。権限がチェックされない特定のケースを次に示します。

UI で情報を非表示にするための権限の使用

一部の非機密情報を UI で非表示にするためだけに権限を使用することはお勧めできません。特に、この情報が一部のクエリでのフィルタリング、結合、並べ替えに使用される可能性がある場合には注意が必要です。このような場合は、代わりに UI のみの非表示メソッドを使用する必要があります。たとえば、データモデルのプロパティでフィールドをデフォルトビューでは非表示として設定するか、関係するユーザー用のビューを作成します。

上記の提案を適用できず、権限を使用して非機密情報を非表示にする必要がある場合は、モデルでノードを非機密として設定する必要があります。詳細については、機密性の定義を参照してください。

クエリ API での権限チェックの制限事項

クエリまたはリクエストでセッションを指定するときに実行される権限チェックは、クエリで使用されている機密フィールドが現在のユーザーに対して非表示になっている場合、QueryPermissionException をスローします。以下を除くすべてのフィールドは機密情報と見なされます。

注意

レコード依存の AccessRule を持つ機密ノードの機密性は、部分的にのみ適用されます。実際に、AccessRule.getPermission メソッドは、権限チェックの実行中に aDataSetOrRecord パラメーターとしてデータセットのみで呼び出され、レコードで呼び出されることはありません。結果として、ルールのレコード依存ロジックは、このチェック中には適用されません。

レコードとテーブル履歴に関するスクリプト化された権限ルール

スクリプト化された権限ルールを使用して、テーブルレコードとテーブル履歴をフィルタリングできます。デフォルトでは、テーブル履歴へのアクセスはすべてのユーザーに対して無効になっています。この動作はセキュリティの強化に役立ちます。ただし、権限ルールを編集し、履歴へのアクセスを許可するプロファイルリストに目的のプロファイルを追加することで、テーブル履歴へのアクセスを許可されたプロファイルのリストを作成できます。

カスタム表示ラベルでの非表示フィールドの使用

テーブル (「defaultLabel」プロパティ) および関係 (「display」プロパティ) のカスタム表示ラベルの解決では、権限が考慮されます。ラベルで非表示フィールドが検出されるとすぐに、代わりに主キーが表示されます。

注意

これは、TableRefDisplay や Adaptation.getLabelOrName などの API を使用する場合には当てはまりません。提供されたコンテキストには現在のセッションが含まれていないため、権限チェックを実行できません。結果として、開発者はこれらの API を使用するときに機密データが公開されていないことを確認する必要があります。

注意

また、クイック検索では、履歴ビューのコンテキストや子データセットのカスタム表示ラベルに非表示のフィールドがあるノードが無視されることに注意してください。

この動作のため、クエリでのフィルタリングにラベルを使用することは推奨されません。非表示フィールドのあるラベルを使用すると、pk 値に置き換えられ、フィルターの一貫性が失われます。

リンクフィールド権限チェック

リンクされたフィールドアクセス権限が計算されると、結果は、メインテーブルのノードに適用される権限とターゲットテーブルのノードの間の最小値になります。実際には、フィールドがテーブルで非表示になっている場合、他のテーブルでそのフィールドを指しているすべてのリンクされたフィールドも非表示になることを意味します。

テーブルアクション権限に関連する制限事項

プロシージャ内のテーブルに対してアクション (作成、削除、上書き、または非表示) を実行する場合、権限の解決中に、テーブルノードに対する現在のユーザーセッションアクセス権限は無視されます。このチェックを実行する場合、クライアントコードは、プロシージャの前に SessionPermissions.getNodeAccessPermission を明示的に呼び出す必要があります。

権限キャッシュのライフサイクル

データサービスとユーザーサービスの両方の権限の解決を最適化するために、セッションレベルで専用キャッシュが実装されています。動的ルールを含むすべての権限がキャッシュされます。これは、以下で説明するキャッシュの期間中、ルールの結果が変更されないことを意味します。

セッションキャッシュのライフサイクルは、以下で説明するように、コンテキストによって異なります。

致命的なエラーが発生したデータセットに対する権限

データセットに致命的なエラーがある場合、所有者と管理者のみがアクセス権を持ち、次のアクションのみが使用可能になります。

機密性の定義

ノードの機密性は、特定のユーザーに対してノードが非表示になっているときにクエリまたはリクエストで使用できるかどうかを定義します。デフォルトでは、すべてのノードは機密として扱われます。

ノードで機密性を定義すると、それを使用する関係およびビューに次の影響があります。

ノードと関係を定義する追加の XPath フィルターの詳細については、外部キーおよび関連付けを参照してください。

注意

フィールドを非機密として設定する前に、十分に注意することをお勧めします。これは、非公開であっても、悪意のあるユーザーがこのノードを使用してフィルター処理または並べ替えを行うことで、値を「推測」する可能性があるためです。常にできるわけではありませんが、UI で情報を非表示にするための権限の使用で推奨されているように、一般に、ビューを使用してこの種のユースケースを処理する方が優れたオプションです。

ノードの機密性は DMA で構成できます。詳細については、ノードの機密性を参照してください。

ユーザー定義ルールの定義

各レベルには同様のスキーマがあり、プロファイルの権限ルールを定義できます。

データスペースのユーザー定義ルールの定義

特定のデータスペースについて、各プロファイルに許可される権限は次のとおりです。

データスペースへのアクセス

認証

書き込み

  • データスペースを表示できます。

  • データセットの権限に従ってデータセットにアクセスできます。

読み取り専用

  • データスペースとそのスナップショットを表示できます。

  • 権限で許可されている場合は、子データスペースを表示できます。

  • データスペースの内容を表示できますが、変更することはできません。

非表示

  • データスペースもそのスナップショットも表示できません。

  • 子データスペースの表示が許可されている場合、現在のデータスペースを表示できますが、選択することはできません。

  • データセットを含むデータスペースの内容にアクセスできません。

  • データスペースに対してアクションを実行できません。

制限ポリシー

このデータスペースプロファイルと権限の関連付けを他の権限ルールよりも優先する必要があるかどうかを示します。

子データスペースの作成

プロファイルが現在のデータスペースから子データスペースを作成できるかどうかを示します。

子スナップショットの作成

プロファイルが現在のデータスペースのスナップショットを作成できるかどうかを示します。

マージの開始

プロファイルが現在のデータスペースをその親データスペースとマージできるかどうかを示します。

アーカイブのエクスポート

プロファイルが現在のデータスペースをアーカイブとしてエクスポートできるかどうかを示します。

アーカイブのインポート

プロファイルがアーカイブを現在のデータスペースにインポートできるかどうかを示します。

データスペースを閉じる

プロファイルが現在のデータスペースを閉じることができるかどうかを示します。

スナップショットを閉じる

プロファイルが現在のデータスペースのスナップショットを閉じることができるかどうかを示します。

サービスの権限

プロファイルにデータスペースでサービスを実行する権限があるかどうかを示します。デフォルトでは、すべてのデータスペースサービスが許可されています。現在のデータスペースのビルトイン管理者またはスーパーオーナー、または現在のデータスペースの権限の変更を許可されている特定のユーザーは、これらの権限を変更して、特定のプロファイルのデータスペースサービスを制限できます。

作成時の子データスペースの権限

ユーザーが子データスペースを作成すると、この新しいデータスペースの権限は、親データスペースの「作成時の子データスペースの許可」で定義された権限に基づいて、プロファイルの所有者に自動的に割り当てられます。異なるロールを通じて所有者に複数の権限が定義されている場合、所有者のプロファイルは他のプロファイルと同じように動作し、通常どおりに権限が解決されます。

データセットのユーザー定義ルールの定義

特定のデータセットについて、各プロファイルに許可される権限は次のとおりです。

データセットに対するアクション

制限ポリシー

このデータセットプロファイルと権限の関連付けを他の権限ルールよりも優先する必要があるかどうかを示します。

子データセットの作成

プロファイルに現在のデータセットの子データセットを作成する権限があるかどうかを示します。

データセットの複製

プロファイルに現在のデータセットを複製する権限があるかどうかを示します。

データセットの親の変更

プロファイルに、特定の子データセットの親データセットを変更する権限があるかどうかを示します。

テーブルに対するアクション

デフォルトテーブルのアクション権限は、データセットレベルで定義されます。その後、1 つ以上のテーブルに対するこれらのデフォルトの権限をオーバーライドすることができます。各プロファイルに許可される権限は次のとおりです。

新しいレコードの作成

プロファイルにテーブルにレコードを作成する権限があるかどうかを示します。

継承されたレコードを上書きする

プロファイルに、テーブル内の継承されたレコードを上書きする権限があるかどうかを示します。

継承されたレコードを非表示にする

プロファイルに、テーブル内の継承されたレコードを非表示にする権限があるかどうかを示します。

レコードの削除

プロファイルにテーブル内のレコードを削除する権限があるかどうかを示します。

ノード値のアクセス権限

特定のターミナルノードで定義された権限は、デフォルトのアクセス権限をオーバーライドします。

読み書き

ノード値を表示および変更できます。

読み取り

ノードを表示できますが、それらの値を変更することはできません。

非表示

ノードを表示できません。

サービスの権限

ビルトインの管理者または現在のデータスペースの所有者は、サービスのデフォルトの権限を変更して、特定のプロファイルへのアクセスを制限または許可できます。

有効

現在のプロファイルへのサービスアクセスを許可します。

無効

現在のプロファイルへのサービスアクセスを禁止します。メニューには表示されず、Web コンポーネントを介して起動することもできません。

デフォルト

サービス宣言時に定義されたデフォルトの権限に従って、サービス権限を有効または無効に設定します。

詳細については、ActivationContext.setDefaultPermission を参照してください。

データセット権限構成サービスの使用

データセットレベルでのユーザー定義のアクセスルールは、データセットの [アクション] メニューから利用できる [許可] サービスを使用して定義されます。このサービスから、管理者はこのデータセット内のデータ、アクション、サービスへのユーザーアクセスを確認および構成できます。

権限サービス UI の概要

サービスは次のようなグリッドとして表示されます。

/config_page_profiles_added.PNG

プロファイルの管理

プロファイル管理タスクには次のものが含まれます。

ユーザー定義のアクセスルールの追加

プロファイルのルールを追加するには、次の手順を実行します。

/config_page_select_profile.PNG

プロファイル構成の別プロファイルへの複製

既存のプロファイルの構成を別のプロファイルに複製するには、次の手順を実行します。

プロファイル構成の削除

プロファイル構成を削除するには、次の手順を実行します。

権限の管理

ノード、アクション、サービスに権限を割り当てる方法には、次の 2 つがあります。

注意

権限ツールバーの [読み取りと書き込み / 有効] および [非表示 / 無効] の値は、選択がノードであるかアクション/サービスであるかによって変わります。実際の値は、ノードの場合は [読み書き] と [非表示]、アクション/サービスの場合は [有効] と [無効] です。

以下のスクリーンショットでは、[新しいレコードの作成] サービスとユーザー John Doe に対応する権限セルが [有効] に設定されています。

/config_page_set_permission.PNG

動的ルールの定義

動的ルールは、コンテキストに応じてデータまたはユーザーサービスにアクセスするための条件をより正確に定義する可能性を提供します。

プログラムルールにはさまざまな種類があります。

データに対するスクリプト化された権限ルールの定義

スクリプト化された権限ルールは、コンテキストに応じて、テーブルのレコードに対する読み取り/書き込み権限を動的に定義するルールです。

このようなルールを定義するには、DMA にレコード権限スクリプトを作成する必要があります。スクリプトエディターは、テーブルノード定義の [拡張機能] タブで利用できます。

データに対するアクセスルールの定義

AccessRules は、コンテキストに応じて、データモデルノードまたはテーブルのレコードに対する読み取り/書き込み権限をプログラムで定義するルールです。

AccessRule の定義は次のように実行されます。

  1. AccessRule または AccessRuleForCreate インターフェイスを実装する Java クラスの形式でのルールの作成。

  2. スキーマ拡張内の関連ノードへのこのルールの割り当て：SchemaExtensions。

    ルールの対象 (モデルノードまたはレコード) とタイプ (AccessRule または AccessRuleForCreate) に応じて、SchemaExtensionsContext.setAccessRuleOnOccurrence や SchemaExtensionsContext.setAccessRuleForCreateOnNode などいくつかのメソッドを使用することができます。

    このように割り当てられたルールは「ローカル」と呼ばれ、ターゲットエンティティが要求された場合にのみ実行されます。詳細については、データ権限の解決を参照してください。

    注意

    ノード、データスペース、またはレコードごとに定義できる AccessRule は 1 つだけです。テーブルの子ノードごとに定義できる AccessRuleForCreate は 1 つだけです。あるタイプの新しいプログラムルールを定義すると、既存のルールが置き換えられます。

サービスのアクティベーションルールの定義

ServiceActivationRules を使用すると、特定のデータスペースまたはデータセットに対してサービスをアクティブ化するかどうかを指定できます。このルールによって非アクティブ化されたサービスは、現在のプロファイルに関係なく、権限画面であっても、非アクティブ化されたエンティティで実行または表示することはできません。

ServiceActivationRule の定義は、次のように実行されます。

  1. サービスの種類に応じて、ServiceActivationRuleForDataspace インターフェイス または ServiceActivationRuleForDataset を実装する Java クラスの形式でルールを作成します。

  2. ActivationContextOnDataspace.setActivationRule または ActivationContextWithDatasetSet.setActivationRule メソッドにより、サービスの種類に応じて、影響を受けるサービスの宣言レベルでこのルールを割り当てます。

    結果として割り当てられたルールは、サービスアクティベーションの評価中に評価されます。詳細については、サービスの権限の解決を参照してください。

サービスの権限ルールの定義

ServicePermissionRules は、コンテキスト (現在のセッション、選択したエンティティなど) に応じて、サービスの表示条件と実行条件を動的に定義できる高度なルールです。このタイプのルールをトリガーするには、事前に現在のコンテキストに対してサービスをアクティブ化する必要があります。

ServicePermissionRule の定義は、次のように実行されます。

  1. ServicePermissionRule インターフェイスを実装する Java クラスの形式でルールを作成します。

  2. 次のように、このルールを、影響を受けるサービスに割り当てます。

    • いずれの場合も、新しいサービスの場合は、ActivationContext.setPermissionRule メソッドを介した宣言レベルで割り当てます。

      このように割り当てられたルールは「グローバル」と呼ばれ、現在のコンテキストでサービスがアクティブ化された場合にのみ実行されます。詳細については、サービスの権限の解決を参照してください。

    • または、既存のサービスの場合スキーマ拡張で、SchemaExtensionsContext.setServicePermissionRuleOnNode および SchemaExtensionsContext.setServicePermissionRuleOnNodeAndAllDescendants メソッドを介して割り当てます。この場合、1 つ以上のデータモデルノード (テーブルノード、関連付けノードなど) で、EBX® から提供される標準サービスを含む任意のサービスにルールを割り当てることができます。

      このように割り当てられたルールは「ローカル」と呼ばれ、拡張スキーマコンテキストで、ノードが指定されたものに対応する場合にのみ実行されます。詳細については、サービスの権限の解決を参照してください。

      注意

      モデルノードごとに定義できる ServicePermissionRule は 1 つだけです。したがって、新しいプログラムルールの定義は既存のルールを置き換えます。

データ権限の解決

ユーザー定義ルールの解決

ユーザーインターフェイスを使用して定義されたアクセス権限は、データスペース、データセット、レコード (該当する場合)、およびノードの 4 つのレベルで解決されます。

プロファイルが特定のレベルで制限付きアクセス権限に関連付けられている場合、そのレベルで定義されているすべての制限付き権限の最小値が解決されます。そのレベルで制限が定義されていない場合、そのレベルで定義されているすべてのアクセス権限の最大値が解決されます。

プロファイルに制限付き権限が定義されている場合、ユーザーの他のロールによって付与される可能性のある他の権限よりも優先されます。通常、現在のユーザーセッションに一致するすべてのユーザー定義の権限ルールについて、次のことが適用されます。

例

同じユーザーに関する 2 つのプロファイル P1 と P2 がある場合、次の表に、そのユーザーのサービスへの権限を解決する際の可能性を示します。

P1 認証P2 認証権限の解決
有効有効有効。制限に何の違いもありません。
無効無効無効。制限に何の違いもありません。
有効無効P2 の許可が制限されていない限り、有効になります。
無効有効P1 の許可が制限されていない限り、有効になります。

同じ制限ポリシーがデータアクセス権限の解決に適用されます。

別の例では、ビルトインプロファイル「Profile.EVERYONE」とアクセス権限「hidden」の間に制限付きの関連付けを定義することにより、データスペースをすべてのユーザーから隠すことができます。

どのレベルでも、このレベルとそれ以上のレベルで解決されたものの間で最も制限の厳しいアクセス権限が適用されます。たとえば、ユーザーのデータセットアクセス権限が読み取り/書き込みアクセスに解決されたが、コンテナデータスペースが読み取りアクセスのみを許可している場合、ユーザーはこのデータセットへの読み取り専用アクセスのみを持ちます。

注意

データセットの継承メカニズムは、値とアクセス権限の両方に適用されます。つまり、データセットで定義されたアクセス権限は、その子データセットに適用されます。子データセットでこれらの権限をオーバーライドすることができます。

アクセス権限解決の例

この例では、次の定義済みのロールとプロファイルに属する 3 人のユーザーが存在します。

ユーザー

プロファイル

ユーザー 1

  • user1

  • ロールA

  • ロールB

ユーザー 2

  • user2

  • ロールA

  • ロールB

  • ロールC

ユーザー 3

  • user3

  • ロールA

  • ロールC

特定のエレメントのプロファイルのアクセス権限は次のとおりです。

プロファイル

アクセス権限

制限ポリシー

user1

非表示

はい

user3

読み取り

いいえ

ロールA

読み取り/書き込み

いいえ

ロールB

読み取り

はい

ロールC

非表示

いいえ

上記のロールとプロファイルのアクセス権限に基づいて解決した後、各ユーザーに適用される権限は次のとおりです。

ユーザー

解決されたアクセス権限

ユーザー 1

非表示

ユーザー 2

読み取り

ユーザー 3

読み取り/書き込み

データスペースとスナップショットのアクセス権限の解決

データスペースレベルでは、アクセス権限は次のように解決されます。

データセットのアクセス権限の解決

データセットレベルでは、データスペースレベルと同じ原則が適用されます。データセットレベルのみでアクセス権限を解決した後、最終的なアクセス権限は、解決されたデータスペースの権限と解決されたデータセットの権限の間の最小の権限を取得することによって決定されます。たとえば、データスペースがユーザーに対して読み取り専用であると解決され、そのデータセットの 1 つが読み取り/書き込みであると解決された場合、ユーザーはそのデータセットへの読み取り専用アクセスのみを持ちます。

ノードアクセス権限の解決

ノードレベルでは、データスペースおよびデータセットレベルと同じ原則が適用されます。ノードレベルのみでアクセス権限を解決した後、最終的なアクセス権限は、解決されたデータセットの権限と解決されたノードの権限の間の最小の権限を取得することによって決定されます。

特定のアクセス権限は、ノードレベルで定義できます。特定のアクセス権限が定義されていない場合、解決プロセスにはデフォルトのアクセス権限が使用されます。

注意

解決手順は、テーブルノードとテーブル子ノードでわずかに異なります。

テーブルおよびテーブルの子ノードの特殊なケース

これは、特定のテーブルノードまたはテーブルレコード N に使用される解決プロセスについて説明しています。

ユーザーのプロファイルの 1 つに一致するユーザー定義のアクセス権限ルールごとに、N のアクセス権限は次のいずれかです。

  1. N のローカルで定義されたアクセス権限。

  2. テーブルノードで定義されたアクセス権限から継承。

  3. データセット値のデフォルトのアクセス権限から継承。

一致するすべてのユーザー定義のアクセス権限ルールは、 N のアクセス権限を解決するために使用されます。解決は、制限ポリシーに従って行われます。

最終的に解決されたアクセス権限は、N のデータスペース、データセット、および解決されたアクセス権限の間の最小値になります。

動的ルールの解決

動的アクセス権限ルールの解決には、データセット、レコード、ノードの 3 つのレベルがあります。特定のレベルに設定できるプログラムによるアクセスルールは 1 つだけなので、最後のルールセットは解決手順で使用されるルールセットです。ただし、スクリプト化されたルールは、テーブルレベルでプログラムルールの上に指定できます。

データセットのルール解決

データセットの場合、最後のルールセットが解決されたルールと見なされます。

レコードのルール解決

レコードの場合、解決されたルールは、データセットで解決されたルールセットとこのレコードで設定されたルールの間の最小値です。

詳細については、SchemeExtensionsContext.setAccessRuleOnOccurrence を参照してください。

ノードでのルール解決

レコードの子ノードであるノードの場合、解決されたルールは、レコード上の解決されたルールとこのノードに設定されたルールの間の最小値です。

データセットの子ノードの場合、解決されたルールは、データセットで解決されたルールセットとこのノードで設定されたルールの間の最小値です。

詳細については、SchemeExtensionsContext.setAccessRuleOnNode を参照してください。

外部キードロップダウンメニューの表示ポリシー

アクセスルールのためにレコードが非表示になっている場合、そのレコードは外部キーのドロップダウンメニューに表示されません。

注意

データセットまたはデータセットノードで解決されたアクセス権限は、ユーザーインターフェイスで定義された解決されたアクセス権限と、解決された動的ルール (存在する場合) の間の最小値です。

サービスの権限の解決

ユーザーサービスは、ユーザーインターフェイスから特定の高度な機能を実行する可能性を提供します。定義に応じて、これらのサービスは、メニューから、ワークフローのアクションとして、パースペクティブアイテムとして呼び出すことも、URL から Web コンポーネントとして直接実行することもできます。

以下も参照してください。

サービスの権限は、サービスがユーザーインターフェイスから呼び出されるときに解決されます。つまり、次のようになります。

したがって、すべてのリクエストに応じて、サービスの権限の解決は、次の順序で、条件に従う限り、次のように実行されます。

  1. サービスのアクティブ化は、現在のコンテキストに対応している必要があります。このアクティベーションでは、次のことを考慮します。

  2. 現在のコンテキストでサービスがアクティブ化されると、ユーザーセッションの権限が評価されます。

ユーザー定義ルールの解決

例

この例では、異なるロールとプロファイルに属する 2 人のユーザーが存在します。

ユーザー

プロファイル

ユーザー 1

  • user1

  • ロールA

  • ロールB

ユーザー 2

  • ロールC

  • ロールD

データセットレベルで定義されたロールとプロファイルに関連付けられている権限は次のとおりです。

プロファイル

ビルトインサービスの作成 (@creation)

ビルトインサービスの複製 (@duplicate)

ビルトインサービスの比較 (@compare)

カスタムサービス 1 (custom1)

カスタムサービス 2 (custom2)

制限ポリシー

user1

有効

無効

有効

無効

有効

いいえ

ロールA

有効

有効

無効

有効

無効

はい

ロールB

有効

無効

有効

有効

無効

はい

ロールC

有効

有効

無効

無効

無効

いいえ

ロールD

有効

無効

無効

有効

無効

いいえ

権限解決後に各ユーザーが利用できるサービスは次のとおりです。

ユーザー

利用可能なサービス

ユーザー 1

ビルトインサービスの作成 (@creation)

カスタムサービス 1 (custom1)

ユーザー 2

ビルトインサービスの作成 (@creation)

ビルトインサービスの複製 (@duplicate)

カスタムサービス 1 (custom1)
以下も参照してください。

アクションの権限の解決

アクションは、プロファイルの実行権限を定義できる EBX® オブジェクト操作の低レベルの操作です。ユーザーインターフェイスにのみ影響するユーザーサービスの権限とは異なり、これらの権限は、操作がプログラムで (つまり、プロシージャを介して) または間接的に (たとえば、データのインポート中に、テーブルに対するアクション (作成、オーバーライド、非表示、および削除) が評価されます)。

権限を定義できるアクションのリストは次のとおりです。

アクションオブジェクト

利用可能なアクション

データスペース

子データスペースの作成
スナップショットの作成
マージの開始
アーカイブのエクスポート
アーカイブのインポート
データスペースを閉じる
スナップショットを閉じる
データセットの作成

データセット

データセットの複製
データセットの削除
データセットのアクティブ化/非アクティブ化
ビューの作成

テーブル

新しいレコードの作成
レコードの上書き
レコードの非表示
レコードの削除

アクションの権限の解決では、現在のユーザー (またはそのロール) のユーザーインターフェイスを介して定義された権限のみが考慮され、ユーザーインターフェイスを介して定義された他の権限と同様に制限ポリシーが適用されます。

詳細については、ユーザー定義ルールの解決セクションを参照してください。

ユーザー定義ルールの解決

例

この例では、異なるロールとプロファイルに属する 2 人のユーザーが存在します。

ユーザー

プロファイル

ユーザー 1

  • user1

  • ロールA

  • ロールB

ユーザー 2

  • ロールC

  • ロールD

特定のテーブルのアクションのロールとプロファイルに関連付けられている権限は次のとおりです。

プロファイル

レコードの作成

レコードの上書き

レコードの非表示

レコードの削除

制限ポリシー

user1

いいえ

はい

いいえ

はい

いいえ

ロールA

はい

いいえ

はい

いいえ

はい

ロールB

いいえ

はい

はい

いいえ

はい

ロールC

はい

いいえ

いいえ

いいえ

いいえ

ロールD

いいえ

いいえ

はい

いいえ

いいえ

権限を解決した後に各ユーザーが使用できるアクションは次のとおりです。

ユーザー

利用可能なアクション

ユーザー 1

レコードの非表示

ユーザー 2

レコードの作成

レコードの非表示
以下も参照してください。
ドキュメント > リファレンスマニュアル > その他