SAML SSO 設定

SAML ベースの SSO 前提条件

SAML ベースの SSO 設定には以下のシステム設定が必要です:

  • NTP セットアップ

  • DNS セットアップ

  • ディレクトリのセットアップ

NTP セットアップ

SAML SSO では、Network Time Protocol(NTP)を使用することで Unified Communications アプリケーションと IdP の間で時刻を同期させることができます。 SAML は時間に依存するプロトコルであり、IdP は SAML アサーションの時間ベースの有効性を決定します。 IdP と Unified Communications アプリケーションのクロックが同期していない場合、アサーションが無効になり、SAML SSO 機能が停止します。 IdP と Unified Communications アプリケーション間で許容されている最大時差は 3 秒です。


(注)  


SAML SSO を有効にするには、正しい NTP セットアップをインストールし、IdP と Unified Communications アプリケーションとの時差が 3 秒を超えないことを確認する必要があります。

クロックを同期するために NTP サーバを追加する方法については、『 Cisco Unified Communications Manager のシステム構成ガイド』の「デバイスプールのコア設定」の章を参照してください。

DNS セットアップ

ドメイン ネーム システム (DNS) は、ネットワーク内でホスト名とネットワーク サービスの IP アドレスへのマッピングを有効にします。 ネットワーク内に展開された DNS サーバは、ネットワークサービスをホスト名にマッピングし、さらにホスト名を IP アドレスにマッピングするデータベースを提供します。 ネットワーク上のデバイスは、DNS サーバにクエリを行い、ネットワーク内の他のデバイスの IP アドレスを受け取ることができるため、ネットワーク デバイス間の通信が容易になります。

Unified Communications アプリケーションは DNS を使用して、完全修飾ドメイン名を IP アドレスに解決できます。 サービス プロバイダーと IdP は、ブラウザーによって解決可能である必要があります。 例えば、管理者がサービスプロバイダのホスト名 (http://www.cucm.com/ccmadmin) をブラウザに入力すると、ブラウザはホスト名を解決する必要があります。 SAML SSO のために、サービスプロバイダーがブラウザを IdP(http://www.idp.com/saml)にリダイレクトする場合、ブラウザは IdP ホスト名を解決する必要があります。 さらに、IdP がサービスプロバイダーの ACS URL にリダイレクトする場合、ブラウザはそれも解決する必要があります。

ディレクトリのセットアップ

LDAP ディレクトリの同期は、さまざまな Unified Communications アプリケーションで SAML SSO を有効にするための前提条件および必須の手順です。 Unified Communications アプリケーションと LDAP ディレクトリの同期により、管理者は Unified Communications アプリケーションのデータフィールドをディレクトリ属性にマッピングすることで、ユーザを簡単にプロビジョニングできます。


(注)  


SAML SSO を有効にするには、LDAP サーバが IdP サーバにより信頼され、Unified Communications アプリケーションによりサポートされている必要があります。

詳細については、次の場所にある『Cisco コラボレーション システム ソリューション リファレンス ネットワーク デザイン(SRND)』の「ディレクトリ統合と ID 管理」の章を参照してください。

https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-system/products-implementation-design-guides-list.html

証明書管理と検証


重要


Cisco は、サーバ証明書が SAML SSO に対して署名され、製品サポートが利用できる場合にはマルチサーバ証明書が使用されることを強く推奨します。



(注)  


  • 共通名 (CN) およびサブジェクト代替名 (SAN) は、要求されているアドレスの IP アドレスまたは完全修飾ドメイン名 (FQDN) への参照です。 例えば、「 https://www.cisco.com」と入力した場合、CN または SAN のヘッダーには "www.cisco.com" が必要です。

  • Unified Communications Manager がすでに混合/セキュアモードであり、証明書に変更が加えられた場合、セキュア USB トークンを使用して CTL 証明書を更新する必要があります。 そうしないと、 Cisco Jabber クライアントはテレフォニー機能を取得できません。 CTL トークンの更新では、Unified Communications Manager を再起動する必要があります。


SAML SSO では、ユーザのウェブブラウザを含む、SAML メッセージ交換に参加している各エンティティは、要求されたエンティティへのシームレスで安全な HTTPS 接続を確立する必要があります。 Cisco は、SAML SSO 展開に参加する各 UC 製品で、信頼できる認証局により発行された署名付き証明書を設定することを強く推奨します。

Unified Communications アプリケーションは証明書の検証を使用して、サーバーとのセキュアな接続を確立します。 証明書はエンドポイント間で使用され、データの信頼/認証と暗号化を構築します。 これにより、エンドポイントが目的のデバイスと通信し、2 つのエンドポイント間でデータを暗号化するオプションがあることを確認します。

安全な接続の確立を試みる際、サーバは Unified Communications クライアントに証明書を提示します。 クライアントが証明書を検証できない場合、証明書を受け入れるかどうかを確認するプロンプトをユーザに表示します。

認証局によって署名された証明書

Cisco は、以下のタイプの認証局 (CA) のいずれかによって署名されたサーバ証明書の使用を推奨しています。

  • 公開 CA - サードパーティがサーバの身元を確認し、信頼できる証明書を発行します。
  • プライベート CA - ローカル CA を作成、管理し、信頼できる証明書を発行します。

署名プロセスは各製品によって異なり、サーバのバージョンによっても異なります。 各サーバの各バージョンに対する詳細な手順を提供することは、このドキュメントの範囲を超えます。 CA によって署名された証明書を取得する方法に関する詳細な手順については、適切なサーバのドキュメントを参照してください。

しかし、次のステップは、手順の大まかな概要を説明しています。

手順

ステップ 1

クライアントに証明書を提示できる各製品で、証明書署名リクエスト(CSR)を生成します。

ステップ 2

各 CSR を CA に送信します。

ステップ 3

CA が発行する証明書を各サーバにアップロードします。


すべてのサーバ証明書には、クライアントコンピュータの信頼ストアに存在するルート証明書が関連付けられている必要があります。 Cisco UC アプリケーションは、サーバが提供する証明書を信頼ストアのルート証明書と照合して検証します。

パブリック CA により署名されたサーバ証明書を取得する場合、クライアントコンピュータのトラストストアに、パブリック CA のルート証明書がすでにあるはずです。 この場合、クライアントコンピュータにルート証明書をインポートする必要はありません。

証明書がプライベート CA などの信頼ストアにまだ存在しない CA によって署名されている場合、ルート証明書をインポートする必要があります。

SAML SSO では、IdP とサービスプロバイダは CN または SAN の正しいドメインを持つ CA の署名入りの証明書を持っている必要があります。 正しい CA 証明書が検証されない場合、ブラウザはポップアップ警告を発行します。

例えば、管理者がブラウザで https://www.cucm.com/ccmadmin; Unified Communications Manager ポータルは CA 証明書をブラウザに提示します。 ブラウザが https://www.idp.com/saml にリダイレクトされると、IdP は CA 証明書を提示します。 ブラウザは、サーバによって提示された証明書にそのドメインの CN または SAN フィールドが含まれていること、および証明書が信頼された CA によって署名されていることを確認します。

代わりに、顧客が独自のプライベート CA を持っている場合、その CA は、管理者がブラウザを起動しているコンピュータにルート トラスト アンカーとしてインストールする必要があります。

マルチサーバ SAN 証明書の設定

各 Cisco 製品には、マルチサーバ SAN 証明書を生成するための独自のプロセスがあります。 マルチサーバ SAN 証明書をサポートする Cisco 製品についての情報は、関連するガイドを参照してください。

Microsoft Edge 相互運用のための証明書発行者を展開する

Microsoft Edge ブラウザが展開されている SAML SSO 展開には、相互運用性の問題が存在します。 SSO が有効なマシンに Edge ブラウザが展開されている場合、Edge ブラウザは Unified Communications Manager 証明書の発行者を認識せず、アクセスを提供しません。

この手順を使用して、グループ ポリシー オブジェクト (GPO) および Active Directory 経由でこの問題を修正します。これにより、Unified Communications Manager 証明書の発行者を、Edge ブラウザを使用するローカル マシンの信頼されたルート証明書にプッシュできます。


(注)  


「証明書の発行者」は、証明書のセットアップ方法によって異なります。 たとえば、サードパーティ CA 証明書の場合、CA 自体が Unified Communications Manager 証明書に署名する場合にのみ、CA 証明書をプッシュする必要があります。 ただし、中間 CA が Unified Communications Manager 証明書に署名する場合、ルート証明書、中間証明書、およびリーフ証明書を含む完全な証明書チェーンをプッシュする必要があるかもしれません。


始める前に

この手順を実行するには、ローカルマシンのローカル Administrators グループのメンバーシップ、またはそれと同等の権限が最低限必要です。

手順


ステップ 1

Active Directory で、グループポリシー管理コンソールを開きます。

ステップ 2

既存の GPO を検索するか、証明書の設定を含む新しい GPO を作成します。 GPO は、ポリシーの影響を受けるユーザのドメイン、サイト、または組織単位と関連付けられている必要があります。

ステップ 3

GPO を右クリックして、[編集(Edit)] を選択します。

グループポリシー管理エディタ が開き、ポリシーオブジェクトの現在のコンテンツが表示されます。

ステップ 4

ナビゲーションペインで [コンピュータの設定(Computer Configuration)] > [Windows の設定(Windows Settings)] > [セキュリティ設定(Security Settings)] > [公開キーポリシー(Public Key Policies)] > [信頼できる発行元(Trusted Publishers)] を開きます。

ステップ 5

[アクション(Action)] メニューをクリックし、[インポート(Import)] をクリックします。

ステップ 6

証明書インポートウィザード の手順に従い、証明書を見つけてインポートしてください。

ステップ 7

証明書が自己署名証明書で、[信頼されたルート証明機関(Trusted Root Certification Authorities)] 証明書ストアにある証明書までさかのぼることができない場合は、証明書をそのストアにコピーする必要があります。 ナビゲーションペインで、[ 信頼されたルート証明機関] をクリックし、ステップ 5 と 6 を繰り返してストアに証明書のコピーをインストールします。



(注)  


Active Directory での信頼されたルート証明書の管理についての詳細は、 https://technet.microsoft.com/en-us/library/cc754841(v=ws.11).aspxを参照してください。


SAML SSO 設定タスク フロー

これらのタスクを完了して、Cisco Collaboration 環境で SAML SSO を設定します。 このプロセスには、次のアプリケーションの手順が含まれます。
  • Cisco Unified Communications Manager

  • IM and Presence Service

  • Cisco Unity Connection

  • Cisco Expressway(MRA 導入とともに)

手順

  コマンドまたはアクション 目的

ステップ 1

コラボレーション アプリケーションの SSO 設定を開始する

Cisco Collaboration 環境で、SSO 設定を開始し、UC メタデータをエクスポートします。

ステップ 2

ID プロバイダでの SAML SSO の設定

ID プロバイダで、以下の手順を実行します。

  • UC メタデータをアップロードする

  • SAML SSO 合意を設定する

  • IdP メタデータ ファイルをエクスポートする

ステップ 3

Cisco コラボレーションアプリケーションの SAML SSO を有効にする

IdP メタデータを Cisco Collaboration 環境にインポートし、構成を完了します。

コラボレーション アプリケーションの SSO 設定を開始する

Cisco Collaboration 環境で、SAML SSO 構成を開始し、ID プロバイダにアップロードするために UC メタデータをエクスポートします。 SAML SSO を設定しているアプリケーションおよび選択したオプションに応じて、複数のダウンロードファイルがある場合があります。

始める前に

どのタイプの SAML SSO 合意 (クラスター全体またはノードごと) と証明書タイプを事前に計画してください。

手順


ステップ 1

Cisco Unified Communications Manager で、UC メタデータファイルをエクスポートします。

  1. Cisco Unified CM Administration で、[システム(System)] > [SAMLシングルサインオン(SAML Single Sign-On)] の順に選択します。

  2. [SSO モード(SSO Mode)] オプションとして、[クラスタ全体(Cluster wide)] または [ノードごと(Per Node)] を選択します。

  3. 証明書 オプションを選択します: システムで生成された自己署名証明書 または Cisco Tomcat 証明書。

  4. [ すべてのメタデータをエクスポート ] をクリックして、メタデータファイルを安全な場所に保存します。

    クラスター全体の合意では、単一のメタデータ ファイルを受け取ります。 ノードごとの合意では、zip ファイルのダウンロードには各クラスタノードの個別の XML ファイルが含まれます。 標準導入で IM and Presence Service がある場合、

ステップ 2

IM and Presence Service - IM and Presence Servce に集中導入がある場合、IM and Presence 中央クラスタの一部であるスタンドアロン Unified CM パブリッシャノードでステップ 1 を繰り返します。

(注)  

 
IM and Presence サービスの標準的な展開では、このタスクをスキップできます。前のステップで Unified Communications Manager からダウンロードしたメタデータファイルには IM and Presence サービス クラスタのメタデータが含まれるためです。

ステップ 3

Cisco Unity Connection で、メタデータ ファイルをエクスポートします。

  1. Cisco Unity Connection の管理から、 システム設定 > SAML シングルサインオンを選択します。

  2. [SSO モード(SSO Mode)] オプションとして、[クラスタ全体(Cluster wide)] または [ノードごと(Per node)] を選択します。

  3. [ すべてのメタデータをエクスポート] をクリックします。

ステップ 4

Cisco Expressway-C で、メタデータファイルをエクスポートします。

  1. Expressway-C プライマリピアで、[設定(Configuration)] > [Unified Communications] > [設定(Configuration)] に移動します。

  2. [ MRA アクセス制御 ] セクションで、 認証パス に対して次のいずれかのオプションを選択します:

    • SAML SSO 認証

    • SAML SSO および UCM/LDAP—いずれかの方法を許可します。

  3. [SAML メタデータ(SAML Metadata)] オプションとして、[クラスタ(Cluster)] または [ピア(Peer)] を選択します。

    • Cluster—クラスタ用の単一メタデータファイル

    • ピア(Peer):ノードごとに個別のメタデータファイル。

  4. [SAML データのエクスポート(Export SAML data)] をクリックします。

    • クラスタ合意の場合は、[証明書の生成(Generate Certificate)] をクリックしてから、証明書を [ダウンロード(Download)] します。

    • ピア合意の場合は、[すべてダウンロード(Download All)] します。

  5. 安全な場所に保存します。


この手順が完了すると、各 Collaboration アプリケーションのメタデータファイルを保有することになります。 メタデータ ファイルの数は、構成と展開の種類によって異なります。

メタデータのダウンロードの例

Cisco Collaboration の展開で予想されるファイルのダウンロード数の例については、以下を参照してください。 次のアプリケーションの SSO を設定すると想定します:

  • 5 ノードの Cisco Unified Communications Manager クラスタ

  • 3 ノードの IM and Presence Service クラスタ

  • 2 ノードの Cisco Unity Connection クラスタ

  • 3 ノード Expressway-C クラスターと 3 ノード Expressway-E クラスター(MRA 導入)

以下の表は、クラスタ全体の合意を使用しているかどうか、および IM and Presence Service が標準導入と集中導入のどちらにあるかによって、予想されるダウンロードファイルの合計の内訳を示しています。

表 1. 予想されるメタデータのダウンロード

合意タイプ

IM and Presence が標準導入の場合にダウンロードされるファイルの合計数

IM および Presence が集中導入の場合にダウンロードされるファイルの合計数*

クラスタワイド

以下のクラスターを表す 3 つのメタデータ XML ファイル:

  • Unified Communications Manager および IM and Presence Service クラスタ

  • Unity Connection クラスタ

  • Expressway-C クラスター

以下のクラスターを表す 4 つのメタデータ XML ファイル:

  • Unified Communications Manager クラスタ

  • IM and Presence サービス クラスタ

  • Unity Connection クラスタ

  • Expressway-C クラスター

ノードごと

13 個のメタデータ XML ファイルを含む 3 つの zip ファイル:

  • Unified CM および IM and Presence ノード用の 8 つの XML ファイルを含む 1 つの zip ファイル

  • Unity Connection ノード用の 2 つの XML ファイルを含む 1 つの zip ファイル

  • Expressway-C ノード用に 3 つの XML ファイルを含む 1 つの zip ファイル

14 メタデータ XML ファイルを含む 4 つの zip ファイル:

  • Unified CM ノード用の 5 つの XML ファイルを含む 1 つの zip ファイル

  • IM and Presence ノード用の 3 つの XML ファイル、および IM and Presence 中央クラスタにあるスタンドアロン Unified CM パブリッシャノード用の追加の XML ファイルを含む 1 つの zip ファイル

  • Unity Connection ノード用の 2 つの XML ファイルを含む 1 つの zip ファイル

  • Expressway-C ノード用に 3 つの XML ファイルを含む 1 つの zip ファイル


(注)  


標準導入では、IM およびプレゼンス サービスは Cisco Unified Communications Manager と同じクラスタにあります。 IM およびプレゼンス サービスのメタデータは、Cisco Unified Communications Manager からダウンロードしたメタデータに含まれています。

集中導入では、IM および Presence Service が Cisco Unified Communications Manager テレフォニークラスタとは異なるクラスタにあり、IM および Presence セントラルクラスタ内のスタンドアロンで非テレフォニーの Unified CM パブリッシャノードを使用して、IM および Presence Service のメタデータを個別にエクスポートする必要があります。


ID プロバイダでの SAML SSO の設定

ID プロバイダで、次の作業を行う必要があります。

  • Cisco Collaboration 環境からダウンロードした UC メタデータファイルをインポートします

  • Cisco Collaboration アプリケーションに対する SAML SSO 合意を設定する必要があります

  • あなたは後で Cisco Collaboration アプリケーションにインポートする ID プロバイダ メタデータ ファイルをエクスポートする必要があります。

Cisco は、使用するためのガイドとして、次の Idp 固有の構成例を提供します。


(注)  


上記のリンクは例にすぎません。 正式な説明については、IdP のドキュメントをご覧ください。


Cisco コラボレーションアプリケーションの SAML SSO を有効にする

始める前に

ID プロバイダのメタデータを Cisco Collaboration アプリケーションにインポートし、SAML SSO 構成を完了します。

重要


この注意事項は、リリース 14SU2 以降に適用されます。



(注)  


ドメインの設定時には、「CUCM サーバー定義を IP アドレスまたはホスト名から FQDN 形式に変更する」にある「設定」の項を参照することをお勧めします。これにより、接続エラーとメタデータの不一致の警告メッセージを避けることができます。これらのメッセージは、SAML SSO を有効にした後に表示されます。 これは BCFIPS 機能で導入されました。


手順


ステップ 1

Cisco Unified Communications Manager で、SSO 設定を完了します。

  1. SAML SSO を有効にする前に Cisco Tomcat サーバを再起動してください。

  2. Cisco Unified CM Administration で、[システム(System)] > [SAMLシングルサインオン(SAML Single Sign-On)] の順に選択します。

  3. [SAML SSO の有功化(Enable SAML SSO)]をクリックします。

  4. [続行(Continue)]をクリックし、プロンプトに従います。

  5. クラスター全体の合意のみ。 [マルチサーバの tomcat 証明書のテスト ] をクリックします。

  6. [次へ(Next)] をクリックします。

  7. 参照 して IdP メタデータファイルを選択します。 ファイルを開いたら、[IdP メタデータをインポート(Import IdP Metadata)] をクリックします。

  8. [次へ(Next)]をクリックします。

  9. 標準 CCM スーパーユーザー権限を持つ LDAP 同期ユーザーを選択し、[SSO テストを実行(Run SSO test)] します。

  10. ユーザのサインイン情報でログインします。

  11. [完了(Finish)]をクリックして、SAML SSO のセットアップを完了します。

  12. Cisco Tomcat サーバを再起動します。

  13. ノードごとの合意のみ。 各 Unified Communications Manager ノードでこのプロセスを繰り返します。

    (注)  

     

    Unified Communications Manager で FIPS または ESM が有効になっている場合、SSO 署名アルゴリズムを sha256 に設定する必要があります。

    Unified CM のすべてのノードの管理 CLI でこのコマンドを実行します。

    utils sso set signing-algorithm sha256

ステップ 2

IM and Presence サービス - IM and Presence サービスの集中導入の場合、IM and Presence 中央クラスタの一部であるスタンドアロン Unified CM パブリッシャノードで前の手順を繰り返します。

ステップ 3

Cisco Unity Connection で、SAML SSO 構成を完了します。

  1. SAML SSO を有効にする前に Cisco Tomcat サーバを再起動してください。

  2. Cisco Unity Connection Administration で、[システム設定(System Settings)] > [SAML シングルサインオン(SAML Single Sign On)] に移動します。

  3. [SAML シングルサインオンを有効にする(Enable SAML Single Sign On)] をクリックします。

  4. [続行(Continue)]をクリックし、プロンプトに従います。

  5. IdP メタデータ ファイルを Cisco Unity Connection にインポートします。

  6. SSO 接続をテストします。

  7. Cisco Tomcat サーバを再起動します。

  8. ノードごとの合意のみ。 各クラスター ノードに対してこのプロセスを繰り返します。

ステップ 4

Expressway-C プライマリピアで、SAML SSO 構成を完了します。

  1. [設定(Configuation)] > [Unified Communications] > [ID プロバイダ(Identity providers)] に移動します。

  2. [ 新しい IdP を SAML からインポート] をクリックします。

  3. [SAML ファイルのインポート ] コントロールを使用して IdP メタデータファイルを指定します。

  4. ダイジェスト に必要な SHA ハッシュアルゴリズムを設定してください。

  5. [アップロード(Upload)]をクリックします。

    (注)  

     
    メタデータをインポートした後で、[設定(Configuration)] > [Unified Communications] > [ID プロバイダ(Identity Providers)(IdP)] に移動して、署名アルゴリズムを変更できます。自分の IdP 行を見つけて、[アクション(Actions)] 列で [ダイジェストの設定(Configure Digest)] をクリックします。
  6. IdP が ID プロバイダのリストに表示されることを確認します。

  7. [IdP] の行の ドメインの関連付け をクリックします。

  8. この ID プロバイダに指定するドメインをチェックします。

  9. [保存(Save)] をクリックします。

    (注)  

     
    SAML SSO のために Cisco Expressway with Active Directory Federation Services (ADFS) を展開する場合、Expressway の追加設定 ADFS のための追加の Expressway 構成 を参照してください。

SAML SSO の追加タスク

以下の追加タスクを実行し、要件に応じて SAML SSO セットアップを有効にすることができます。

Cisco Tomcat サービスの再起動

SAML シングルサインオンを有効化または無効化した後は、シングルサインオンが実行されているすべての Unified CM クラスタノードと IM and Presence Service クラスタノードで、Cisco Tomcat サービスを再起動します。

手順


ステップ 1

コマンドライン インターフェイスにログインします。

ステップ 2

utils service restart Cisco Tomcat CLI コマンドを実行します。

ステップ 3

シングル サインオンが有効化されているすべてのクラスタ ノードで、この手順を繰り返します。


ADFS のための追加の Expressway 構成

Active Directory フェデレーションサービスを使用して Expressway に SAML SSO を展開する場合、これらの追加の Expressway 構成を完了します。

手順


ステップ 1

Windows PowerShell® で、ADFS で作成された各 Relying Party Trust ごとに、各 Expressway-E の <EntityName> に対して以下のコマンドを 1 回実行します。

Set-ADFSRelyingPartyTrust -TargetName "<EntityName>" -SAMLResponseSignatureMessageAndAssertion、ここで <EntityName> は ADFS で設定されている Expressway-E の Relying Party Trust の表示名でなければなりません。

ステップ 2

ADFS で、各証明書利用者にクレーム ルールを追加します。

  1. [クレームルールの編集(Edit Claims Rule)] ダイアログを開き、AD 属性をクレームとして送信する新しいクレームルールを作成します。

  2. AD 属性を選択して、OAuth ユーザを内部システムに識別する属性を選択します。通常はメールまたは SAMAccountName です。

  3. 発信クレーム タイプとして uid を入力します。


iOS Cisco Jabber の SSO ログインの動作設定

手順


ステップ 1

Cisco Unified CM Administrationから、[システム] > [企業パラメータ] を選択します。

ステップ 2

オプトイン制御を設定するには、[SSO の設定(SSO Configuration)] セクションの [iOS 向け SSO ログイン動作(SSO Login Behavior for iOS)] パラメータで、[ネイティブブラウザの使用(Use Native Browser)] オプションを選択します。

(注)  

 
[iOS向けSSOログイン動作(SSO Login Behavior for iOS)]パラメータには次のオプションが含まれます。
  • [組み込みブラウザの使用(Use Embedded Browser)]:このオプションを有効にすると、Cisco Jabber は SSO の認証に、組み込みブラウザを使用します。 このオプションにより、バージョン 9 より前の iOS デバイスのネイティブ Apple Safari ブラウザで、クロス起動なしの SSO を使用できるようになります。 このオプションは、デフォルトで有効です。

  • ネイティブブラウザの使用(Use Native Browser):このオプションを有効にすると、Cisco Jabber は、iOS デバイスで Apple Safari フレームワークを使用し、MDM の導入で、ID プロバイダ(IdP)を利用する証明書ベースの認証を実行します。

    (注)  

     

    ネイティブ ブラウザの使用は組み込みブラウザの使用ほど安全ではないため、制御された MDM の導入での利用を除いては、このオプションの設定を推奨しません。

ステップ 3

[保存(Save)] をクリックします。


リカバリ URL へのアクセス

トラブルシューティングのために、SAML シングル サインオンをバイパスして、Cisco Unified Communications Manager Administration インターフェイスと Cisco Unified CM IM and Presence サービス インターフェイスにログインする場合に、リカバリ URL を使用します。 たとえば、サーバのドメインまたはホスト名を変更する前に、リカバリ URL を有効にします。 リカバリ URL にログインすると、サーバ メタデータの更新が容易になります。


(注)  


セルフケアポータルにログインしようとするエンドユーザー(LDAP またはローカル)に対して、復元 URL は機能しません。

始める前に

  • 管理権限を持っているアプリケーション ユーザのみがリカバリ URL にアクセスできます。

  • SAML SSO が有効になっている場合は、リカバリ URL がデフォルトで有効になります。 CLI からリカバリ URL を有効/無効にすることができます。 リカバリ URL を有効または無効にする CLI コマンドの詳細については、『Cisco Unified Communications のソリューション コマンド ライン インタフェース リファレンス ガイド』を参照してください。

手順


ブラウザで、「https://hostname:8443/ssosp/local/login」と入力します。


ドメインまたはホスト名の変更後のサーバ メタデータの更新

ドメインまたはホスト名の変更後は、この手順を実行するまで、SAML シングル サインオンが機能しません。


(注)  


この手順を実行しても [SAML シングル サインオン(SAML Single Sign-On)]ウィンドウ にログインできない場合は、ブラウザのキャッシュをクリアしてもう一度ログインしてみてください。


始める前に

リカバリ URL が無効になっている場合、シングル サインオン リンクをバイパスするようには表示されません。 リカバリ URL を有効にするには、CLI にログインして次のコマンドを実行します:utils sso recovery-url enable

手順


ステップ 1

Web ブラウザのアドレス バーに次の URL を入力します。

https://<Unified CM-server-name>

<Unified CM-server-name> は、サーバのホスト名、または IP アドレスです。

ステップ 2

[シングル サインオンをバイパスするリカバリURL(Recovery URL to bypass Single Sign-On (SSO))] をクリックします。

ステップ 3

管理者ロールを持つアプリケーション ユーザのクレデンシャルを入力し、[ログイン(Login)]をクリックします。

ステップ 4

Cisco Unified CM Administration で、[システム(System)] > [SAML シングル サインオン(SAML Single Sign-On)] を選択します。

ステップ 5

[メタデータのエクスポート(Export Metadata)] をクリックしてサーバ メタデータをダウンロードします。

ステップ 6

サーバ メタデータ ファイルを IdP にアップロードします。

ステップ 7

[テスト実行(Run Test)]をクリックします。

ステップ 8

有効なユーザ ID とパスワードを入力します。

ステップ 9

成功のメッセージが表示されたら、ブラウザウィンドウを閉じます。


IdP メタデータの更新

この手順を使用して、クラスター内のすべてのサーバで IdP メタデータ信頼ファイルを更新します。

始める前に

リカバリ URL が無効になっている場合、シングルサインオン リンクをバイパスするようには表示されません。 リカバリ URL を有効にするには、CLI にログインして次のコマンドを実行します:utils sso recovery-url enable

手順


ステップ 1

Web ブラウザのアドレス バーに次の URL を入力します。

https://<Unified CM-server-name>

<Unified CM-server-name> はサーバのホスト名または IP アドレスです。

ステップ 2

[シングルサインオンをバイパスするリカバリ URL(Recovery URL to bypass Single Sign-On (SSO))] をクリックします。

ステップ 3

管理者ロールを持つアプリケーションユーザの資格情報を入力して、[ ログイン] をクリックします

ステップ 4

Cisco Unified CM Administration で、[システム(System)] > [SAMLシングルサインオン(SAML Single Sign-On)] を選択します。

ステップ 5

[IdP メタデータファイルの更新(Update IdP Metadata File)] をクリックして、IdP メタデータトラストファイルをインポートします。

ステップ 6

[参照(Browse)] をクリックして IdP メタデータトラストファイルを選択し、[IdP メタデータのインポート(Import IdP Metadata)] をクリックしてコラボレーションサーバーにインポートします。

ステップ 7

[ 次へ] をクリックします。

ステップ 8

メタデータファイルが適切に設定されているかどうかを確認するための標準 CCM スーパーユーザー権限を持つ LDAPと同期されたユーザーを選択し、[SSO テストを実行(Run SSO Test)] します。

ステップ 9

有効なユーザのサインイン情報でログインします。

ステップ 10

[完了] をクリックして、クラスタ内のすべてのサーバで SAML SSO 設定を有効にします。

(注)  

 

アプリケーションが更新されると、少し遅延があります。 SSO モードが「クラスター全体」の場合、「Cisco Tomcat」、「Cisco SSOSP Tomcat」、「Cisco UDS Tomcat」 サービスは、クラスター内のすべてのノードで再起動します。 そうしないと、IDP メタデータが更新された特定のノードでサービスが再起動されます。


サーバ メタデータの手動プロビジョニング

ID プロバイダで複数の UC アプリケーション用の単一接続をプロビジョニングするには、ID プロバイダとサービス プロバイダー間の信頼の輪を設定しながら、サーバ メタデータを手動でプロビジョニングする必要があります。 信頼の輪の設定方法については、IdP 製品のマニュアルを参照してください。

一般的な URL 構文は次のとおりです。

https://<SP FQDN>:8443/ssosp/saml/SSO/alias/<SP FQDN>

手順


サーバ メタデータを手動でプロビジョニングするには、Assertion Customer Service(ACS)URL を使用します。

例:

ACS URL の例: <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://cucm.ucsso.cisco.com:8443/ssosp/saml/SSO/alias/cucm.ucsso.cisco.com" index="0"/>


アップグレード後の OpenAM SSO から SAML SSO への再設定

リリース 11.0(1) で、Unified Communications Manager は OpenAM SSO ソリューションを提供しなくなりました。 Open AM SSO ソリューションが設定された以前のリリースからアップグレードした場合、サポートされている IdP の 1 つを使用して SAML SSO ソリューションにシステムを再設定する必要があります。 このガイドに記載されている設定を使用して、SAML SSO を使用するようにシステムを再設定します。


(注)  


OpenAM SSO ソリューションと、ID プロバイダに OpenAM を使用する SAML SSO ソリューションを混同しないでください。これらは別のソリューションであるためです。 SAML SSO を使用するためにシステムを再設定する場合、本書に記載されている任意の IdP を使用することができます。


ネットワーク移行後のクラスターの再プロビジョニング

SSO ログインが適切に機能するためには、ネットワーク移行後にクラスターを再プロビジョニングしてください。


(注)  


この手順は、SSO が有効になっているネットワーク移行クラスターにのみ適用できます。 この手順は、シンプル移行には適用できません。

始める前に

  • 管理権限を持っているアプリケーション ユーザのみがリカバリ URL にアクセスできます。

  • SAML SSO が有効になっている場合は、リカバリ URL がデフォルトで有効になります。 CLI からリカバリ URL を有効/無効にすることができます。 リカバリ URL を有効または無効にする CLI コマンドの詳細については、『Cisco Unified Communications のソリューション コマンド ライン インタフェース リファレンス ガイド』を参照してください。

手順


ステップ 1

ウェブブラウザのアドレスバーに、次の URL を入力します。https://<Unified CM-server-name>, ここで、Unified CM-server-name> はサーバーのホスト名または IP アドレスです。

ステップ 2

[シングル サインオンをバイパスするリカバリURL(Recovery URL to bypass Single Sign-On (SSO))] をクリックします。

ステップ 3

管理者ロールを持つアプリケーション ユーザのクレデンシャルを入力し、[ログイン(Login)]をクリックします。

ステップ 4

Cisco Unified CM Administration で、[システム(System)] > [SAML シングルサインオン(SAML Single Sign-On)] を選択します。

ステップ 5

[ すべてのメタデータをエクスポート ] をクリックして、ID プロバイダにアップロードするサーバのメタデータをダウンロードします。

ステップ 6

[IdP メタデータファイルの更新(Update IdP Metadata File)] をクリックして、IdP メタデータトラストファイルをインポートします。

ステップ 7

[参照(Browse)] をクリックして IdP メタデータトラストファイルを選択し、[IdP メタデータのインポート(Import IdP Metadata)] をクリックしてコラボレーションサーバーにインポートします。 [次へ(Next)]をクリックします。

ステップ 8

LDAP 同期済みで、標準 CCM スーパーユーザ権限を持つユーザを選択してメタデータファイルが適切に設定されているかどうかを確認し、 [テストを実行] をクリックします。

ステップ 9

[完了] をクリックして、クラスタ内のすべてのサーバで SAML SSO 設定を有効にします。

アプリケーションが更新されると、少し遅延があります。 SSO モードが「クラスター全体」の場合、 "Cisco SSOSP Tomcat"、および "Cisco UDS Tomcat" サービスは、クラスター内のすべてのノードで再起動します。


SAML SSO 展開の相互作用と制限

特長

機能の相互作用

Tomcat 証明書の再生成

Tomcat 証明書を再生成する場合、サービス プロバイダーで新しいメタデータ ファイルを生成し、そのメタデータ ファイルを IdP にアップロードします。

メタデータの再生成

以下のいずれかを実行すると、メタデータファイルが再生成されます。

  • 自己署名証明書を Tomcat 証明書に、またはその逆に変更します。

  • Tomcat 証明書を ITL 回復証明書に再発行します。

Cisco Unified Communications Manager は再生成されたメタデータファイルをダウンロードし、IdP にアップロードします。