権限とは、あらかじめ定義された機能と操作の集まりで、これをユーザーに割り当てることによって、ワークフローとドキュメントおよびコンフィギュレーション管理の特定のタスクへのアクセスが許可されます。割り当てられた権限のセットにより、利用可能な機能への各ユーザーのアクセスが決まります。権限が与えられていないユーザーはタスクを実行できません。

コンフィギュレーション管理のすべてのタスク、およびワークフローとドキュメントの一部のタスクには、特定のプリンシパル (グループおよびユーザー) を許可または拒否する、あらかじめ定義された権限が必要です。権限が与えられていないプリンシパルはタスクを実行できません。たとえば、ロックされたファイルをチェックアウトするには、FetchRevision 権限と Lock 権限が必要です。

また、セキュリティ権限の更新にアクセスするユーザーを制御するために、ACL の管理に使用するアプリケーションにもそれ自体の ACL があることを理解しておく必要もあります。Authorization Administration の ACL は、コンフィギュレーション管理で使用する ACL とは無関係です。必要に応じて、他の ACL を制御する ACL を作成することもできます。

デフォルトで、everyone というプリンシパル グループにはすべての権限が有効になった状態で出荷されます。

利用可能な権限については、ワークフロートとドキュメントの権限およびコンフィギュレーション管理の権限を参照してください。

このアクセス制御システムでは、権限はデフォルトで親 ACL から継承されます。これは、親 ACL が mks:aa:mks 管理 ACL、製品レベルの ACL (mks:im、mks:si)、またはコンフィギュレーション管理固有の ACL (プロジェクト、サブプロジェクト、メンバー ACL など) のいずれであっても同様です。

Windchill RV&S Server は、ACL データベースにユーザーのアクセス権限をクエリし、アーカイブ ACL レベルから最上位 (グローバル) レベルまで ACL の名前空間の構造を下から上に探索し、ユーザーが要求した操作を行うために必要な権限を持っているかどうかを判別します。

ユーザーが操作を実行すると、Windchill RV&S Server は ACL をチェックして、要求したユーザーおよび指定したコマンドに対応する権限を調べます。ACL の権限のチェックでは、次の 2 つの領域をチェックします。

Windchill RV&S Server が権限をチェックする際には、まずターゲットユーザーに最も限定された ACL を探し、次により一般的な ACL を探します。次の図は、Windchill RV&S Server が権限をチェックする際にたどる経路を示しています。

最も限定的な権限のタイプは、ユーザーとして定義されたプリンシパルを持つアーカイブ ACL (図のセクション 1) です。この次にサーバーは、グループとして定義されたプリンシパルを持つアーカイブ ACL (図のセクション 2) に移ります。その後、ユーザーとして定義されたプリンシパルを持つプロジェクト権限 (セクション 3) をチェックする、というように続きます。

権限は必ず次の 3 つの状態のいずれかをとります。

サーバーは常に ACL 階層内で検出した最も限定的な権限を使用します。たとえば、許可または拒否された権限は、消去された権限よりも限定的です。

権限の消去と拒否の違いに留意してください。他のプリンシパルによって権限が許可されている場合でも、継承に基づいて、明示的に拒否された権限が優先されます。権限を消去した場合、依然として他のプリンシパルまたは親 ACL からその権限を明示的に許可できます。

ACL のチェックを実行すると、Windchill RV&S Server は許可された権限または拒否された権限の有無を各レベルで検索します。いずれかの権限が検出されると、サーバーは権限のチェックを停止し、ユーザーが要求した操作を実行 (許可された権限がある場合) するか、該当のエラー メッセージを送信 (拒否された権限がある場合) します。

ACL を構成すると、権限を消去する選択もできます。Windchill RV&S Server では、操作の権限を明示的に設定しないと、権限が消去されている (未指定である) と見なされます。これにより、さまざまなレベルで権限を定義できます。

権限の継承機能を使用すると、個々の開発パス ACL に対する権限の継承を有効または無効にすることもできます。個々の開発パス ACL を設定すると、選択した開発パスに対するグローバルな「開発パスの継承」設定が上書きされます。

開発パス ACL を選択し、権限の継承を「真」に設定すると、ターゲット開発パス ACL はプロジェクト ACL から権限を継承します。「偽」に設定すると、選択された開発パスは最上位レベルの mks:si ACL から権限を継承します。開発パス ACL の作成手順については、「開発パスの権限」を参照してください。

「権限の継承」を「真」に設定するか、グローバルな「開発パスの継承」を「真」に設定すると、ツリー内のマスタプロジェクトから権限が継承されます。マスタ プロジェクトに ACL が設定されていない場合、権限は最上位レベルの mks:si に解決されます。したがって、プロジェクト ACL が設定されておらず、権限の継承が「真」に設定されていると、権限は最上位レベルの mks:si に解決されます。

権限の継承が「偽」に設定されていると、権限は最上位レベルの mks:si から継承されます。

開発パスの権限の継承の設定については、「開発パスの権限」を参照してください。

ユーザーが固有の権限を持つプリンシパルとして識別され、権限を許可されたグループの一部でもある場合、権限の競合がどのように解決されるかを理解することが重要です。

各 ACL エントリは、許可 (正数の場合) または拒否 (負数の場合) の権限セットを示します。プリンシパルが持つのは、多くても 1 つの正の ACL エントリと 1 つの負の ACL エントリです。つまり、プリンシパルには同じ権限に対して複数の正または負の ACL エントリは許可されません。定義された権限はすべて、継承された権限よりも優先されます。

ACL 権限の解決では、ユーザー プリンシパルに対して権限が明示的に指定されると、常にその権限がグループに含まれる権限よりも優先されます。個々の権限は、常に個々のユーザーが属するグループの権限より優先されます。したがって、個々の負の権限 (特定の権限の拒否) はグループの正の権限より優先され、個々の正の権限はグループの負の権限より優先されます。たとえば、ユーザー "Patrick Molinas" は pmolinas のユーザー プリンシパルによって CreateProject 権限を許可されていますが、Developersのグループ プリンシパルのメンバーシップによって CreateProject 権限を拒否されています。個々のプリンシパルの権限はグループ プリンシパルの権限より優先されるため、Patrick は CreateProject 権限を許可されます。

グループ間での競合を解決する場合は、負の権限が優先されます。プリンシパルが、あるグループでは権限を許可されていても別のグループでは同じ権限を拒否されている場合、権限を拒否することによって競合を解決します。

次にプリンシパルの権限セットが親 ACL から継承されます。ルート ACL をチェックして、プリンシパルに適用する明示的な正または負のエントリがない場合、プリンシパルは解決済みの ACL に対する空の権限セットを持つと見なされます。これは、拒否された権限のデフォルト値となります。

権限の主要な要素を次に示します。