承認スキームの定義
9 タスク
30 分
シナリオ
Front Stageの組織は、以下のセキュリティー要件を導入したいと考えています。
- 財務情報を見ることができるのは、セールスエグゼクティブとエグゼクティブマネージャーだけです。
- セールスエグゼクティブは、他のセールスエグゼクティブが作成したケースの作業を行えます。 ただし、10,000人を超える参加者がいるイベントの場合、セールスエグゼクティブは他のセールスエグゼクティブのケースにアクセスできません。
- イベントマネージャーは、自分に割り当てられたケースのみのワークを行えます。 しかし、イベントマネージャーのチームリードは、どのイベントマネージャーに割り当てられたケースについても、ワークを行えます。
- 設備コーディネーターは、自分に割り当てられたケースしか表示できず、ワークも行えません。
- エグゼクティブオフィサーは、ケースのライフサイクル全体を通してそのケースを表示でき、新しいカスタムレポートを作成できます。
Front Stageのイベント企画の組織体制は、次の図のようになっています。
以下の表は、チャレンジに必要なログイン情報をまとめたものです。
ロール | ユーザー名 | パスワード |
---|---|---|
Administrator | Admin@Booking | rules |
以下の表は、テスト用に用意されたサンプルユーザーの一覧です。
部門 | ロール | ユーザー名 | パスワード |
---|---|---|---|
Executives | Executive Officer and CEO | CEO@Booking | rules |
Sales | Sales Executive | SalesExecutive1@Booking | rules |
Sales | Sales Executive | SalesExecutive2@Booking | rules |
Facility | Facility Coordinator specialized in Parking | FacilityCoordinator1@Booking | rules |
Facility | Facility Coordinator specialized in Weather Preparation | FacilityCoordinator2@Booking | rules |
Facility | Facility Coordinator specialized in Weather Preparation and Parking | FacilityCoordinator3@Booking | rules |
EventManagers | Event Manager and Team Lead | EventManager1@Booking | rules |
EventManagers | Event Manager | EventManager2@Booking | rules |
EventManagers | Event Manager | EventManager3@Booking | rules |
要件を満たすための認証スキームを設計して実装してください。
- アクセスグループとロールを特定する。
- 上記の要件を実装する。
詳細なタスク
1 ソリューション詳細のレビュー
ユニットを作成する
以下のユニットを追加します。
組織ユニット |
---|
Executives |
EventManagers |
Facilities |
Sales |
オペレーターの作成とスキルの割り当て
スキルの作成/更新
CEO、TeamLead、Parking、Weatherの各スキルを、1(低)~10(高)のレベルで追加します。
オペレーターをManagerアクセスグループとデフォルトのアクセスグループに作成します。
ユーザー名 |
SalesExecutive1@Booking |
SalesExecutive2@Booking |
以下の各オペレーターについて、テーブルに定義されているオペレーターのスキルと評価を更新します。
ユーザー名 | スキルと評価 |
---|---|
CEO@Booking | CEO(5)、TeamLead(5) |
FacilityCoordinator1@Booking | Parking(5) |
FacilityCoordinator2@Booking | Weather(5) |
FacilityCoordinator3@Booking | Parking(5)、Weather(5) |
EventManager1@Booking | TeamLead(5) |
アクセスグループとロールの割り当て
システムで生成されるロール
New Applicationウィザードで、Booking:Administrator / Booking:Authorsロール、およびBooking:UserとBooking:Managerの2つのユーザーロールが作成されます。
Booking:Userロールはアプリケーションの任意のケースを開き、任意の割り当てを実行できます。 Booking:Managerロールは、レポート、委任されたルール、ワークグループを作成および更新できます。
Bookingアクセスグループの確認
アクセス権は部門に基づいて付与されるため、部門ごとにアクセスグループとロールを作成して構成します。
Event Bookingアプリケーションが最初に開発されたときに、以下のアクセスグループが作成されている場合があります。 その場合、アクセスグループ名がPegaの命名規則に準拠していないことがあります。 必要に応じて、次の表の情報を使って名前を変更します。
POCアクセスグループ名 | 新しいアクセスグループ名 |
---|---|
Booking:FacilityCoordinator | Booking:Facilities |
既存のアクセスグループの名前を変更するには、以下の手順を実行します。
- 演習システムから、Admin@Bookingとしてログオンします。
- Dev Studioメニューで、System > Configure > Refactor > Rulesとクリックし、Search/Replace a Stringウィザードを開きます。
- 「Search/Replace a String」を選択します。
- 「Original String Value」フィールドに、「Booking:FacilityCoordinator」と入力します。
- 「New String Value」フィールドに、「Booking:Facilities」と入力します。
- 「Limit search to RuleSets in my RuleSet list?」を「No」に設定します。
- 「Select RuleSet Scope」セクションで、「Booking 」ルールセットを選択します。
- 「Next」をクリックすると、Records with OccurrencesとOccurrences Foundのレコード数が掲載されているレポートが表示されます。
- 「Next」をクリックすると、Selectable rules available which have references to the class being refactoredが掲載されているレポートが表示されます。
- レポートのヘッダーで、「Rule Type」チェックボックスにチェックを入れると、すべてのレコードが選択されます。
- オプション:「Export to Excel」で、影響のあるレコードのログを保存できます。
- 「Finish」を選択すると、リファクタリングプロセスの完了を示すメッセージが表示されます。また、リファクタリングされなかったルールとデータのインスタンスのレポートが表示されます。
- オプション:「Export Page to Excel」または「Review Log」。
- 「Done」をクリックします。
- 「Booking:Facilities」アクセスグループで、「Save as」をクリックして、さらに以下の3つのアクセスグループを作成します。
アクセスグループ Booking:Executives Booking:Sales Booking:EventManagers
Event Bookingロールの作成
権限や特権は部門に基づいて付与されるため、部門ごとに以下のロールを作成します。 ロールはEventルールセットに保存します。
ロール名識別子 | Label | 依存先 |
---|---|---|
Booking:Executive | Executive | PegaRULES:WorkMgr4 |
Booking:SalesExecutive | Sales Executive | PegaRULES:WorkMgr4 |
Booking:EventManager | Event Manager | PegaRULES:WorkMgr4 |
Booking:FacilityCoordinator | Facility Coordinator | PegaRULES:WorkMgr4 |
ロールのEvent Bookingアクセスグループへの割り当て
以下のロールを、名前を変更したアクセスグループに割り当てます。 他のすべてのロールは削除します。
アクセスグループ | ロール |
---|---|
Booking:Executives | Booking:Executive、Booking:Manager、Booking:User、PegaRULES:PegaAPI |
Booking:Sales | Booking:SalesExecutive、Booking:User、PegaRULES:PegaAPI |
Booking:Facilities | Booking:FacilityCoordinator、Booking:User、PegaRULES:PegaAPI |
Booking:EventManagers | Booking:EventManager、Booking:User、PegaRULES:PegaAPI |
Event Bookingワークグループの作成
ワークは部門ごとに割り当てられることが多いため、以下のワークグループを作成します。 ワークグループは、Eventルールセットに保存します。 また、Admin@Booking、Author@Bookingという名前の権限を持つマネージャーを各ワークグループに追加します。
ワークグループの識別子 | 説明 | マネージャー | デフォルトのワークバスケット |
---|---|---|---|
Executives@FSG | FSG Executives | CEO@Booking | Booking:Executives |
Sales@FSG | FSG Sales | SalesExecutive1@Booking | Booking:Sales |
EventManagers@FSG | FSG Event Managers | EventManager1@Booking | Booking:EventManagers |
Facilities@FSG | FSG Facility Coordinators | FacilityCoordinator1@Booking | Booking:Facilities |
Event Bookingワークバスケットの作成/更新
以下のワークバスケットを作成または更新します。
ワークバスケット | 組織ユニット | ワークグループ | ロール |
---|---|---|---|
Booking:Executives | Executives | Executives@FSG | Booking:Executive |
Booking:EventManagers | EventManagers | EventManagers@FSG | Booking:EventManager |
Booking:Facilities | Facilities | Facilities@FSG | Booking:FacilityCoordinator |
Booking:Sales | Sales | Sales@FSG | Booking:SalesExecutive |
オペレーターへの更新
以下の各オペレーターについて、デフォルトのアクセスグループ、ワークグループ、ユニットを更新します。
オペレーターID | デフォルトのワークグループ | デフォルトのアクセスグループ | ユニット |
---|---|---|---|
CEO@Booking | Executives@FSG | Booking:Executives | Executives |
SalesExecutive1@Booking | Sales@FSG | Booking:Sales | Sales |
SalesExecutive2@Booking | Sales@FSG | Booking:Sales | Sales |
FacilityCoordinator1@Booking | Facilities@FSG | Booking:Facilities | Facilities |
FacilityCoordinator2@Booking | Facilities@FSG | Booking:Facilities | Facilities |
FacilityCoordinator3@Booking | Facilities@FSG | Booking:Facilities | Facilities |
EventManager1@Booking | EventManagers@FSG | Booking:EventManagers | EventManagers |
EventManager2@Booking | EventManagers@FSG | Booking:EventManagers | EventManagers |
EventManager3@Booking | EventManagers@FSG | Booking:EventManagers | EventManagers |
2 エグゼクティブオフィサーがEvent Bookingライフサイクルを通してケースにアクセスするための許可
エグゼクティブオフィサーがライフサイクル全体を通してケースを表示できるようにするには、エグゼクティブオフィサーのオペレーターIDを編集し、以下のステップを実行します。
- CEO@BookingオペレーターIDレコードを開きます。
- 「Work」タブの「Routing」セクションで、以下の手順に従います。
- Work group、Executives@FSG、Sales@FSG、EventManagers@FSG、Facilities@FSGを追加します。
- デフォルトとして、Executives@FSGを指定します。 完了すると、セクションは以下の画像のようになります。
- Booking:Executivesアクセスグループを開きます。
-
「Definition」タブで利用可能なロール、Booking:Executive、Booking:SalesExecutive、Booking:EventManager、Booking:FacilityCoordinator、Booking:Manager、Booking:User、PegaRULES:PegaAPIを追加します。
完了すると、アクセスグループは以下の画像のようになります。
-
Executiveアクセスグループを保存します。
Event Bookingケースタイプのルーティングの更新
- ケースエクスプローラーから、Event Bookingケースタイプを開きます。
- Manage Eventステージで、Hotelsプロセスを開きます。
- 「Search Hotels」割り当てプロパティパネルを開き、次の画像のように、「Specific user」がEventManager に設定されていることを確認します。
Parkingケースタイプのルーティングの更新
- ケースエクスプローラーから、Parkingケースタイプを開きます。
- Search Parking ステージで、Search Parkingプロセスを開きます。
- 「SearchParkingLocations 」割り当てプロパティパネルを開き、以下の設定を確認します。
フィールド 設定 Route to Custom Assignment type Worklist Router ToLeveledGroup ワークグループ Facilities@FSG Skill Parking - Reporting ステージで、Reportingプロセスを開きます。
- 「Enter Number of Cars Parked」割り当てプロパティパネルを開き、以下の設定を確認します。
フィールド 設定 Route to Custom Assignment type Worklist Router ToWorkParty Party FacilityCoordinator - Search Parking ステージで、Search Parkingプロセスを開きます。
- 「SearchParkingLocations」フローアクションを開きます。
- フローアクションの「Action」タブにある「Post-processing」セクションで、以下の情報を入力します。
フィールド 設定 Run activity addWorkObjectParty PartyRole parameter FacilityCoordinator PartyClass parameter Data-Party-Operator PartyModel parameter CurrentOperator 完了すると、Run activity の設定は次の画像のようになります。
Weatherケースタイプのルーティングの更新
-
Preparation ステージのForecast プロセスで、「Track Preparation 」割り当てプロパティパネルを開き、以下の情報で構成されていることを確認します。
フィールド 設定 Route to Custom Assignment type Worklist Router ToLeveledGroup ワークグループ Facilities@FSG Skill Weather -
Resolve ステージのResolve Weather Prep プロセスで、「Teardown」割り当てプロパティパネルを開き、以下の情報で構成されていることを確認します。
フィールド 設定 Route to Custom Assignment type Worklist Router ToLeveledGroup ワークグループ Facilities@FSG Skill Weather
3 属性ベースのアクセス制御セキュリティーの有効化
属性ベースのアクセス制御(ABAC)を使用して、認証スキームを構成します。
ABACを使用して財務情報へのアクセスを制限する
シナリオに説明されているように財務情報へのアクセスを制限するためには、次のようにします。
- SalesExecutiveとExecutiveOfficerというAccess Whenレコードを作成し、オペレーターがセールスエグゼクティブまたはエグゼクティブオフィサーのアクセスグループに属しているかどうかをテストします。
- 新しいAccess Whenレコードを参照するSalesAndExecutivesアクセス制御ポリシー条件を作成します。
- 新しいアクセス制御ポリシーの条件を参照するRestrictFinancialInformationプロパティ読み取りアクセス制御ポリシーを作成します。 SalesAndExecutivesアクセス制御ポリシーの条件で定義されたユーザーは、.Profit、.Totalcost、.TotalPrice、.DiscountPercentage、.PricingDisplay.EventPrice、.PricingDisplay.HotelServicePriceの各プロパティを表示できます。
Sales ExecutiveとExecutiveOfficerというAccess Whenレコードを作成する
- Records Explorerで、「Security」カテゴリーを展開します。
- 「Access When」レコードタイプを選択します。
- 「Create」をクリックします。
- New Record画面に、以下の情報を入力します。
フィールド 設定 Label Sales Executive Apply to FSG-Booking-Work-BookEvent Add to ruleset Event - 「Create and open」をクリックして、新しいAccess Whenレコードを作成します。
- 「Conditions」タブに、次のWhen式を入力します。
pxThread.pxCurrentAccessGroup = "Booking:Sales".
完了すると、「Conditions」タブは、次の画像のようになります。
- 新しいSalesExecutive Access Whenレコードを保存します。
- 1~4の手順を繰り返します。
- New Record画面に、以下の情報を入力します。
フィールド 設定 Label Executive Officer Apply to FSG-Booking-Work-BookEvent Add to ruleset Event - 「Create and open」をクリックして、新しいAccess Whenレコードを作成します。
- 「Conditions」タブに、次のWhen式を入力します。
pxThread.pxCurrentAccessGroup = "Booking:Executives"
完了すると、「Conditions」タブは、次の画像のようになります。
- 新しいExecutiveOfficer Access Whenレコードを保存します。
補足: BookingAdministrator Access Whenレコードを、pxThread.pxCurrentAccessGroup = "Booking:Authors"で作成するか、式の中で必要なアクセスグループを指定します。これにより、引き続きAdmin@Bookingまたはその他の編集オペレーター(管理者)として制限のあるプロパティの編集と表示を引き続き行えます。
SalesAndExecutivesアクセス制御ポリシーの条件の作成
- Records Explorerを開きます。
- 「Security」カテゴリーを展開します。
- 「Access Control Policy Condition」レコードタイプを選択します。
- 「Create」をクリックします。
-
New Record画面に、以下の情報を入力します。
フィールド 設定 Label Sales And Executives Apply to FSG-Booking-Work-BookEvent Add to ruleset Event - 「Create and open」をクリックして、新しいSalesAndExecutivesアクセス制御ポリシーの条件を作成します。
- アクセス制御ポリシーの条件の「Definition」タブの「Conditional Logic」セクションで、作成したAccess Whenレコード、ExecutiveOfficerとSalesExecutiveを入力します。
- オプション:「icy Conditions」セクションで、常にfalseを返す条件を指定し、Access Whenルールのいずれかがtrueと評価された場合にのみアクセスが許可されるようにします。
- 新しいSalesAndExecutivesアクセス制御ポリシーの条件のレコードを保存します。
補足: BookingAdministrator Access When 条件を追加し、引き続きAdmin@Bookingとして制限のあるプロパティの編集と表示を行えるようにします。
完了すると、「Definition」タブは、次の画像のようになります。
RestrictFinancialInformationアクセス制御ポリシーの作成
- Records Explorerを開きます。
- 「Security」カテゴリーを展開します。
- 「Access Control Policy」レコードタイプを選択します。
- 「Create」をクリックします。
-
New Record画面に、以下の情報を入力します。
フィールド 設定 Label Restrict Financial Information Action PropertyRead Apply to FSG-Booking-Work-BookEvent Add to ruleset Booking - 「Create and open」をクリックして、新しいRestrictFinancialInformationアクセス制御ポリシーを作成します。
- アクセス制御ポリシーの「Definition」タブの「Permit access if」フィールドに、作成したSalesAndExecutivesアクセス制御ポリシーの条件を入力します。
- .Profit、.Totalcost、.TotalPrice、.DiscountPercentage、.PricingDisplay.EventPrice、.PricingDisplay.HotelServicePriceの各プロパティを追加します。 すべてのプロパティで、「Restriction Method」に「Mask with N digits」を使用します。
完了すると、「Definition」タブは、次の画像のようになります。
- 新しいRestrictFinancialInformationアクセス制御ポリシーレコードを保存します。
4 ABACを使用してEvent Bookingケースへのアクセスを制限する
シナリオに沿ってEvent Bookingケースへのアクセスを制限するには、次のようにします。
- オペレーターがEventManagerアクセスグループに含まれているかどうかをテストするために、EventManager Access Whenレコードを作成します。
- オペレーターがEventManagerアクセスグループに含まれており、Team Leadスキルを持っているかどうかをテストするために、TeamLeadEventManager Access Whenレコードを作成します。
- アクセス制御ポリシーの条件で使用するプロパティが、検索やレポートで使用されるように構成します。
- 新しいAccess Whenレコードを参照し、ポリシーの条件とアクセス許可が含まれるHasEventReadAccessアクセス制御ポリシーの条件を作成します。
- 新しいアクセス制御ポリシーの条件を参照するRestrictEventAccessアクセス制御ポリシーを作成します。
EventManager Access WhenレコードとTeamLeadEventManager Access Whenレコードを作成する
オペレーターがEventManagersアクセスグループに含まれているかどうかをテストするために、次の手順に従って、EventManager Access Whenレコードを作成します。
- Records Explorerで、「Security」カテゴリーを展開します。
- 「Access When」レコードタイプを選択します。
- 「Create」をクリックします。
- New Rule画面に、以下の情報を入力します。
フィールド 設定 Label Event Manager Apply to FSG-Booking-Work-BookEvent Add to ruleset Event - 「Create and open」をクリックして、EventManager Access Whenレコードを作成します。
-
「Conditions 」タブに、次のWhen式を入力します。
pxThread.pxCurrentAccessGroup = "Booking:EventManagers"
完了すると、「Conditions」タブは、次の画像のようになります。
- 新しいEventManager Access Whenレコードを保存します。
オペレーターがEventManagersアクセスグループに含まれていて、TeamLeadスキルを持っているかどうかをテストするために、次の手順に従って、TeamLeadEventManager Access Whenレコードを作成します。
- Records Explorerで、「Security」カテゴリーを展開します。
- 「Access When」レコードタイプを選択します。
- 「Create」をクリックします。
- New Rule画面に、以下の情報を入力します。
フィールド 設定 Label Team Lead Event Manager Apply to FSG-Booking-Work-BookEvent Add to ruleset Event - 「Create and open」をクリックして、amleadEventManager Access Whenレコードを作成します。
-
「Conditions」タブで、次のWhen式を使用します。
pxThread.pxCurrentAccessGroup = "Booking:EventManagers" AND function @IsInPageList("TeamLead","pySkillName",OperatorID.pySkills)完了すると、「Conditions」タブは、次の画像のようになります。
- 新しいTeamLeadEventManager Access Whenレコードを保存します。
アクセス制御ポリシーの条件となるプロパティの構成
新しいHasEventReadAccessアクセス制御ポリシーの条件を設定する前に、以下の操作を行います。
- 新しいProperty EventManagerを作成して値を割り当てる
- EventManagerプロパティとNumAttendeesプロパティをレポート用に最適化します。
- NumAttendeesをフィルタリング可能な検索プロパティにします。
新しいProperty EventManagerを作成して値を割り当てる
- 新しいTextタイプのプロパティEventManagerをFSG-Booking-Work-BookEventクラスに作成します。
- 新しいデータトランスフォーム名PopulateEventManagerを作成し、次の画像のように、.pyAssignedOperatorからEventManagerに入力します。
- 次の図のように、後処理でデータトランスフォームPopulateEventManager を追加して、フローアクションManagerAssignmentを更新します。
EventManagerプロパティとNumberOfAttendeeプロパティの最適化
App Explorerで次のプロパティを右クリックし、 Optimize for reportingを選択します。
- (FSG-Booking-Work-BookEvent) EventManager
- (FSG-Booking-Work-BookEvent) NumberOfAttendees
NumAttendeesをフィルタリング可能な検索プロパティにする
- Dev Studioのヘッダーで、「Create」>「SysAdmin」>「Custom Search Properties」の順にクリックします。
- 「Class Name」フィールドに、「FSG-Booking-Work-BookEvent」と入力します。
- 「Create and open」をクリックします。
- レコードヘッダーのAssociated RuleSetをEventに設定します。
- 「Use dedicated index 」チェックボックスにチェックを入れます。
- Rule画面を保存します。
- Click on Create dedicated index ボタンをクリックします。このボタンはRule画面を保存するときにのみ表示されます。
- カスタム検索プロパティの「Definition」タブで、「FSG-Booking-Work-BookEvent」プロパティを選択します。
- 「Add」をクリックして、「Property Configurations」ダイアログボックスを開きます。
- 「Property Configurations」ダイアログボックスで、「NumAttendees」プロパティを選択します。
- 「Submit」をクリックすると、更新内容が保存され、ダイアログが閉じます。
-
FSG-Booking-Work-BookEventを展開します。
-
「Include in search results」チェックボックスにチェックを入れます。
完了すると、Custome Search Propertiesレコードの「Definition」タブは、次の画像のようになります。
- FSG-Booking-Work-BookEvent • pySearch Custome Search Propertiesレコードを保存します。
5 HasEventReadAccessアクセス制御ポリシーの条件の構成
- Records Explorerで、「Security」カテゴリーを展開します。
- 「Access Control Policy Condition」レコードタイプを選択します。
- 「Create」をクリックします。
- New Rule画面に、以下の情報を入力します。
フィールド 設定 Label Has Event Read Access Apply to FSG-Booking-Work-BookEvent Add to ruleset Event - 「Create and open」をクリックして、HasEventReadAccessアクセス制御ポリシーの条件を作成します。
- 「Pages & Classes」タブで、Data-Admin-Operator-IDクラスを使用して、Page name OperatorIDを追加します。
- 「Definition 」タブで、次のようにします。
- 「Conditional Logic 」セクションで、条件として作成したTeamLeadEventManager、EventManager、SalesExecutive access whenレコードを追加します。
-
「Policy Conditions」セクションで、次の条件を指定します。 条件Dは、常にtrueを返します。これは、いずれのAccess Whenルールもtrueと評価されない場合にアクセスが拒否されないようにするためです。
条件 列のソース 関係 値 A .NumberOfAttendees is less than 10000 B .pxCreateOperator Is equal OperatorID.pyUserIdentifier C .EventManager Is equal OperatorID.pyUserIdentifier D .pxCreateOperator Is not null 完了すると、アクセス制御ポリシーの条件レコードの「Definition」タブは、次の画像のようになります。
- HasEventReadAccessアクセス制御ポリシーの条件を保存します。
RestrictEventAccessアクセス制御ポリシーの作成
Event Bookingケースタイプで、Readアクションを持つアクセス制御ポリシーを作成し、Event Bookingケースへのアクセスを制限します。
- Records Explorerを開きます。
- 「Security」カテゴリーを展開します。
- 「Access Control Policy」レコードタイプを選択します。
- 「Create」をクリックします。
- New Rule画面に、以下の情報を入力します。
フィールド 設定 Label Restrict Event Access Apply to FSG-Booking-Work-BookEvent Add to ruleset Event Action Read - 「Create and open」をクリックして、新しいictEventAccessアクセス制御ポリシーを開きます。
-
「Permit access if」フィールドに、作成したHasEventReadAccessアクセス制御ポリシーの条件を入力します。
完了すると、Read • RestrictEventAccessアクセス制御ポリシーは次の画像のようになります。
- RestrictEventAccessアクセス制御ポリシーを保存します。
Facilityケースへのアクセス制限
ロールベースのアクセス制御を使用して、Facilityケースを開くことを制限できます。 これには、Facilityケースタイプを開き、Access Managerを使用して、PerformにNo Accessを構成します。
6 作業の確認
- Admin@Bookingでログアウトします。
- ユーザー@Bookingでログインし、新しいEvent Bookingケースを作成します。 .Profit、.Totalcost、.TotalPrice、.DiscountPercentageの各フィールドはすべてマスクされており、読み取り専用です。
- ログアウトします。
-
SalesExecutive1@Bookingでログインし、新しいEvent Bookingケースを作成します。 .Profit、.Totalcost、.TotalPrice、.DiscountPercentage、.PricingDisplay.EventPrice、.PricingDisplay.HotelServicePriceの各フィールドはマスクされておらず、編集できます。
- 次の2つのEvent Bookingケースを作成します。
- 参加者が1万人未満のケース
- 参加者が1万人を超えるケース
どちらの場合も、Customer Approvalステップは実行しません。
- ログアウトします。
- SalesExecutive2@Bookingとしてログインしてからケースマネージャーポータルに切り替えて、次のようにします。
- Dashboardで、「Team members」セクションの「Sales Executive 1」を選択して、SalesExecutive1@Bookingのオープンケースを表示します。
- 参加者が1万人未満のケースでは、「Customer Approval」を選択します。 これにより、ケースのワークを行えます。
- 参加者が1万人を超えるケースでは、「Customer Approval」を選択します。 「Access Control Policy denied access for class FSG-Booking-Work-BookEvent and action Open」というエラーメッセージが表示されます。
- ログアウトします。
- EventManager2@Bookingとしてログインします。 ケースマネージャーポータルに切り替えて、次のようにします。
- Dashboardで、「Team members」セクションの「Event Manager 1」を選択して、EventManager1@Bookingのオープンケースを表示します。
- リストされているすべてのケースに、「Approve Assignment」を選択します。 その結果、「Access Control Policy denied access for class FSG-Booking-Work-BookEvent and action Open」という内容のエラーメッセージが表示されるはずです。
- ログアウトします。
- EventManager1@Bookingとしてログインします。 ケースマネージャーポータルに切り替えて、次のようにします。
- Dashboardで、「Team members」セクションの「Event Manager 2」を選択して、EventManager2@Bookingのオープンケースを表示します。
- リストされているすべてのケースに、「Approve Assignment」を選択します。 これにより、選択したケースの作業を行えます。
7 代替アプローチ
次に示すのは代替アプローチです。 これらを開発する必要はありません。 ロールベースのアクセスコントロール(RBAC)を使用してEvent Bookingケースへのアクセスを制限したり、ABACを使用して設備の割り当てへのアクセスを制限したりする方法を試してみたい場合は、ここに記載されている詳細なインストラクションを参考にしてください。
財務情報へのアクセスの制限
財務情報へのアクセスを制限するための代替アプローチはありません。
RBACを使用したEventケースへのアクセス制限
イベントのロールを作成し、適切なアクセスグループに追加します。 Access Managerを使用して、Access of Role to Objectレコードを作成し、制限を定義するAccess Whenレコードを設定します。
Event Bookingケースへのアクセス制限:RBACとABACの比較
次の表は、それぞれの方法の長所と短所を示しています。
設計 | 長所 | 短所 |
---|---|---|
属性ベースのアクセス制御 | 構成が簡単 | Access Managerに表示されない |
ロールベースのアクセス制御 | Access Managerに表示される | 追加のロールが必要 |
ABACを使用したFacilitiesへの割り当ての制限(任意)
- Assign-Worklistクラス用に、FacilityCoordinatorというAccess When条件を、Eventルールセットに作成します。
-
「Conditions」タブで、次のWhen式を使用します。
pxThread.pxCurrentAccessGroup = "Booking:Facilities"
「Conditions」タブは、次の画像のようになります。
- Assign-Worklistクラス用に、新しいFacilityCaseAssignedToMeアクセス制御ポリシーの条件を、Eventルールセットに作成します。
- アクセス制御ポリシーの条件レコードの「Pages & Classes」タブで、「Page name」フィールドにOperatorIDを入力し、「Class」フィールドに「Data-Admin-Operator-ID」を入力します。
-
「Definition」タブで、ユーザーが設備コーディネーターかどうかを確認し、ケースがそのユーザーに割り当てられているかどうかを確認します。 その他のユーザーには、アクセスを付与します。
「Definition」タブの構成は、次の画像のようになります。 - Assign-Worklistクラス用に、RestrictFacilityCasesアクセス制御ポリシーを、EventBookingルールセットに作成します。 「Action」を「Read」に設定し、他の設備コーディネーターが割り当てを開いて作業しないようにします。
-
「Permit access if」フィールドに、作成したFacilityCaseAssignedToMeアクセス制御ポリシーの条件を入力します。
アクセス制御ポリシーは次の画像のようになります。
Facilities割り当てへのアクセス制限:RBACとABACの比較
次の表は、それぞれの方法の長所と短所を示しています。
設計 | 長所 | 短所 |
---|---|---|
属性ベースのアクセス制御 | 構成が簡単 | Access Managerに表示されない |
ロールベースのアクセス制御 | Access Managerに表示される | 追加のロールが必要 |
8 代替オプションのレビュー
次に示すのは代替アプローチです。 これらを開発する必要はありません。 ロールベースのアクセスコントロール(RBAC)を使用してEvent Bookingケースへのアクセスを制限したり、ABACを使用して設備の割り当てへのアクセスを制限したりする方法を試してみたい場合は、ここに記載されている詳細なインストラクションを参考にしてください。
財務情報へのアクセスの制限
財務情報へのアクセスを制限するための代替アプローチはありません。
RBACを使用したEventケースへのアクセス制限
イベントのロールを作成し、適切なアクセスグループに追加します。 Access Managerを使用して、Access of Role to Objectレコードを作成し、制限を定義するAccess Whenレコードを設定します。
Event Bookingケースへのアクセス制限:RBACとABACの比較
次の表は、それぞれの方法の長所と短所を示しています。
設計 | 長所 | 短所 |
---|---|---|
属性ベースのアクセス制御 | 構成が簡単 | Access Managerに表示されない |
ロールベースのアクセス制御 | Access Managerに表示される | 追加のロールが必要 |
ABACを使用したFacilitiesへの割り当ての制限(任意)
- Assign-Worklistクラス用に、FacilityCoordinatorというAccess When条件を、Eventルールセットに作成します。
-
「Conditions」タブで、次のWhen式を使用します。
pxThread.pxCurrentAccessGroup = "Booking:Facilities"
「Conditions」タブは、次の画像のようになります。
- Assign-Worklistクラス用に、新しいFacilityCaseAssignedToMeアクセス制御ポリシーの条件を、Eventルールセットに作成します。
- アクセス制御ポリシーの条件レコードの「Pages & Classes」タブで、「Page name」フィールドにOperatorIDを入力し、「Class」フィールドに「Data-Admin-Operator-ID」を入力します。
-
「Definition」タブで、ユーザーが設備コーディネーターかどうかを確認し、ケースがそのユーザーに割り当てられているかどうかを確認します。 その他のユーザーには、アクセスを付与します。
「Definition」タブの構成は、次の画像のようになります。 - Assign-Worklistクラス用に、RestrictFacilityCasesアクセス制御ポリシーを、EventBookingルールセットに作成します。 「Action」を「Read」に設定し、他の設備コーディネーターが割り当てを開いて作業しないようにします。
-
「Permit access if」フィールドに、作成したFacilityCaseAssignedToMeアクセス制御ポリシーの条件を入力します。
アクセス制御ポリシーは次の画像のようになります。
Facilities割り当てへのアクセス制限:RBACとABACの比較
次の表は、それぞれの方法の長所と短所を示しています。
設計 | 長所 | 短所 |
---|---|---|
属性ベースのアクセス制御 | 構成が簡単 | Access Managerに表示されない |
ロールベースのアクセス制御 | Access Managerに表示される | 追加のロールが必要 |
9 ソリューションのレビュー
本コースのApplication designミッションで提供されるソリューションRAP(Rule Admin Product)ファイルには、Front Stageシナリオ要件で指定されたすべての権限要件の完全な実装は含まれていません。 指定されているすべての要件は、RBACとABACを組み合わせることで実装できます。
実装されたソリューションを確認するには、Admin@Bookingオペレーターとしてログインしている状態で、アプリケーションをBooking Authorizationに切り替えます。
このモジュールは、下記のミッションにも含まれています。
If you are having problems with your training, please review the Pega Academy Support FAQs.