コラボレーションおよび再スケジュール関連APIへのロール・ベースのアクセス

Fusion Field Serviceでは、コラボレーションおよび再スケジュール関連APIの権限グループが導入され、APIアクセスの管理における制御と柔軟性が強化されました。 これらの権限グループは、セキュリティ・コンソール内のジョブ・ロールまたは職務ロールに割り当て、その後ユーザーに付与できます。

既存のロール ベースのセキュリティ フレームワークを補完することにより、管理者は高度にターゲットを絞ったアクセス権限を与え、必要な特定のAPI操作についてのみ統合およびユーザーに権限を与えることができます。 このアプローチにより、セキュリティが強化され、アクセス管理が簡素化されます。

この拡張機能の影響を受けるAPIは、次の表にリストされています。 OAuth 2.0を使用して認証するVisual Builder拡張機能を含む外部アプリケーションには、これらのAPIを正常に起動するために、適切なユーザー・ロールに割り当てられた関連権限グループが必要です。

コラボレーション関連APIの次の権限グループが追加されました:

コラボレーション関連APIの権限グループ

 

権限グループ名

権限グループ・コード

権限グループ摘要

1

フィールドサービスアドレス帳 RESTリソースの読み取り

oraCxFieldService_read_AddressBook_OraResource

Field Serviceコラボレーションのアドレス帳を返します。 アクセス権限を付与

GET /api/field-service/collaboration/v1/addressBook

2

フィールド・サービス・チャットRESTリソースの作成

oraCxFieldService_create_Chat_OraResource

フィールド・サービス・コラボレーションでチャットを作成します。 アクセス権限を付与

POST /api/field-service/collaboration/v1/chats

   

3

休暇フィールド・サービス・チャットRESTリソース

oraCxFieldService_leave_Chat_OraResource

フィールド・サービス・コラボレーションでのチャットの退出を許可します。 アクセス権限を付与

POST /api/field-service/collaboration/v1/chats/{chatId}/leave

4

フィールド・サービス・チャット・メッセージRESTリソースの読取り

oraCxFieldService_read_ChatMessage_OraResource

フィールド・サービス・コラボレーションのチャットからメッセージを返します。 アクセス権限を付与

GET /api/field-service/collaboration/v1/chats/{chatId}/messages

5

フィールド・サービス・チャット・メッセージRESTリソースの作成

oraCxFieldService_create_ChatMessage_OraResource

フィールド・サービス・コラボレーションでチャット・メッセージを作成します。 アクセス権限を付与

POST /api/field-service/collaboration/v1/chats/{chatId}/messages

6

フィールド・サービス・チャット参加者RESTリソースの読取り

oraCxFieldService_read_ChatParticipant_OraResource

フィールド・サービス・コラボレーションのチャットの参加者を返します。 アクセス権限を付与

GET /api/field-service/collaboration/v1/chats/{chatId}/participants

7

フィールド・サービス・チャット参加者RESTリソースの作成

oraCxFieldService_create_ChatParticipant_OraResource

フィールド・サービス・コラボレーションでのチャットへの参加者の招待を許可します。 アクセス権限を付与

POST /api/field-service/collaboration/v1/chats/{chatId}/participants/invite

次の権限グループが、再スケジュール中に使用されるアクティビティおよびリソースAPIに追加されました:

アクティビティおよびリソースAPIの権限グループ

 

権限グループ名

権限グループ・コード

権限グループ摘要

1

フィールド・サービス活動RESTリソースの移動

oraCxFieldService_move_Activity_OraResource

フィールド・サービス活動を移動します。 アクセス権限を付与

POST /rest/ofscCore/v1/activities/{activityId}/custom-actions/move

2

フィールド・サービス活動RESTリソースの取消

oraCxFieldService_cancel_Activity_OraResource

Field Service活動を取り消します。 アクセス権限を付与

POST /rest/ofscCore/v1/activities/{activityId}/custom-actions/cancel

3

フィールド・サービス・リソースRESTリソースの読取り

oraCxFieldService_read_Resource_OraResource

Field Serviceリソースを返します。 アクセス権限を付与

GET /rest/ofscCore/v1/resources/{resourceId}

25Dで導入された次の権限グループの名前が変更されました。

名前変更された権限グループ

 

旧権限グループ名

新規権限グループ名

権限グループ・コード

権限グループ摘要

1

read: フィールドサービス予約依存関係

フィールド・サービス予約依存関係RESTリソースの読取り

oraCxFieldService_read_bookingDependency_oraResource

予約されるアクティビティのパラメータを決定するためにshowBookingGrid APIファンクションで必要となるフィールドおよびプロパティのリストを返します。 アクセス権限を付与

GET /rest/ofscCapacity/v1/bookingFieldsDependencies

2

読み取り: フィールドサービス予約グリッド

フィールド・サービス予約グリッドRESTリソースの読取り

oraCxFieldService_read_bookingGrid_oraResource

要求の基準に基づいてアクティビティを予約するための予約グリッドを返します。 アクセス権限を付与

POST /rest/ofscCapacity/v1/showBookingGrid

  

3

read: フィールドサービスマッチングリソース

フィールド・サービス照合リソースRESTリソースの読取り

oraCxFieldService_read_matchingResource_oraResource

リクエストの条件に基づいてアクティビティを完了できるリソースのリストを返します。 アクセス権限を付与

POST /rest/ofscCore/v1/resources/custom-actions/findMatchingResources

4

作成: フィールドサービス活動

フィールド・サービス・アクティビティRESTリソースの作成

oraCxFieldService_create_activity_oraResource

フィールド・サービス活動を作成します。 アクセス権限を付与

POST /rest/ofscCore/v1/activities

5

update: フィールドサービス活動

フィールド・サービス活動RESTリソースの更新

oraCxFieldService_update_activity_oraResource

フィールド・サービス活動を更新します。 アクセス権限を付与

PATCH /rest/ofscCore/v1/activities/{activityId}

6

read: フィールドサービス活動

フィールド・サービス・アクティビティRESTリソースの読取り

oraCxFieldService_read_activity_oraResource

Field Service活動を返します。 アクセス権限を付与

GET /rest/ofscCore/v1/activities/{activityId}

および

GET /rest/ofscCore/v1/activities

権限グループは、ジョブ・ロールまたは職務ロールに割り当てられ、ユーザーに付与されます。 この構造により、既存のセキュリティ・フレームワークと連携しながら、APIアクセスを柔軟かつ正確に制御できます。

これらのAPIと統合され、ユーザー・アイデンティティ・コンテキストを必要とするサード・パーティ・アプリケーションの場合、権限グループをOracle Cloud Infrastructure Identity and Access Management (IAM)のOAuth 2.0認可コード構成とともに使用する必要があります。

認可コード付与タイプを使用したOAuthの構成

認可コード構成の場合、関係者は、ユーザー、アプリケーション、認可サーバーおよびリソース・サーバーです。 ユーザーが認可を受けるには、アプリケーションを認可サーバー(この場合はOracle Cloud Infrastructure Identity and Access Management (IAM))に登録する必要があります。 したがって、複数のユーザーがアクセスできる機密アプリケーションを作成する必要がありますが、OAuth資格証明を機密に保ち、保護できます。 アプリケーションでこれを行う方法を見てみましょう。

OAuthトークン発行者の名前は変更しないでください。

この手順では、構成に不可欠なフィールドとデータ入力ポイントについてのみ説明します。 ここに記載されていないUIの他のフィールドは無視してスキップできます。 関連する場合は、フィールドをスキップする手順が手順に含まれています。

クライアントおよびリソース・アプリケーションを認可サーバーに登録します。

  1. Oracle Cloud Infrastructure Identity and Access Management (IAM)に管理者としてサインインします。
  2. アイデンティティ・ドメインのリストから、「統合アプリケーション」をクリックし、「アプリケーションの追加」をクリックします。
  3. 「アプリケーションの追加」ダイアログ・ボックスで、「機密アプリケーション」を選択し、「ワークフローの起動」をクリックします。
  4. 「機密アプリケーションの追加」ページで、追加するアプリケーションの名前を入力します。
  5. 他のすべてのフィールドをスキップして、「次へ」をクリックします。
  6. 「Configure OAuth」セクションで、「Configure this application as a client now」を選択してクライアント構成設定に進みます。 クライアント・アプリケーションを作成しているため、このオプションのみが関連します。
  7. 「認可」セクションで、「認可コード」チェック・ボックスを選択して、付与タイプを指定します。 これは、このフローに必要な唯一の付与タイプです。
  8. 「リダイレクトURL」フィールドに、Fusion Applications RESTリソースへのアクセスを必要とするカスタム・アプリケーションのURLを入力します。
  9. 次のいくつかのフィールドをスキップして、「トークン発行ポリシー」セクションに移動します。
  10. 「認可済リソース」で、「特定」を選択して、特定のリソースへのアクセス権のみをユーザーに付与します。

リダイレクトURLパスは、アプリケーションのタイプによって異なる場合があります。 OAuth構成に使用されるリダイレクトURLに関する正確な情報は、カスタム・アプリケーションのドキュメントを参照してください。

製品のリソースを追加します。

  1. 「リソースの追加」チェック・ボックスを選択して、ユーザーがアクセスできるリソースを含めます。
  2. 「リソース」サブセクションで、「スコープの追加」をクリックします。
  3. 「スコープの追加」ダイアログ・ボックスで、「Oracle Fusion Field Service」を選択し、「追加」をクリックします。 リソースが追加されます。 アプリケーション管理者が定義したスコープは、次の形式で使用可能であることがわかります。

    <リソース・オーディエンス名><リソース・スコープ名>

    。スコープ"/"が追加されていることを確認します。

スコープによって、アプリケーションのリソースに対するアクセス権のレベルが決まります。 スコープは、リソース・アプリケーション管理者によって定義されます。 スコープを確認するには、ドメインに移動し、Oracle Fusion Field ServiceなどのOracleプロビジョニング済リソース・アプリケーションを探します。 サービスの詳細ページで、OAuth構成セクションに移動し、OAuth保護する必要があるアプリケーションAPIを構成してから、スコープを構成します。 スコープが表にリストされています。

「認可付与タイプ」では、コード「/」のデフォルトのスコープを選択する必要があります。

PostmanまたはcURLでは、オーディエンスとスコープを連結する必要があります。 例: urn:opc:resource:fusion:<env_id>:field-service-common/

<env_id>は、使用している環境の特定の環境IDです。

アプリケーションの作成を完了し、アプリケーションをアクティブ化します。

  1. リソースを追加した後、「次へ」をクリックし、「Web層ポリシー」セクションのデフォルト設定に進みます。 このページの設定を変更する必要はありません。
  2. 「終了」をクリックします。 確認ダイアログ・ボックスが表示され、自動生成された「クライアントID」および「クライアント・シークレット」の値が表示されます。
  3. 「閉じる」をクリックします。 作成したアプリケーション・ページが表示されます。
  4. 「アクティブ化」をクリックします。 アプリケーションをアクティブ化するための確認を求める確認メッセージが表示されます。
  5. 「アプリケーションのアクティブ化」をクリックします。 機密アプリケーションがアクティブ化され、使用できるようになります。

アクセス・トークンのリクエストにはクライアントIDおよびクライアント・シークレットの値が必要になるため、それらをノートにとります。

アクセス・トークンをリクエストします。 これを行うには、Postmanなどのクライアント・アプリケーションまたはcURLコマンドを使用します。 両方のオプションを見てみましょう。

アクセス・トークンをリクエストしています

Postmanの使用 cURLの使用
  1. Postmanで新しいリクエストを作成します。
  2. 「認可」タブで、認可タイプとしてOAuth 2.0を選択します。
  3. 「新規トークンの構成」セクションで、次のクライアント構成を入力します:
    1. トークン名: トークンの汎用名を入力します。
    2. Grant Type(付与タイプ): 付与タイプを「Authorization Code(認可コード)」に設定します。
    3. コールバックURL: アイデンティティ・ドメインに入力されたリダイレクトURLの値を入力します。
    4. 「Authorize using browser」チェック・ボックスを選択して、ブラウザを介したトークンの生成を認可します。 このオプションを選択すると、認証後にブラウザにアプリケーションURLに追加された認可コードが表示されることがわかります。
    5. 認証URL: /oauth2/v1/authorizeが付加されたIDCS URLが認証URLとして使用されます。 URLは、https://idcs-<idcs-id>.identity.oraclecloud.com/.well-known/idcs-configurationから取得できます。
    6. アクセス・トークンURL: /oauth2/v1/tokenが付加されたIDCS URLがアクセス・トークンURLとして使用されます。 URLは、https://idcs-<idcs-id>.identity.oraclecloud.com/.well-known/idcs-configurationから取得できます。
    7. クライアントID: 機密アプリケーションの作成後に自動生成されたクライアントID値を入力します。
    8. クライアント・シークレット: 機密アプリケーションの作成後に自動生成されたクライアント・シークレット値を入力します。
    9. 範囲: アイデンティティ・ドメインに定義されているスコープを示します。 例: urn:opc:resource:fusion:<env_id>:field-service-common/
    10. クライアント認証: 「基本認証ヘッダーとして送信」を選択します。
  4. 「新規アクセス・トークンの取得」をクリックします。 Postmanは、情報をアイデンティティ・ドメインに渡して認証し、アクセス・トークンを返します。
  1. ブラウザを開き、次のURLを使用して認可コードを取得するリクエストを送信します。

    https://<domainURL>/oauth2/v1/authorize?response_type=code&client_id=<clientid>&redirect_uri=<redirect url>&scope=urn%3Aopc%3Aresource%3Afusion%3A<env_id>%3Afield-service-common%2F


    ブラウザは、機密アプリケーションで指定された<リダイレクトURL>にリダイレクトされます。 URLパスでは、認可コードをパラメータとして検索できます。 手順3の後半で使用する認可コードをコピーします。
  2. コマンド・プロンプトを起動します。
  3. 次のcURLコマンドを入力し、山カッコ( < > )内のテキストを適切な値に置き換えます。

    curl -u <clientid:clientsecret> --basic -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" --request POST https://<domainURL>/oauth2/v1/token -d "grant_type=authorization_code&code=<authorization code>&redirect_uri=<redirect url>"

  4. d. 次のような形式でレスポンスを期待できます。

    Status: 200
    "access_token":"eyJ4NXQiOiI4Wk. . ." "token":"Bearer",
    "expires_in":3600

アクセス・トークンを使用してリソースにアクセスします。

Postmanで、「Use Token」をクリックしてトークンを使用し(「Token」フィールドを自動入力)、リソース・サーバーからリソースにアクセスします。 または、前のステップでcURLコマンドを使用した場合は、コマンド・プロンプトを続行してRESTリクエストを送信し、リソースへのアクセス権を取得できます。 リクエストは、次のように構成する必要があります:

curl -X GET -H "Content-Type:<as needed by your REST endpoint, such as, application/json>" -H "Authorization: Bearer <access_token>" "https://<REST API endpoint URL>"

AuthorizationヘッダーはBearerトークンに設定され、以前に取得したアクセス・トークンをその値として指定することに注意してください。

ビジネス上の利点

  • ロールで明示的に必要なAPI操作のみを公開することで、OAuthベースの統合の最小権限セキュリティを強化します。
  • 正確でスケーラブルなアクセス管理: 管理者は、広範なAPIアクセスを過剰にプロビジョニングすることなく、必要な正確な権限グループを割り当てることができます。
  • Oracle Fusion全体で連携されたセキュリティ・ガバナンス。Fusion Field Serviceでは、他のFusionアプリケーションで使用するのと同じ権限グループ・アプローチが使用されるようになり、ロール設計と継続的な保守が簡素化されます。

有効化および構成ステップ

この機能は、26Bのアップグレード後に自動的に使用可能になります。 アクセスを構成するには:

  1. Oracle Fusionでセキュリティ・コンソールを開きます。
  2. Field Service APIにアクセスする必要があるジョブ・ロールまたは職務ロールを見つけます。
  3. ロールの詳細を開き、「権限グループ」タブに切り替えます。
  4. 「追加」をクリックし、前述のいずれかまたは複数の権限グループを追加します。
  5. ロールを保存します。
  6. そのロールを、アクセスが必要なユーザーまたは統合アカウントに割り当てます。
  7. OAuth 2.0認証を使用してAPIコールをテストし、アクセスが期待どおりに機能していることを確認します。

ヒントと考慮事項

  • 最小権限のアクセス権を付与します。 呼び出される特定のコラボレーションおよび再スケジュールAPIに必要な権限グループのみを割り当て、必要以上に幅広いアクセスをバンドルしないようにします。
  • Fusionのみの依存関係。 この機能は、Fusion Identity and Access Management (IAM)およびFusion権限グループに依存しているため、Fusion Field Serviceでのみ使用できます。
  • 以前のリリースから名前が変更された権限グループのアカウント。 以前の構成からアップグレードする場合、アクセスの検証時に不一致が発生しないように、前に紹介した名前変更された権限グループを確認してください。

主なリソース

NA

アクセス要件

NA