Web Services Security のトラブルシューティングのヒント

Web Services Security のトラブルシューティングを行う場合は、 アセンブリー・ツールで構成を確認し、クライアントとサーバーの要求および応答の構成を 一致させます。

Web Services Security のトラブルシューティング行う場合は、 アセンブリー・ツールで構成を確認し、クライアントとサーバーの要求および応答の構成を 一致させることが最善の方法です。これらの構成は必ず一致させる必要があります。 クライアント要求送信側の構成は、サーバー要求受信側の構成と一致している必要があります。暗号化を正常に行うには、 受信側の公開鍵が送信側に対してエクスポートされる必要があり、この鍵が暗号化情報内で正常に構成されている必要があります。認証の場合、 クライアントが使用するメソッドをサーバーのログイン・マッピングで指定する必要があります。

以下のステップは、実行可能な汎用トラブルシューティングのステップのリストです。

このタスクのステップ

  1. クライアント・セキュリティーの拡張機能およびサーバー・セキュリティーの拡張機能が、 以下の送信側および受信側のダウンストリーム呼び出しのそれぞれについて一致していることを確認します。
    • 要求送信側と要求受信側
    • 応答送信側と応答受信側
  2. Add Created Time Stamp」オプションがクライアント・サイドで使用可能の場合に、 サーバーで「Add Received Time Stamp」オプションが構成されていることを確認します。アセンブリー・ツールで、 セキュリティーの拡張機能を構成する必要があります。
  3. クライアント・セキュリティー・バインディングおよびサーバー・セキュリティー・バインディングが 正しく構成されていることを確認します。クライアント認証メソッドがシグニチャーの場合、 サーバーにログイン・マッピングがあることを確認してください。クライアントが公開鍵、cn=Bob,o=IBM,c=US を使用して本体を暗号化する場合、 このサブジェクトがサーバー鍵ストアにおける個人証明書であり、 これによって本体を秘密鍵で復号できることを確認してください。アセンブリー・ツールまたは WebSphere® Application Server 管理コンソールを使用して、セキュリティー・バインディングを構成できます。
  4. 問題に関する情報を提供するメッセージについては、${USER_INSTALL_ROOT}/logs/server1 ディレクトリー (server1 はサーバー名に応じて変化します) 内の SystemOut.log ファイルをチェックします。
    注: このトピックでは、 1 つ以上のアプリケーション・サーバー・ログ・ファイルを参照します。推奨される代替案として、分散システムや IBM® i システムの SystemOut.logSystemErr.logtrace.logactivity.log ファイルではなく、High Performance Extensible Logging (HPEL) ログおよびトレース・インフラストラクチャーを使用するようにサーバーを構成できます。また HPEL は、ネイティブ z/OS® ロギング機能と連携させて使用することができます。HPEL を使用する場合、LogViewer コマンド・ライン・ツールを サーバー・プロファイルの bin ディレクトリーから使用して、すべてのログ・ファイルにアクセスし、 情報をトレースできます。HPEL の使用について詳しくは、HPEL を使用してのアプリケーションの トラブルシューティングに関する情報を参照してください。
  5. 以下のトレース仕様を使用して、Web Services Security のトレースを使用可能にします。
    com.ibm.xml.soapsec.*=all=enabled:com.ibm.ws.webservices.*=all=enabled: com.ibm.wsspi.wssecurity.
    *=all=enabled:com.ibm.ws.security.*=all=enabled: SASRas=all=enabled

    これらの 2 行は、実際には 1 行として入力してください。

Web サービスを保護する際のエラー

Web サービスを保護する際に、以下のエラーが発生することがあります。

「CWWSS6811E: メッセージから取得した鍵 ID <identifier name> は、鍵ストアから取得した 鍵 ID <identifier name> と異なります」という 鍵のミスマッチ・エラー・メッセージが表示される

原因:

製品に組み込まれているサンプル鍵ストア・ファイル が、一部の証明書の期限満了により、更新されています。混合クラスター環境でこれらの鍵を使用すると、鍵のミスマッチ・エラーが発生します。 以下に例を示します。
com.ibm.wsspi.wssecurity.core.SoapSecurityException: CWWSS6521E: The Login failed 
because of an exception: javax.security.auth.login.LoginException: CWWSS6811E: 
The key identifier TVpC640XSSc= retrieved from the message is different from the
 key identifier QdZLf+KjrUg= acquired from the keystore Path: 
C:¥WebSphere¥AppServer¥profiles¥AppSrv01//etc/ws-security/samples/enc-receiver.jceks."
製品に組み込まれている鍵ストア・ファイルはサンプルとして使用することを目的としています。実稼働環境では使用できません。 ただし、サンプル・ファイルを使用して混合クラスター環境のテストを行う場合は、鍵のミスマッチ・エラーが生じないようにファイルを同期化する必要があります。 鍵ストア・ファイルは、プロファイル・ディレクトリーのサブディレクトリー内にあります。 以下に例を示します。

profile_root/etc/ws-security/samples/dsig-sender.ks
profile_root/etc/ws-security/samples/dsig-receiver.ks
profile_root/etc/ws-security/samples/enc-sender.jceks
profile_root/etc/ws-security/samples/enc-receiver.jceks
profile_root/etc/ws-security/samples/intca2.cer

ここで、profile_root は、インスタンス化した特定の WebSphere Application Server プロファイル用のホーム・ディレクトリーを表します。
サンプル鍵ストア・ファイルは、次のインストール・ディレクトリーにもあります。

app_server_root/etc/ws-security/samples/dsig-sender.ks
app_server_root/etc/ws-security/samples/dsig-receiver.ks
app_server_root/etc/ws-security/samples/enc-sender.jceks
app_server_root/etc/ws-security/samples/enc-receiver.jceks
app_server_root/etc/ws-security/samples/intca2.cer

ここで、app_server_rootWebSphere Application Server のインストール先を表します。

解決策:

この鍵ミスマッチ・エラーは、鍵ストア・ファイルを混合クラスター内のバージョン 7.0 以降のノードからバージョン 6.1 Feature Pack for Web Services のノードに手動でコピーすることで対処することができます。これにより、バージョン 7.0 以降のノードとバージョン 6.1 Feature Pack for Web Services のノードが同じ鍵ストア・ファイルを確実に使用することになります。 別の対処方法として、バージョン 7.0 以降の鍵ストア・ファイルを共通のディレクトリー・ロケーションに移動して、バインディングをすべて変更し、鍵ストア・ファイル用の共通のロケーションを指すようにする方法があります。

「CWWSI5061E: SOAP 本文に署名がありません」というエラー・メッセージが表示される

原因:

このエラーは一般に、 SOAP セキュリティー・ハンドラーが正しくロードされておらず、SOAP 本体に署名がない場合に発生します。 SOAP セキュリティー・ハンドラーは通常、サーバー側で発生する最初の検証であり、 多くの問題によりこのメッセージが表示されます。このエラーは無効な actor URI 構成により発生する場合があります。

解決策:

アセンブリー・ツール内の以下の場所で、actor Universal Resource Identifier (URI) を構成することができます。

  • クライアント構成のアセンブリー・ツール内の Web サービス・クライアント・エディターから、
    • 「セキュリティー拡張」>「クライアント・サービス構成詳細」をクリックして、「アクター URI」フィールドでアクター情報を示します。
    • 「セキュリティー拡張」>「要求送信側構成」セクション >「詳細」をクリックして、「アクター」フィールドでアクター情報を示します。
  • サーバー構成のアセンブリー・ツール内の Web Services Editor から、
    • 「セキュリティー拡張」>「サーバー・サービス構成」セクションをクリックします。actor URI にクライアント・サイドと同じ actor ストリングがあることを確認します。
    • 「セキュリティー拡張」>「応答送信側サービス構成の詳細」>「詳細」をクリックして、「アクター」フィールドでアクター情報を示します。

クライアントおよびサーバー上のアクター情報は、 両方とも同一のストリングを参照する必要があります。 クライアントとサーバーの「アクター」フィールドが一致すると、 要求または応答はダウンストリームに転送されるのではなく、処理されます。 他の Web サービスのゲートウェイとして動作する Web サービスがある場合は、「アクター」フィールドが異なる場合があります。しかし、それ以外の場合、 クライアントおよびサーバーでアクター情報が一致することを検証してください。Web サービス実装がゲートウェイとして動作し、 ゲートウェイを介して渡される要求同じ actor を構成していない場合、 この Web サービス実装はクライアントからのメッセージを処理しません。代わりに、要求をダウンストリームに送信します。正しいアクター・ストリングを含む ダウンストリーム・プロセスによって、要求が処理されます。 応答でも同じ状況が発生します。 したがって、該当するクライアントとサーバーの「actor」フィールドが同期化されていることを確認することが重要です。

また、本体をクライアント構成内で署名されるように指定しない場合には、 エラーが表示されることがあります。アセンブリー・ツールの Web サービス・クライアント・エディターを使用してメッセージ本文に署名するには、 「セキュリティー拡張」>「要求送信側構成」>「保全性」をクリックして、 署名するメッセージ・パートを選択します。

「CWWSI5075E: いずれかの AuthMethod を満たすセキュリティー・トークンがありません」というエラー・メッセージが表示される

解決策:

セキュリティー拡張機能でクライアントとサーバーのログイン構成情報が一致しているかを確認してください。 また、クライアントに有効なログイン・バインディングがあること、 およびサーバーにセキュリティー・バインディングで有効なログイン・マッピングがあることを 確認してください。この情報は、 アセンブリー・ツールの以下の場所を調べることで確認できます。

  • クライアント構成のアセンブリー・ツール内の Web サービス・クライアント・エディターから、
    • 「セキュリティー拡張」>「要求送信側構成」>「ログイン構成」の順にクリックして、認証方式を確認します。
    • 「ポート・バインディング」>「セキュリティー要求送信側のバインディング構成」>「ログイン・バインディング」の順にクリックして、認証方式およびその他のパラメーターを確認します。
  • サーバー構成のアセンブリー・ツール内の Web Services Editor から、
    • 「セキュリティー拡張」>「要求受信側サービス構成の詳細」>「ログイン構成」の順にクリックして、認証方式を確認します。
    • 「バインディング構成」>「要求受信側のバインディング構成の詳細」>「ログイン・マッピング」をクリックして、認証方式およびその他のパラメーターを確認します。

また、クライアントおよびサーバーで指定された actor URI が一致することを 確認してください。アセンブリー・ツール内の以下の場所で、actor URI を構成することができます。

  • クライアント構成のアセンブリー・ツール内の Web サービス・クライアント・エディターから、
    • 「セキュリティー拡張」>「クライアント・サービス構成詳細」をクリックして、「アクター URI」フィールドでアクター情報を示します。
    • 「セキュリティー拡張」>「要求送信側構成」セクション >「詳細」をクリックして、「アクター」フィールドでアクター情報を示します。
  • サーバー構成のアセンブリー・ツール内の Web Services Editor から、
    • 「セキュリティー拡張」>「サーバー・サービス構成」セクションをクリックします。「アクター URI」フィールドにクライアント側と同じ actor ストリングがあることを確認します。
    • 「セキュリティー拡張」>「応答送信側サービス構成の詳細」>「詳細」をクリックして、「アクター」フィールドでアクター情報を示します。

「CWWSI5094E: TrustMode が BasicAuth であるときに、トラステッド・ユーザーの UsernameToken が見つからなかったか、またはユーザーのログインが失敗しました」というエラー・メッセージが表示される

原因:

この状態は、ログイン構成で IDAssertion を認証メソッドとして構成した場合に発生します。

解決策:

送信側の Web サービスで、 ログイン・バインディング内にトラステッド基本認証エントリーを構成してください。次に、サーバー側で、 トラステッド ID エバリュエーターに基本認証エントリーのユーザー名を含むプロパティーのセットがあることを検証します。

ID アサーション用のクライアントを構成するには、メソッドの指定、および認証メソッドを収集する ID アサーション用のクライアントの構成を行う際に『ID アサーション用クライアントの構成』を参照してください。

ID アサーション用のサーバーを構成するには、ID アサーション認証を処理するためのサーバーの構成、および ID アサーション認証情報を検証するためのサーバーの構成に関する情報を参照してください。

「CWSCJ0053E: /UNAUTHENTICATED の許可が失敗しました」というエラー・メッセージが表示される

原因:

セキュリティー名として UNAUTHENTICATED を使用すると、以下の許可エラーが発生します。
CWSCJ0053E: Authorization failed for /UNAUTHENTICATED while invoking (Home)com/ibm/wssvt/tc/
pli/ejb/Beneficiary findBeneficiaryBySsNo(java.lang.String):2 securityName: /UNAUTHENTICATED;accessID: 
null is not granted any of the required roles: AgentRole

この状態は、 ログイン構成が構成されていないため、または Web Services Security がクライアントから サーバーに構成されていないために発生します。 要求がサーバーに到達し、認証情報が受信されない場合、スレッドに UNAUTHENTICATED ユーザーが設定されています。だれでもアクセスできる特殊な「Everyone」ロール以外のロールがリソースに割り当てられている場合、許可はこのエラーを戻します。

クライアントが Enterprise JavaBeans (EJB) ファイルに対して正常に認証されても、 その EJB ファイルが Web Services Security またはトランスポート・セキュリティー (HTTP ユーザー ID、 パスワードなど) で構成されていないダウンストリーム EJB ファイルを呼び出す場合、 このダウンストリーム要求でエラーが発生する可能性があります。

解決策:

アセンブリー・ツールを使用して、 クライアントとサーバーの両方に対するエンタープライズ・アーカイブ (EAR) ファイルのセキュリティー機能拡張およびセキュリティー・バインディングが適切であることを検証します。詳しくは、以下のトピックを 参照してください。
  • アセンブリー・ツールを使用したクライアント・セキュリティー・バインディングの構成
  • 管理コンソールを使用してサーバー上のセキュリティー・バインディングをクライアントとして動作するように構成する
  • アセンブリー・ツールを使用したサーバー・セキュリティー・バインディングの構成
  • 管理コンソールを使用したサーバー・セキュリティー・バインディングの構成

ID アサーション用のクライアントを構成するには、メソッドの指定、および認証メソッドを収集する ID アサーション用のクライアントの構成を行う際に『ID アサーション用クライアントの構成』を参照してください。

トークン・コンシューマーまたはトークン生成プログラムに対して値のタイプのローカル名と URI を指定すると、「WSWS3243I: 情報: 例外を WebServicesFault にマップしています」というエラー・メッセージが表示される

原因:

値タイプの URI は、以下の事前定義された値タイプのローカル名に対しては必要ありません。
  • ユーザー名トークン
  • X509 証明書トークン
  • PKIPath 内の X509 証明書
  • PKCS#7 内の X509 証明書および CRL のリスト

解決策:

前述の値のタイプのローカル名の 1 つを指定した場合は、値のタイプ URI フィールドに値を入力しないでください。

WebSphere Application Server の Web サービスにアクセスする Microsoft .NET クライアントを使用すると、「無効な URI: URI の形式を決定できませんでした」というエラー・メッセージが表示される

原因:

WebSphere Application Server の Web サービスにアクセスする Microsoft .NET クライアントを使用すると、次のような例外メッセージが表示されることがあります。
Invalid URI: The format of the URI could not be determined.
例外タイプ:
System.UriFormatException 
at System.Uri.Parse() 
at System.Uri..ctor(String uriString, Boolean dontEscape) 
at System.Uri..ctor(String uriString) 
at Microsoft.Web.Services2.SoapInputFilter.CanProcessHeader(XmlElement header, SoapContext context) 
at Microsoft.Web.Services2.Security.SecurityInputFilter.ProcessMessage(SoapEnvelope envelope) 
at Microsoft.Web.Services2.Pipeline.ProcessInputMessage(SoapEnvelope envelope) 
at Microsoft.Web.Services2.InputStream.GetRawContent() 
at Microsoft.Web.Services2.InputStream.get_Length() 
at System.Xml.XmlScanner..ctor(TextReader reader, XmlNameTable ntable) 
at System.Xml.XmlTextReader..ctor(String url, TextReader input, XmlNameTable nt) 
at System.Xml.XmlTextReader..ctor(TextReader input) 
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, 
WebResponse response, Stream responseStream, Boolean asyncCall) 
WebSphere Application Server 内では Web Services Security が有効で、ActorURI 属性が使用されます。このエラーが発生するのは、Microsoft .NET Web Services Enhancements (WSE) Version 2.0 Service Pack 3 が、 ActorURI 属性の相対 URI 値をサポートしていないためです。WSE Version 2.0 Service Pack 3 は、この属性に対しては絶対 URI のみをサポートしています。

解決策:

Microsoft .NET クライアントを使用するには、 この属性を絶対 URI として構成する必要があります。絶対 URI とは、例えば abc://myWebService のようなものです。 相対 URI とは、例えば myWebService のようなものです。

WebSphere Application Server で使用する ActorURI 属性を構成するには、IBM のアセンブリー・ツールを使用して以下の手順を実行します。
  1. Web サービス・エディターを開き、「Extensions」タブをクリックして「Server Service Configuration」を展開します。
  2. 「Actor」フィールドに、完全な絶対 URI を入力します。
  3. 「応答ジェネレーター・サービス構成の詳細」>「詳細」と展開します。
  4. 「Actor」フィールドに、完全な絶対 URI を入力します。
詳しくは、『アセンブリー・ツール』の情報を参照してください。

「WSEC5502E: エレメントは、ターゲット・エレメントとして想定されていません」というエラー・メッセージが表示される

原因:

以下のエラーが表示される場合、メッセージ内の X.509 トークンが原因である可能性がありますが、一致する構成済みトークン・コンシューマーはありません。 このエラーは、コンシューマーまたはプロバイダーの JAX-RPC アプリケーションで発生している可能性があります。
com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5502E: Unexpected element as the target element: wsse:BinarySecurityToken
このエラーは、X.509 トークンが構成され、かつ、X.509v3 トークンが受信されている、あるいは X.509v3 トークンが構成され、かつ、X.509 トークンが受信されていることが原因です。 この状態は、X.509v3 トークンを Microsoft .NET から受信する場合にもっとも頻繁に見られます。 これが問題の原因であるかどうかを判断するには、以下の手順に従ってください。
  1. メッセージを生成するプロセスの WS-Security トレースを取得します。 WS-Security トレースを実装する方法について詳しくは、『Web サービスのトレース』を参照してください。
  2. 次の手順で、トレースに着信 SOAP メッセージに関する情報が含まれているかどうかを確認します。
    1. 例外が発生した場所から逆方向検索を行って soapenv:env という語を探します。
    2. 同じ場所で、逆方向検索を行って X509 という語を探します。
    3. #X509 または #X509v3 の X.509 セキュリティー・トークンのタイプをメモしておきます。
  3. 例えばトレースが不完全なためにトレースに着信 SOAP メッセージについての情報が含まれていない場合 は、用語「Target's value type is」を、例外の時点から後方検索します。 この検索で、エラー時にどのセキュリティー・トークンが処理されていたかを示すトレース部分が見つかります。 #X509 または #X509v3 のセキュリティー・トークンのタイプをメモしておきます。
  4. 次の手順で、コンシューマー構成で指定されている X.509 セキュリティー・トークンのタイプを確認します。
    1. 例外が発生した場所から逆方向検索を行って WSSConsumerConfig という語を探します。
    2. ここでは、順方向検索で #X509 という語を探します。
    3. #X509 または #X509v3 の構成済み X.509 セキュリティー・トークン・コンシューマーのタイプをメモしておきます。
  5. 構成したトークン・コンシューマーが着信セキュリティー・トークンのタイプと一致しない場合は、エラーの原因がセキュリティー・トークン・タイプのミスマッチであることがわかります。

解決策:

構成済みトークン・コンシューマーは着信セキュリティー・トークンに指定したタイプと一致する必要があります。 前述の手順で判断したように、エラー原因がセキュリティー・トークン・タイプのミスマッチであると判断した場合は、WS-Security のコンシューマー構成またはプロバイダー構成を変更して、トークン・タイプが一致するようにしてください。

「WSEC6664E: PKIXBuilderParameters にヌルは指定できません。TrustAnchor および CertStoreList の構成は正しくありません」という例外が表示される

原因:

証明書のパス設定が正しく構成されていません。

解決策:

次のステップを実行して、証明書のパス設定を構成します。
  1. 管理コンソールで、「セキュリティー」>「Web サービス」をクリックします。
  2. 見出し「デフォルト・コンシューマー・バインディング」から、「署名情報」>「configuration_name」をクリックします。
  3. すべてを信頼」オプションまたは「専用署名情報」オプションのいずれかを選択します。

    専用署名情報」オプションを選択した場合は、 ドロップダウン・リストにある構成から、トラスト・アンカーと証明書ストアを選択してください。

  4. OK」および「保存」をクリックして、マスター構成に保存します。

Microsoft .NET エラー「WSE567: 着信ユーザー名トークンには、nonce と、リプレイ検出機能の作成時刻の両方が含まれている必要があります。」が表示される

原因:

このシナリオでは、WebSphere Application Server の Web サービス・クライアントと Microsoft .NET Web サービスを利用しています。Microsoft .NET Web サービスには、構成されるユーザー名トークンに ws-security 制約があります。Microsoft .NET サーバーから次の例外がスローされます。

WSE567: 着信ユーザー名トークンには、nonce と、 リプレイ検出機能の作成時刻の両方が含まれている必要があります。

デフォルトでは、Microsoft .NET Web サービスはユーザー名トークンの nonce (ランダム・ストリング) とタイム・スタンプを検証します。ただし、WebSphere Application Server を使用する Web サービス・クライアントに対して nonce およびタイム・スタンプ・プロパティーを構成するかどうかは任意です。

解決策:

以下の手順を実行して、WebSphere Application Server の Web サービス・クライアント上で、ユーザー名トークンの nonce およびタイム・スタンプ・プロパティーを追加します。以下の手順を実行するには、アセンブリー・ツールが必要です。
  1. Web サービス・クライアントのデプロイメント記述子を開き、「WS-Binding」タブをクリックします。
  2. 「セキュリティー要求ジェネレーター・バインディング構成」 > 「トークン生成プログラム」のセクションを展開します。
  3. 既に作成済みのユーザー名トークンの名前をクリックして、「編集」をクリックします。
  4. 「トークン生成プログラム」ウィンドウの「プロパティー」セクションで、「追加」をクリックします。
  5. 「名前」フィールドに com.ibm.wsspi.wssecurity.token.username.addNonce と入力して、nonce プロパティーの名前を指定します。
  6. 」フィールドに「true」を入力します。
  7. 追加」をクリックします。
  8. 「名前」フィールドに com.ibm.wsspi.wssecurity.token.username.addTimestamp と入力して、タイム・スタンプ・プロパティーの名前を指定します。
  9. 「値」フィールドに true と入力します。
  10. OK」をクリックして、クライアントのデプロイメント記述子を保存します。

Java 2 セキュリティーを有効にして com.ibm.wsspi.wssecurity.auth.token パッケージを使用すると、 Java 2 セキュリティー例外が発生する

原因:

Java™ 2 セキュリティーが 有効になっているときに com.ibm.wsspi.wssecurity.auth.token.* パッケージを使用すると、 アプリケーションが Java 2 セキュリティー例外を作成します。

WebSphere Application Server バージョン 6.1 では、 com.ibm.wsspi.wssecurity.auth.token.* パッケージの各種 public メソッド用に、 新しい Java 2 アクセス権が設定されました。ご使用のアプリケーションが、Java 2 セキュリティー権限で保護されるクラスの public メソッドのいずれかを使用する場合に、 当該アクセス権を持っていないと、そのアプリケーションは失敗します。例外メッセージには、 対応する新規 Java 2 セキュリティー権限の影響を受けるクラスおよび public メソッドを識別する情報が含まれています。

解決策:

以下の手順で、アプリケーションの was.policy ファイルに アクセス権を付与します。
  1. PolicyTool を使用してポリシー・ファイルを編集します。オペレーティング・システムに適したステップに 従ってください。
  2. アプリケーションのエンタープライズ・アーカイブ (EAR) ファイルに パッケージ化される was.policy ファイルに、すべてのアクセス権を追加します。 アプリケーションの was.policy ファイルでアクセス権をもっと細かく 設定したい場合は、必要とするクラスごとに、アプリケーションに必要なアクセス権を 使用可能にします。
    例えば、X509BSToken のメソッドにのみ アクセスできればよい場合は、was.policy ファイルに以下のアクセス権を 追加します。
    grant codeBase "file:${application}" {
       permission com.ibm.websphere.security.WebSphereRuntimePermission
         "wssecurity.X509BSToken.setBytes";
       permission com.ibm.websphere.security.WebSphereRuntimePermission
         "wssecurity.X509BSToken.setCert";
      permission com.ibm.websphere.security.WebSphereRuntimePermission
        "wssecurity.WSSToken.setTrusted";
      permission com.ibm.websphere.security.WebSphereRuntimePermission
         "wssecurity.WSSToken.addAttribute";
      permission com.ibm.websphere.security.WebSphereRuntimePermission
         "wssecurity.WSSToken.setUsedTokenConsumer";
    };
  3. アプリケーションの EAR ファイル内の was.policy ファイルを更新します。
  4. WebSphere Application Server からアプリケーションをアンインストールし、 新規 EAR ファイルと更新済みの was.policy ファイルとともに、再インストールします。

SOAP エレメントで 保全性または機密性を表明すると、例外が発生することがある

原因:

クライアントが SOAP エレメントの保全性または機密性を表明しているのに、 そのエレメントがメッセージに含まれていない場合は、例外が発行されます。

クライアントがシグニチャーまたは暗号化を SOAP エレメントに適用するように 要求する場合は、SOAP エレメントが必ず存在していなければなりません。このエレメントの存在は、 オプションではありません。例えば、構成で wscontext エレメントに保全性または機密 性を適用する必要があると指定されているのに、wscontext がメッセージに含まれていないと、以下の例外が発行されます。

com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5636W: Objects 
to be processed not found with the dialect 
[http://www.ibm.com/websphere/webservices/wssecurity/dialect-was] 
and the keyword [wscontext]

解決策:

クライアント開発者は、 保全性または機密性のターゲットとする SOAP エレメントが必ず SOAP メッセージに含まれていることを、 保証する必要があります。SOAP エレメントが必ず含まれていると 保証できない場合は、SOAP エレメントを保全性または機密性のターゲットにすることは できません。

JSR-101 プログラミング・モデルと JSR-109 プログラミング・モデルの違いによって、クライアント出力例外が発生する

原因:

クライアントの実行中に、 クライアント出力例外が生成されることがあります。JSR-101 プログラミング・モデルと JSR-109 プログラミング・モデルの違いが、クライアント出力例外の原因になる 場合があります。

ユーザーは、任意の Web Services Security 制約 (ユーザー名トークン、X509 トークン、SOAP エレメントへの署名、SOAP エレメントの暗号化など) を 構成できます。例えば、WebSphere Application Server のクライアントおよび サービスでは、ユーザー名トークンを構成できます。クライアントは 要求でユーザー名トークンを送信するように構成され、サーバーはユーザー名トークンを予期するように 構成されます。クライアントがユーザー名トークンを送信しないと、 サーバーはその要求を拒否します。Java Naming and Directory Interface (JNDI) ネーミング検索を 実行しないクライアントは、JSR-109 クライアントではないと考えられます。JSR-109 クライアントでない場合は、 JSR-109 構成情報 (セキュリティー構成など) が取得されず、 要求は失敗します。

JSR-109 プログラミング・モデルでは、 呼び出しは JNDI 検索から始まり、これによってセキュリティー構成情報を関連付けることが できます。JSR-101 プログラミング・モデルでは、JNDI 検索は実行されず、 セキュリティー構成情報を関連付けることはできません。

解決策:

JSR-101 プログラミング・モデルでも JSR-109 プログラミング・モデルでも、 この振る舞いは問題とはなりません。 Web Services Security は、JSR-101 クライアントに対しては、WebSphere Application Server セキュリティー構成情報を提供しません。

Web Services Security の 実装は、以下のガイドラインに従って行われます。
  • JSR-101 クライアントでは、Web Services Security はサポートされません。
  • Web Services Security を使用するように構成できるのは、JSR-109 クライアントだけです。

クライアントが Web Services Security を要求する場合、そのクライアントは JSR-109 クライアントでなければなりません。

「WSSecurityCon E WSEC5514E: WS-Security メッセージの処理中に例外が発生しました」というエラーが表示される

原因:

lookup() 呼び出しが Java Naming and Directory Interface (JNDI) を使用しなかったため、管理対象クライアントは、Web サービス・デプロイメント記述子にアクセスできません。lookup() 呼び出しがなければ、クライアントは、デプロイメント記述子にアクセスできません。 Web Services Security 構成は、Web サービス・デプロイメント記述子内にあります。以下は、作成される詳細な例外です。
00000046 WebServicesFa 1 
com.ibm.ws.webservices.engine.WebServicesFault makeUserFault 
MakeUserFault:     com.ibm.wsspi.wssecurity.SoapSecurityException: 
WSEC5720E: A required message part [body] is not signed.
		at com.ibm.wsspi.wssecurity.SoapSecurityException.format(SoapSecurityException.java:143)
		at com.ibm.ws.webservices.wssecurity.dsig.VerifiedPartChecker.invoke(VerifiedPartChecker.java:
263)
		at com.ibm.ws.webservices.wssecurity.core.WSSConsumer.checkRequiredIntegrity(WSSConsumer.java:
1430)
		at com.ibm.ws.webservices.wssecurity.core.WSSConsumer.invoke(WSSConsumer.java:545)
		at com.ibm.ws.webservices.wssecurity.handler.WSSecurityConsumerBase.invoke(WSSecurityConsumerB
ase.java:85)
		at com.ibm.ws.webservices.wssecurity.handler.GlobalSecurityHandler.handleRequest6(GlobalSecuri
tyHandler.java:406)

解決策:

管理対象クライアントの場合、サービス検索は Java Naming and Directory Interface (JNDI) 検索を介して行われます。UsernameToken、Web Services Security、デジタル署名 Web Services Security、および Lightweight Third-Party Authentication (LTPA) トークン Web Services Security のセットアップ方法に関する資料を参照してください。以下は、JSR 109 準拠のコンテキスト検索の例です。

InitialContext ctx = new InitialContext();
FredsBankServiceLocator locator
    =(FredsBankService)ctx.lookup("java:comp/env/service/FredsBankService");
FredsBank fb = locator.getFredsBank(url);
long balance = fb.getBalance();  

管理対象クライアントのコンテキスト検索のインスタンスを作成している場合は、 サービス・ロケーターに new() を使用しないでください。 以下に、JSR 109 準拠ではない例を示します (新規 ServiceLocator)。

Properties prop = new Properties();
InitialContext ctx = new InitialContext(prop);
FredsBankServiceLocator locator = new FredsBankServiceLocator();
FredsBank fb = locator.getFredsBank(url);
long balance = fb.getBalance(); 

「WSEC6500E: ログインに使用される候補がありません」というエラー・メッセージが表示される

原因:

この状態は、以下のいずれかの条件下で発生する場合があります。
  • アプリケーション・セキュリティーは使用可能になっているが、サービスのコンシューマー呼び出し元パーツで指定される必須のセキュリティー・トークンが インバウンド SOAP メッセージに含まれていない。
  • Web サービス・クライアントが Web Services Security を使用して Web サービスを呼び出す場合に、Web サービスをホスティングするアプリケーション・サーバー上で アプリケーション・セキュリティーが使用不可になっている。

例えば、Web サービスは、ユーザー名トークンまたは LTPA トークンを使用して、認証用に構成される場合があります。ただし、グローバル・セキュリティーが使用不可な場合、それはアプリケーション・サーバーにデプロイされます。Web サービスが、Web サービス・クライアント (必須ユーザー名トークンまたは LTPA トークンを正しく提供する) によって呼び出される場合、Web サービス呼び出しは失敗します。以下の障害が、Web サービス・クライアントに戻される可能性があります。

<soapenv:Fault>   <faultcode xmlns:p55="http://docs.oasis-open.org/wss/2004/01/oasis-
      200401-wss-wssecurity-secext-1.0.xsd">p55: FailedAuthentication 
</faultcode>  
<faultstring>
<![CDATA[com.ibm.wsspi.wssecurity.SoapSecurityException:   
WSEC6500E: There is no candidate used to login.]]>   
</faultstring>  
<detail encodingStyle=""/>  
</soapenv:Fault>

解決策:

Web サービスをホスティングするアプリケーション・サーバー上でアプリケーション・セキュリティーが使用可能になっている場合、 クライアントを正しく構成し、Web Services Security のコンシューマー呼び出し元パーツ構成の Web サービスに必須の セキュリティー・トークンが送信されるようにします。

Web サービスをホスティングするアプリケーション・サーバー上で アプリケーション・セキュリティーが使用不可になっている場合は、以下のいずれかを行います。
  • Web サービスをホスティングするアプリケーション・サーバー上で、アプリケーション・セキュリティーを使用可能にします。
  • Web サービスの Web Services Security カスタム・プロパティー com.ibm.wsspi.wssecurity.config.disableWSSIfApplicationSecurityDisabled を設定します。

com.ibm.wsspi.wssecurity.config.disableWSSIfApplicationSecurityDisabled プロパティーは、Web Services Security を使用可能にし、アプリケーション・セキュリティーが使用不可の場合は、WS-Security ヘッダーが処理されないようにします。このプロパティーを使用すると、 システム管理者およびアプリケーション・プログラマーは、非セキュア環境でのサービスの状況をデバッグでき、 デプロイメント記述子から WS-Security 情報を除去する必要もありません。このプロパティーは、診断での使用のみを目的としており、実稼働環境での使用を目的とするものでありません。

このプロパティーの有効な値は、true および false です。デフォルト値は false です。

アプリケーション・レベル、セル・レベル、およびサーバー・レベルは、WebSphere Application Server が提供するバインディングのレベルです。

サーバー・レベルのバインディング (デフォルト) を構成する場合、以下を実行します。
  1. 「サーバー」>「アプリケーション・サーバー」>「<server_name>とクリックします。
  2. 「セキュリティー」の下の「Web サービス: Web Services Security の デフォルト・バインディング 」をクリックします。
  3. 以下のいずれかを行います。
    • 「デフォルト・コンシューマー・バインディング」>「プロパティー」をクリックします (セル内のすべてのアプリケーションに適用される場合があります)。
    • 「追加プロパティー」>「プロパティー」をクリックします (セル内のすべてのアプリケーションに適用される場合があります)。
セル・レベルのバインディングを構成して、 セル・レベルのデフォルト・バインディングにアクセスする場合、以下を実行します。
  1. 「セキュリティー」>「Web サービス」とクリックします。
  2. 「デフォルト生成バインディング」または「デフォルト・コンシューマー・バインディング」の下の「プロパティー」をクリックします。
  3. 「セキュリティー」の下の「Web サービス: Web Services Security の デフォルト・バインディング 」をクリックします。
  4. 優先順位に従い、以下のロケーションで指定されるいずれかを実行します。
    • 「デフォルト・コンシューマー・バインディング」>「プロパティー」をクリックします。
    • 「追加プロパティー」>「プロパティー」をクリックします。
JVM システム・プロパティーを構成するには、以下を実行します。
  1. 「サーバー」>「アプリケーション・サーバー」>「<server_name>をクリックします。
  2. 「サーバー・インフラストラクチャー」の下で、「Java およびプロセス管理」 >「プロセス定義」とクリックします。
  3. 「追加プロパティー」の下で、「Java 仮想マシン」をクリックします。
  4. 「追加プロパティー」の下の「カスタム・プロパティー」をクリックします。

Kerberos トークン用の SHA-1 鍵 ID が使用されていないか、カスタム・プロパティーを設定せず正しく生成されていない

原因:

OASIS Standard の Web Services Security Kerberos Token Profile v1.1 で規定されているように、SHA-1 変換キー値の base64 エンコードは、Kerberos AP-REQ トークン用の鍵 ID の指定に使用できます。 SHA-1 は、入力データを変換し、修正されたサイズのストリングを返す暗号ハッシュ関数です。 クライアントおよびサービス・プロバイダーが Web サービスの初期メッセージを交換した後で、Kerberos 認証トークンを外部で参照する場合に SHA-1 鍵 ID が使用されます。 こうした目的で SHA-1 を使用するには、ポリシー・バインディングでカスタム・プロパティーを構成し、SHA-1 鍵 ID を生成して使用する必要があります。 カスタム・プロパティーの com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken は、クライアント・トークン生成プログラムバインディングおよびサービス・トークン・コンシューマー・バインディングに追加されます。 このプロパティーを使用することで、Kerberos トークンを認証トークンとして使用している状態で、後続の Web サービスのメッセージ交換の際に、SHA-1 鍵 ID がアプリケーションで正しく生成されて使用されるようになります。

解決策:

Web サービスのメッセージ交換ごとに SHA-1 鍵 ID をアプリケーションで生成または使用する場合は、アプリケーション用のトークン生成プログラム・バインディングとトークン・コンシューマー・バインディングの com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken カスタム・プロパティーを true に設定してください。

管理コンソールを使用してカスタム・プロパティーを設定するには、 以下の手順を実行します。
  1. 「サービス」>「ポリシー・セット」とクリックします。
  2. 「汎用プロバイダー・ポリシー・セット・バインディング」>「binding_nameとクリックします。
  3. 「ポリシー」テーブルで「WS-Security」ポリシーをクリックします。
  4. セキュリティー・ポリシー・バインディングのセクションで「認証と保護」をクリックします。
  5. 認証トークン」で、トークン・コンシューマーまたはトークン生成プログラムの名前をクリックします。
  6. カスタム・プロパティー」セクションで、com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken カスタム・プロパティーを入力し、プロパティーの値を true と入力します。
  7. OK」をクリックしてから、「保存」をクリックします。
注: メッセージの交換中に SHA-1 鍵がインターセプトされる場合がある中間者 (man-in-the-middle) 攻撃の可能性を考慮する必要があります。 SHA-1 鍵を保護する場合は、SSL などのトランスポート・レベルのセキュリティーを使用するか、署名および暗号化によるメッセージ・レベルのセキュリティーを使用してください。

Kerberos V5 バイナリー AP_REQ トークンがカスタム・プロパティーなしで正しく生成または使用されない

原因:

Microsoft® Web サービス・アプリケーションが Kerberos トークンを使用するメッセージを要求する場合は、Kerberos V5 AP_REQ トークン用のカスタム・プロパティーをポリシー・バインディングで構成して、トークンを生成および使用する必要があります。 com.ibm.wsspi.wssecurity.kerberos.attach.apreq カスタム・プロパティーをクライアント・トークン生成プログラムバインディングとサービス・トークン・コンシューマー・バインディングに追加してください。 このプロパティーを使用可能にすることで、アプリケーションで Web サービスの要求メッセージごとの Kerberos AP_REQ トークンが生成され、使用されるようになります。

解決策:

Web サービスの要求メッセージごとに Kerberos V5 AP_REQ トークンをアプリケーションで生成または使用する場合は、以下の手順で、アプリケーション用のトークン生成プログラム・バインディングとトークン・コンシューマー・バインディングの com.ibm.wsspi.wssecurity.kerberos.attach.apreq カスタム・プロパティーを true に設定してください。
  • Microsoft .NET クライアント・アプリケーションと相互運用する場合は、ターゲット・サービスのトークン・コンシューマー・バインディングのカスタム・プロパティーを true に設定します。
  • Microsoft .NET サービスと相互運用する場合は、クライアント・トークン生成プログラム・バインディングのカスタム・プロパティーを true に設定します。
  • Web サービス・メッセージごとに Kerberos AP_REQ トークン をアプリケーションで生成する場合は、クライアント・トークン生成プログラム・バインディングとサービス・トークン・コンシューマー・バインディングの両方で、カスタム・プロパティーを true に設定してください。
注: Web サービスの要求メッセージごとに AP_REQ トークンを生成して使用することは、メッセージ処理の効率とメモリー使用量などの製品性能に影響を与えます。
管理コンソールでこのカスタム・プロパティーを設定するには、以下の手順を実行します。
  1. 管理コンソールで、「サービス」>「ポリシー・セット」とクリックします。
  2. 「汎用プロバイダー・ポリシー・セット・バインディング」>「binding_nameとクリックします。
  3. 「ポリシー」テーブルで「WS-Security」ポリシーをクリックします。
  4. セキュリティー・ポリシー・バインディングのセクションで「認証と保護」をクリックします。
  5. 「保護トークン」で、トークン・コンシューマーまたはトークン生成プログラムの名前をクリックします。
  6. 「カスタム・プロパティー」セクションで、com.ibm.wsspi.wssecurity.kerberos.attach.apreq カスタム・プロパティーと該当する値 (true) を入力します。

無効な証明書が使用された場合に CertPath 例外が発行されずに、有効な証明書パスが Sun Solaris でビルドされる

原因:

無効な証明書が使用されたにもかかわらず、Sun Solaris システム上の WS-Security が使用可能になっている Web サービス・アプリケーションで、 有効な証明書パスが誤ってビルドされる場合があります。要求側証明書の鍵と、サーバーで取得される証明書の鍵が一致しない場合、 エラー・メッセージが発行されます。ただし、DN 以外のすべての点で証明書が異なり、Sun セキュリティー・プロバイダーが使用されている場合、証明書パスが有効として戻されます。この問題は IBMCertPath セキュリティー・プロバイダーが使用されている場合には発生しません。IBMCertPath は Sun Solaris 以外のすべてのシステムではデフォルト・セキュリティー・プロバイダーになっているため、 この問題が発生するシステムは Sun Solaris のみです。

  • Web サービスが Sun Solaris 以外のシステムにデプロイされると、IBM デフォルト CertPath プロバイダー (IBMCertPath) が戻されます。コードが正しく機能している場合、 鍵が一致しないため、次の例外が発生します。
    WSEC5085E: Unable to build a valid CertPath:  java.security.cert.CertPathBuilderException:  
    unable to find valid certification path to requested target
  • Web サービスが Sun Solaris にデプロイされると、java.security.cert.CertPathBuilder.build メソッドは、IBM CertPath ではなく Sun デフォルト CertPath プロバイダーを戻します。Sun セキュリティー・プロバイダーは、 識別名 (DN) のみをチェックし、署名情報はチェックしません。

    無効な鍵のため、要求は失敗します。ただし、DN のみがチェックされるため、無効な CertPath が有効として戻されます。入力が DN を除き、サーバー側の証明書とすべての点で異なり無効な場合に、Sun Solaris で実行される Web サービス・アプリケーションは、 誤って、有効な CertPath をビルドする場合があります。

解決策:

新規のプロパティー (com.ibm.wsspi.wssecurity.config.CertStore.Provider) が WebSphere Application Server v 6.0.2 以降に追加されました。

Web Services Security が Solaris 上の WebSphere Application Server で実行されている場合に、このプロパティーによって、Web Services Security では Sun CertPath プロバイダーではなく、IBMCertPath プロバイダーが使用されるようになります。このプロパティーは、トラスト・アンカーを使用する場合、および証明書ストア・セキュリティー・プロバイダーが証明書ストアと一緒に指定された場合に、Web Services Security が使用する必要のあるセキュリティー・プロバイダーです。

com.ibm.wsspi.wssecurity.config.CertStore.Provider が指定され、かつ、セキュリティー・プロバイダーが証明書ストアに指定されている場合、証明書ストア・セキュリティー・プロバイダーは、com.ibm.wsspi.wssecurity.config.CertStore.Provider の設定をオーバーライドします。

ハードウェア暗号化要求にカードに関する例外が含まれている場合でも、暗号化ソフトウェアを使用して正常に要求を実行する必要がある

原因:

マシンの負荷が大きい場合、ハードウェア暗号化デバイスに関する例外が発生することがあります。 特定の操作で例外を受け取った場合は、代わりに暗号化ソフトウェアが使用されるため、要求は正常に実行されます。 ただし、ハードウェア暗号化デバイスは使用されません。

負荷テストの実行中に、以下のような例外が発生します。
CWWSS5601E: The following exception occurred while decrypting the message:
com.ibm.pkcs11.PKCS11Exception: Another operation is already active
および
CWWSS5601E: The following exception occurred while decrypting the message: Key handle is invalid:
com.ibm.pkcs11.PKCS11Exception: Key handle is invalid

この問題は、ハードウェア暗号化カードが多数の操作を処理している場合にのみ発生します。

解決策:

既知の回避策はありません。 ただし、ハードウェアの暗号化操作が失敗した場合にソフトウェアの暗号化が行われるため、要求は正常に実行されます。


トピックのタイプを示すアイコン 参照トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rwbs_troubleshoot
ファイル名:rwbs_troubleshoot.html