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

1. パートナー管理者資格情報を使用して、ヘルプ デスク (https://admin.webex.com/helpdesk) にサインインします。

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

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

   

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

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

   

   BroadWorks に Webex を使用する場合、BroadWorksの Webex ユーザーは 、bc-sp 標準エンタイトルメント を持つ必要があります。 これは、Cisco が管理するクラウド コーリング サービスを通じた Webex アプリ コーリングである「Webex Calling (Broadcloud)」のエンタイトルメントです。

組織の Calling 動作を確認する

1. パートナー管理者資格情報を使用して、ヘルプ デスク (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

  ヘッダーには認証が含まれます。 Basic と user-agent: broadworksTeamsClient

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

• Webex への Xsi 応答には、(BroadWorks) userId および他の詳細 (図の 2.2) を含む XML プロファイル ブロックが含まれます。

クライアントと 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 を発行できます。

• LongLivedTokenManager から応答 (図の 5.4) を検索します - トークンが生成されました、件名: bwksUserId@example.com、発行者: BroadWorks …

  および StatusCode=200 で、trackingid を使用して元の要求に関連付けできます。 CLIENT… ヘッダー。

XsiActionsLog の場合:

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

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

  ヘッダー認証の場合: Bearer token と user-agent: WebexTeams (variant/version)

• Xsi-Actions インターフェイスはトークンを authservice (アドレス インターフェイスに構成される構成) に POST します。例: 127.0.0.1:80 POST http://127.0.0.1:80/authService/token

  これにより、trackingid と関連付け可能です。 GET の CLIENT… ヘッダーと POST の X-BROADSOFT-CORRELATION-ID : CLIENT… ヘッダー

authenticationService ログの場合:

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

• StatusCode=200 は xsi に戻る

• 本文に "token" JSON ブロックを持つ、トークン検証応答。

• trackingid: CLIENT… を使用して関連付け

XsiActionsLog の場合:

• クライアントのトークンを検証した authservice から 200 OK を受け取り、Xsi-Actions アプリケーションは、UserPrimaryAndSCADeviceGetListRequest に対して OCI-P 要求を送信するようになりました。

• accessDeviceTable XML 構造を含む OCI-P UserPrimaryAndSCADeviceGetListResponse を受信します。

• OCI-P 応答は、AccessDevices XML 構造を含むクライアントへの Xsi 応答としてエンコードされます。これは deviceTypes をもちます。例: Business Communicator – PC。また、クライアントがデバイス構成ファイルを取得できる URL を持ちます。

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

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

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