権限
権限は、各ユーザーがデータとアクションにアクセスできるかどうかを決定します。
Related information
概要
権限は、アクションが許可されているかどうかに関連しています。これらは、アクセス権限、つまり、エンティティが非表示、読み取り、または読み取り/書き込みのいずれであるかにも関連しています。権限によって制御される主なエンティティは次のとおりです。
-
データスペース
-
データセット
-
テーブル
-
グループ
-
フィールド
ユーザー、ロール、プロファイル
権限の定義と解決には、ユーザーまたはロールに適用される一般的な用語であるプロファイルの概念が広く使用されています。
各ユーザーは複数のロールに参加でき、ロールは複数のユーザーで共有できます。
これらの関係は、ユーザーおよびロールディレクトリで定義されます。ユーザーとロールのディレクトリを参照してください。
特別な定義
-
ビルトインの管理者は、ビルトインのロール「ADMINISTRATOR (管理者)」のメンバーです。
-
データセットの所有者は、ルートデータセットの情報で指定された所有者属性のメンバーです。この場合、データセットのコンテキストで権限が解決されると、ビルトインのロール「OWNER (所有者)」がアクティブになります。
-
データスペースの所有者は、データスペースに指定された所有者属性のメンバーです。この場合、データスペースのコンテキストで権限が解決されると、ビルトインのロール「OWNER (所有者)」がアクティブになります。
権限ルール
権限ルールは、特定のエンティティのプロファイルに付与される認証を定義します。
ユーザー定義の権限ルールは、ユーザーインターフェイスを介して作成されます。ユーザー定義ルールの定義セクションを参照してください。
動的権限ルールは、開発者が作成したプログラムルール、または管理者が作成したスクリプトルールのいずれかです。 動的ルールの定義セクションを参照してください。
権限の解決
権限は常に認証されたユーザーセッションのコンテキストで解決されるため、権限は主にユーザープロファイルに基づいています。
一般に、権限の解決は、特定のレベルとその親レベルの間で制限的に実行されます。したがって、どのレベルでも、ユーザーは親レベルで解決された権限よりも高い権限を持つことはできません。
動的な権限は常に制限的であると見なされます。
注意:
Java API では、クラス
SessionPermissions が解決された権限へのアクセスを提供します。
以下も参照してください。:
所有者と管理者の特別な権限
データセット上
ビルトインの管理者またはデータセットの所有者は、次のアクションを実行できます。
-
その権限を管理します。
-
データセットがルートデータセットの場合は、所有者を変更します。
-
一般情報 (ローカライズされたラベルと説明) を変更
注意:
権限の定義により、ビルトインの管理者またはデータセット所有者がデータを表示したり特定のアクションを実行したりする権限を制限できますが、権限管理へのアクセス権限は常にあるため、自分のアクセス権限を変更することは可能です。
データスペース上
データスペースのスーパーオーナーになるには、ユーザーは次のいずれかを行う必要があります。
-
データスペースを所有し、その権限の管理を許可する。
-
現在のデータスペースの祖先であるデータスペースを所有し、その祖先データスペースの権限を管理できるようにする。ビルトインの管理者またはデータスペースのスーパー所有者は、次のアクションを実行できます。
-
データスペースの権限を管理
-
所有者を変更
-
ロックまたはロック解除
-
一般情報 (ローカライズされたラベルと説明) を変更
さらに、ワークフローでは、「データスペースの作成」または「スナップショットの作成」ビルトインスクリプトタスクを使用する場合、解決された権限は、現在のセッションではなく、スクリプトタスクの構成で定義された所有者を使用して計算されます。これは、これらの場合、現在のセッションがシステムユーザーに関連付けられているためです。
注意:
権限の定義により、ビルトインの管理者またはデータスペース所有者がデータを表示したり特定のアクションを実行したりする権限を制限できますが、権限管理へのアクセス権限は常にあるため、自分のアクセス権限を変更することは可能です。
権限に対するマージの影響
データスペースがマージされると、ユーザーがマージプロセス中にそうするように指定した場合にのみ、子データセットの権限が親データセットの権限とマージされます。親データスペースの権限が影響を受けることはありません。
マージを実行しようとしているプロファイルに対して一部のエレメントが非表示になっている場合、データに対するマージの影響が完全に表示されないため、続行できません。
権限に関する重要な考慮事項
このセクションには、権限を操作する際に留意する必要のあるいくつかの非常に重要な情報がリストされています。
高い特権を付与するアクションとユーザーサービス
次のアクションとそれに関連するユーザーサービスは、信頼できる管理者にのみ許可する必要があります。
-
「データスペースの作成」 (データスペースの権限を定義する権限を付与する「所有者」ロールを付与します)
-
「データセットの作成」 (データセットの権限を定義する権限を付与する「所有者」ロールを付与します)
-
‘‘「アーカイブのインポート」(権限に関係なくアーカイブコンテンツの書き込みを許可します)
注意:
これらのプロファイルに付与される権限の詳細については、所有者と管理者の特別な権限セクションを参照してください。
権限チェックなしの API アクセス
開発者と管理者は、API の一部が権限チェックなしで実行できることに注意する必要があります。一般に、コードが
セッションが指定されたコンテキストで実行される場合、権限がチェックされることを意味します。権限がチェックされない特定のケースを次に示します。
-
Java プロシージャが、
ProcedureContext.setAllPrivilegesを使用してすべての権限チェックを無効にする場合。 -
データベースに直接クエリを実行して EBX データにアクセスする際に、テーブルでレプリケーションモードまたは履歴が有効になっている場合。これは、EBX 権限が基盤となるデータベースで「変換」されないためです。結果として、データベースアクセスをグローバルに制限するか、適切な権限をデータベースに定義する必要があります。
UI で情報を非表示にするための権限の使用
UI で非機密情報を非表示にする目的だけに権限を使用することはお勧めできません。特に、この情報が一部のクエリでフィルタリング/結合/並べ替えに使用される可能性が高い場合は注意が必要です。そのような場合は、代わりに UI のみの非表示メソッドを使用する必要があります。たとえば、データモデルのプロパティでフィールドを デフォルトビューで非表示として設定したり、関係するユーザーのビューを作成したりします。
上記の提案を適用できず、権限を使用して非機密情報を非表示にする必要がある場合は、モデルでノードを非機密として設定する必要があります。詳細については、機密性の定義を参照してください。
クエリ API での権限チェックの制限事項
クエリまたはリクエストでセッションを指定するときに実行される権限チェックは、クエリで使用されている機密フィールドが現在のユーザーに対して非表示になっている場合、QueryPermissionException をスローします。以下を除くすべてのフィールドは機密情報と見なされます。
-
主キーに属するフィールド。
-
非機密として明示的に定義されたフィールド。詳細については、機密性の定義を参照してください。
注意:
レコード依存の
AccessRule を持つ機密ノードの機密性は、部分的にのみ適用されます。実際に、AccessRule.getPermission メソッドは、権限チェックの実行中に aDataSetOrRecord パラメーターとしてデータセットのみで呼び出され、レコードで呼び出されることはありません。結果として、ルールのレコード依存ロジックは、このチェック中には適用されません。
レコードとテーブル履歴に関するスクリプト化された権限ルール
スクリプト化された権限ルールは、テーブル内のレコードを正しくフィルター処理しますが、テーブルの履歴には適用できません。したがって、テーブル履歴へのアクセスはデフォルトですべてのユーザーに対して無効になっています。この動作は、セキュリティの強化にも役立ちます。
権限ルールを編集することで、テーブル履歴へのアクセスを許可されたプロファイルのリストを作成できます。これらのユーザーは、スクリプト化されたルールが適用されないため、すべてのレコードの履歴にアクセスできるため、注意が必要です。
カスタム表示ラベルでの非表示フィールドの使用
テーブル (「defaultLabel」プロパティ) および関係 (「display」プロパティ) のカスタム表示ラベルの解決では、権限が考慮されます。ラベルで非表示フィールドが検出されるとすぐに、代わりに主キーが表示されます。
注意:
これは、
TableRefDisplay や Adaptation.getLabelOrName などの API を使用する場合には当てはまりません。提供されたコンテキストには現在のセッションが含まれていないため、権限チェックを実行できません。結果として、開発者はこれらの API を使用するときに機密データが公開されていないことを確認する必要があります。
注意:
また、クイック検索では、履歴ビューのコンテキストや子データセットのカスタム表示ラベルに非表示のフィールドがあるノードが無視されることに注意してください。
この動作のため、クエリでのフィルタリングにラベルを使用することは強くお勧めしません。非表示フィールドのあるラベルを使用すると、pk 値に置き換えられ、フィルターの一貫性が失われます。
リンクフィールド権限チェック
リンクフィールドアクセス権限が計算されると、結果は、メインテーブルのノードに適用される権限とターゲットテーブルのノードの間の最小値になります。実際には、フィールドがテーブルで非表示になっている場合、他のテーブルでそのフィールドを指しているすべてのリンクされたフィールドも非表示になることを意味します。
テーブルアクション権限に関連する制限事項
プロシージャ内のテーブルに対してアクション (作成、削除、上書き、または非表示) を実行する場合、権限の解決中に、テーブルノードに対する現在のユーザーセッションアクセス権限は無視されます。このチェックを実行する場合、クライアントコードは、プロシージャの前に
SessionPermissions.getNodeAccessPermission を明示的に呼び出す必要があります。
権限キャッシュのライフサイクル
データサービスとユーザーサービスの両方の権限の解決を最適化するために、セッションレベルで専用キャッシュが実装されています。動的ルールを含むすべての権限がキャッシュされます。これは、以下で説明するキャッシュの期間中、ルールの結果が変更されないことを意味します。
セッションキャッシュのライフサイクルは、以下で説明するように、コンテキストによって異なります。
-
UI では、ajax 以外のイベント (ページ表示、ポップアップの開始など) ごとにキャッシュがクリアされます。
-
プログラムプロシージャでは、明示的にクリアされない限り、キャッシュはプロシージャの最後まで存続します (以下を参照)。注意:EBX® アーカイブをインポートしたり、プログラムでデータスペースをマージしたりして、プロシージャのコンテキストで権限を変更する場合は、
Session.clearCacheを呼び出してセッションキャッシュをクリアする必要があります。そうしないと、プロシージャが終了するまで変更が反映されません。
機密性の定義
注意:
フィールドを非機密として設定する前に、十分に注意することをお勧めします。これは、非公開であっても、悪意のあるユーザーがこのノードを使用してフィルター処理または並べ替えを行うことで、値を「推測」する可能性があるためです。常にできるわけではありませんが、UI で情報を非表示にするための権限の使用で推奨されているように、一般に、ビューを使用してこの種のユースケースを処理する方が優れたオプションです。
ノードの機密性は DMA で設定できます。詳細については、ノードの機密性を参照してください。
ユーザー定義ルールの定義
各レベルには同様のスキーマがあり、プロファイルの権限ルールを定義できます。
データスペースのユーザー定義ルールの定義
特定のデータスペースについて、各プロファイルに許可される権限は次のとおりです。
|
データスペースへのアクセス
|
認証
|
|---|---|
|
書き込み
|
|
|
読み取り専用
|
|
|
非表示
|
|
|
制限ポリシー
|
このデータスペースプロファイルと権限の関連付けを他の権限ルールよりも優先する必要があるかどうかを示します。
|
|
子データスペースの作成
|
プロファイルが現在のデータスペースから子データスペースを作成できるかどうかを示します。
|
|
子スナップショットの作成
|
プロファイルが現在のデータスペースのスナップショットを作成できるかどうかを示します。
|
|
マージの開始
|
プロファイルが現在のデータスペースをその親データスペースとマージできるかどうかを示します。
|
|
アーカイブのエクスポート
|
プロファイルが現在のデータスペースをアーカイブとしてエクスポートできるかどうかを示します。
|
|
アーカイブのインポート
|
プロファイルがアーカイブを現在のデータスペースにインポートできるかどうかを示します。
|
|
データスペースを閉じる
|
プロファイルが現在のデータスペースを閉じることができるかどうかを示します。
|
|
スナップショットを閉じる
|
プロファイルが現在のデータスペースのスナップショットを閉じることができるかどうかを示します。
|
|
サービスの権限
|
プロファイルにデータスペースでサービスを実行する権限があるかどうかを示します。デフォルトでは、すべてのデータスペースサービスが許可されています。現在のデータスペースのビルトイン管理者またはスーパー所有者、または現在のデータスペースの権限の変更を許可されている特定のユーザーは、これらの権限を変更して、特定のプロファイルのデータスペースサービスを制限できます。
|
|
作成時の子データスペースの権限
|
ユーザーが子データスペースを作成すると、この新しいデータスペースの権限は、親データスペースの「作成時の子データスペースの許可」で定義された権限に基づいて、プロファイルの所有者に自動的に割り当てられます。異なるロールを通じて所有者に複数の権限が定義されている場合、所有者のプロファイルは他のプロファイルと同じように動作し、通常どおりに権限が解決されます権限の解決。
|
データセットのユーザー定義ルールの定義
特定のデータセットについて、各プロファイルに許可される権限は次のとおりです。
データセットに対するアクション
|
制限ポリシー
|
このデータセットプロファイルと権限の関連付けを他の権限ルールよりも優先する必要があるかどうかを示します。
|
|
子データセットの作成
|
プロファイルに現在のデータセットの子データセットを作成する権限があるかどうかを示します。
|
|
重複するデータセット
|
プロファイルに現在のデータセットを複製する権限があるかどうかを示します。
|
|
データセットの親の変更
|
プロファイルに、特定の子データセットの親データセットを変更する権限があるかどうかを示します。
|
テーブルに対するアクション
デフォルトテーブルのアクション権限は、データセットレベルで定義されます。その後、1つ以上のテーブルに対するこれらのデフォルトの権限を上書きすることができます。各プロファイルに許可される権限は次のとおりです。
|
新しいレコードの作成
|
プロファイルにテーブルにレコードを作成する権限があるかどうかを示します。
|
|
継承されたレコードを上書きする
|
プロファイルに、テーブル内の継承されたレコードを上書きする権限があるかどうかを示します。
|
|
継承されたレコードを非表示にする
|
プロファイルに、テーブル内の継承されたレコードを非表示にする権限があるかどうかを示します。
|
|
レコードの削除
|
プロファイルにテーブル内のレコードを削除する権限があるかどうかを示します。
|
ノード値のアクセス権限
特定のターミナルノードで定義された権限は、デフォルトのアクセス権限を上書きします。
|
読み書き
|
ノード値を表示および変更できます。
|
|
読み取り
|
ノードを表示できますが、それらの値を変更することはできません。
|
|
非表示
|
ノードを表示できません。
|
サービスの権限
ビルトインの管理者または現在のデータスペースの所有者は、サービスのデフォルトの権限を変更して、特定のプロファイルへのアクセスを制限または許可できます。
|
有効
|
現在のプロファイルへのサービスアクセスを許可します。
|
|
無効
|
現在のプロファイルへのサービスアクセスを禁止します。メニューには表示されず、Web コンポーネントを介して起動することもできません。
|
|
デフォルト
|
サービス宣言時に定義されたデフォルトの権限に従って、サービス権限を有効または無効に設定します。
詳細については、 ActivationContext.setDefaultPermission を参照してください。
|
データセット権限構成サービスの使用
権限サービス UI の概要
プロファイルの管理
プロファイル管理タスクには次のものが含まれます。
ユーザー定義のアクセスルールの追加
プロファイル構成の別プロファイルへの複製
プロファイル構成の削除
権限の管理
ノード、アクション、サービスに権限を割り当てる方法には、次の 2 つがあります。
-
1 つ以上のセルを選択し、ツールバーまたはショートカットを使用して権限を適用します。
-
セルが選択されていない状態で、ツールバーまたはショートカットを使用して権限を選択し、この権限を 1 つ以上のセルに適用します。この方法を使用すると、マウスポインターの横にアイコンが表示され、コンテキストに応じてアイコンが変化します。
注意:
動的ルールの定義
動的ルールは、コンテキストに応じてデータまたはユーザーサービスにアクセスするための条件をより正確に定義する可能性を提供します。
プログラムルールにはさまざまな種類があります。
-
AccessRule。データに対するアクセスルールの定義のセクションで説明されています。 -
スクリプト化されたレコードの権限ルール。データに対するスクリプト化された権限ルールの定義のセクションで説明されています。
-
ServiceActivationRule。サービスのアクティベーションルールの定義のセクションで説明されています。
-
ServicePermissionRule。サービスの権限ルールの定義で説明されています。
データに対するスクリプト化された権限ルールの定義
スクリプト化された権限ルールは、コンテキストに応じて、テーブルのレコードに対する読み取り/書き込み権限を動的に定義するルールです。
このようなルールを定義するには、DMA にレコード権限スクリプトを作成する必要があります。スクリプトエディターは、テーブルノード定義の タブで利用できます。
データに対するアクセスルールの定義
AccessRules は、コンテキストに応じて、データモデルノードまたはテーブルのレコードに対する読み取り/書き込み権限をプログラムで定義するルールです。
AccessRule の定義は次のように実行されます。
-
AccessRuleまたはAccessRuleForCreateインターフェイスを実装する Java クラスの形式でのルールの作成。 -
スキーマ拡張内の関連ノードへのこのルールの割り当て：
SchemaExtensions。ルールの対象 (モデルノードまたはレコード) とタイプ (AccessRuleまたはAccessRuleForCreate) に応じて、SchemaExtensionsContext.setAccessRuleOnOccurrenceやSchemaExtensionsContext.setAccessRuleForCreateOnNodeなどいくつかのメソッドを使用することができます。このように割り当てられたルールは「ローカル」と呼ばれ、ターゲットエンティティが要求された場合にのみ実行されます。詳細については、データの権限の解決を参照してください。注意:ノード、データスペース、またはレコードごとに定義できるAccessRuleは 1 つだけです。テーブルの子ノードごとに定義できるAccessRuleForCreateは 1 つだけです。あるタイプの新しいプログラムルールを定義すると、既存のルールが置き換えられます。
サービスのアクティベーションルールの定義
ServiceActivationRules を使用すると、特定のデータスペースまたはデータセットに対してサービスをアクティブ化するかどうかを指定できます。このルールによって非アクティブ化されたサービスは、現在のプロファイルに関係なく、権限画面であっても、非アクティブ化されたエンティティで実行または表示することはできません。
ServiceActivationRule の定義は、次のように実行されます。
-
サービスの種類に応じて、
ServiceActivationRuleForDataspaceインターフェイス またはServiceActivationRuleForDatasetを実装する Java クラスの形式でルールを作成します。 -
ActivationContextOnDataspace.setActivationRuleまたはActivationContextWithDatasetSet.setActivationRuleメソッドにより、サービスの種類に応じて、影響を受けるサービスの宣言レベルでこのルールを割り当てます。結果として割り当てられたルールは、サービスアクティベーションの評価中に評価されます。詳細については、サービスの権限の解決を参照してください。
サービスの権限ルールの定義
ServicePermissionRules は、コンテキスト (現在のセッション、選択したエンティティなど) に応じて、サービスの表示条件と実行条件を動的に定義できる高度なルールです。このタイプのルールをトリガーするには、事前に現在のコンテキストに対してサービスをアクティブ化する必要があります。
ServicePermissionRule の定義は、次のように実行されます。
-
ServicePermissionRuleインターフェイスを実装する Java クラスの形式でルールを作成します。 -
次のように、このルールを、影響を受けるサービスに割り当てます。
-
いずれの場合も、新しいサービスの場合は、
ActivationContext.setPermissionRuleメソッドを介した宣言レベルで割り当てます。このように割り当てられたルールは「グローバル」と呼ばれ、現在のコンテキストでサービスがアクティブ化された場合にのみ実行されます。詳細については、サービスの権限の解決を参照してください。 -
または、既存のサービスの場合スキーマ拡張で、
SchemaExtensionsContext.setServicePermissionRuleOnNodeおよびSchemaExtensionsContext.setServicePermissionRuleOnNodeAndAllDescendantsメソッドを介して割り当てます。この場合、1 つ以上のデータモデルノード (テーブルノード、関連付けノードなど) で、EBX® から提供される標準サービスを含む任意のサービスにルールを割り当てることができます。このように割り当てられたルールは「ローカル」と呼ばれ、拡張スキーマコンテキストで、ノードが指定されたものに対応する場合にのみ実行されます。詳細については、サービスの権限の解決を参照してください。注意:モデルノードごとに定義できるServicePermissionRuleは 1 つだけです。したがって、新しいプログラムルールの定義は既存のルールを置き換えます。
-
データ権限の解決
ユーザー定義ルールの解決
ユーザーインターフェイスを使用して定義されたアクセス権限は、データスペース、データセット、レコード (該当する場合)、およびノードの 4 つのレベルで解決されます。
プロファイルが特定のレベルで制限付きアクセス権限に関連付けられている場合、そのレベルで定義されているすべての制限付き権限の最小値が解決されます。そのレベルで制限が定義されていない場合、そのレベルで定義されているすべてのアクセス権限の最大値が解決されます。
プロファイルに制限付き権限が定義されている場合、ユーザーの他のロールによって付与される可能性のある他の権限よりも優先されます。通常、現在のユーザーセッションに一致するすべてのユーザー定義の権限ルールについて、次のことが適用されます。
-
制限付きのルールが定義されている場合、これらの制限付きルールの最小権限が適用されます。
-
制限のあるルールが定義されていない場合、一致するすべてのルールの最大権限が適用されます。
例
同じユーザーに関する2つのプロファイル P1 と P2 がある場合、次の表に、そのユーザーのサービスへの権限を解決する際の可能性を示します。
| P1 認証 | P2 認証 | 権限の解決 |
|---|---|---|
| 有効 | 有効 | 有効。制限に何の違いもありません。 |
| 無効 | 無効 | 無効。制限に何の違いもありません。 |
| 有効 | 無効 | P2 の許可が制限されていない限り、有効になります。 |
| 無効 | 有効 | P1 の許可が制限されていない限り、有効になります。 |
同じ制限ポリシーがデータアクセス権限の解決に適用されます。
別の例では、ビルトインプロファイル「Profile.EVERYONE」とアクセス権限「hidden」の間に制限付きの関連付けを定義することにより、データスペースをすべてのユーザーから隠すことができます。
どのレベルでも、このレベルとそれ以上のレベルで解決されたものの間で最も制限の厳しいアクセス権限が適用されます。たとえば、ユーザーのデータセットアクセス権限が読み取り/書き込みアクセスに解決されたが、コンテナデータスペースが読み取りアクセスのみを許可している場合、ユーザーはこのデータセットへの読み取り専用アクセスのみを持ちます。
注意:
データセットの継承メカニズムは、値とアクセス権限の両方に適用されます。つまり、データセットで定義されたアクセス権限は、その子データセットに適用されます。子データセットでこれらの権限を上書きすることができます。
アクセス権限解決の例
この例では、次の定義済みのロールとプロファイルに属する 3 人のユーザーがいます。
|
ユーザー
|
プロファイル
|
|
ユーザー 1
|
|
|
ユーザー 2
|
|
|
ユーザー 3
|
|
特定のエレメントのプロファイルのアクセス権限は次のとおりです。
| プロファイル | アクセス権限 | 制限ポリシー |
|---|---|---|
| user1 | 非表示 | はい |
| user3 | 読み取り | いいえ |
| ロールA | 読み取り/書き込み | いいえ |
| ロールB | 読み取り | はい |
| ロールC | 非表示 | いいえ |
上記のロールとプロファイルのアクセス権限に基づいて解決した後、各ユーザーに適用される権限は次のとおりです。
|
ユーザー
|
解決されたアクセス権限
|
|
ユーザー 1
|
非表示
|
|
ユーザー 2
|
読み取り
|
|
ユーザー 3
|
読み取り/書き込み
|
データスペースとスナップショットのアクセス権限の解決
データスペースレベルでは、アクセス権限は次のように解決されます。
-
ユーザーが複数のプロファイルを通じて定義された複数の権限を持っている場合
-
権限に制限が含まれている場合は、最小限の制限的なプロファイルと権限の関連付けが適用されます。
-
それ以外の場合は、プロファイルと権限の関連付けの最大値が適用されます。
-
-
ユーザーに権限が定義されていない場合
-
ユーザーがビルトインの管理者またはデータスペースの所有者である場合、このデータスペースには読み取り/書き込みアクセス権限が付与されます。
-
それ以外の場合、データスペースは非表示になります。
-
データセットのアクセス権限の解決
データセットレベルでは、データスペースレベルと同じ原則が適用されます。データセットレベルのみでアクセス権限を解決した後、最終的なアクセス権限は、解決されたデータスペースの権限と解決されたデータセットの権限の間の最小の権限を取得することによって決定されます。たとえば、データスペースがユーザーに対して読み取り専用であると解決され、そのデータセットの 1 つが読み取り/書き込みであると解決された場合、ユーザーはそのデータセットへの読み取り専用アクセスのみを持ちます。
ノードアクセス権限の解決
ノードレベルでは、データスペースおよびデータセットレベルと同じ原則が適用されます。ノードレベルのみでアクセス権限を解決した後、最終的なアクセス権限は、解決されたデータセットの権限と解決されたノードの権限の間の最小の権限を取得することによって決定されます。
特定のアクセス権限は、ノードレベルで定義できます。特定のアクセス権限が定義されていない場合、解決プロセスにはデフォルトのアクセス権限が使用されます。
注意:
解決手順は、テーブルノードとテーブル子ノードでわずかに異なります。
テーブルおよびテーブルの子ノードの特殊なケース
これは、特定のテーブルノードまたはテーブルレコード N に使用される解決プロセスについて説明しています。
ユーザーのプロファイルの 1 つに一致するユーザー定義のアクセス権限ルールごとに、N のアクセス権限は次のいずれかです。
-
N のローカルで定義されたアクセス権限。
-
テーブルノードで定義されたアクセス権限から継承。
-
データセット値のデフォルトのアクセス権限から継承。
一致するすべてのユーザー定義のアクセス権限ルールは、 N のアクセス権限を解決するために使用されます。解決は、制限ポリシーに従って行われます。
最終的に解決されたアクセス権限は、N のデータスペース、データセット、および解決されたアクセス権限の間の最小値になります。
動的ルールの解決
動的アクセス権限ルールの解決には、データセット、レコード、ノードの 3 つのレベルがあります。特定のレベルに設定できるプログラムによるアクセスルールは 1 つだけなので、最後のルールセットは解決手順で使用されるルールセットです。ただし、スクリプト化されたルールは、テーブルレベルでプログラムルールの上に指定できます。
データセットのルール解決
データセットの場合、最後のルールセットが解決されたルールと見なされます。
レコードのルール解決
レコードの場合、解決されたルールは、データセットで解決されたルールセットとこのレコードで設定されたルールの間の最小値です。
詳細については、
SchemeExtensionsContext.setAccessRuleOnOccurrence を参照してください。
ノードでのルール解決
レコードの子ノードであるノードの場合、解決されたルールは、レコード上の解決されたルールとこのノードに設定されたルールの間の最小値です。
データセットの子ノードの場合、解決されたルールは、データセットで解決されたルールセットとこのノードで設定されたルールの間の最小値です。
詳細については、
SchemeExtensionsContext.setAccessRuleOnNode を参照してください。
外部キードロップダウンメニューの表示ポリシー
アクセスルールのためにレコードが非表示になっている場合、そのレコードは外部キーのドロップダウンメニューに表示されません。
注意:
データセットまたはデータセットノードで解決されたアクセス権限は、ユーザーインターフェイスで定義された解決されたアクセス権限と、解決された動的ルール (存在する場合) の間の最小値です。
サービスの権限の解決
ユーザーサービスは、ユーザーインターフェイスから特定の高度な機能を実行する可能性を提供します。定義に応じて、これらのサービスは、メニューから、ワークフローのアクションとして、パースペクティブアイテムとして呼び出すことも、URL から Web コンポーネントとして直接実行することもできます。
以下も参照してください。:
サービスの権限は、サービスがユーザーインターフェイスから呼び出されるときに解決されます。つまり、次のようになります。
-
実行中、サービスが表示される直前。ユーザーコンテキストで解決された権限が
有効でない場合、サービスの代わりに制限メッセージが表示されます。 -
サービスがメニューで表示可能として定義されている場合、メニューの表示中。ユーザーのコンテキストで解決された権限が
有効でない場合、サービスはメニューに表示されません。
したがって、すべての要求に応じて、サービスの権限の解決は、次の順序で、条件に従う限り、次のように実行されます。
-
サービスのアクティブ化は、現在のコンテキストに対応している必要があります。このアクティベーションでは、次のことを考慮します。
-
選択したエンティティタイプ (データセット、テーブル、レコードなど)。
-
UserServiceDeclaration.defineActivationメソッド内で定義された静的アクティベーションルール。 -
UserServiceDeclaration.defineActivationメソッド内でも定義されている潜在的な動的アクティベーションルール (ServiceActivationRule)。
-
-
現在のコンテキストでサービスがアクティブ化されると、ユーザーセッションの権限が評価されます。
-
現在のユーザー (またはそのロール) のユーザーインターフェイスを介して権限が定義されている場合、その解決策は
有効を返す必要があります。詳細については、ユーザー定義ルールの解決セクションを参照してください。
-
ユーザー定義ルールの解決
例
この例では、異なるロールとプロファイルに属する 2 人のユーザーがいます。
|
ユーザー
|
プロファイル
|
|
ユーザー 1
|
|
|
ユーザー 2
|
|
データセットレベルで定義されたロールとプロファイルに関連付けられている権限は次のとおりです。
| プロファイル | ビルトインサービスの作成 (@creation) |
ビルトインサービスの複製 (@duplicate) |
ビルトインサービスの比較 (@compare) |
カスタムサービス 1 ( custom1) |
カスタムサービス 2 ( custom2) |
制限ポリシー |
|---|---|---|---|---|---|---|
| user1 | 有効 | 無効 | 有効 | 無効 | 有効 | いいえ |
| ロールA | 有効 | 有効 | 無効 | 有効 | 無効 | はい |
| ロールB | 有効 | 無効 | 有効 | 有効 | 無効 | はい |
| ロールC | 有効 | 有効 | 無効 | 無効 | 無効 | いいえ |
| ロールD | 有効 | 無効 | 無効 | 有効 | 無効 | いいえ |
権限解決後に各ユーザーが利用できるサービスは次のとおりです。
| ユーザー | 利用可能なサービス |
|---|---|
| ユーザー 1 | ビルトインサービスの作成 (@creation) |
カスタムサービス 1 ( custom1) |
|
| ユーザー 2 | ビルトインサービスの作成 (@creation) |
ビルトインサービスの複製 (@duplicate) |
|
カスタムサービス 1 ( custom1) |
以下も参照してください。:
アクションの権限の解決
アクションは、プロファイルの実行権限を定義できる EBX® オブジェクト操作の低レベルの操作です。ユーザーインターフェイスにのみ影響するユーザーサービスの権限とは異なり、これらの権限は、操作がプログラムで (つまり、
プロシージャを介して) または間接的に (たとえば、データのインポート中に、テーブルに対するアクション (作成、オーバーライド、非表示、および削除) が評価されます)。
権限を定義できるアクションのリストは次のとおりです。
| アクションオブジェクト | 利用可能なアクション |
|---|---|
| データスペース | 子データスペースの作成 |
| スナップショットの作成 | |
| マージの開始 | |
| アーカイブのエクスポート | |
| アーカイブのインポート | |
| データスペースを閉じる | |
| スナップショットを閉じる | |
| データセットの作成 | |
| データセット | データセットの複製 |
| データセットの削除 | |
| データセットのアクティブ化/非アクティブ化 | |
| ビューの作成 | |
| テーブル | 新しいレコードの作成 |
| レコードの上書き | |
| レコードの非表示 | |
| レコードの削除 |
アクションの権限の解決では、現在のユーザー (またはそのロール) のユーザーインターフェイスを介して定義された権限のみが考慮され、ユーザーインターフェイスを介して定義された他の権限と同様に制限ポリシーが適用されます。
詳細については、ユーザー定義ルールの解決セクションを参照してください。
ユーザー定義ルールの解決
例
この例では、異なるロールとプロファイルに属する 2 人のユーザーがいます。
|
ユーザー
|
プロファイル
|
|
ユーザー 1
|
|
|
ユーザー 2
|
|
特定のテーブルのアクションのロールとプロファイルに関連付けられている権限は次のとおりです。
| プロファイル | レコードの作成 | レコードの上書き | レコードの非表示 | レコードの削除 | 制限ポリシー |
|---|---|---|---|---|---|
| user1 | いいえ | はい | いいえ | はい | いいえ |
| ロールA | はい | いいえ | はい | いいえ | はい |
| ロールB | いいえ | はい | はい | いいえ | はい |
| ロールC | はい | いいえ | いいえ | いいえ | いいえ |
| ロールD | いいえ | いいえ | はい | いいえ | いいえ |
権限を解決した後に各ユーザーが使用できるアクションは次のとおりです。
| ユーザー | 利用可能なアクション |
|---|---|
| ユーザー 1 | レコードの非表示 |
| ユーザー 2 | レコードの作成 |
| レコードの非表示 |
以下も参照してください。: