1. 構成ガイド
  2. SALTアプリケーションの構成
  3. Oracle Tuxedo Webサービスの構成
  4. セキュリティ機能の構成
  5. X.509ベース認証の構成

1.1.7.4 X.509ベース認証の構成

発信GWWS SOAPメッセージのX.509ベース認証には、X.509 V3公開キー証明書が必要です。この目的で使用する公開キー証明書は、同じWebサービスを宛先とするすべてのリクエスト用に1つの証明書を構成するか、Tuxedo SECURITYがUSER_AUTH以上に設定されている場合はリクエストの呼出しごとに1つの証明書を構成します。後者の場合、証明書にはTuxedoユーザーIDまたはマップされたリモート・ユーザー名(IDマッピング・プラグインがインストールされている場合)と同じ名前が付けられている必要があります。

構成したX.509公開キー証明書は、次のように使用されます。

  1. トランスポート層のセキュリティ用の手動認証(つまり、TLS)。
  2. メッセージ署名。
  3. メッセージレベルで(トランスポート層ではなく).ユーザーを認証するために使用するSOAPメッセージの一部

3つのタスクのすべてを実行するか一部のみを実行するかは、Webサービスで使用するWSポリシーによって異なります。

メッセージの暗号化は必須ではないため、サポートされません。メッセージの整合性とプライバシを保護するには、TLSを優先トランスポート・メカニズムにすることをお薦めします。TLSに使用されるX.509公開キー証明書は署名に使用されるものとは異なり、ユーザーの構成に依存します。

GWWSはクライアントからのリクエストを受信すると、メッセージを処理し、オプションでメッセージに署名を行い、WSポリシーで要求されている場合は証明書をSOAPリクエスト・メッセージへのバイナリ・セキュリティ・トークンとして添付します。次に、TLSを介してリモートWebサービスにリクエストを送信します。このTLS接続が一方向または双方向TLSのいずれになるかは、WSポリシーによって異なります。

TLS接続がプロセスを確立している間、接続が双方向TLSでありリクエストをWebサービスに転送する場合、アプリケーション・サーバーはクライアントの証明書を検証します。

Webサービスはリクエストを受信すると、Webサービスで要求されている場合は証明書を検証し、署名を検証します。リクエストが正しい場合は、応答を返信します。Webサービスによって返信される応答にも、WSポリシーに従って署名が行われます。

GWWSは応答を受信すると、それを実際のSALTクライアントに転送します。応答に署名がある場合、GWWSはSALTクライアントに応答を返信する前に、証明書を検証し、署名を確認します。

例1-24 X.509認証に基づくSOAPメッセージ

<S11:Envelope xmlns:S11="…" >
<S11:Header>
<wsse:Security xmlns:wsse="…" xmlns:wsu="…">
<wsse:BinarySecurityToken
wsu:id="binarytoken"
ValueType="wsse:X590v3"
EncodingType="wsse:Base64Binary">
MIIEzzCCA9CgAwIBAgIQEmtJZc0…
</wsse:BinarySecurityToken>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:Reference URI="#body">…</ds:Reference>
<ds:Reference URI="#binarytoken">…</ds:Reference>
</ds:SignedInfo>
…
</ds:Signature>
</wsse:Security>
</S11:Header>
<S11:Body wsu:Id="body" xmlns:wsu="…">
…
</S11:Body>
</S11:Envelope>

GWWSを介してWebサービスに正常にアクセスするには、GWWSが実行時にアクセスできる有効なクライアント証明書と秘密キーを構成する必要があります。この証明書と秘密キーは、Webサービスの要件に従って、トランスポート・レベル・セキュリティまたはメッセージ・レベル・セキュリティ、あるいはその両方で使用できます。

現在、Tuxedo SALTはデプロイメント記述子のSystem要素を通して構成された単一の証明書のみをサポートしています。この制限によって、異なるインスタンスのGWWSゲートウェイ 1を通過するすべてのリクエストでTLS接続を確立するために同じ証明書が使用されます。同様に、Webサービスからは、これらが同じユーザーから送られたものとして見えるため、アクセス権限は同じです。新機能によってこの制約が排除され、異なる証明書を使用して異なるクライアントまたはゲートウェイを表すことができるようになりました。

SALT構成は、デプロイメント記述子(DEP)と複数のWebサービス定義ファイル(WSDF)で構成されます。新しい機能では、この目的に使用するデフォルトのユーザーIDの構成や、TuxedoユーザーIDをX.509証明書にマップするためのフィルタ/マッパーの使用方法をGWWSに指示するために"Property"を使用します。構成に使用する"Property"は、"GWInstance"および"Service"の両方に構成可能な子要素として使用可能なXML要素です。"GWInstance"はSALTデプロイメント記述子に構成されており、"Service"はSALT Webサービス定義ファイルに構成されています。

WebサービスのWS-Securityポリシーでメッセージレベルのセキュリティが必要とされている場合、GWWSは秘密キーを使用してメッセージに署名を行い、SOAPメッセージにバイナリ・セキュリティ・トークンとして証明書を添付します。これは、ターゲットのWebサービスがメッセージを検証してユーザーを認証するために使用します。あるいは、証明書と秘密キーのみを使用して、セキュアなトランスポート・レイヤー接続(TLS)を作成します。

サービス・リクエストがユーザー識別に"X.509"セキュリティ・トークンを使用するかどうかは、Webサービスに関連付けられているWSセキュリティ・ポリシーによって決まります。

ノート:

この機能は、X.509 V3公開キー証明書のみをサポートします。他のバージョンはサポートされません。

親トピック: セキュリティ機能の構成