認証サービスは、WebSphere MQ Real-time Transport および WebSphere Message Broker Real-timeInput および Real-timeOptimizedFlow ノードを使用するクライアント・アプリケーションの間でのみサポートされています。
WebSphere Message Broker 認証サービスは、ブローカーおよびクライアント・アプリケーションが主張どおりのものであり、パブリッシュ/サブスクライブ・セッションに参加できることを検証します。
セッション中の各参加者は、認証プロトコルを使用して、自分が主張どおりの人物であり、 有効な参加者を装った侵入者ではないことを他の参加者に証明します。
WebSphere Message Broker 製品は、次の 4 つのプロトコルをサポートします。
これらのプロトコルの最初の 2 つおよびそのインフラストラクチャー要件は、 それぞれ単純な telnet 方式のパスワード認証および相互にユーザー確認のための質問への応答を行うパスワード認証で詳しく説明されています。 非対称および対称 SSL プロトコルは SSL 認証で説明されています。
プロトコルは、セッションで無効ではない参加者に対する保護の提供という点で、強さが異なります。 P が最も弱く、R が最も強い保護を提供します。
ブローカー・ドメイン内の特定のブローカーによってサポートされる プロトコルのセットは、ワークベンチを使用して構成することができます。1 つ以上のプロトコルを それぞれのブローカーごとに指定することができます。ワークベンチを使用して、 特定のブローカーに定義される各 Real-timeInput ノード上の 認証を使用可能にしたり使用不可にしたりしてください。認証が Real-timeInput ノードで使用可能になると、そのノードはそれに対応するブローカー に指定されたプロトコルのセットをすべてサポートします。構成オプションは、 以下の図で説明されています。
パスワードが暗号化されずにネットワークを通過するため、 このプロトコルは、オープン・パスワード式 と説明することもできます。 クライアント・アプリケーションは、TCP/IP を使って Real-timeInput ノードに接続します。 入力ノードは、クライアントが自分を識別するように要求します。 クライアントはその「ユーザー ID」とパスワードを送信します。
この単純なプロトコルは、クライアントとブローカーが両方ともユーザー ID に関連したパスワードを 知っていることに依存しています。特にブローカーは、ユーザーおよびパスワード情報のリポジトリーへの アクセスが必要です。ユーザー ID とパスワード情報は、ユーザー・ネーム・サーバーによって WebSphere Message Broker 製品のドメイン中の すべてのブローカーに配布されます。ユーザー・ネーム・サーバーは、 オペレーティング・システム・ファイルからユーザーおよびパスワード情報を取り出します。
ユーザー・ネーム・サーバーのアプローチによって、 ユーザーおよびパスワードのソースの集中メンテナンスが可能になり、 ブローカーに情報が自動的に配布され、さらに必要なら情報を自動的にリフレッシュします。 また、ユーザーおよびパスワード情報は各ブローカーで持続的に維持されるので、 可用性の利点もあります。
各クライアント・アプリケーションは、独自のユーザー ID を認識し、 パスワードを秘密にしておくことが必要です。 接続を行う際、クライアントはその証明書を名前/パスワードの組み合わせとして指定します。
このプロトコルが提供するセキュリティーは、比較的弱いものです。 これはセッション・キーを計算せず、「盗聴者」や信用できない「仲介者」がいない環境でのみ 使用するべきです。
ユーザーおよびパスワード情報がユーザー・ネーム・サーバー・システムの フラット・ファイルに保管されている場合、パスワードを「安全に」保管および分散します。
クライアントおよびサーバーには、非常に軽い計算負荷しかかかりません。
これは、秘密セッション・キーの生成が関係する、より洗練され、よりセキュアなプロトコルです。 クライアントとサーバーの両方が、クライアントのパスワードを使用してこのキーを計算します。 ユーザー確認のための質問と応答のプロトコルを介して、 クライアントとサーバーは互いにこの秘密を知っていることを証明します。
クライアントは、サーバーがクライアントの質問に応答する前にサーバーの質問に 応答しなければなりません。つまり、クライアントを装ったアタッカーは、 アタックを予期している「オフライン」のパスワードをマウントする情報を集めることができません。 クライアントとサーバーの両方が互いにパスワードを知っていることを証明するので、 このプロトコルは「偽名」アタックに対して有効です。
単純な telnet 方式のパスワード・プロトコルの場合と同様、ブローカーはユーザーおよび パスワード情報にアクセスできなければなりません。 ユーザー ID およびパスワードについての情報は、ユーザー・ネーム・サーバーによって ドメイン中のすべてのブローカーに配布されます。 ユーザー・ネーム・サーバーは、オペレーティング・システム・ファイルからユーザーおよび パスワード情報を取り出します。
各クライアント・アプリケーションは、独自のユーザー ID を認識し、 パスワードを秘密にしておくことが必要です。 接続を行う際、クライアントはその証明書を名前/パスワードの組み合わせとして指定します。
クライアントとサーバー両方の計算要求はどちらも適度なものです。