ユーザーの Calling 動作とコネクタ エンタイトルメントを確認する

1. 担当パートナーの資格情報を使用して [Help Desk (ヘルプ デスク)] (https://admin.webex.com/helpdesk) にサインインします。

2. ユーザーを検索します。

3. ユーザーをクリックして、[Calling 動作] エントリを確認します。 「Webex での Calling」である必要があります。

   

4. ユーザー名をクリックして、[ユーザーの詳細] 画面を開きます。

5. 下にスクロールして [ entitlements] セクションを見つけ、[ broadworks-connector] が含まれていることを確認します。

   

   BroadWorks 版 Webex ユーザーは、[ bc-sp-standard] エンタイトルメントは不要です（BroadWorks 版 Webex を使用する予定がない場合）。 これは、Cisco が管理するクラウド コーリング サービスを通じた Webex アプリ コーリングである「Webex Calling (Broadcloud)」のエンタイトルメントです。

組織の Calling 動作を確認する

1. 担当パートナーの資格情報を使用して [Help Desk (ヘルプ デスク)] (https://admin.webex.com/helpdesk) にサインインします。

2. 組織を検索します。

3. 組織をクリックして、[Calling 動作] エントリを確認します。 「Webex での Calling」である必要があります。

   

ユーザーはクライアントと対話し、クライアントは Webex サービスと対話します。

• ユーザーは Webex アプリに電子メール アドレスを提供します (図の 1)。

• CI はこのユーザーをリダイレクトして、BroadWorks パスワード (UAP 経由) を入力することを知っています (図の 2)。

• IDP プロキシは XSP の Xsi インターフェイスにプロファイル取得リクエストを送信します。

tomcat access_log の場合:

• Webex から Xsi-Actions インターフェイス (図の 2.1) に向かって、サブスクライバ プロファイルの GET 要求を検索します。 Webex ユーザー ID を持っています。 例:

  GET /com.broadsoft.xsi-actions/v2.0/user/webexuserid@example.com/profile

XsiActionsLog の場合:

• Webex からのプロファイル GET 要求を検索します (図の 2.1)。 Webex ユーザー ID を持っています。 例:

  GET /com.broadsoft.xsi-actions/v2.0/user/webexuserid@example.com/profile

  ヘッダに含まれるのは、 authorization: Basic および user-agent: broadworksTeamsClient

• XSP は、BroadWorks に対して OCI-P Basic 認証を行います (AuthenticationVerifyRequest および AuthenticationVerifyResponse、Xsi 経由で Basic 認証を行う他のアプリケーションと同様)。また、UserGetRequest および ServiceProviderGetRequest を使ってサブスクライバ情報を収集します。

• Webex への Xsi 応答には XML Profile ブロックが含まれ、これには（BroadWorks） userId および他の詳細が含まれます（図の 2.2）。

クライアントと Webex サービスの対話:

• IDP プロキシは BroadWorks から受け取ったユーザー プロファイルと一致し、SAML アサーションをクライアントに発行します (図の 2.3)。

• クライアントは CI トークンの SAML アサーションを交換します (図の 3)

• クライアントは、サインインしたユーザーが broadworks-connector エンタイトルメントを持っていることを確認します (図の 4)。 ヘルプ デスクでユーザーのエンタイトルメントを確認します）

• クライアントは CI トークンを使用して、IDP プロキシから JSON ウェブ トークン (JWT) を要求します (図の 5)

• IDP プロキシが CI で CI トークンを検証します

• IDP プロキシは認証サービスから JWT を要求します

authenticationService ログ:

• Webex からのトークン要求を検索します (図の 5.2)。例:

  GET /authService/token

  これには、 http_bw_userid ヘッダなどがあります。

• XSP には OCI-P UserGetLoginInfoRequest があり、提供されたユーザー ID が BroadWorks ユーザーに対応することを確認します（図の 5.3）。 AuthService は mTLS 接続により Webex との信頼を確立しました。そのため LLT を発行できます。

• 応答（図の 5.4）を LongLivedTokenManager - Token generated, subject: bwksUserId@example.com, issuer: BroadWorks …

  および StatusCode=200 から探します。これは trackingid: CLIENT… ヘッダを使用して元のリクエストに関連付けることができます。

XsiActionsLog の場合:

• クライアントは Xsi-Actions インターフェイスで長期間トークンを提示して、デバイス プロファイルを取得できます (図の 6)。 例:

  GET /com.broadsoft.xsi-actions/v2.0/user/bwksUserId%40example.com/profile/device

  ヘッダは、 authorization: Bearer token および user-agent: WebexTeams (variant/version)

• Xsi-Actions インターフェイスでは、POST によってトークンが authservice (ループバック インターフェイス上に構成される) になります。例: 127.0.0.1:80 POST http://127.0.0.1:80/authService/token

  これは、次のヘッダに関連付けることができます。 trackingid: CLIENT… ヘッダ（ GET と X-BROADSOFT-CORRELATION-ID : CLIENT… ヘッダ（ POST.

authenticationService ログ:

• Xsi (ループバック) からの POST の受領

• A StatusCode=200 が Xsi に戻ります

• また、トークン検証応答には、 "token" JSON ブロックが本文中にあります。

• 関連付けに使用するのは、 trackingid: CLIENT…

XsiActionsLog の場合:

• クライアントのトークンを検証した authservice から 200 OK を受け取った Xsi-Actions アプリケーションは、次の OCI-P リクエストを送信します： UserPrimaryAndSCADeviceGetListRequest

• 次のOCI-P を受信します： UserPrimaryAndSCADeviceGetListResponse これには次が含まれます： accessDeviceTable XML 構造が含まれます。

• OCI-P 応答は、次を含むクライアントへの Xsi 応答としてエンコードされます： AccessDevices XML 構造。この構造には、 deviceTypes 例： Business Communicator – PC および、クライアントがデバイス構成ファイルを取得する URL があります。

クライアントは通常通り継続します。

• デバイス エントリを選択し、DMS と対話してデバイス プロファイルを取得する (図の 6)

• DMS からの構成で取得できる SBC 経由の BroadWorks に登録する (図の 7)