承認コード付与フローの導入とトラブルシューティング – OAuth機能拡張：Cisco Collaboration Solutions 12.0

概要

このドキュメントでは、特にモバイル上のJabberで、さまざまなデバイス間のJabberユーザエクスペリエンスを向上させるために、認証コード許可(AUTHORIZATION)フローが更新トークンに基づくしくみを説明します。

前提条件

要件

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

• Cisco Unified Communications Manager(CUCM)12.0バージョン
• シングルサインオン(SSO)/SAML
• Cisco Jabber
• Microsoft ADFS
• アイデンティティプロバイダー(IdP)

これらのトピックの詳細については、次のリンクを参照してください。

• Cisco Unified Communications用SAML SSO導入ガイド
• Unified Communications Manager SAML SSOの設定例：
• SAML SSO 向け AD FS 2.0 バージョンのセットアップ例:

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアに基づいています。

• Microsoft ADFS(IdP)
• LDAP Active Directory
• Cisco Jabber クライアント
• CUCM 12.0

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

現在、インフラストラクチャを使用したJabber SSOフローは、CUCM Authzサービスが短期アクセストークンを割り当てる暗黙的許可フローに基づいています。

ポストアクセストークンの期限切れ、CUCMは再認証のためにJabberをIdPにリダイレクトします。

これにより、ユーザエクスペリエンスが低下します。特に、ユーザがクレデンシャルを頻繁に入力するように求められるモバイル上のjabberでは問題が発生します。

また、Security Re-Architecture Solutionでは、SSOと非SSOの両方のシナリオでJabberとエンドポイントのログインフローを統合するための、認証コード付与フロー(Refresh Tokensアプローチ（エンドポイント/他のコラボレーションアプリケーションに拡張可能）も提案しています。

主な機能

• 承認コードの付与フローは、更新トークン（エンドポイントやその他のコラボレーションアプリケーションに拡張可能）に基づいて、さまざまなデバイス（特にモバイル上のJabber）のJabberユーザエクスペリエンスを向上させます。
• 自己完結型および暗号化OAuthトークンをサポートし、さまざまなコラボレーションアプリケーションがクライアントのリソース要求を検証および応答できるようにします。
• 暗黙的な認可フローモデルが保持され、後方互換性が確保されます。これにより、認証コード許可フローに移動していない他のクライアント（RTMTなど）のシームレスなパスも可能になります。

重要な考慮事項

• 古いJabberクライアントが新しいCUCMと連携できるようにする実装（暗黙的な認可と認可コードの認可フローの両方をサポートするため）。 また、新しいJabberは古いCUCMと連携できます。Jabberは、CUCMが認証コード認可フローをサポートしているかどうかを判別できます。また、このモデルをサポートしている場合にのみ、暗黙的な認可フローを切り替えて使用します。
• AuthZサービスはCUCMサーバで実行されます。
• AuthZは暗黙的な許可フローのみをサポートします。これは、更新トークン/オフラインアクセストークンがなかったことを意味します。クライアントが新しいアクセストークンを必要とするたびに、ユーザはIdPで再認証する必要があります。
• アクセストークンは、展開がSSO対応の場合にのみ発行されます。この場合、非SSO展開は機能せず、すべてのインターフェイスで一貫してアクセストークンが使用されませんでした。
• アクセストークンは自己完結型ではなく、トークンを発行したサーバーのメモリに保持されます。CUCM1がアクセストークンを発行した場合は、CUCM1によってのみ確認できます。クライアントがCUCM2のサービスにアクセスしようとすると、CUCM2はCUCM1でそのトークンを検証する必要があります。ネットワーク遅延（プロキシモード）。
• ユーザがIdPで再認証を行う場合（通常、いくつかの要因に応じて1時間から8時間の間で実行される）、英数字のキーパッドでクレデンシャルを再入力する必要があるため、モバイルクライアントでのユーザエクスペリエンスは非常に悪いです。
• 複数のインターフェイスを介して複数のアプリケーションと通信するクライアントは、複数のクレデンシャル/ブロックを維持する必要があります。2つの類似クライアントから同じユーザがログインするシームレスなサポートはありません。たとえば、ユーザAは2つの異なるiPhoneで実行されるjabberインスタンスからログインします。
• AuthZ:SSOと非SSOの両方の導入をサポートします。
• 暗黙的な認可フロー+認可コード認可フローをサポートするAuthZ。下位互換性があるため、RTMTなどのクライアントも適応するまで作業を継続できます。
• 認証コード認可フローでは、AuthZはアクセストークンとリフレッシュトークンを発行します。refreshトークンを使用すると、認証を必要とせずに、別のアクセストークンを取得できます。
• アクセストークンは、自己完結型、署名型、暗号化型であり、JWT（JSON Webトークン）標準（RFC準拠）を使用します。
• 署名キーと暗号化キーは、クラスタに共通です。クラスタ内の任意のサーバがアクセストークンを確認できます。メモリ内で維持する必要はありません。
• CUCM 12.0で実行されるサービスは、クラスタ内の中央集中型の認証サーバです。
• 更新トークンはデータベース(DB)に保存されます。 管理者は、必要に応じて取り消す必要があります。失効は、useridまたはuseridとclientIDに基づいています。
• 署名付きアクセストークンを使用すると、異なる製品がアクセストークンを保存しなくても検証できます。設定可能なアクセストークンと更新トークンの有効期間（デフォルトは1時間と60日）。
• JWTフォーマットはSparkと連携しており、将来的にSparkハイブリッドサービスとの相乗効果が期待できます。
• 同じユーザが2台の類似デバイスからログインできます。例：ユーザAは、2つの異なるiPhoneで実行されるjabberインスタンスからログインできます。

承認コード付与フローの要素

• 認証Zサーバ
• 暗号キー
• 署名キー
• トークンの更新

設定

この機能はデフォルトでは有効になっていません。

ステップ1：この機能を有効にするには、[System] > [Enterprise Parameters]に移動します。

ステップ2：図に示すように、Refresh Login Flowを使用したパラメータOAuthを[Enabled]に設定します。

• アクセストークンは署名され、暗号化されます。署名と暗号化キーはクラスタに共通です。つまり、クラスタ内の任意のノードがアクセストークンを検証できます。
• アクセストークンはJWT形式(RFC 7519)です。
• アクセストークンは、古いトークン形式と新しいトークン形式の両方に適用されるエンタープライズパラメータ(OAuth Access Token Expiry timer)を再利用します。
• デフォルト値：60分
• 最小値：1分
• 最大値：1440分

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjhkMGQ1MzI0LWY0ZjAtNGIwYi04MTFlLTRhNTlmZGI2YjcyMjpjMjc3MGM5N2JkYTlkMzRmZDA1YTdlYTFhZWQzZTU0Y2E4MGJkZDdlZTM1ZDk3MDNiNjBiNTQ5MTBiZDQ0ODRiIn0.eyJwcml2YXRlIjoiZXlKaGJHY2lPaUprYVhJaUxDSmpkSGtpT2lKS1YxUWlMQ0psYm1NaU9pSkJNVEk0UTBKRExVaFRNalUySWl3aWEybGtJam9pT0dRd1pEVXpNalF0WmpSbU1DMDBZakJpTFRneE1XVXROR0UxT1daa1lqWmlOekl5T21Vd1ptUm1ZMk16WlRRMU5ERTFOV0ZpTkRJek5tRTJOMlV4T0RCbU1qWmxZMkl3WXpJeE56SXlOREJtWlRFellXWXlOak14TkRkalpHVXpNR1l3TjJJaWZRLi5xQWd6aGdRaTVMMkdlaDl5V2RvN25nLmdMTHNpaTRjQk50c1NEUXRJTE51RWRnWTl4WkJVczJ4YzBaeTFGQjZQNmNzWWJfZkRnaDRZby04V1NaNjUzdXowbnFOalpXT1E1dGdnYW9qMlp6ZFk2ZzN2SWFHbF9JWUtNdkNIWWNscmt4YUFGTk5MWExLQlJmaTA2LVk2V3l1dUdxNmpNWk5DbnlKX1pTbUpkVFQwc1Z4RTdGTXVxaUJsMElrRGdyVDdvOFNXMEY5cXFadndEZDJSaDdqNkRJWGdkS3VtOWltU2xNU1pjejhueVdic01Udk5yMWY0M25VenJzMHk5WWN6NnBDX0czZmlWYjJsX2VWLVFkcFh4TUo2bnZodXcydjRiUGVkM3VMQlpaVW1oQ3B6TUVDdW5NMlh1TVBrTGdlS1NqWG44aGhPRFNVcW1WQ0Uta3RZdnRBc2Q0RnJxcGNxWlZiS0ZiVTFRbU0wV2pMYVJtUk9IVllQVkc0a3FBdTRWalVMUzVCRWszNnZ4Nmp3U3BMUy1IdTcwbVRNcmR3dmV5Q2ZOYkhyT0FlVmVvekFIR3JqdGlmaFpmSFVUTWZiNkMtX2tOQVJGQWdDclZTZy0wUzlxb1JvTWVkUENETEE4MDJiaWwtNDJjOC15MWo4X1FVaC02UUtCV2dodVd4VWtBODRpekFFaWl0QTlsSHFKM3Nxd2JFNURkZmhIay05bTJfTTN5MWlWVkdoRVQ3ZW9XVDBqWllnRGRBQjFzUGwxLTlaSFNYYmsydTE3SkJVRV9FOXI0V0tWMnBqWGtiN0lQSWgtQ3JWQTZkcVdQRHVIbmx1V19wblNLYnYtTkZVbGQ0WEY3cmZLYmQySlg4eUhhX05pOVVVUnUwZVdsNWxGRUVabklubmFKZEdHLUZrb3VuN2xHSFlwSE4ydXVudmRnOHZVZzZsa0JPbmozeUFjc1ZTMGxKc1NWdUxFYldwd2c4YjdBdDM3d3AtMWt2Y1ZQaWpCQ1lCV181d2JzbTFYd2k4MVc2WHVpNzMzQVg3cEJVQnBfT2VRNzQ2ZXJJekNUUFZCYUpZUGJuZWEtdFhsU3RmZzBGeVRmbnhnX1Vzazl3QXJkemE4c204T0FQaWMxZmFQOG0uUTdFN0FVX2xUVnNmZFI2bnkydUdhQSJ9.u2fJrVA55NQC3esPb4kcodt5rnjc1o-5uEDdUf-KnCYEPBZ7t2CTsMMVVE3nfRhM39MfTlNS-qVOVpuoW_51NYaENXQMxfxlU9aXp944QiU1OeFQKj_g-n2dEINRStbtUc3KMKqtz38BFf1g2Z51sdlnBn4XyVWPgGCf4XSfsFIa9fF051awQ0LcCv6YQTGer_6nk7t6F1MzPzBZzja1abpm--6LNSzjPftEiexpD2oXvW8Vl0Z9ggNk5Pn3Ne4RzqK09J9WChaJSXkTTE5G39EZcePmVNtcbayq-L2pAK5weDa2k4uYMfAQAwcTOhUrwK3yilwqjHAamcG-CoiPZQ

 

OAuth Refresh Token Expiry Timer” parameter in enterprise parameters page in CUCM.
Path: System -> Enterprise parameters
Values are integers ranging from 1 – 90
Minimum lifetime = 1 Day
Default lifetime = 60 days
Maximum lifetime = 90 days

新しいアクセストークンは、クライアントが1つのアクセストークンを要求するたびに発行されます。古いバージョンは、次の限り有効です。

• 署名/暗号化キーは変更されていません
• 有効性（トークン内に格納）が壊れます。
• JSON Webトークン：次の3つの部分で構成されます。ドットで区切られます。ヘッダー、ペイロード、および署名。

アクセストークンの例：

• 太字で強調表示されているトークンの先頭にヘッダーがあります。
• 中央の部分がペイロードです。
• 最後に、トークンが太字で強調表示されている場合はシグニチャです。

ネットワーク図

関連するコールフローの概要を次に示します。

トークンの更新

• 更新トークンが署名されています。
• Refreshトークンは、データベース内のrefreshtokendetailsテーブルに、自身のハッシュ値として格納されます。これは、DBによるレプリケーションを防止するためのものです。これは、誰かが選択できるためです。テーブルを確認するには、次のコマンドを実行します。

  run sql select * from refreshtokendetails

  または判読可能な有効日付を使用して：
  

  run sql select pkid,refreshtokenindex,userid,clientid,dbinfo('utc_to_datetime',validity) as validity,state from refreshtokendetails

警告：有効期限が切れると、更新トークンがDBからフラッシュされます。タイマースレッドは毎日午前2時に実行されます（UIでは構成できませんが、リモートサポートアカウントで変更できます）。テーブルに多数のアクセストークンがある場合は、無効であり、フラッシュする必要があります。これにより、CPUスパイクが発生する可能性があります。

Sample refresh token:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjhkMGQ1MzI0LWY0ZjAtNGIwYi04MTFlLTRhNTlmZGI2YjcyMjpjMjc3MGM5N2JkYTlkMzRmZDA1YTdlYTFhZWQzZTU0Y2E4MGJkZDdlZTM1ZDk3MDNiNjBiNTQ5MTBiZDQ0ODRiIn0.eyJleHAiOjE1MDI2MjAwNTIsImlzcyI6IjhkMGQ1MzI0LWY0ZjAtNGIwYi04MTFlLTRhNTlmZGI2YjcyMiIsInR5cCI6InVzZXIiLCJ0aWQiOiJiOTkxMjIxZi1mNDJlLTRlNTItODg3MS1jODc2ZTYzNWRkNWIiLCJjdHlwIjoicmVmcmVzaCIsImNjaWQiOiJDM2IwYWZmZWZlMTQzOTA0MTY4M2U5YzJjMzdkMzZmNDM4ZWYwZWYyN2MwOTM4YWRjNjIyNmUwYzAzZDE2OWYyYSJ9.creRusfwSYAMAtttS2FIPAgIVvCiREvnzlouxeyGVndalJlMa-ZpRqv8FOBrsYwqEyulrl-TeM8XGGQCUvFaqO9IkhJqSYz3zvFvvySWzDhl_pPyWIQteAhL1GaQkue6a5ZegeHRp1sjEczKMLC6H68CHCfletn5-j2FNrAUOX99Vg5h4mHvlhfjJEel3dU_rciAIni12e3LOKajkzFxF6W0cXzzujyi2yPbY9gZsp9HoBbkkfThaZQbSlCEpvB3t7yRfEMIEaHhEUU4M3-uSybuvitUWJnUIdTONiWGRh_fOFR9LV3Iv9J54dbsecpsncc369pYhu5IHwvsglNKEQ

 

更新トークンの取り消し

管理者は、userIDまたはuserIDとClientIDを使用して、ユーザーまたはデバイスのみの更新トークンのすべての更新トークンを取り消す機能を備えています。

ユーザのデバイスベースのRTを取り消すには、次の手順を実行します。

• ユーザxyzとclient_id abcによって識別されるデバイスのRTを取り消します。
• https://cucm-193:8443/ssosp/token/revoke?user_id=xyz&client_id=abc

署名キーと暗号化キー

• 署名キーはRSAベースで、公開/秘密キーペアを持つ。
• 暗号化キーは対称キーです。
• これらのキーはパブリッシャでのみ作成され、クラスタ内のすべてのノードに分散されます。
• リストされているオプションを使用して、署名キーと暗号化キーの両方を再生成できます。ただし、これは、管理者がキーが侵害されたと思っている場合にのみ行う必要があります。これらのキーを再生成すると、AuthZサービスによって発行されたすべてのアクセストークンが無効になります。
• 署名キーは、UIおよびCLIを使用して再生成できます。
• 暗号キーはCLIでのみ再生成できます。

CUCMの[Cisco Unified OS Administration]ページからAuthz証明書(署名キー)を再生成すると、図のように表示されます。

CLIコマンドを使用したAuthz署名キーの再生成を図に示します。

管理者は、CLIを使用して認証キーと暗号化キーを表示できます。キーのハッシュは、元のキーではなく表示されます。

キーを表示するコマンドは次のとおりです。

署名キー：show key authz signingと図に示すように。

暗号キー:show key authz encryptionと図に示すように。

注：署名authzと暗号化authzは常に異なります。

確認

ここでは、設定が正常に機能しているかどうかを確認します。

Cisco Unity Connection(CUC)サーバでOAuthを使用する場合、ネットワーク管理者は2つの手順を実行する必要があります。

ステップ1:OAuthトークン署名と暗号化キーをCUCMから取得するようにUnity Connectionサーバを設定します。

ステップ2:CUCサーバでOAuthサービスを有効にします。

注：署名キーと暗号化キーを取得するには、CUCMホストの詳細とCUCM AXLアクセスが有効なユーザアカウントを使用してUnityを設定する必要があります。これが設定されていない場合、UnityサーバはCUCMからOAuthトークンを取得できず、ユーザのボイスメールログインを使用できません。

[Cisco Unity Connection Administration] > [System Settings] > [Authz Servers]に移動します

トラブルシュート

ここでは、設定のトラブルシューティングに使用できる情報を示します。

注：OAuthを使用していて、Cisco Jabberユーザがログインできない場合は、CUCMおよびインスタントメッセージングおよびプレゼンス(IM&P)サーバから署名および暗号化キーを必ず確認してください。

ネットワーク管理者は、すべてのCUCMおよびIM&Pノードで次の2つのコマンドを実行する必要があります。

• show key authz signing
• show key authz encryption

署名authzと暗号化authzの出力がすべてのノードで一致しない場合は、再生成する必要があります。これを実行するには、次の2つのコマンドをすべてのCUCMおよびIM&Pノードで実行する必要があります。

• set key regen authz encryption
• set key regen authz signing

その後、すべてのノードでCisco Tomcatサービスを再起動する必要があります。

キーの不一致に加えて、次のエラー行がCisco Jabberのログに表示されます。

2021-03-30 14:21:49,631 WARN  [0x0000264c] [vices\impl\system\SingleSignOn.cpp(1186)] [Single-Sign-On-Logger] [CSFUnified::SingleSignOn::Impl::handleRefreshTokenFailure] - Failed to get valid access token from refresh token, maybe server issue.

ssoアプリケーションログは次の場所で生成されます。

• file view activelog platform/log/ssoApp.logログ収集のトレース設定は不要です。SSOアプリケーションの操作が実行されるたびに、ssoApp.logファイルに新しいログエントリが生成されます。

• SSOSPログ： file list activelog tomcat/logs/ssosp/log4j
  ssoが有効になるたびに、この場所にssosp00XXX.logという名前の新しいログ・ファイルが作成されます。その他のSSO操作とすべてのOauth操作もこのファイルにログインします。

• 証明書ログ： file list activelog platform/log/certMgmt*.log
  AuthZ証明書が再生成されるたびに（UIまたはCLI）、このイベントに対して新しいログファイルが生成されます。
  authz暗号化キーの再生成では、このイベントに対して新しいログファイルが生成されます。

関連情報

Cisco Collaboration Solutionリリース12.0によるOAuthの導入