SAML SSO は生産性を向上させると同時に、エンタープライズのセキュリティを向上させます。 SAML SSO は、SAML 2.0 プロトコルを使用して、Cisco Collaboration インフラストラクチャをサードパーティの ID プロバイダに接続し、異なるドメインや製品の管理者とクライアントのログインに安全なログインと認証サービスを提供します。 ID プロバイダがシングル ログインを保存するため、Worker の生産性が向上します。一度コラボレーション アプリケーションの 1 つに正常にログインしたら、再度ログインする必要なく、それらのアプリケーションにアクセスできます。

SAML SSO は ID フレームワークに以下の利点を提供します。

• 異なるユーザ名とパスワードの組み合わせを入力する必要性を排除することで、パスワードの手間を軽減します。

• アプリケーションをホストするシステムの認証をサードパーティのシステムに転送します。

• 認証情報を保護および保護します。 SAML SSO は暗号化機能を提供し、IdP、サービスプロバイダー、ユーザ間で受け渡される認証情報を保護します。 SAML SSO は、IdP とサービスプロバイダーの間で受け渡される認証メッセージを外部ユーザから隠すこともできます。

• 同じ ID の資格情報を再入力する時間が短縮されるため、生産性が向上します。

• パスワードのリセットのためのヘルプ デスクへの電話が減り、それによりコストが削減され、さらなる節約が可能になります。

IdP との信頼関係

SAML SSO 展開は、サービス プロバイダー (Cisco Unified Communications Manager) とサードパーティのアイデンティティ プロバイダー間の信頼関係の作成に依存しています。 次の 2 つの SSO モードのいずれかを使用して、SAML SSO 関係を設定できます。

• ノードごとの配置—UC メタデータの zip ファイルには、各ノードの個別の XML ファイルが含まれています

• クラスターごとの配置 - クラスターの単一のメタデータ ファイル

この信頼関係は、メタデータ ファイルの最初の交換を通じて作成されます。 Cisco UC メタデータ ファイルは、次の情報を含む XML ファイルです。

• 一意の識別子

• 組織

• この情報の有効期限

• キャッシュ期間

• この情報の XML 署名

• 連絡先担当者

• エンティティの一意の識別子 (エンティティ ID)

• この SAML インスタンスの SAML ロールの説明 (アイデンティティプロバイダ、サービスプロバイダなど)

認証

IdP により認証が提供されると、Cisco Unified Communications Manager リソースへのユーザアクセスは、ローカルに設定されたアクセスコントロールグループとそれらのグループが提供するロール権限により決定されます。

SAML SSO 構成および ID プロバイダの要件

ID プロバイダの構成情報や要件など、SAML SSO の詳細については、『 Cisco Unified Communications アプリケーションのための SAML SSO 導入ガイド』を参照してください。

SAML SSO を展開しておらず、ユーザを会社の LDAP ディレクトリと同期させている場合、LDAP 認証により、会社の LDAP ディレクトリに保存されている資格情報と照合してユーザのパスワードを認証できます。 このオプションにより、Cisco Unified Communications Manager の Identity Management System (IMS) ライブラリが会社の LDAP ディレクトリを使用して、LDAP 同期ユーザのユーザパスワードを認証できるようになります。

エンドユーザがセルフケアポータルにログインする場合、会社の LDAP ディレクトリで設定されている会社のパスワード (AD パスワードなど) を入力します。

このオプションが設定されている場合:

• LDAP からインポートされたユーザのエンドユーザパスワードは、簡単なバインド操作によって、企業ディレクトリに対して認証されます。

• ローカルユーザのエンドユーザパスワードは、Unified CM データベースに対して認証されます。

• アプリケーションのユーザ パスワードは、Unified CM データベースに対して認証されます。

• エンドユーザの PIN は Unified CM データベースに対して認証されます。

サードパーティの ID プロバイダで SAML SSO を展開していない場合、または LDAP 認証が設定されていない場合、エンドユーザには Cisco Unified Communications Manager データベースに対するローカル認証方式が必要です。 このオプションでは、ユーザ パスワードはローカル データベースに保存され、[エンド ユーザ設定] で管理されます。

アプリケーションユーザとエンドユーザ PIN の両方について、認証の管理には常にローカルデータベース認証方式が使用されます。 次の表では、3 つの主なパスワード タイプとその管理方法を示します。

（注）	すべてのローカルパスワードと PIN は暗号化された形式でデータベースに保存されます。

OAuth 認証フレームワークは、RFC 6749 に基づいて IETF によって定義されています。OAuth 2.0 認証プロトコルにより、リソース所有者 (たとえば、Cisco Unified Communications Manager) は、HTTP サービスへの制限付きアクセスを取得するために、サードパーティのアプリケーションを認証できます。 Cisco Unified Communications Manager では、OAuth フレームワークはアクセストークンを使用してアクセスを提供し、トークンの有効期間中、リソースへのアクセスを提供するためにトークンを更新します。 OAuth により、情報にアクセスしようとするときにウェブサイトがパスワードを要求する必要がなくなります。 OAuth では、リソース所有者がクライアントがサーバ上のリソースにアクセスすることを許可します。

Cisco Jabber クライアントは OAuth リフレッシュログインを使用して、Cisco Unified Communications Manager からリソースへのアクセスを取得します。 最初のログインの後、OAuth アクセス トークンと更新トークンは、トークンの有効期間中、リソースへのシームレスなアクセスを提供します。

OAuth リフレッシュログイン

OAuth リフレッシュログインでは、短命のアクセストークンにより Jabber が認証され、トークンの寿命中、アクセスが提供されます (アクセストークンのデフォルトの有効期間は 60 分です)。 古いアクセス トークンが期限切れになると、有効期限が長い更新トークンが Jabber に新しいアクセス トークンを提供します。 更新トークンが有効である限り (デフォルトの有効期間は 60 日)、Jabber クライアントは新しいアクセス トークンを動的に取得できるため、ユーザが再認証する必要なく、シームレスなアクセスを提供できます。

OAuth トークンが有効期間の 75% に達するたびに、エンドユーザのアプリケーションは新しいアクセストークンを要求し、CUCM はエンドユーザを認証するための新しいアクセストークンを提供します。 更新トークンが有効期限の 100% に達した場合、新しいアクセス トークンを生成する前に再認証する必要があります。

SIP OAuth モード

SIP OAuth モードは OAuth フレームワークを強化し、SIP 回線の Oauth アクセストークンと更新トークンの使用を可能にします。これにより、Jabber クライアントに LSC 証明書をインストールする必要がなくなります。 SIP OAuth モードでは、CAPF なしで Jabber の安全な署名とメディアが可能です。 トークンの検証は SIP 登録中に完了します。 このモードでは、Jabber は LSC なしでメディアとシグナリングの暗号化を実行でき、Unified CM で混合モードを有効にする必要はありません。

OAuth のキーの再生成

OAuth トークンの署名と暗号化に使用されるキーが危険にさらされていると思われる場合は、次の CLI コマンドを使用して新しいキーを生成します。 署名キーは非対称で RSA ベースであるのに対し、暗号キーは対称キーです。

• キー再生認証暗号化設定

• キー再生認証署名設定

（注）	OAuth キーが再生成された場合は、Jabber OAuth ログインが動作するように、すべての IM and Presence ノードで Cisco XCP 認証サービスを再起動する必要があります。