アクセス制御規則でのダイナミック役割の使用
ダイナミック役割は、コンテキストチームと共有チーム内のチームメンバーに割り当てられた役割に対して作成されたシステムグループと、アプリケーションコンテキスト内で作成されたシステムグループは、コンテキストチーム内にメンバーを持つ組織を表すを表します。
ダイナミック役割は、アクセス制御規則に対して次のように選択できます。
• サイトコンテキストでは、「ポリシー管理」ユーティリティを使用してアクセス制御規則を作成する場合にダイナミック役割を使用できます。これらのダイナミック役割は、wt.project.RoleRB.rbInfo ファイルで定義されている役割ごとのコンテキストチーム役割から成ります。サイトコンテキストのインタフェースでコンテキストチーム役割を追加作成することはできませんが、カスタマイズの一環として、wt.project.RoleRB.rbInfo ファイルのコンテキストを変更することはできます。
.rbInfo ファイルのコンテンツの修正方法については、「PTC 提供のファイルをカスタマイズするためのベストプラクティス」を参照してください。
• 組織コンテキストでは、「ポリシー管理」ユーティリティを使用してアクセス制御規則を作成する場合にダイナミック役割を使用できます。これらのダイナミック役割は、特定の組織コンテキストから「役割」テーブルに表示されるように設定された役割のコンテキストチーム役割から成ります。
特定の組織コンテキストから「役割」テーブルに表示される役割の初期設定は、サイトコンテキストから継承されます。組織コンテキストでは、組織管理者が「役割」テーブルに表示されているコンテキストチーム役割を、追加および削除したり、表示/非表示にすることができます。このようにして、組織管理者は組織コンテキストから「ポリシー管理」ユーティリティを起動した場合に表示されるコンテキストチーム役割のセットを管理できます。
詳細については、#PolicyAdminDynamicRolesAbout/ExampleUserを参照してください。
• サイトコンテキストと組織コンテキストのどちらでも、ダイナミック役割は、アプリケーションコンテキスト内に作成可能なシステムグループを表す組織役割から成ります。組織役割は、コンテキストチーム内にメンバーを持つ組織を表します。アクセス制御規則を作成する際には、アクセス権を持つ組織の組織役割を使用できます。組織役割は自動的に作成されるので、組織役割を追加で作成することはできません。
詳細については、#PolicyAdminDynamicRolesAbout/ExampleWCを参照してください。
• アプリケーションコンテキストでは、「ポリシー管理」ユーティリティを使用してアクセス制御規則を作成する際に使用可能なダイナミック役割はコンテキストチーム役割から成り、これらの役割は「チーム」ページの「メンバー」テーブルに表示されます。アプリケーションコンテキストからアクセス制御規則を作成する場合、組織役割から成るダイナミック役割もあります。これらの組織役割は、コンテキストチーム内にメンバーを持つ各組織のコンテキスト内で作成されたシステムグループを表します。これらの組織役割から、アクセス権を持つ組織の組織役割を使用できます。
サイトおよび組織のコンテキストで確立されたダイナミック役割を使用して、一般的なアクセス制御規則を作成します。特定の役割または特定の組織のチームに追加されているすべてのユーザーのアプリケーションコンテキストによってこれらの規則は継承されます。
 |
ダイナミック役割に対して作成されたアクセス制御規則は、アプリケーションコンテキスト内に存在するドメインに属するオブジェクトのみに適用されます。ダイナミック役割は、コンテキストチームでのみ使用されるからです。サイトコンテキストと組織コンテキストにはコンテキストチームが関連付けられていません。このため、ダイナミック役割に作成されている規則は、これらのコンテキスト内のドメインに存在するオブジェクトには適用されません。
|
例: ユーザーが作成した役割
ある組織のすべての仕様ドキュメントを作成する人達のグループがあるとします。このグループに、すべてのドキュメントに対する読み取り、ダウンロード、コンテンツ修正、修正、移動によって作成、および作成の権限を付与します。「デモ組織」に対してこのタスクを実行するには、以下の手順に従います。
1. 「デモ組織」コンテキストの「役割」テーブルで、新しい「Spec Writer」役割を作成します。
2. 「デモ組織」コンテキストの「ユーティリティ」ページから「ポリシー管理」を起動します。
3. 「ドメイン」枠で、デフォルトドメインを選択します。
4. 「アクセス制御規則」タブで、「新規アクセス制御規則を作成」アイコン 
をクリックします。
をクリックします。5. 「新規アクセス制御規則」ウィンドウで、以下のオプションを選択します。
フィールド | 選択する値 | ||
|---|---|---|---|
タイプ | 「ドキュメント」を選択します。 | ||
状態 | 「すべて」を選択します。 | ||
参加者 | 「参加者」フィールドで、Spec Writer をサーチします。「参加者」フィールドに、「Spec Writer (コンテキストチーム役割 -デモ組織)」が表示されます。 | ||
アクセス許可 | 「権限あり」列で、「読み取り」、「ダウンロード」、「修正」、「コンテンツの修正」、「移動によって作成」、「作成」を選択します。
|
6. 「OK」をクリックして規則を作成します。
これで、「デモ組織」コンテキストに関連付けられた /Default ドメインに、「Spec Writer」ダイナミック役割の規則が作成されました。/Default ドメインの子のドメインはすべて、この規則を継承します。デフォルトでは、子のドメインには、非プライベートアプリケーションコンテキストと共有チームを作成するときに使用される PDM、プロジェクト、共有チームドメインが含まれています。したがって、「Spec Writer」役割を使用し、非プライベートアプリケーションコンテキストに対して、または共有チームとして作成されたチームを持つアプリケーションコンテキスト内の /Default ドメインは、「Spec Writer」アクセス制御規則を自動的に継承します。
ダイナミック役割が参加者として選択されているサイトコンテキストや組織コンテキスト内でアクセス制御規則を作成して管理することで、アクセス制御規則の管理を一元化することができます。アプリケーションコンテキスト内では、ダイナミック役割参加者は、それぞれに対応するコンテキストチーム役割と組織役割に関連付けられたシステムグループであるかのように処理されます。コンテキストチームのシステムグループに対するアクセス制御規則セットと対応するダイナミック役割に対するアクセス制御規則セットが存在する場合、特定のドメイン内で特定のタイプおよび状態に対するポリシーのアクセス制御リスト (ACL) を決定するときに、規則がマージされます。たとえば、次のように指定されているとします。
• 「Spec Writer」ダイナミック役割に対するアクセス制御規則が、上記の例での説明どおりに作成されている。
• 「Super Bike」プロジェクトが「デモ組織」の下に、デフォルトの「プロジェクトのメンバーのみ」以外のアクセスレベルで作成されており、標準の /Default ドメインを使用している。/Default ドメインのドメイン階層には、「デモ組織」に関連付けられた /Default ドメインが親として含まれています。このドメインは「Spec Writer」ダイナミック役割に対するアクセス制御規則が作成された場所です。
• 「Spec Writer」役割が「Super Bike」プロジェクトに追加されている。
「Super Bike」プロジェクト内の「Spec Writer」システムグループに対して生成された ACL には、「デモ組織」コンテキスト内で「Spec Writer」ダイナミック役割に対して作成されたポリシー規則を介して付与されたアクセス許可が含まれます。「Spec Writer」システムグループには、「Super Bike」プロジェクトで作成されるその他のポリシー規則やアドホック規則を追加することもできます。ほかにもポリシー規則が存在する場合は、すべてのポリシー規則 (「Spec Writer」ダイナミック役割に対する規則セットを含む) がマージされます。ドメインおよびドメイン階層の詳細については、ドメインとポリシーの管理を参照してください。
| | ダイナミック役割に対してサイトおよび組織のコンテキスト内で作成されたアクセス制御規則を効果的に使用するには、コンテキストの作成に使用する組織およびアプリケーションコンテキストのテンプレート内でアクセス制御規則セットをレビューする必要があります。ダイナミック役割に対する規則セットがテンプレート内で重複しないように、これらのテンプレートに対する変更内容を決定します。サンプルのダイナミック役割テンプレートをロードして、組織テンプレートを使用してダイナミック役割に対する多くのアクセス制御規則を設定することができます。これらの規則は、サンプルのダイナミック役割の製品、ライブラリ、プロジェクトのテンプレートから作成されたアプリケーションコンテキスト内で使用されます。ダイナミック役割テンプレートの例については、ダイナミック役割の使用を参照してください。 |
例: Windchill で作成された組織役割
営業と製造の 2 つの組織があるとします。さらに、ビーチアンブレラとスポーツアンブレラの 2 つの製品があるとします。次の表に示すように、この組織と製品には 6 人のユーザーが割り振られています。
ユーザー | 組織 | 製品 |
|---|---|---|
Pat | 営業 | スポーツアンブレラ |
Paul | 営業 | スポーツアンブレラ |
Pam | 営業 | ビーチアンブレラ |
Dawn | 製造 | ビーチアンブレラ |
Dave | 製造 | ビーチアンブレラ |
Debbie | 製造 | スポーツアンブレラ |
Windchill によって、以下に示す Sport Umbrella 製品のシステムグループとそれに対応する組織役割が作成されます。
グループ | メンバー | 組織役割 |
|---|---|---|
営業 | Pat、Paul | 営業 |
製造 | Debbie | 製造 |
Windchill によって、次に示すビーチアンブレラ製品のシステムグループとそれに対応する組織役割が作成されます。
グループ | メンバー | 組織役割 |
|---|---|---|
営業 | Pam | 営業 |
製造 | Dawn、Dave | 製造 |
"製造" ダイナミック役割が割り当てられているすべてのユーザーに部品オブジェクトに対する修正アクセス許可を付与するポリシーアクセス制御規則をサイトレベルで作成します。この規則は、ビーチアンブレラ製品内の部品が属するドメインによって継承されます。この結果、ビーチアンブレラ製品内の部品にアクセスした場合、組織の製造システムグループのメンバーであるのは Dawn と Dave なので、この 2 人にサイトレベルの規則が適用されます。同様に、スポーツアンブレラ製品内の部品にアクセスした場合、Debbie にサイトレベルの規則が適用されます。スポーツアンブレラ製品のチームメンバーとして Dave も追加された場合、Dave にも Debbie とともに "製造" ダイナミック役割が割り当てられるので、その製品の部品に関する規則が Dave に適用されます。
関連トピック