SSOを有効にするようにIdentity Provider for Cisco Identity Serviceを設定します

概要

このドキュメントでは、シングル サインオン（SSO）を有効にする ID プロバイダー（IdP）の設定について説明します。

Cisco IdS 導入モデル

Product	導入
Unified CCX	共存
PCCE	CUIC（Cisco Unified Intelligence Center）と LD（ライブ データ）の共存
UCCE	2k 導入用の CUIC と LD の共存。 4k および 12k 導入用のスタンドアロン。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• Cisco Unified Contact Center Express（UCCX）リリース 11.5、Cisco Unified Contact Center Enterprise リリース 11.5、Packaged Contact Center Enterprise（PCCE）リリース 11.5（該当する場合）
• Microsoft Active Directory：Windows Server にインストールされた AD
• Active Directory フェデレーション サービス（ADFS）バージョン 2.0/3.0

注：このドキュメントは、スクリーンショットや例で UCCX を参照していますが、設定は Cisco アイデンティティ サービス（UCCX/UCCE/PCCE）や IdP と類似しています。

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。

背景説明

SSO の概要

シスコはさまざまな形式の多くのサービスを提供しています。エンド ユーザであれば、1 回のサインインですべてのシスコ サービスにアクセスできるようになることを望みます。任意のシスコ アプリケーションやデバイスから連絡先を見つけて管理する場合、使用可能なすべてのソース（企業ディレクトリ、Outlook、携帯電話の連絡先、Facebook、LinkedIn、履歴）を活用し、連絡先の応答可能性や最善の連絡方法を知るのに必要な情報を、共通の一貫した方法で表示させます。

SAML（セキュリティ アサーション マークアップ言語）を使用する SSO は、この要求に応えるためのものです。SAML/SSO は、共通アカウントと、IdP と呼ばれる認証 ID を使用して、複数のデバイスとサービスにログインできます。この SSO 機能は、UCCX/UCCE/PCCE 11.5 以降で使用できます。

設定の概要 

設定

認証タイプ

Cisco アイデンティティ サービス サポートは、ID プロバイダーのフォーム ベースの認証のみをサポートします。

ADFS でフォーム認証を有効にする方法については、これらの MSDN の記事を参照してください。

• ADFS 2.0 の場合は、次の Microsoft TechNet 記事を参照してください。
  http://social.technet.microsoft.com/wiki/contents/articles/1600.ad-fs-2-0-how-to-change-the-local-authentication-type.aspx
  
• ADFS 3.0 の場合は、次の Microsoft TechNet 記事を参照してください。
  https://blogs.msdn.microsoft.com/josrod/2014/10/15/enabled-forms-based-authentication-in-AD FS-3-0/

注：Cisco Identity Service 11.6以降では、フォームベース認証とKerberos認証の両方がサポートされています。Kerberos認証が機能するには、フォームベース認証を無効にする必要があります。

信頼関係の確立 

シングル サインオンに Cisco アイデンティティ サービスを使用するようにアプリケーションをオンボーディングおよび有効化するには、アイデンティティ サービス（IdS）と IdP の間でメタデータ交換を実行します。

• SAML SP メタデータ ファイル sp.xml をダウンロードします。
• [Settings] から、[Identity Service Management] ページの [IdS Trust] タブに移動します。

• 次の URL の IdP から IdP メタデータ ファイルをダウンロードします。
  https://<ADFSServer>/federationmetadata/2007-06/federationmetadata.xml

• [Identity Service Management] ページで、前の手順でダウンロードした ID プロバイダー メタデータ ファイルをアップロードします。

これは IdS メタデータをアップロードしてクレーム ルールを追加する手順です。ADFS 2.0 と 3.0 の場合の概要は、次のとおりです。

ADFS 2.0：

ステップ1:ADFSサーバで、図に示すように、[Start] > [All Programs] > [Administrative Tools] > [AD FS 2.0 Management]に移動します。

手順 2：図で示すとおり、[Add AD FS 2.0] > [Trust Relationship] > [Relying Party Trust] と移動します。

手順 3：図で示すとおり、[Import data about the relying party from a file] オプションを選択します。

手順 4：信頼当事者証明の設定を実行します。

ステップ5:[Relying Party Trust]のプロパティで、[Identifier]タブを選択します。

ステップ 6：ID を、sp.xml のダウンロード元となる Cisco アイデンティティ サーバの完全修飾ホスト名として設定します。

ステップ 7：信頼当事者証明を右クリックして、それから [Edit Claim Rules] をクリックします。

2 つのクレーム ルールを追加する必要があります。1 つは LDAP（Lightweight Directory Access Protocol）属性が一致する場合のルールであり、もう 1 つはカスタム クレーム ルールによるルールです。

uid：この属性は、アプリケーションが認証されたユーザを識別するために必要です。
user_principal：この属性は、Cisco アイデンティティ サービスが認証ユーザのレルムを識別するために必要です。

クレームR規則 1:

ルールをタイプの名前 NameID で追加します（LDAP 属性の値をクレームとして送信します）。

• Active Directory として属性ストアを選択します。
• LDAP 属性 User-Principal-Name を user_principal（小文字）にマップします。
• アプリケーション ユーザがログインして uid（小文字）にマップする userId として使用する必要がある LDAP 属性を選択します。

SamAccountName をユーザ ID として使用する場合の設定例を以下に示します。

• LDAP 属性 SamAccountName を uid にマップします。
• LDAP 属性 User-Principal-Name を user_principal にマップします。

UPN をユーザ ID として使用する必要がある場合の設定例を以下に示します。

• LDAP 属性 User-Principal-Name を uid にマップします。
• LDAP 属性 User-Principal-Name を user_principal にマップします。
               

PhoneNumber をユーザ ID として使用する必要がある場合の設定例を以下に示します。

• LDAP 属性 telephoneNumber を uid にマップします。
• LDAP 属性 User-Principal-Name を user_principal にマップします。

注：CUCM LDAP 同期のユーザ ID に設定された LDAP 属性が、ADFS クレーム ルール NameID の uid に対して設定された LDAP 属性と一致していることを確認する必要があります。これは Cisco Unified Intelligence Center（CUIC）および Finesse ログインを正しく機能させるための確認です。

注：このドキュメントでは、NameID、UCCX の FQDN などのクレーム ルール名や表示名に対する制約を参照します。カスタムのフィールドや名前はさまざまなセクションで適用できる場合がありますが、クレーム ルール名と表示名は、一貫性の維持のため、また命名規則のベストプラクティスとして、全体を通して標準に維持されます。

請求ルールe 0:

• 別のルール（タイプがカスタム クレーム ルールであり、Cisco アイデンティティ サーバの完全修飾ホスト名（FQDN）である名前を持つ）を追加し、そのルール テキストを追加します。
                                

  c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:transient", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] = "http://<ADFS Server FQDN>/ADFS/services/trust", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "<fully qualified hostname of IdS/UCCX>");

  
  
• Cisco アイデンティティ サーバ クラスタでは、すべての完全修飾ホスト名は、Cisco アイデンティティ サーバのプライマリ ノードまたはパブリッシャ ノードのホスト名です。
  
  
• Cisco アイデンティティ サーバの完全修飾ホスト名は大文字と小文字を区別するので、大文字小文字の違いを含め、Cisco アイデンティティ サーバの FQDN と厳密に突き合わされます。
  
  
• ADFS サーバの FQDN は大文字と小文字を区別するので、大文字小文字の違いを含め、ADFS FQDN と厳密に突き合わされます。

手順 8：図で示すとおり、[Relying Party Trust] を右クリックし、[Properties] をクリックして、[Advanced] タブを選択します。

手順 9：図で示すとおり、セキュア ハッシュ アルゴリズム（SHA）を SHA-256 として選択します。

ステップ 10：[OK] をクリックします。

ADFS 3.0：

ステップ1:ADFSサーバで、[Server Manager] > [Tools] > [AD FS Management]に移動します。

手順 2：[AD FS] > [Trust Relationship] > [Relying Party Trust] と移動します。

手順 3：[Import data about the relying party from a file] オプションを選択します。

手順 4：信頼当事者証明の設定を実行します。

ステップ5:[Relying Party Trust]のプロパティで、[Identifier]タブを選択します。

ステップ 6：ID を、sp.xml のダウンロード元となる Cisco アイデンティティ サーバの完全修飾ホスト名として設定します。

ステップ 7：信頼当事者証明を右クリックして、それから [Edit Claim Rules] をクリックします。

2 つのクレーム ルールを追加する必要があります。1 つは LDAP（Lightweight Directory Access Protocol）属性が一致する場合のルールであり、もう 1 つはカスタム クレーム ルールによるルールです。

uid：この属性は、アプリケーションが認証されたユーザを識別するために必要です。
user_principal：この属性は、Cisco アイデンティティ サービスが認証ユーザのレルムを識別するために必要です。

クレームR規則 1:

ルールをタイプの名前 NameID で追加します（LDAP 属性の値をクレームとして送信します）。

• Active Directory として属性ストアを選択します。
• LDAP 属性 User-Principal-Name を user_principal（小文字）にマップします。
• アプリケーション ユーザがログインして uid（小文字）にマップする userId として使用する必要がある LDAP 属性を選択します。

SamAccountName をユーザ ID として使用する場合の設定例を以下に示します。

• LDAP 属性 SamAccountName を uid にマップします。
• LDAP 属性 User-Principal-Name を user_principal にマップします。

UPN をユーザ ID として使用する必要がある場合の設定例を以下に示します。

• LDAP 属性 User-Principal-Name を uid にマップします。
• LDAP 属性 User-Principal-Name を user_principal にマップします。
               

PhoneNumber をユーザ ID として使用する必要がある場合の設定例を以下に示します。

• LDAP 属性 telephoneNumber を uid にマップします。
• LDAP 属性 User-Principal-Name を user_principal にマップします。

注：CUCM LDAP 同期のユーザ ID に設定された LDAP 属性が、ADFS クレーム ルール NameID の uid に対して設定された LDAP 属性と一致していることを確認する必要があります。これは Cisco Unified Intelligence Center（CUIC）および Finesse ログインを正しく機能させるための確認です。

注：このドキュメントでは、NameID、UCCX の FQDN などのクレーム ルール名や表示名に対する制約を参照します。カスタムのフィールドや名前はさまざまなセクションで適用できる場合がありますが、クレーム ルール名と表示名は、一貫性の維持のため、また命名規則のベストプラクティスとして、全体を通して標準に維持されます。

請求ルールe 0:

• 別のルール（タイプがカスタム クレーム ルールであり、Cisco アイデンティティ サーバの完全修飾ホスト名（FQDN）である名前を持つ）を追加し、そのルール テキストを追加します。
                                

  c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:transient", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] = "http://<ADFS Server FQDN>/ADFS/services/trust", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "<fully qualified hostname of IdS/UCCX>");

  
  
• Cisco アイデンティティ サーバ クラスタでは、すべての完全修飾ホスト名は、Cisco アイデンティティ サーバのプライマリ ノードまたはパブリッシャ ノードのホスト名です。
  
  
• Cisco アイデンティティ サーバの完全修飾ホスト名は大文字と小文字を区別するので、大文字小文字の違いを含め、Cisco アイデンティティ サーバの FQDN と厳密に突き合わされます。
  
  
• ADFS サーバの FQDN は大文字と小文字を区別するので、大文字小文字の違いを含め、ADFS FQDN と厳密に突き合わされます。

手順 8：[Relying Party Trust] を右クリックし、[Properties] をクリックして、[Advanced] タブを選択します。

手順 9：図で示すとおり、セキュア ハッシュ アルゴリズム（SHA）を SHA-256 として選択します。

ステップ 10：[OK] をクリックします。

これらは、手順 10 の後に必ず行うべき手順です。

信頼当事者証明（Cisco アイデンティティ サービス）の署名入り SAML アサーションの有効化

ステップ 1：[Start] をクリックし、powershell と入力して Windows PowerShell を開きます。

手順 2：ADFS コマンドレットを PowerShell に、Add-PSSnapin Microsoft.Adfs.Powershell コマンドを実行して追加します。

ステップ3:Set-ADFSRelyingPartyTrust -TargetName <Relying Party Trust Name>コマンドを実行します

-SamlResponseSignature "MessageAndAssertion"

          

注：ADFS 3.0 を使用しているのであれば、コマンドレットがロールと機能の追加に含まれてすでにインストールされているため、手順 2 は不要の場合があります。

注：信頼当事者証明は大文字と小文字を区別するので、大文字小文字の違いを含め、信頼当事者証明のプロパティの [Identifier] タブで設定された内容と突き合わされます。

注：UCCXバージョン12.0以降のCisco Identity ServiceはSHA-256をサポートします。証明書利用者信頼はSAML要求の署名にSHA-256を使用し、応答でADFSが同じことを行うことを期待します。

フェデレーテッド ADFS のマルチドメイン設定の場合

ADFS でのフェデレーションの場合、特定のドメイン内の ADFS が、他の構成済みドメインのユーザに対してフェデレーテッド SAML 認証を提供する場合には、追加の構成が必要になります。

このセクションでは、「プライマリ ADFS」という用語は、IdS で使用する必要がある ADFS を指しています。「フェデレーテッド ADFS」という用語は、そのユーザに IdS を介したログインが許可される（つまりプライマリ ADFS である）ADFS を示しています。

フェデレーテッド ADFS 設定

各フェデレーテッド ADFS では、前のセクションで説明したとおり、信頼当事者証明をプライマリ ADFS に対して作成し、クレーム ルールを設定する必要があります。

プライマリ ADFS 設定

プライマリ ADFS の場合、IdS の信頼当事者証明とは別に、次の追加設定が必要です。

クレーム プロバイダー証明を、フェデレーションを設定する必要がある ADFS とともに追加します。

クレーム プロバイダー証明で、[Pass through or Filter an Incoming Claim] ルールが、オプションとして [Pass through all claim values] を指定して設定されていることを確認します。

• Name ID
• [Incoming Claim Type] ドロップ ボックスから NameID を選択します。
• 着信 NameID 形式のオプションとして [Transient] を選択します。
• uid：これはカスタム クレームです。値 uid を [Incoming Claim Type] ドロップ ボックスに入力します。
• user_principal：これはカスタム クレームです。値 user_principal を [Incoming Claim Type] ドロップ ボックスに入力します。

IdS の信頼当事者証明で、[Pass though or Filter an Incoming Claim] ルールを、[Pass through all claim values] をオプションで指定して追加します。

• NameIDFromSubdomain
• [Incoming Claim Type] ドロップ ボックスから NameID を選択します。
• 着信 NameID 形式のオプションとして [Transient] を選択します。
• uid：これはカスタム クレームです。値 uid を [Incoming Claim Type] ドロップ ボックスに入力します。
• user_principal：これはカスタム クレームです。値 user_principal を [Incoming Claim Type] ドロップ ボックスに入力します。

ADFS自動証明書ロールオーバー

• 証明書の自動ロールオーバーは、UCCX 11.6.1以降でサポートされています。[これは、Fedletライブラリをバージョン14.0にアップグレードすることで、UCCX 11.6で修正されました]

Kerberos認証（統合Windows認証）

統合Windows認証(IWA)は、ユーザの認証メカニズムを提供しますが、クレデンシャルをネットワーク経由で送信することはできません。統合Windows認証を有効にすると、 はチケットに基づいて動作し、非セキュアネットワークを介して通信するノードが、セキュアな方法で互いのアイデンティティを証明できるようにします。ユーザは、Windowsマシンにログインした後、ドメインにログインできます。 

注:Kerberos認証は11.6以降でのみサポートされています。

ドメインコントローラ(DC)にすでにログインしているドメインユーザは、クレデンシャルを再入力しなくても、SSOクライアントにシームレスにログインできます。 非ドメインユーザの場合、IWAはNTLM(New Technology Local Area Network Manager)にフォールバックし、ログインダイアログが表示されます。IWA認証によるIdSの認定は、ADFS 3.0に対するKerberosで行われます。

ステップ1:Windowsコマンドプロンプトを開き、管理者ユーザとして実行して、setspnコマンドでhttpサービスを登録します 

             setspn -s http/<ADFS url> <domain>\<account name> .

ステップ2：フォーム認証を無効にし、イントラネットサイトのWindows認証を有効にします。[ADFS Management] > [Authentication Policies] > [Primary Authentication] > [Global Settings] > [Edit]に移動します。[Intranet]で、[Windows Authentication]のみがオンになっていることを確認します([Uncheck Form Authentication])。

IWAサポートのためのMicrosoft Internet Explorerの設定

ステップ1:[Internet Explorer] > [Advanced] > [Enable Integrated Windows Authentication]にチェックマークが入っていることを確認します。

ステップ2:[Security] > [Intranet zones] > [Sites] にADFS URLを追加する必要があります(winadcom215.uccx116.comはADFS URLです)

ステップ3：イントラネットサイトのログイン済み資格情報を使用するために、[Internet Explorer] > [Security] > [Local Intranet] > [Security Settings] > [User Authentication - Logon]が設定されていることを確認します。

IWAサポートのためのMozilla Firefoxの設定

ステップ1:Firefoxのコンフィギュレーションモードに入ります。Firefoxを開き、URLにabout:configと入力します。リスクステートメントを受け入れます。

ステップ2:ntlmを検索し、network.automatic-ntlm-auth.allow-non-fqdnを有効にして、trueに設定します。

ステップ3:network.automatic-ntlm-auth.trusted-urisをドメインまたは明示的にADFS URLに設定します。

IWAサポートのためのGoogle Chromeの設定が必要

WindowsのGoogle ChromeはInternet Explorerの設定を使用するため、Internet Explorerの[ツール] > [インターネットオプション]ダイアログ、またはサブカテゴリの[ネットワークとインターネット]の[インターネットオプション]のコントロールパネルから設定します。

SSO の詳細設定：

このドキュメントでは、Cisco アイデンティティ サービスと統合する SSO の設定について、IdP の面から説明しています。詳細については、個々の製品のコンフィギュレーション ガイドを参照してください。

• Unified CCX
• UCCE
• PCCE

確認

この手順は、信頼当事者証明が Cisco IdS と IDP との間で正しく設定されているかどうかを判別するために使用します。

• ブラウザからURL https://<ADFS_FQDN>/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=<IDS_FQDN>を入力します
• ADFS はログイン フォームを提供します。これは、上記の設定が正しいときに使用できます。
• 認証が成功するには、ブラウザが https://<IDS_FQDN>:8553/ids/saml/response にリダイレクトし、チェックリスト ページが表示される必要があります。

注：検証プロセスの一部として表示されるチェックリスト ページはエラーではなく、証明が正しく設定されていることの確認となります。

トラブルシュート

トラブルシューティングについては、https://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-express/200662-ADFS-IdS-Troubleshooting-and-Common-Prob.htmlを参照してください。

   

UCCX SSOバイパス/リカバリURL

• Cisco Unified CCX AdministrationのURL:https://<IP_or_FQDN>/appadmin/recovery_login.htm
• Cisco Unified CCX ServiceabilityのURL:https://<IP_or_FQDN>/uccxservice/recovery_login.htm

SSOの無効化

• GUI：[CCX Administration] > [Single Sign-On (SSO)] > [Disable]に移動します。
• CLI:set authmode non_sso(このコマンドはPubとSubの両方のSSOを無効にする必要があります。ハイアベイラビリティ(HA)クラスタの場合は、UCCXノードのいずれかから実行できます)

スクリーンショット

CCX Administration:Non_SSO:

[CCX Administration] - [SSO Enabled]:

Finesseログイン：非SSO:

Finesseログイン – SSO有効：

CUIC - Non_SSO:

CUIC - SSO有効：