次のウェブ アクセス管理およびフェデレーション ソリューションは、Webex 組織に対しテスト済みです。 以下でリンクされているドキュメントは、特定の ID プロバイダー (IdP) を Webex 組織に統合する方法について順を追って説明しています。


これらのガイドは、Control Hub (https://admin.webex.com) で管理される Webex サービスの SSO インテグレーションについて記載しています。 (サイト管理で管理されている) Webex Meetings サイト の SSO インテグレーションについては、「Cisco Webex サイトのシングル サインオンを設定する」を参照してください。

以下のリストにご使用の IdP がない場合は、この記事の [SSO 設定] タブの手順概要に従ってください。

シングル サインオン (SSO) を使用すると、ユーザーは組織の共通 ID プロバイダー (IdP) の認証を受けて Webex に安全にサインインできます。 Webex アプリは Webex サービスを使用して、Webex プラットフォームのアイデンティティ サービスとやりとりします。 アイデンティティ サービスはご利用の ID プロバイダ (IdP) を使用して認証します。

Control Hub で構成を開始します。 このセクションでは、サードパーティーの IdP の統合の包括的な手順を示します。

SSO および Control Hub では、IdP は SAML 2.0 の仕様を満たす必要があります。 加えて、IdP は以下のように設定されている必要があります。

  • NameID 形式の属性を urn:oasis:names:tc:SAML:2.0:nameid-format:transient に設定します

  • 展開する SSO のタイプに応じて、IdP への要求を構成します。

    • SSO (組織向け) - 組織の代理で SSO を設定する場合、Directory Connector で選択された属性にマッピングされた UID 属性名、または Webex アイデンティティ サービスで選択された属性と一致するユーザー属性を含めるように IdP 要求を構成します。 (この属性はたとえば、E-mail-Addresses または User-Principal-Name となる場合があります)。

    • パートナー SSO (サービス プロバイダーのみ) - サービス プロバイダーが管理し、顧客組織が使用するパートナー SSO を構成しているサービス プロバイダー管理者の場合、メール属性 (UID ではなく) を含めるように IdP 要求を構成します。 Directory Connector で選択された属性、または Webex アイデンティティ サービスで選択された属性と一致するユーザー属性に、値がマッピングされる必要があります。


    SSO またはパートナー SSO の場合のカスタム属性のマッピングについて詳しくは、「https://www.cisco.com/go/hybrid-services-directory」を参照してください。

  • パートナー SSO 限定。 ID プロバイダーは、複数のアサーション コンシューマー サービス (ACS) の URL をサポートする必要があります。 ID プロバイダーで複数の ACS URL を構成する方法の例については、次を参照してください。

  • サポートされているブラウザを使用する。 最新版の Mozilla Firefox または Google Chrome を推奨します。

  • ブラウザーのポップアップブロッカー機能をすべて無効化します。


この設定ガイドでは、SSO インテグレーションの具体的な例を示しますが、すべての可能性に対し網羅的な設定を提供するものではありません。 たとえば、nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transient のインテグレーション手順がドキュメントにまとめられています。 urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified または urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress のようなその他の形式は、SSO インテグレーションで動作しますが、当社のドキュメントの対象外にあります。

Webex プラットフォームのアイデンティティ サービスおよび IdP 間の SAML 合意を確立する必要があります。

SAML 合意を成功させるためには 2 つのファイルが必要です。

  • IdP からメタデータ ファイルを Webex に提供します。

  • Webex から メタデータ ファイルを IdP に提供します。

これは、IdP からメタデータを持つ PingFederate メタデータ ファイルの例です。

ID サービスからのメタデータ ファイル。

以下は、ID サービスからメタデータ ファイルで確認できることです。

  • EntityID —これは、IdP 構成の SAML 契約を識別するために使用されます

  • 署名された AuthN 要求や署名アサーションに要件はなく、メタデータ ファイルの IdP 要求に準拠します。

  • IdP の署名されたメタデータ ファイルは、ID サービスに属するメタデータを検証します。

1

Control Hub (https://admin.webex.com) の顧客ビューから、[管理] > [組織の設定] に移動し、[認証] までスクロールして、[シングル サインオン] 設定に切り替えて、設定ウィザードを開始します。

2

証明書タイプを選択します。

  • Cisco による自己署名 - このオプションを選択して、当社を SP とすることを推奨します。 こうすることで、証明書の更新が 5 年ごとで済みます。
  • パブリック認証局による署名 - Hydrant や Godaddy などのパブリック CA から証明書を取得する場合、このオプションは安全で推奨されます。 ただし、年に 1 回証明書を更新する必要があります。
3

[メタデータのダウンロード] をクリックし、[次へ] をクリックします。

4

Webex プラットフォームのアイデンティティ サービスにより、IdP からのメタデータ ファイルが検証されます。

顧客 IdP からメタデータを検証するには 2 つの方法があります。

  • 顧客 IdP は、公的ルート CA により署名されたメタデータの署名を提供します。

  • 顧客 IdP は事故署名のプライベート CA を提供するか、メタデータには署名を提供しません。 このオプションは安全性が薄れます。

5

有効にする前に、SSO 接続をテストします。 このステップはドライ ランのように機能し、次のステップで SSO を有効化するまで組織の設定には影響を与えません。


 

SSO サインイン エクスペリエンスを直接見るには、この画面から [URL をクリップボードに貼り付け] をクリックして、それをプライベート ブラウザー ウィンドウに貼り付けることもできます。 そこから、SSO のサインインをウォークスルーできます。 これは、SSO 設定のテスト時に誤判定の結果をもたらす可能性のある、Web ブラウザーにキャッシュされた情報を削除するのに役立ちます。

6

テストに成功した場合、SSO を有効にし変更を保存します。

SSO を組織で有効にするには、変更を保存する必要があります。

証明書の有効期限切れ通知を受け取った場合でも、既存の SSO 設定を確認する場合でも、証明書の管理と一般的な SSO のメンテナンス業務のために、Control Hubのシングル サインオン (SSO) 管理機能を使用できます。

SSO インテグレーションで問題が発生した場合、このセクションの要件と手順を使用して、IdP と Webex の間の SAML フローをトラブルシューティングします。

  • Firefox または Chrome の SAML トレース アドオンを使用する

  • トラブルシューティングをするには、SAML トレース デバッグ ツールをインストールした Web ブラウザーを使用して、https://web.webex.com で Webex のウェブ バージョンに進みます。

以下は、Webex アプリ、Webex サービス、Webex プラットフォームのアイデンティティ サービス、ID プロバイダー (IdP) 間のメッセージ フローです。

  1. https://admin.webex.com に進みメール アドレスの SSO 対応 アプリでメールアドレスをプロンプトします。
  2. アプリはトークンを求めて GET 要求を OAuth 認証サーバーに送信します。 SSO またはユーザー名とパスワード フローに対して、要求は ID サービスにリダイレクトされます。 認証サーバーの URL が戻されます。
  3. Webex アプリは SAML HTTP POST を使用して IdP からの SAML アサーションを要求します。
  4. アプリの認証は、オペレーティング システム ウェブ リソースと IdP 間で発生します。
  5. アプリは HTTP Post をアイデンティティ サービスに戻し、IdP により提供され、初期合意で合意された属性を含めます。
  6. IdP から Webex への SAML アサーション。
  7. ID サービスは、Oauth アクセスと置き換えられた認証コードを受け取り、トークンを更新します。 このトークンはユーザーの代わりにリソースへアクセスするために使用されます。
1

https://admin.webex.com に進みメール アドレスの SSO 対応 アプリでメールアドレスをプロンプトします。

アプリは Webex サービスに情報を送信し、Webex サービスはメール アドレスを検証します。

2

アプリはトークンを求めて GET 要求を OAuth 認証サーバーに送信します。 SSO またはユーザー名とパスワード フローに対して、要求は ID サービスにリダイレクトされます。 認証サーバーの URL が戻されます。

トレース ファイルの GET 要求を表示できます。

パラメーター セクションで、サービスは Oauth コード、要求を送信するユーザーのメール、ClientID、redirectURI、Scope などその他の Oauth の詳細を探します。

3

Webex アプリは SAML HTTP POST を使用して IdP からの SAML アサーションを要求します。

SSO が有効になっているとき、ID サービスの認証エンジンは SSO の IdP URL にリダイレクトします。 メタデータが交換されたとき提供された IdP URL。

SAML POST メッセージのトレース ツールでチェックします。 IdPbroker で要求された IdP に対して HTTP POST メッセージが表示されます。

RelayState パラメーターは IdP から正しい返信が表示されます。

SAML 要求のデコード バージョンを確認し、必須の AuthN がなく、応答の宛先が IdP の宛先 URL になるようにする必要があります。 nameid 形式が正しい entityID (SPNameQualifier) の下の、IdP で正しく構成されていることを確認します。

SAML 契約が作成された際、IdP nameid 形式は指定され、構成された契約の名前となります。

4

アプリの認証は、オペレーティング システム ウェブ リソースと IdP 間で発生します。

IdP で構成された IdP および認証メカニズムに応じて、別のフローが IdP から開始されます。

5

アプリは HTTP Post をアイデンティティ サービスに戻し、IdP により提供され、初期合意で合意された属性を含めます。

認証に成功すると、アプリは SAML POST メッセージの情報をアイデンティティ サービスに送信します。

EntityID がアサーションを要求している IdP をアプリが伝えている場合、RelayState は以前の HTTP POST メッセージと同じです。

6

IdP から Webex への SAML アサーション。

7

ID サービスは、Oauth アクセスと置き換えられた認証コードを受け取り、トークンを更新します。 このトークンはユーザーの代わりにリソースへアクセスするために使用されます。

アイデンティティ サービスは IdP からの回答を検証した後に、Webex アプリが別の Webex サービスにアクセスできるようにする OAuth トークンを発行します。