![]() ![]() ![]() ![]() |
この章では、Web サービスのセキュリティをコンフィグレーションする方法について説明します。
WebLogic Web サービスを保護するには、以下の 3 種類の異なるセキュリティを 1 つまたは複数コンフィグレーションします。
「メッセージレベルのセキュリティ (デジタル署名と暗号化) のコンフィグレーション」を参照してください。
「転送レベルのセキュリティのコンフィグレーション」を参照してください。
「アクセス制御セキュリティのコンフィグレーション : 主な手順」を参照してください。
アクセス制御のセキュリティは、「誰が何を実行できるか」という質問の回答となります。まず、Web サービスへのアクセスが許可されているセキュリティ ロールを指定します。セキュリティ ロールとは、特定の条件に基づいてユーザまたはグループに付与される特権です。次に、クライアント アプリケーションが Web サービスのオペレーションを呼び出そうとするときに、そのクライアントは WebLogic Server に対して自身を認証し、権限がある場合はその呼び出しを続行することができます。アクセス制御セキュリティは、WebLogic Server のリソースのみを保護します。つまり、アクセス制御のセキュリティしかコンフィグレーションされていない場合は、クライアント アプリケーションと WebLogic Server の接続が保護されず、SOAP メッセージはプレーン テキストになります。
転送レベルのセキュリティでは、クライアント アプリケーションと WebLogic Server の間の接続がセキュア ソケット レイヤ (SSL) で保護されます。SSL では、ネットワーク接続している 2 つのアプリケーションが互いの ID を認証できるようにするとともに、アプリケーション間でやりとりされるデータを暗号化することでセキュアな接続が実現します。認証を使用すると、サーバは (場合によってはクライアントも) ネットワーク接続の相手側アプリケーションの ID を検証できます。ネットワーク経由で送信されるデータは暗号化されるので、予定されている宛先以外には解釈できません。
ただし、転送レベルのセキュリティでは接続そのものしか保護されません。つまり、クライアントと WebLogic Server の間にルータやメッセージ キューなどの仲介機能がある場合、その仲介機能は SOAP メッセージをプレーン テキストで取得します。仲介機能から次の送信先にメッセージが送信されたとき、その受信側では元々そのメッセージがどこから来たのかわかりません。また、SSL で使用される暗号化は「オール オア ナッシング」です。つまり、SOAP メッセージの全体が暗号化されるか、あるいはまったく暗号化されないかのいずれかになります。SOAP メッセージの一部だけを選択して暗号化することはできません。
メッセージレベルのセキュリティでは、SSL のすべてのセキュリティ上のメリットに、柔軟性と機能が追加されます。メッセージレベルのセキュリティはエンド ツー エンドです。つまり、SOAP メッセージは転送の過程でいくつ仲介機能があっても保護されます。接続だけでなく、SOAP メッセージ自体がデジタル署名および暗号化されます。さらに、メッセージの一部のみを署名または暗号化するように指定することもできます。
メッセージレベルのセキュリティでは、クライアント アプリケーションとそれが呼び出す Web サービスの間の SOAP メッセージに対してデジタル署名、暗号化、またはその両方のいずれを行うかを指定します。複数の SOAP メッセージを交換するイベントにおいて、Web サービスとクライアント間で共有セキュリティ コンテキストを指定することもできます。
WebLogic Web サービスには、以下の 2004 年 4 月 6 日付の OASIS 標準 Web Services Security (WS-Security) 1.0Web サービス セキュリティ (WS-Security) 1.0 仕様が実装されています。
これらの仕様は、セキュリティ トークンの伝播、メッセージの整合性、およびメッセージの機密性を提供します。これらのメカニズムは別々に (ユーザ認証でのユーザ名トークンの受け渡しなど)、または組み合わせて (SOAP メッセージのデジタル署名と暗号化、認証でのユーザによる X.509 証明書の使用の指定など) 使用できます。
また、WebLogic Web サービスには Web Services Trust Language (WS-Trust) 仕様と Web Services Secure Conversation Language (WS-SecureConversation) 仕様も実装されています。これらが連携して Web サービスとそのクライアント (または別の Web サービスやスタンドアロンの Java クライアント アプリケーション) との間のセキュアな通信を提供します。具体的に言うと WS-SecureConversation 仕様には、セキュアな会話を実現するために、セキュリティ コンテキストの確立と共有のメカニズム、およびセキュリティ コンテキストからキーを派生するためのメカニズムが定義されています。セキュリティ コンテキストと派生キーを併用すると、交換の全体的なパフォーマンスやセキュリティの向上につながります。この機能は WS-Security 仕様にはありません。WS-Security 仕様はメッセージの認証モデルに重点をおいたもので、そのためにさまざまなセキュリティ攻撃の影響を受けることがあります。
WS-Policy 仕様 (2004 年 9 月付) で指定されているように、セキュリティ ポリシー ステートメントを格納する 1 つまたは複数の WS-Policy ファイルを添付することにより、Web サービスのメッセージレベルのセキュリティをコンフィグレーションします。Web サービス実行時環境におけるこれらのファイルの使用方法については、「メッセージレベルのセキュリティ コンフィグレーションに対する WS-Policy ファイルの使い方」を参照してください。
簡単なメッセージレベルのセキュリティをコンフィグレーションする場合に実行する基本的な手順については、「簡単なメッセージレベルのセキュリティのコンフィグレーション : 主な手順」を参照してください。この節では、Web サービス実行時環境に対するメッセージレベルのセキュリティのコンフィグレーション、特定の Web サービスに対するメッセージレベルのセキュリティのコンフィグレーション、およびそのサービスを呼び出すクライアント アプリケーションのコーディング方法について説明します。
また、Web サービスのデプロイ後に、実行時における Web サービスのメッセージレベルのセキュリティをコンフィグレーションすることもできます。詳細については、「Administration Console を使用した実行時の WS-Policy ファイルの関連付け」を参照してください。
注意 : | SOAP 添付ファイルに対しては、デジタル署名も暗号化も行えません。 |
Web Services Security: SOAP Message Security 仕様の BEA 実装は、以下の使い方をサポートします。
1 つまたは複数の WS-Policy ファイルを使用して、WebLogic Web サービスのメッセージレベルのセキュリティの詳細を指定します。WS-Policy 仕様には、Web サービスのポリシーを記述して通信するための、汎用的なモデルと XML 構文が規定されています。
注意 : | WebLogic Server には、ほとんどの使用例について推奨されるあらかじめパッケージ化された WS-Policy ファイルが用意されています。「WebLogic Server WS-Policy ファイル」を参照してください。ただし、認証に SAML トークンを使用する場合や、SOAP メッセージの全体ではなく、特定の一部分に対し暗号化またはデジタル署名を行う場合は、独自の WS-Policy ファイルを作成する必要があります。「カスタム WS-Policy ファイルの作成と使用」を参照してください。 |
メッセージレベルのセキュリティに使用される WS-Policy ファイルは、オペレーションを呼び出した結果として発生する SOAP メッセージに対してデジタル署名または暗号化を行うかどうかの明記とその方法が記述された XML ファイルです。また、クライアント アプリケーションがユーザ名、SAML、または X.509 の各トークンを使用して自身を認証することの指定もできます。
注意 : | WebLogic Web サービスのメッセージレベルのセキュリティをコンフィグレーションするための WS-Policy ファイルで使用されるポリシー アサーションは、Web Services Security Policy Language (WS-SecurityPolicy) 仕様 (2002 年 12 月 18 日付) に記述されているアサーションに基づいています。つまり、WebLogic Server のアサーションの正確な構文と使用方法は、この仕様で説明されているアサーションとは異なっていますが、意味上の違いはありません。このアサーションは、最新の仕様 (2005 年 7 月 13 日付) には基づいていません。 |
WS-Policy ファイルを Web サービスと関連付けるには、JWS ファイル内で @Policy
および @Policies
JWS アノテーションを使用します。Web サービスに関連付けることのできる WS-Policy ファイルの数に制限はありません。ただし、アサーションが互いに矛盾しないように管理者が確認する必要があります。WS-Policy ファイルは、JWS ファイルのクラスレベルでも、メソッドレベルでも指定できます。
WebLogic Server には WS-Policy ファイルのセットが用意されていて、独自の WS-Policy ファイルを作成しない場合に JWS ファイルに指定できます。特定のセキュリティ ニーズがない限り、できるだけこうしたあらかじめパッケージ化されているファイルを使用するようにします。これらの WS-Policy ファイルはすべて抽象ファイルです。詳細については、「抽象および具象 WS-Policy ファイル」を参照してください。
あらかじめパッケージ化されている WS-Policy ファイルは以下のとおりです。
Sign.xml
や Encrypt.xml
と併用することもできます。Auth.xml
や Encrypt.xml
と併用することもできます。Auth.xml
や Sign.xml
と併用することもできます。注意 : | このあらかじめパッケージ化された WS-Policy ファイルは単体での使用を目的としています。Auth.xml 、Sign.xml 、Encrypt.xml 、または Wssc-sct.xml との併用は意図されていません。また、クライアントとサービスでセキュリティ コンテキストを共有する場合、セキュリティ レベルを高めるためには Wssc-sct.xml ではなくこの WS-Policy ファイルを使用することをお勧めします。 |
注意 : | このあらかじめパッケージ化された WS-Policy ファイルは単体での使用を目的としています。Auth.xml 、Sign.xml 、Encrypt.xml 、または Wssc-dk.xml との併用は意図されていません。また、この WS-Policy ファイルでは WS-SecureConversation 仕様のさまざまな使用例がサポートされますが、クライアントとサービスでセキュリティ コンテキストを共有する場合、セキュリティ レベルを高めるためには Wssc-sct.xml ではなく Wssc-dk.xml WS-Policy ファイルを使用することをお勧めします。 |
下記の WebLogic Server Auth.xml
ファイルでは、Web サービスを呼び出すクライアント アプリケーションが、認証をサポートしているトークン (ユーザ名または X.509) のいずれかを使用して自身を認証する必要があることを指定します。
あらかじめパッケージ化されている WS-Policy ファイルは抽象ファイルです。そのため、開発時には Auth.xml
ファイルに特定のユーザ名や X.509 トークンのアサーションはありません。ユーザが WebLogic Server に対してどのようにセキュリティをコンフィグレーションしたかによって、ユーザ名トークン、X.509 トークン、またはその両方が、Web サービスに関連付けられた実際の実行時バージョンの Auth.xml
WS-Policy ファイルに示されます。さらに、実行時バージョンの WS-Policy ファイルにある X.509 トークンがクライアントの呼び出しに適用される場合は、SOAP メッセージの本文全体が署名されます。
ID として X.509 のみを使用し、ユーザ名トークンは使用しないように指定する場合、また ID として X.509 を使用していて SOAP メッセージの特定の部分だけを署名するように指定する場合は、カスタム WS-Policy ファイルを作成する必要があります。「ID として X.509 証明書トークンのみを使用する場合」を参照してください。
<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
>
<wssp:Identity/>
</wsp:Policy>
WebLogic Server の Sign.xml
ファイルでは、SOAP メッセージの本文および WebLogic 固有のシステム ヘッダをデジタル署名することを指定します。また、デジタル署名されるタイムスタンプを SOAP メッセージに含めることを指定し、署名に使用するトークンにもデジタル署名を行うことを指定します。署名に使用するトークンは SOAP メッセージに含まれます。
以下のヘッダは、Sign.xml
WS-Policy ファイルの使用時に署名されます。
以下に WebLogic Server の Sign.xml
ファイルを示します。
<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
>
<wssp:Integrity>
<wssp:SignatureAlgorithm URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<wssp:CanonicalizationAlgorithm
URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1" />
<wssp:MessageParts
Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SystemHeaders()
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1" />
<wssp:MessageParts
Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SecurityHeader(wsu:Timestamp)
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1" />
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
</wssp:Integrity>
<wssp:MessageAge/>
</wsp:Policy>
WebLogic Server の Encrypt.xml
ファイルでは、SOAP メッセージの本文全体を暗号化することを指定します。デフォルトでは、暗号化トークンは SOAP メッセージに含まれません。
<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
>
<wssp:Confidentiality>
<wssp:KeyWrappingAlgorithm URI="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<wssp:Target>
<wssp:EncryptionAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
<wssp:KeyInfo/>
</wssp:Confidentiality>
</wsp:Policy>
WS-SecureConversation 仕様のとおりにクライアントと Web サービスでセキュリティ コンテキストを共有すること、および派生キー トークンを使用することを指定します。このファイルは、もっとも高度なセキュリティを確保できます。
この WS-Policy ファイルでは以下のコンフィグレーションが提供されます。
デフォルトのセキュリティ コンテキストと派生キーの動作を変更する場合は、以降の節で説明するカスタム WS-Policy ファイルを作成する必要があります。
警告 : | このあらかじめパッケージ化された WS-Policy ファイルを指定する場合、他のあらかじめパッケージ化された WS-Policy ファイルは指定しないでください。 |
<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
>
<wssp:Integrity SupportTrust10="true">
<wssp:SignatureAlgorithm URI="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
<wssp:CanonicalizationAlgorithm URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SystemHeaders()
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SecurityHeader(wsu:Timestamp)
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
<wssp:SupportedTokens>
<wssp:SecurityToken IncludeInMessage="true"
TokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/dk"
DerivedFromTokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct">
<wssp:Claims>
<wssp:Label>WS-SecureConversationWS-SecureConversation</wssp:Label>
<wssp:Length>16</wssp:Length>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Integrity>
<wssp:Confidentiality SupportTrust10="true">
<wssp:Target>
<wssp:EncryptionAlgorithm URI="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()</wssp:MessageParts>
</wssp:Target>
<wssp:KeyInfo>
<wssp:SecurityToken IncludeInMessage="true"
TokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/dk"
DerivedFromTokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct">
<wssp:Claims>
<wssp:Label>WS-SecureConversationWS-SecureConversation</wssp:Label>
<wssp:Length>16</wssp:Length>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:KeyInfo>
</wssp:Confidentiality>
<wssp:MessageAge/>
</wsp:Policy>
WS-SecureConversation 仕様のとおりに、クライアントと Web サービスでセキュリティ コンテキストを共有することを指定します。この場合、SOAP メッセージの暗号化と署名にはセキュリティ コンテキスト トークンが使用されます。これは Wssc-dk.xml の場合とは異なり、Wssc-dk.xml では派生キー トークンが使用されます。Wssc-sct.xml
WS-Policy ファイルは、仕様のすべての使用例をサポートするために提供されています。ただし、セキュリティ コンテキストの共有を指定する場合、最高のセキュリティを実現するためには、セキュリティ レベルの高い Wssc-dk.xml を常に使用することをお勧めします。
この WS-Policy ファイルでは以下のコンフィグレーションが提供されます。
デフォルトのセキュリティ コンテキストと派生キーの動作を変更する場合は、以降の節で説明するカスタム WS-Policy ファイルを作成する必要があります。
警告 : | このあらかじめパッケージ化された WS-Policy ファイルを指定する場合、他のあらかじめパッケージ化された WS-Policy ファイルは指定しないでください。 |
<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
>
<wssp:Integrity SupportTrust10="true">
<wssp:SignatureAlgorithm URI="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
<wssp:CanonicalizationAlgorithm URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SystemHeaders()
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SecurityHeader(wsu:Timestamp)
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
<wssp:SupportedTokens>
<wssp:SecurityToken IncludeInMessage="true"
TokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct">
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Integrity>
<wssp:Confidentiality SupportTrust10="true">
<wssp:Target>
<wssp:EncryptionAlgorithm URI="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()</wssp:MessageParts>
</wssp:Target>
<wssp:KeyInfo>
<wssp:SecurityToken IncludeInMessage="true"
TokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct">
</wssp:SecurityToken>
</wssp:KeyInfo>
</wssp:Confidentiality>
<wssp:MessageAge />
</wsp:Policy>
WebLogic Web サービス実行時環境では、抽象および具象という若干異なる 2 種類の WS-Policy ファイルが認識されます。「WebLogic Server WS-Policy ファイル」で説明した、あらかじめパッケージ化されている WS-Policy ファイルは、すべて抽象ファイルです。
抽象 WS-Policy ファイルでは、認証、暗号化、およびデジタル署名に使用されるセキュリティ トークンが明示的に指定されません。Web サービス実行時環境が Web サービスがデプロイされるときにセキュリティ トークンを決定します。つまり具体的には、WS-Policy ファイルの <Identity>
および <Integrity>
要素 (またはアサーション) には <SupportedTokens><SecurityToken>
子要素が含まれず、WS-Policy ファイルの <Confidentiality>
要素には <KeyInfo><SecurityToken>
子要素が含まれません。
Web サービスがあらかじめパッケージ化されている WS-Policy ファイルのみに関連付けられている場合は、クライアント認証でユーザ名トークンが必要になります。Web サービスでは、暗号化とデジタル署名用のトークン タイプは 1 つしかサポートされていません (X.509
)。つまり、<Integrity>
要素および <Confidentiality>
要素が使用される場合でも、抽象 WS-Policy ファイルと具象 WS-Policy ファイルは結果として本質的には同じになります。
Web サービスが抽象 WS-Policy ファイルに関連付けられ、そのファイルが WSDL の添付ファイルとして公開される場合 (デフォルトの動作)、Web サービスのアーカイブ ファイル (JAR または WAR) にパッケージ化される静的 WSDL ファイルは、デプロイされた Web サービスの動的 WSDL ファイルとは若干異なります。つまり、抽象的な静的 WSDL には特定の <SecurityToken>
要素が含まれていないのに対し、動的 WSDL にはこうした要素が含まれています。これは、サービスがデプロイされるときに Web サービス ランタイムによってこれらの要素が自動的に設定されるためです。このため、クライアント アプリケーション内に JAX-RPC スタブを作成するコードにおいては、必ず動的 WSDL を指定してください。そうしないとオペレーションを呼び出そうとしたときに実行時エラーが発生します。
HelloService service = new HelloService(Dynamic_WSDL);
この場合、clientgen
Ant タスクには静的 WSDL と動的 WSDL のどちらでも指定できます。デプロイされた Web サービスの動的 WSDL ファイルの表示については、「Web サービスの WSDL の参照」を参照してください。
具象 WS-Policy ファイルでは、Web サービスのプログラミング時にセキュリティ トークンの詳細が明示的に指定されます。サービスのプログラミング時に、認証のタイプの詳細 (x509
トークンまたは SAML
トークンの使用など) や、キーストアの複数のプライベート キーと証明書のペアが暗号化とデジタル署名に使用されるかどうかなどが分かっている場合に、具象 WS-Policy ファイルを作成します。
以下では、Web サービス セキュリティ ランタイム、特定の WebLogic Web サービス、および Web サービスのオペレーションを呼び出すクライアント アプリケーションに対して簡単なメッセージレベルのセキュリティをコンフィグレーションする手順について説明します。このマニュアルでは、簡単なメッセージレベルのセキュリティを次のように定義します。
警告 : | それぞれの WebLogic Server インスタンスが別のコンピュータ上で動作しているクラスタに Web サービスをデプロイする場合は、テスト目的であっても、用意されているもの以外のキーストアおよびキー ペアを使用する必要があります。これは、デフォルトの WebLogic Server キーストア DemoIdentity.jks 内のキー ペアが、異なるマシン上で動作している WebLogic Server 間で同じになるという保証がないためです。デフォルトのキーストアを使用する場合は、デプロイされている Web サービスの WSDL で、これらのキーストアの 1 つから公開鍵が指定されますが、実際にはサービスの呼び出しは、別のコンピュータ上で実行されているサーバによって処理される可能性があり、この場合、サーバのプライベート キーは、公開されている公開鍵に一致せず、呼び出しが失敗してしまいます。この問題は、クラスタ内でデフォルトのキーストアとキー ペアを使用した場合に発生するものであり、独自のキーストアとキー ペアを使用することで簡単に解決されます。 |
上記のシナリオの一部に関する詳細と、簡単なメッセージレベルのセキュリティの使用例に基づいて Web サービス セキュリティを追加する使用例については、後半の節で説明します。
次の手順では、WebLogic Web サービスを実装する JWS ファイルがすでに作成済みであることを前提として、SOAP メッセージにデジタル署名と暗号化を行うようにそのファイルを更新します。また、Ant ビルド スクリプトを使用して Web サービスを反復的に開発することと、新しい情報で更新できる作業用の build.xml
ファイルがあることも前提となっています。さらに、保護されていない Web サービスを呼び出すクライアント アプリケーションも用意されているものとします。これらの前提条件が満たされていない場合は、以下を参照してください。
WebLogic Web サービスに対して簡単なメッセージ レベルのセキュリティをコンフィグレーションするには、次の手順に従います。
@Policy
および @Policies
JWS アノテーションを追加して、Web サービス全体または特定のオペレーションに添付されるあらかじめパッケージ化された WS-Policy ファイルを指定します。
WS-Policy ファイルの指定方法については、「@Policy および @Policies アノテーションによる JWS ファイルの更新」を参照してください。この基本的な手順の場合は、あらかじめパッケージ化されている WS-Policy ファイル (Auth.xml
、Sign.xml
、Encrypt.xml
、Wssc-dk.xml
、および Wssc-sct.xml
) を指定する手順を行うだけでかまいません。
「Java から開始する WebLogic Web サービスの反復的な開発 : 主な手順」を参照してください。
この手順には、Cert Gen ユーティリティまたは Sun Microsystems の keytool ユーティリティを使用します。開発が目的の場合は、keytool
ユーティリティを使用すると簡単に開始できます。
「プライベート キー、デジタル証明書、信頼性のある認証局の取得」を参照してください。
証明書のキーを使用することで、暗号化とデジタル署名の双方ができるようになっていることを確認してください。WebLogic Server でクライアントの証明書が有効であることを確認する方法については、「WebLogic Server でクライアントの証明書を検証できることの確認」も参照してください。
警告 : | キーの長さは 1024 ビット以上にする必要があります。 |
この手順には、Sun Microsystems の keytool ユーティリティを使用できます。
「プライベート キー、デジタル証明書、信頼性のある認証局の取得」を参照してください。
「ユーザ、グループ、セキュリティ ロール」を参照してください。
「クライアント アプリケーションの更新によるメッセージ保護された Web サービスの呼び出し」を参照してください。
全般的な情報については、「クライアント アプリケーションのコンパイルと実行」を参照してください。
簡単なメッセージレベルのセキュリティの使用例に基づいて Web サービス セキュリティを追加する使用例については、以下の節を参照してください。
メッセージ保護された Web サービスの問題をデバッグする方法については、「システム プロパティを使用したメッセージ レベルのセキュリティのデバッグ」を参照してください。
クライアントが SOAP リクエストのデジタル署名に使用し、WebLogic Server がクライアントへの SOAP 応答の暗号化に使用する X.509 証明書を WebLogic Server で検証できることを確認しておく必要があります。以下のいずれかを実行します。
詳細については、「SSL 証明書の検証」を参照してください。
JWS ファイルで @Policy
アノテーションおよび @Policies
アノテーションを使用して、Web サービスに 1 つまたは複数の WS-Policy ファイルが添付されていることを指定できます。これらのアノテーションは、クラス レベルまたはメソッド レベルのいずれかで使用できます。
@Policies
アノテーションは、複数の @Policy
アノテーションをグループ化するものです。複数の WS-Policy ファイルをクラスまたはメソッドに添付する場合は、@Policies
アノテーションを使用してください。WS-Policy ファイルを 1 つだけ添付する場合は、そのファイル自体に対して @Policy
を使用します。
@Policy
アノテーションでは、1 つの WS-Policy ファイル、その場所、ポリシーが SOAP のリクエスト メッセージ、応答メッセージ、またはその両方のいずれに適用されるか、およびその WS-Policy ファイルをサービスの公開 WSDL に添付するかどうかを指定します。
警告 : | すべての JWS アノテーションについて言えることですが、@Policy アノテーションは実行時にオーバーライドされません。つまり、アノテーションを使用してビルド時に指定した WS-Policy ファイルは、常に Web サービスに関連付けられます。したがって、たとえば、関連付けられている WS-Policy ファイルは実行時に Administration Console で確認できますが、削除 (関連付けを解除) することはできません。ただし、WS-Policy ファイルを追加で関連付けることは可能です。これについては「Administration Console を使用した実行時の WS-Policy ファイルの関連付け」を参照してください。 |
uri
属性を使用して、WS-Policy ファイルの場所を以下のように指定します。
policy:
プレフィックスといずれかの WS-Policy ファイルの名前 (Auth.xml
、Encrypt.xml
、Sign.xml
、Wssc-dk.xml
、または Wssc-sct.xml
) を使用する。@Policy(uri="policy:Encrypt.xml")
あらかじめパッケージ化されている WS-Policy ファイルを使用する場合は、独自のファイルを作成する必要も、アクセス可能な場所にファイルをパッケージ化する必要もありません。このため、できる限り、あらかじめパッケージ化されている WS-Policy ファイルを使用することをお勧めします。
あらかじめパッケージ化されている WS-Policy ファイルで提供される、各種のメッセージレベルのセキュリティについては、「メッセージレベルのセキュリティ コンフィグレーションに対する WS-Policy ファイルの使い方」を参照してください。
@Policy(uri="../policies/MyPolicy.xml")
この例では、MyPolicy.xml
ファイルは、JWS ファイルを格納するディレクトリの policies
兄弟ディレクトリにあります。
この場合では、WS-Policy ファイルは共有 J2EE ライブラリの META-INF/policies
または WEB-INF/policies
ディレクトリ内にあることが前提となっています。ライブラリをパッケージ化する際には、このディレクトリに WS-Policy ファイルを入れるようにしてください。
共有 J2EE ライブラリにある WS-Policy ファイルを指定するには、次の例に示すように、policy:
プレフィックスと WS-Policy ファイルの名前を使用します。
@Policy(uri=”policy:MySharedPolicy.xml”)
共有ライブラリの作成、および Web サービスが共有の WS-Policy ファイルを見つけられるようにするための環境設定については、「共有 J2EE ライブラリおよびオプション パッケージの作成」を参照してください。
@Policy
アノテーションで以下の属性を設定することもできます。
direction
- ポリシー ファイルがリクエスト (着信) SOAP メッセージ、応答 (発信) SOAP メッセージ、またはその両方のいずれに適用されるかを指定する。この属性を指定しない場合のデフォルト値は、both です。direction
属性には、以下の値を指定できます。attachToWsdl
- ポリシー ファイルを、Web サービスのパブリック規約を記述した WSDL ファイルに添付するかどうかを指定する。この属性のデフォルト値は false
です。抽象 WS-Policy ファイルはビルド時には添付されません。それらは、欠落している情報が WebLogic Server によって設定されるデプロイ時に添付されます。
次の例では、@Policy
および @Policies
JWS アノテーションの使い方を示します。該当する個所は太字で表示しています。
package examples.webservices.security_jws;
import weblogic.jws.WLHttpTransport;import weblogic.jws.Policies;
import javax.jws.WebService;
import weblogic.jws.Policy;
import javax.jws.WebMethod;
import javax.jws.soap.SOAPBinding;
/**
*
*/
@WebService(name="SecureHelloWorldPortType",
serviceName="SecureHelloWorldService",
targetNamespace="http://www.bea.com")
@SOAPBinding(style=SOAPBinding.Style.DOCUMENT,
use=SOAPBinding.Use.LITERAL,
parameterStyle=SOAPBinding.ParameterStyle.WRAPPED)
@WLHttpTransport(contextPath="SecureHelloWorldService",
serviceUri="SecureHelloWorldService",
portName="SecureHelloWorldServicePort")
@Policies({
@Policy(uri="policy:Auth.xml", direction=Policy.Direction.inbound),
@Policy(uri="policy:Sign.xml"),
@Policy(uri="policy:Encrypt.xml")})
public class SecureHelloWorldImpl {
@WebMethod()
public String sayHello(String s) {
return "Hello " + s;
}
}
この例では、3 つの WS-Policy ファイルがクラス レベルで Web サービスに添付されています。つまり、3 つすべての WS-Policy ファイルは Web サービスのすべてのパブリック オペレーションに適用されます。指定された WS-Policy ファイルは、WebLogic Server であらかじめパッケージ化されているファイルです。つまり、開発者は独自のファイルを作成する必要も、対応するアーカイブにファイルをパッケージ化する必要もありません。
Auth.xml
ファイルは、direction
属性で指定されているように、リクエスト (着信) SOAP メッセージのみに適用されます。このため、クライアント アプリケーションのみでユーザ名トークンの指定が必要になります。WebLogic Server が呼び出しに応答するときにはユーザ名トークンは指定されません。Sign.xml
WS-Policy ファイルは、SOAP のリクエスト メッセージおよび応答メッセージの両方の本文と WebLogic システム ヘッダにデジタル署名が行われることを指定しています。Encrypt.xml
ポリシー ファイルは、SOAP のリクエスト メッセージおよび応答メッセージの両方の本文が暗号化されることを指定しています。
「簡単なメッセージレベルのセキュリティのコンフィグレーション : 主な手順」で説明した、簡単なメッセージレベルのコンフィグレーション手順では、Web サービス ランタイムが WebLogic Server に用意されているプライベート キーと X.509 証明書のペアを使用することが前提となっています。SSL 用のコア セキュリティ サブシステムでも同じキー ペアが使用されます。このキー ペアは主にデモまたはテスト目的用に用意されています。プロダクション環境では、Web サービス ランタイムは通常、独自のプライベート キーとデジタル証明書のペアを 2 つ使用します。1 つは SOAP メッセージの署名用、もう 1 つは SOAP メッセージの暗号化用です。
以下では、これらを使用できるようにするための追加の手順について説明します。
必須ではありませんが、WebLogic Web サービスのみが使用するペアを 2 つ取得することをお勧めします。両方の証明書のキーの用途がコンフィグレーションの目的と一致していることを確認してください。たとえば、証明書を暗号化に使用するように指定する場合は、証明書のキーの用途が暗号用として指定されているか、または用途が定義されていないことを確認します。そうでない場合、Web サービス セキュリティ ランタイムによって証明書が拒否されます。
警告 : | キーの長さは 1024 ビット以上にする必要があります。 |
この手順には、Cert Gen ユーティリティまたは Sun Microsystems の keytool ユーティリティを使用します。開発が目的の場合は、keytool
ユーティリティを使用すると簡単に開始できます。
「プライベート キー、デジタル証明書、信頼性のある認証局の取得」を参照してください。
SSL 用に WebLogic Server をすでにコンフィグレーションしてある場合は、この手順で使用できる ID キーストアがすでに作成されています。
この手順には、WebLogic の ImportPrivateKey
ユーティリティと、Sun Microsystems の keytool ユーティリティを使用できます。開発が目的の場合は、keytool
ユーティリティを使用すると簡単に開始できます。
「キーストアの作成およびプライベート キーと信頼性のある認証局のキーストアへのロード」を参照してください。
「プロダクション用のキーストアのコンフィグレーション」を参照してください。
default_wss
にする必要があります。デフォルトの Web サービス セキュリティ コンフィグレーションは、別のコンフィグレーションを使用するように明示的にプログラミングされていない限り、ドメイン内のすべての Web サービスで使用されます。
「Web サービス セキュリティ コンフィグレーションの作成」を参照してください。
「SOAP メッセージに署名する際に使用されるキー ペアの指定」を参照してください。この手順では、キーストアとキー ペアの識別に使用されるプロパティを作成するときに各プロパティの正確な値 (IntegrityKeyStore
、IntegrityKeyStorePassword
など) を [名前] フィールドに入力します。ただし、独自に作成したキーストアとキー ペアを識別する値は [値] フィールドに入力します。
「SOAP メッセージの暗号化に使用されるキー ペアの指定」を参照してください。この手順では、キーストアとキー ペアの識別に使用されるプロパティを作成するときに、各プロパティの正確な値 (ConfidentialityKeyStore
、ConfidentialityKeyStorePassword
など) を [名前] フィールドに入力します。ただし、独自に作成したキーストアとキー ペアを識別する値は [値] フィールドに入力します。
WS-Policy ファイルの <MessageAge>
要素では、WS-Policy ファイルに関連付けられている Web サービスを呼び出した結果として発生する SOAP メッセージに有効期限があるかどうかを指定します。有効期限とメッセージに含まれる作成時のタイムスタンプに基づいて期限切れになった SOAP リクエストは WebLogic Server で拒否されます。また、サービスに関連付けられている Web サービス セキュリティ コンフィグレーションを作成および更新する Administration Console を使用してメッセージの有効期限をコンフィグレーションすることもできます。
以下の項目では、WebLogic Web サービス ランタイムが特定の Web サービスの SOAP メッセージの有効期限を決定する方法について説明します。
<MessageAge>
アサーションが含まれていない場合、SOAP メッセージは期限切れにならない。 <MessageAge>
アサーションが属性のない状態で含まれており、さらに Web サービスが Web サービス セキュリティ コンフィグレーションに関連付けられていない場合、有効期限は 60 秒。Web サービスが Web サービス セキュリティ コンフィグレーションに関連付けられている場合、有効期限は、関連付けられた Web サービス セキュリティ コンフィグレーション (通常は default_wss
) の [有効期間] タイムスタンプ フィールドの値です。
あらかじめパッケージ化されている Sign.xml
WS-Policy ファイルはこのカテゴリに分類されます。
Age
属性が指定された <MesageAge>
アサーションが含まれている場合、有効期限は Age
属性の値。この値は常に、関連付けられた Web サービス セキュリティ コンフィグレーションの [有効期間] フィールドの値をオーバーライドします。
次の手順では、「簡単なメッセージレベルのセキュリティのコンフィグレーション : 主な手順」での手順がすでに実行されていることを前提として、メッセージの有効期限を設定します。
SOAP メッセージの有効期限を設定するには、次の手順に従います。
<MessageAge>
アサーションが含まれていることを確認します。あらかじめパッケージ化されている Sign.xml
ファイルには、属性のない状態の <MessageAge> アサーションが含まれています。
カスタム WS-Policy ファイルに <MessageAge>
アサーションを追加する場合は、Age
属性を指定してください。設定すると、この属性の値が有効期限になります。この値は、Administration Console でオーバーライドされません。デフォルトの 60 秒に設定するために属性を指定しない場合は、そのままでかまいません。ただし、デフォルト値を変更する場合は、次の手順に進みます。
default_wss
にする必要があります。デフォルトの Web サービス セキュリティ コンフィグレーションは、別のコンフィグレーションを使用するように明示的にプログラミングされていない限り、ドメイン内のすべての Web サービスで使用されます。
「Web サービス セキュリティ コンフィグレーションの作成」を参照してください。
WebLogic Server には、ほとんどのプログラマの通常のセキュリティ ニーズを満たす 5 つの WS-Policy ファイルがあらかじめパッケージ化されていますが、追加のコンフィグレーションが必要な場合は、独自の WS-Policy ファイルを作成して使用することもできます。たとえば、以下の場合に独自の WS-Policy ファイルを作成する必要があります。
WS-Policy ファイルの全般的な情報とそれらのメッセージレベルのセキュリティ コンフィグレーションでの使用方法については、「メッセージレベルのセキュリティ コンフィグレーションに対する WS-Policy ファイルの使い方」を参照してください。
カスタム WS-Policy ファイルを作成する場合には、あらかじめパッケージ化されているファイルと同じように 3 つの主なセキュリティ カテゴリ (認証、暗号化、および署名) を 3 つの別々の WS-Policy ファイルに分けることもできますし、3 つのカテゴリすべてを含む 1 つの WS-Policy ファイルを作成することもできます。また、認証など 1 つのカテゴリだけを変更するカスタム WS-Policy ファイルを作成し、その他のカテゴリについてはあらかじめパッケージ化されているファイル (Sign.xml
および Encrypt.xml
) を使用することもできます。つまり、Web サービスに関連付ける WS-Policy ファイルの数および内容は、適宜組み合わせることができます。ただしこの場合は、それらの複数のファイルが互いに矛盾していないことを常に確認する必要があります。
WS-Policy ファイルのルート要素は <Policy>
でなければなりません。また、この要素には次のネームスペース宣言が含まれている必要があります。
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
>
WS-Policy ファイルで、<Policy>
ルート要素の以下の子要素を定義します。これらの要素の詳細なリファレンス情報については、「セキュリティ ポリシー アサーションのリファレンス」を参照してください。
<Identity>
- 認証用にサポートされているトークンを指定します。<SupportedTokens>
要素は、ID としてサポートされているトークンのタイプ (ユーザ名、X.509、または SAML) ごとに 1 つまたは複数の <SecurityTokens>
要素をグループ化します。SAML トークンの確認のタイプ (sender-vouches または holder-of-key) を指定したり、ユーザ名トークンの使用時にパスワード ダイジェストの使用を指定したりするには、<Claims>
要素を使用します。<Confidentiality>
- SOAP メッセージのどの部分に暗号化を行うかを指定します。省略可能な子要素としては、対称鍵のラップに使用されるアルゴリズムを指定する <KeyWrappingAlgorithm>
、暗号化される SOAP メッセージのブロックを指定する <Target>
、暗号化に使用されるトークン (X.509 トークンのみサポート) を指定する <KeyInfo>
があります。<Integrity>
- SOAP メッセージのどの部分にデジタル署名を行うかを指定します。省略可能な子要素としては、メッセージの署名に使用するアルゴリズムを指定する <SignatureAlgorithm>
、正規化に使用するアルゴリズムを指定する <CanonicalizationAlgorithm>
、デジタル署名する SOAP メッセージのブロックを指定する <Target>
、署名に使用できるトークンのタイプ (X.509 トークンのみサポート) を指定する <SupportedTokens>
があります。<MessageAge>
- SOAP メッセージの最大存続期間を秒単位で指定します。
ID として SAML トークンを指定するためのカスタム WS-Policy ファイルの例については、「カスタム WS-Policy ファイルの例」を参照してください。<Integrity>
要素に <KeyInfo>
子要素が、<Confidentiality>
要素に <SupportedTokens>
子要素が含まれていないため、ファイルのこれらのセクションは抽象セクションです。<Identity>
要素には、SAML トークンが含まれているので、ID セクションは具象セクションです。
あらかじめパッケージ化されている抽象 WS-Policy ファイルをテンプレートとして使用して、独自のカスタム ファイルを作成することもできます。以下を参照してください。
<<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
>
<wssp:Identity>
<wssp:SupportedTokens>
<wssp:SecurityToken TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-saml-token-profile-1.0#SAMLAssertionID">
<wssp:Claims>
<wssp:ConfirmationMethod>sender-vouches</wssp:ConfirmationMethod>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Identity>
<wssp:Integrity>
<wssp:SignatureAlgorithm URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<wssp:CanonicalizationAlgorithm
URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<wssp:Target>
<wssp:DigestAlgorithm
URI="http://www.w3.org/2000/09/xmldsig#sha1" />
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1" />
<wssp:MessageParts
Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SecurityHeader(Assertion)
</wssp:MessageParts>
</wssp:Target>
</wssp:Integrity>
<wssp:Confidentiality>
<wssp:KeyWrappingAlgorithm URI="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<wssp:Target>
<wssp:EncryptionAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<wssp:MessageParts
Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SecurityHeader(Assertion)
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:EncryptionAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()</wssp:MessageParts>
</wssp:Target>
<wssp:KeyInfo />
</wssp:Confidentiality>
<wssp:MessageAge/>
</wsp:Policy>
WS-SecureConversation 仕様どおりにセキュリティ コンテキストと派生キーをコンフィグレーションするために、あらかじめパッケージ化された 2 つの WS-Policy ファイル (Wssc-dk.xml
と Wssc-sct.xml
) が用意されています。必要な機能と一般的なデフォルト値のほとんどが、このあらかじめパッケージ化されている 2 ファイルで提供されるので、セキュリティ コンテキストをコンフィグレーションする場合には常にこれらのファイルを使用することを強くお勧めします。これらのファイルで提供される特定のコンフィグレーションについては、「Wssc-dk.xml」および「Wssc-sct.xml」を参照してください。
ただし、これらの WS-Policy ファイルに定義されている値がお使いの環境に適さない場合は、独自のカスタム WS-Policy ファイルを作成する必要があります。以降の節では、セキュアなコンテキストおよび派生キーのコンフィグレーションをカスタマイズする方法と、クライアント アプリケーションでセキュリティ コンテキストと Web サービスをネゴシエーションする方法について説明します。
警告 : | クラスタに対して共有のセキュリティ コンテキストを使用する Web サービスをデプロイしている場合、クラスタ間のセッション ステート レプリケーションもコンフィグレーションする必要があります。詳細については、「クラスタのフェイルオーバとレプリケーション」を参照してください。 |
セキュリティ コンテキストをコンフィグレーションするあらかじめパッケージ化された WS-Policy ファイルがお使いの環境に適さない場合、独自のカスタム WS-Policy ファイルを作成し、JWS ファイルで @Policy
アノテーションを使用するか、実行時に Administration Console を使用してそのカスタム WS-Policy ファイルを Web サービスに関連付ける必要があります。カスタム WS-Policy ファイルの作成の概要については、「カスタム WS-Policy ファイルの作成と使用」を参照してください。この節の以降では、セキュリティ コンテキスト固有の情報について説明します。あらかじめパッケージ化されている Wssc-dk.xml
WS-Policy ファイルをガイドとして使用した上で、必要に応じてカスタマイズすることをお勧めします。
カスタム セキュリティ コンテキストの WS-Policy ファイルを作成する場合、以下のガイドラインに従います。
<wssp:Integrity>
の SupportTrust20=
"true" 属性と、<wssp:Confidentiality>
アサーションを使用する。<wssp:Integrity SupportTrust10="true">
<wssp:Confidentiality SupportTrust10="true">
<wssp:SecurityToken>
アサーションの TokenType
属性を http://schemas.xmlsoap.org/ws/2005/02/sc/dk
に設定し、DerivedFromTokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct"
属性を次のサンプルのように指定する。 <wssp:Confidentiality SupportTrust10="true">
<wssp:Target>
...
</wssp:Target>
<wssp:KeyInfo>
<wssp:SecurityToken IncludeInMessage="true"TokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/dk"
</wssp:SecurityToken>
DerivedFromTokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct">
</wssp:KeyInfo>
</wssp:Confidentiality>
<wssp:SecurityToken>
アサーションの TokenType
属性を、次のサンプルに示すように http://schemas.xmlsoap.org/ws/2005/02/sc/sct
に設定する。<wssp:Confidentiality SupportTrust10="true">
<wssp:Target>
...
</wssp:Target>
<wssp:KeyInfo>
<wssp:SecurityToken
IncludeInMessage="true"TokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct">
</wssp:SecurityToken>
</wssp:KeyInfo>
</wssp:Confidentiality>
<wssp:Integrity>
の <wssp:SignatureAlgorithm>
アサーションに指定する URI は http://www.w3.org/2000/09/xmldsig#hmac-sha1
とする必要がある。<wssp:Integrity SupportTrust10="true">
<wssp:SignatureAlgorithm URI="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
...
<wssp:Confidentiality>
の <wssp:KeyWrappingAlgorithm>
アサーションを指定することはできない。<wssp:Claims>
アサーションの子要素を使用する。<wssp:Claims> 自体は <wssp:SecurityToken>
の子要素で、セキュリティ コンテキスト トークンまたは派生キー トークンをより詳細にコンフィグレーションするためのものです。具体的には次のサンプルに示すように、セキュリティ コンテキストの存続時間 (秒単位) をデフォルトの 12 時間から変更するには <wssp:TokenLifeTime>
アサーションを、キーの長さをデフォルトの 32 から変更するには <wssp:Length>
アサーションを、ラベルを設定するには <wssp:Label>
アサーションを使用します。<wssp:Confidentiality SupportTrust10="true">
<wssp:Target>
...
</wssp:Target>
<wssp:KeyInfo>
<wssp:SecurityToken IncludeInMessage="true"TokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/dk"
<wssp:Claims>
DerivedFromTokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct">
<wssp:TokenLifeTime>600</wssp:TokenLifeTime>
<wssp:Label>WS-SecureConversation</wssp:Label>
<wssp:Length>16</wssp:Length>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:KeyInfo>
</wssp:Confidentiality>
Web サービスの呼び出し時にセキュリティ コンテキストのネゴシエーションを行うクライアント アプリケーションは、メッセージ保護された Web サービスを呼び出す標準的なクライアント アプリケーションに似ています。詳細については、「クライアント アプリケーションの更新によるメッセージ保護された Web サービスの呼び出し」を参照してください。本質的には、セキュアなコンテキスト トークンを明示的にキャンセルするために、weblogic.wsee.security.wssc.utils.WSSCClientUtil API を使用できるという点だけが異なっています。
注意 : | WebLogic Server には、ユーザの利便性だけを目的として WSSCCLientUtil API が用意されています。この Web サービス ランタイムでは、コンフィグレーションされたタイムアウトに到達するとセキュアなコンテキスト トークンが自動的にキャンセルされます。この API は、トークンをキャンセルする時期をより厳密に制御する必要がある場合にのみ使用します。 |
以下のクライアント アプリケーションでは、あらかじめパッケージ化されている Wssc-dk.xml
WS-Policy ファイルに関連付けられた Web サービスを呼び出す単純なサンプルを示します (Wssc-dk.xml はセキュアな会話を実現します)。セキュリティ コンテキストに関連する太字で表された部分については、このサンプルの後で説明します。
package examples.webservices.wssc.client;
import weblogic.security.SSL.TrustManager;
import weblogic.xml.crypto.wss.provider.CredentialProvider;
import weblogic.xml.crypto.wss.WSSecurityContext;
import weblogic.wsee.security.bst.ClientBSTCredentialProvider;
import weblogic.wsee.security.bst.StubPropertyBSTCredProv;import weblogic.wsee.security.wssc.utils.WSSCClientUtil;
import weblogic.wsee.security.util.CertUtils;
import javax.xml.rpc.Stub;
import java.util.List;
import java.util.ArrayList;
import java.security.cert.X509Certificate;
/**
* Copyright (c) 2004 by BEA Systems.All Rights Reserved.
*/
public class WSSecureConvClient {
public static void main(String[] args) throws Throwable {
String clientKeyStore = args[0];
String clientKeyStorePass = args[1];
String clientKeyAlias = args[2];
String clientKeyPass = args[3];
String serverCert = args[4];
String wsdl = args[5];
WSSecureConvService service = new WSSecureConvService_Impl(wsdl);
WSSecureConvPortType port = service.getWSSecureConvServicePort();
// 資格プロバイダを作成し、それをスタブに設定する
List credProviders = new ArrayList();
// x509 を使用して wssc ハンドシェークを保護する
credProviders.add(new ClientBSTCredentialProvider(clientKeyStore, clientKeyStorePass, clientKeyAlias, clientKeyPass));
Stub stub = (Stub)port;
stub._setProperty(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);stub._setProperty(StubPropertyBSTCredProv.SERVER_ENCRYPT_CERT, CertUtils.getCertificate(serverCert));
stub._setProperty(WSSecurityContext.TRUST_MANAGER,
new TrustManager(){
public boolean certificateCallback(X509Certificate[] chain, int validateErr){
// サーバの証明書を信頼できるかどうかの検証に必要
return true;
}
}
);
System.out.println (port.sayHelloWithWSSC("Hello World, once"));
System.out.println (port.sayHelloWithWSSC("Hello World, twice"));
System.out.println (port.sayHelloWithWSSC("Hello World, thrice"));
// 呼び出しの終了後に SecureContextToken をキャンセルするWSSCClientUtil.terminateWssc(stub);
System.out.println("WSSC terminated!");
}
}
import weblogic.wsee.security.wssc.utils.WSSCClientUtil;
stub._setProperty(StubPropertyBSTCredProv.SERVER_ENCRYPT_CERT, CertUtils.getCertificate(serverCert));
WSSClientUtil
クラスの terminateWssc()
メソッドを使用して、セキュアなコンテキスト トークンを終了する。WSSCClientUtil.terminateWssc(stub);
「簡単なメッセージレベルのセキュリティのコンフィグレーション : 主な手順」で説明した、簡単なメッセージレベルのコンフィグレーション手順では、Web サービスを実装する JWS ファイルで @Policy
および @Policies
JWS アノテーションを使用して、サービスに関連付けられている 1 つまたは複数の WS-Policy ファイルを指定する方法について説明しています。つまり、これは Web サービスのプログラミング時には Web サービスとそのオペレーションに関連付ける WS-Policy ファイルをあらかじめ認識しておく必要があることを示します。しかし、常にあらかじめ WS-Policy ファイルを認識できるとは限りません。そのため、Web サービスをデプロイした後で Administration Console を使用して実行時に WS-Policy ファイルを関連付けることもできます。
JWS ファイルで @Policy
JWS アノテーションも @Policies
JWS アノテーションも使用せずに、Administration Console を使用して実行時に WS-Policy ファイルを関連付けることもでき、これらのアノテーションを使用して一部の WS-Policy ファイルを指定し、追加の WS-Policy ファイルを実行時に関連付けることもできます。ただし、いったん JWS アノテーションを使用して WS-Policy ファイルを関連付けると、その関連付けは実行時に Administration Console を使用して変更することはできません。
Administration Console では、ファイル内のポリシー アサーションが互いに矛盾していても、JWS アノテーションに関連付けられている WS-Policy ファイル内のアサーションと矛盾していても、実行時に WS-Policy ファイルを Web サービスやそのオペレーションにいくつでも関連付けることができます。ただし、関連付けられた複数の WS-Policy ファイルが連携できるように、管理者が確認する必要があります。何らかの矛盾がある場合は、クライアント アプリケーションが Web サービスのオペレーションを呼び出すときに、WebLogic Server から実行時エラーが返されます。
Administration Console を使用して実行時に WS-Policy ファイルを関連付ける詳細な手順については、「WS-Policy ファイルと Web サービスとの関連付け」を参照してください。
「簡単なメッセージレベルのセキュリティのコンフィグレーション : 主な手順」で説明した、簡単な Web サービスのコンフィグレーション手順では、ユーザがユーザ名トークンを使用して自身を認証することが前提となっています。WebLogic Server は Web Services Security 仕様の Web Services Security: SAML Token Profile を実装しているため、この節で説明するように、ユーザは Web サービスのオペレーションの呼び出し時に SOAP メッセージで SAML トークンを使用して自身を認証することもできます。
SAML トークンの使用はサーバ間で機能します。つまり、ある WebLogic Server インスタンスで実行されているクライアント アプリケーションが、ID として SAML を使用して別の WebLogic Server インスタンスで実行されている Web サービスを呼び出します。クライアント アプリケーション自体が Web サービスであるため、Web サービス セキュリティ ランタイムによってすべての SAML プロセスが処理されます。
ID として SAML トークンを要求するように Web サービスをコンフィグレーションする場合には、以下のいずれかの確認メソッドを指定できます。
これらの確認メソッドの詳細については、「WebLogic Web サービスでの SAML トークン プロファイルのサポート」および Web Services Security: SAML Token Profile 仕様そのものを参照してください。
注意 : | この節では、読者が SAML の基礎と、SAML を WebLogic Server のコア セキュリティに関連付ける方法を理解していることを前提としています。全般的な情報については、「SAML (Security Assertion Markup Language)」を参照してください。 |
注意 : | 次の手順では、「簡単なメッセージレベルのセキュリティのコンフィグレーション : 主な手順」での手順がすでに実行されていることを前提として、ユーザ名トークンではなく、SAML トークンを ID として使用できるようにします。 |
SAML トークンを ID として使用するには、次の手順に従います。
sender-vouches
または holder-of-key
) によって変わります。
sender-vouches 確認メソッドを指定するには、次の作業を行います。
<Identity><SupportedTokens>
要素の <SecurityToken>
子要素を作成し、TokenType
属性を SAML トークンの使用を示す値に設定する。<SecurityToken>
要素の <Claims><Confirmationmethod>
子要素を追加し、sender-vouches
を指定する。<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
>
<wssp:Identity>
<wssp:SupportedTokens>
<wssp:SecurityToken
TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-saml-token-profile-1.0#SAMLAssertionID
">
<wssp:Claims>
<wssp:ConfirmationMethod>sender-vouches</wssp:ConfirmationMethod>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Identity>
</wsp:Policy>
holder-of-key 確認メソッドを指定するには、次の作業を行います。
<Integrity><SupportedTokens>
要素の <SecurityToken>
子要素を作成し、TokenType
属性を SAML トークンの使用を示す値に設定する。
holder-of-key
確認メソッドのための <Integrity>
アサーションに SAML トークンを含めるのは、Web サービス ランタイムで sender-vouches
では必要でないメッセージの整合性の証明が必要なためです。
<SecurityToken>
要素の <Claims><Confirmationmethod>
子要素を追加し、holder-of-key
を指定する。<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part">
<wssp:Integrity>
<wssp:SignatureAlgorithm
URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<wssp:CanonicalizationAlgorithm
URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<wssp:Target>
<wssp:DigestAlgorithm
URI="http://www.w3.org/2000/09/xmldsig#sha1" />
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
<wssp:SupportedTokens>
<wssp:SecurityToken
IncludeInMessage="true"
TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-saml-token-profile-1.0#SAMLAssertionID
">
<wssp:Claims>
<wssp:ConfirmationMethod>holder-of-key</wssp:ConfirmationMethod>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Integrity>
</wsp:Policy>
<KeyInfo>
アサーションで指定されている X.509 証明書を検証する。SAML holder-of-key アサーション使用時にこの検証を無効化するには、SAML トークン ハンドラ上にプロパティを設定することで、Web サービスと関連付けられた Web サービス セキュリティ コンフィグレーションを指定する必要があります。Administration Console でこれを行う方法については、「SAML holder_of_key アサーション使用時の X.509 証明書の検証の無効化」を参照してください。
独自の WS-Policy ファイルの作成に関する詳細については、「カスタム WS-Policy ファイルの作成と使用」を参照してください。アサーションのリファレンス情報については、「セキュリティ ポリシー アサーションのリファレンス」を参照してください。
@Policy
アノテーションを更新します。たとえば、Web サービスのすべてのオペレーションの呼び出しで SAML を ID として使用する場合は、@Policy
アノテーションをクラスレベルで指定します。
Web サービスに関連付ける WS-Policy ファイルは、互いに矛盾しない限り、適宜組み合わせることができます。たとえば、SAML の ID としての使用を指定する <Identity>
セキュリティ アサーションのみを含む、簡単な MyAuth.xml
ファイルを作成し、あらかじめパッケージ化されている Encrypt.xml
ファイルおよび Sign.xml
ファイルとともにそのファイルを Web サービスに関連付けることができます。ただし、関連付けられた複数の WS-Policy ファイルが互いに矛盾しないように、管理者が確認する必要があります。何らかの矛盾がある場合は、実行時エラーが発生するか、または Web サービスが想定どおりに動作しなくなるおそれがあります。
「Java から開始する WebLogic Web サービスの反復的な開発 : 主な手順」を参照してください。
「簡単なメッセージレベルのセキュリティのコンフィグレーション : 主な手順」で説明した、簡単な Web サービスのコンフィグレーション手順では、ユーザはユーザ名トークン、X.509 トークン、またはその両方を使用して自身を認証することが前提となっています。これは、ユーザがあらかじめパッケージ化された Auth.xml
WS-Policy ファイルを Web サービスに関連付けることが前提とされているためで、Auth.xml
は抽象ファイルなので、デプロイされた WS-Policy ファイルに示される正確なトークンは WebLogic Server のコンフィグレーションに応じて異なり、Web サービスをプログラミングしている時点では ID として実際に使用されるトークンが確定していないからです。
ただし、Web サービスの呼び出し時に、ユーザが自身の認証に X.509 証明書のみを使用し、したがって WS-Policy ファイルからユーザ名トークンを明示的に除外するように指定する場合、Auth.xml
は使用できません。代わりに、カスタム WS-Policy ファイルを以下の手順で説明するとおり作成する必要があります。この手順は、SOAP メッセージの一部を署名するように指定する場合にも使用します。デフォルトでは、Auth.xml
では ID として X.509 を使用する場合、SOAP 本文全体を署名します。署名する部分を指定するには、<Integrity>
アサーションを使用します。
注意 : | 次の手順では、「簡単なメッセージレベルのセキュリティのコンフィグレーション : 主な手順」での手順がすでに実行されていることを前提として、X.509 証明書を ID として使用できるようにします。 |
default_wss
にする必要があります。デフォルトの Web サービス セキュリティ コンフィグレーションは、別のコンフィグレーションを使用するように明示的にプログラミングされていない限り、ドメイン内のすべての Web サービスで使用されます。
「Web サービス セキュリティ コンフィグレーションの作成」を参照してください。
具体的には、<Identity><SupportedTokens>
要素の <SecurityToken>
子要素で TokenType
属性を、次の例に示すように http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3
に設定します。
<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
>
<wssp:Identity>
<wssp:SupportedTokens>
<wssp:SecurityToken TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" />
</wssp:SupportedTokens>
</wssp:Identity>
</wsp:Policy>
独自の WS-Policy ファイルの作成に関する詳細については、「カスタム WS-Policy ファイルの作成と使用」を参照してください。この節では <Integrity>
の追加についても説明しています。
@Policy
アノテーションを更新します。たとえば、Web サービスのすべてのオペレーションの呼び出しで X.509 を ID として使用する場合は、@Policy
アノテーションをクラスレベルで指定します。
Web サービスに関連付ける WS-Policy ファイルは、互いに矛盾しない限り、適宜組み合わせることができます。たとえば、X.509 証明書の ID としての使用を指定する <Identity>
セキュリティ アサーションのみを含む、簡単な MyAuth.xml
ファイルを作成し、あらかじめパッケージ化されている Encrypt.xml
ファイルおよび Sign.xml
ファイルとともにそのファイルを Web サービスに関連付けることができます。ただし、関連付けられた複数の WS-Policy ファイルが互いに矛盾しないように、管理者が確認する必要があります。何らかの矛盾がある場合は、実行時エラーが発生します。
「Java から開始する WebLogic Web サービスの反復的な開発 : 主な手順」を参照してください。
//クライアントサイドの UsernameToken 資格プロバイダ
cp = new ClientUNTCredentialProvider(username, password);
credProviders.add(cp);
デフォルトでは、WebLogic Web サービス セキュリティ ランタイムは、メッセージ保護された Web サービスを呼び出した結果として発生する SOAP メッセージの中で、パスワード ダイジェストではなくクリアテキスト パスワードを使用します。以下では、SOAP メッセージでパスワード ダイジェストが使用されるように、このデフォルトの動作を変更する手順について説明します。
次の手順では、「簡単なメッセージレベルのセキュリティのコンフィグレーション : 主な手順」での手順がすでに実行されていることを前提として、すべての SOAP メッセージでクリアテキスト パスワードではなくパスワード ダイジェストが使用されるように指定します。
default_wss
にする必要があります。デフォルトの Web サービス セキュリティ コンフィグレーションは、別のコンフィグレーションを使用するように明示的にプログラミングされていない限り、ドメイン内のすべての Web サービスで使用されます。警告 : | デフォルトの Web サービス セキュリティ コンフィグレーション (default_wss ) に加えて、Web サービス セキュリティ コンフィグレーションを作成した場合は、各コンフィグレーションで同じパスワード ダイジェストの使用を指定する必要があります。使用するパスワード ダイジェストが Web サービス セキュリティ コンフィグレーション間で異なると、実行時エラーが発生します。 |
「Web サービス セキュリティ コンフィグレーションの作成」を参照してください。
Auth.xml
ファイルを使用する代わりにカスタム WS-Policy ファイルを作成して、<Identity><SupportedTokens><SecurityToken>
要素で明示的にユーザ名トークンを指定している場合は、次に示すように <Claims><UsePassword>
子要素を追加する必要があります。<wssp:Identity>
<wssp:SupportedTokens>
<wssp:SecurityToken TokenType="#UsernameToken">
<wssp:Claims>
<wssp:UsePassword
Type=”http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest” />
</wssp:Claims>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Identity>
あらかじめパッケージ化されている Auth.xml
ファイルを使用して認証をコンフィグレーションしている場合は、この手順を実行する必要はありません。
独自の WS-Policy ファイルの作成に関する詳細については、「カスタム WS-Policy ファイルの作成と使用」を参照してください。
@Policy
アノテーションを更新します。「@Policy および @Policies アノテーションによる JWS ファイルの更新」を参照してください。
「Java から開始する WebLogic Web サービスの反復的な開発 : 主な手順」を参照してください。
前述の使用例の多くでは、Administration Console を使用した、デフォルトの Web サービス セキュリティ コンフィグレーションの作成 (名前は default_wss
) が必要になります。このコンフィグレーションの作成後は、@weblogic.jws.security.WssConfiguration
JWS アノテーションを使用しなくても、属性のない状態でこのアノテーションを指定しても、すべての Web サービスにこのコンフィグレーションが適用されます。
ただし、指定するタイムスタンプ値をサービス間で変える場合など、Web サービスをデフォルト以外のセキュリティ コンフィグレーションに関連付ける必要が生じる場合もあります。
Web サービスをデフォルト以外のセキュリティ コンフィグレーションに関連付けるには、次の手順に従います。
default_wss
以外の名前が指定された Web サービス セキュリティ コンフィグレーションを作成します。@WssConfiguration
アノテーションを追加して、このセキュリティ コンフィグレーションの名前を指定します。詳細と例については、「weblogic.jws.security.WssConfiguration」を参照してください。
「Java から開始する WebLogic Web サービスの反復的な開発 : 主な手順」を参照してください。
警告 : | すべての Web サービス セキュリティ コンフィグレーションで同じパスワード ダイジェストの使用を指定する必要があります。使用するパスワード ダイジェストが Web サービス セキュリティ コンフィグレーション間で異なると、実行時エラーが発生します。 |
次の表に、メッセージ保護された Web サービスの問題をデバックするために設定できるシステム プロパティをまとめます。
メッセージ保護された Web サービスを呼び出すように Java コードを更新する場合には、クライアントのキーストアからプライベート キーとデジタル証明書のペアをロードし、その情報を、WS-Policy で必要とされている場合はユーザ認証用のユーザ名およびパスワードとともに、呼び出されるセキュアな WebLogic Web サービスに渡す必要があります。
Web サービスの WS-Policy ファイルで SOAP リクエストを暗号化するように指定されている場合、Web サービス クライアント ランタイムはサービスの WSDL に添付されている WS-Policy ファイルからサーバの証明書を自動的に取得し、それを暗号化に使用します。ただし、WS-Policy ファイルが WSDL に添付されていない場合や、WSDL 自体を使用できない場合には、クライアント アプリケーションは WS-Policy ファイルのクライアントサイドのコピーを使用する必要があります。詳細については、「クライアントサイド セキュリティ WS-Policy ファイルの使用」を参照してください。
次の例では、「セキュリティ関連アノテーションでの JWS ファイルの更新」の JWS ファイルで記述されているメッセージ保護された WebLogic Web サービスを呼び出す Java クライアント アプリケーションを示します。クライアント アプリケーションは、以下の 5 つの引数を取ります。
サンプル クライアント アプリケーションのセキュリティ固有のコードは太字で表示し、例の後で説明します。
package examples.webservices.security_jws.client;
import weblogic.security.SSL.TrustManager;
import weblogic.xml.crypto.wss.provider.CredentialProvider;
import weblogic.xml.crypto.wss.WSSecurityContext;
import weblogic.wsee.security.bst.ClientBSTCredentialProvider;
import weblogic.wsee.security.unt.ClientUNTCredentialProvider;
import javax.xml.rpc.Stub;
import java.util.List;
import java.util.ArrayList;
import java.security.cert.X509Certificate;
/**
* Copyright (c) 2005 by BEA Systems.All Rights Reserved.
*/
public class SecureHelloWorldClient {
public static void main(String[] args) throws Throwable {
//ユーザ名トークンのユーザ名またはパスワード
String username = args[0];
String password = args[1];
//クライアントのプライベート キー ファイル
String keyFile = args[2];
//クライアントの証明書
String clientCertFile = args[3];
String wsdl = args[4];
SecureHelloWorldService service = new SecureHelloWorldService_Impl(wsdl + "?WSDL" );
SecureHelloWorldPortType port = service.getSecureHelloWorldServicePort();
//資格プロバイダを作成し、それをスタブに設定する
List credProviders = new ArrayList();
//クライアントサイドの BinarySecurityToken 資格プロバイダ -- x509
CredentialProvider cp = new ClientBSTCredentialProvider(clientCertFile, keyFile);
credProviders.add(cp);
//クライアントサイドの UsernameToken 資格プロバイダ
cp = new ClientUNTCredentialProvider(username, password);
credProviders.add(cp);
Stub stub = (Stub)port;
stub._setProperty(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);
stub._setProperty(WSSecurityContext.TRUST_MANAGER,
new TrustManager(){
public boolean certificateCallback(X509Certificate[] chain, int validateErr){
return true;
}
} );
String response = port.sayHello("World");
System.out.println("response = " + response);
}
}
TrustManager
API をインポートする。import weblogic.security.SSL.TrustManager;
import weblogic.xml.crypto.wss.provider.CredentialProvider;
import weblogic.xml.crypto.wss.WSSecurityContext;
import weblogic.wsee.security.bst.ClientBSTCredentialProvider;
import weblogic.wsee.security.unt.ClientUNTCredentialProvider;
ClientBSTCredentialProvider
WebLogic API を使用して、クライアントの証明書とプライベート キーからバイナリ セキュリティ トークン資格プロバイダを作成する。CredentialProvider cp =
new ClientBSTCredentialProvider(clientCertFile, keyFile);
ClientUNTCredentialProvider
WebLogic API を使用して、クライアントのユーザ名とパスワードからユーザ名トークンを作成する。ユーザ名とパスワードは WebLogic Server によっても認識されます。cp = new ClientUNTCredentialProvider(username, password);
WSSecurityContext.CREDENTIAL_PROVIDER_LIST
プロパティを使用して、バイナリ セキュリティ トークンおよびユーザ名トークンを含む List
オブジェクトを JAX-RPC スタブに渡す。stub._setProperty(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders)
weblogic.security.SSL.TrustManager
WebLogic セキュリティ API を使用して、SOAP リクエストの暗号化に使用される証明書が有効かどうかを確認する。Web サービス クライアント ランタイムは Web サービスのデプロイされた WSDL からこの証明書を取得します。プロダクションの際には、この証明書は自動的には信頼されないので、クライアント アプリケーションでは、その証明書を使用して SOAP リクエストを暗号化する前に、証明書が有効であることを確認する必要があります。stub._setProperty(WSSecurityContext.TRUST_MANAGER,
new TrustManager(){
public boolean certificateCallback(X509Certificate[] chain, int validateErr){
return true;
}
} );
「簡単なメッセージレベルのセキュリティのコンフィグレーション : 主な手順」で説明した、簡単な Web サービスのコンフィグレーション手順では、スタンドアロンのクライアント アプリケーションがメッセージ保護された Web サービスを呼び出すことが前提となっています。ただし、クライアント自体が EJB、サーブレット、または別の Web サービスの一部として、WebLogic Server インスタンスで実行されている場合もあります。この場合には、WebLogic Server コア セキュリティ フレームワークを使用して資格プロバイダとトラスト マネージャをコンフィグレーションして、EJB、サーブレット、または JWS コードには保護されたオペレーションの簡単な呼び出しのみが含まれ、他のセキュリティ関連の API の使用は含まれないようにできます。以下では、この場合に WebLogic Server コア セキュリティ フレームワークを使用するための高度な手順について説明します。
CredentialProvider
オブジェクトを作成せず、セキュアな Web サービスのホストである WebLogic Server からの証明書を検証するための TrustManager
コア セキュリティ API も使用しないようにします。クライアント コードでこれらの API を使用しない理由は、Web サービス ランタイムによってこの作業が実行されるためです。注意 : | WebLogic Server には、ユーザ名/パスワードおよび X.509 用の資格マッピング プロバイダがあります。ただし、デフォルトでコンフィグレーションされているのはユーザ名/パスワードのみです。 |
用意されている資格プロバイダとトラスト マネージャをクライアント アプリケーションで使用しない場合は、この手順で説明したように WebLogic Server コア セキュリティ フレームワークをコンフィグレーションする必要はありません。「クライアント アプリケーションの更新によるメッセージ保護された Web サービスの呼び出し」で説明されているスタンドアロンの Java コードと同じ API を EJB、サーブレット、および JWS コードで使用することで、そのコンフィグレーションをすべてオーバーライドできます。ただし、コア セキュリティ フレームワークを使用することで、WebLogic Server のコンフィグレーションが標準化され、Web サービスを呼び出すクライアント アプリケーションの Java コードが簡略化されます。
転送レベルのセキュリティとは、セキュア ソケット レイヤ (SSL) を使用したクライアント アプリケーションと Web サービスの間の接続の保護です。
SSL に関する概要と WebLogic Server に含まれている実装については、「セキュア ソケット レイヤ (SSL)」を参照してください。
転送レベルの Web サービス セキュリティをコンフィグレーションするには、次の手順に従います。
一方向の SSL (WebLogic Server がクライアント アプリケーションに証明書を提示する必要がある)、または双方向の SSL (クライアント アプリケーションと WebLogic Server が両方とも互いに証明書を提示する必要がある) のいずれかをコンフィグレーションできます。
WebLogic Server コア セキュリティ サブシステムに対して、双方向および一方向の SSL をコンフィグレーションする手順については、「SSL のコンフィグレーション」を参照してください。
@weblogic.jws.security.UserDataConstaint
アノテーションを追加し、Web サービスが HTTPS 転送を使用して呼び出されることを要求します。
詳細については、「weblogic.jws.security.UserDataConstraint」を参照してください。
「Java から開始する WebLogic Web サービスの反復的な開発 : 主な手順」を参照してください。
clientgen
Ant タスクを呼び出す build.xml
ファイルを更新して、Web サービスの JAX-RPC スタブの生成に、デプロイされているサービスの動的 WSDL ではなく、静的 WSDL を使用するようにします。
この場合に、clientgen
が動的 WSDL からスタブを生成できない理由は、@UserDataConstraint
アノテーションを指定する際に、すべてのクライアント アプリケーションで、clientgen
を含むトラストストアを指定することが必要であるためです。しかし現在、clientgen
でトラストストアを指定する方法はありません。したがって、Ant タスクは、動的 WSDL と同じ方法で Web サービスを記述する静的な WSDL からクライアント コンポーネントを生成しなければなりません。
-Djava.protocol.handler.pkgs=weblogic.net
-Dweblogic.security.SSL.trustedCAKeyStore=trustStore
trustStore
には、信頼性のある証明書 (そのうちの 1 つはサーバの証明書でなければならない) のリストを格納するクライアントサイドのトラストストアの名前を指定します。ホスト名検証を無効にするには、次のプロパティも指定します。
-Dweblogic.security.SSL.ignoreHostnameVerification=true
-Djavax.net.ssl.trustStore=trustStore
trustStore
には、信頼性のある証明書 (そのうちの 1 つはサーバの証明書でなければならない) のリストを格納するクライアントサイドのトラストストアの名前を指定します。ホスト名検証を無効にするには、次のプロパティも指定します。
-Dweblogic.wsee.client.ssl.stricthostchecking=false
双方向 SSL の詳細については、「クライアント アプリケーションでの双方向 SSL のコンフィグレーション」を参照してください。
WebLogic Server で双方向 SSL をコンフィグレーションした場合は、一方向 SSL で必要なように WebLogic Server がクライアント アプリケーションに証明書を提示するだけでなく、クライアント アプリケーションも WebLogic Server に証明書を提示する必要があります。さらに、以下の要件も満たしている必要があります。
J2SE の SSL パッケージでは、クライアントのプライベート キーのパスワードはクライアントのキーストアのパスワードと同じでなければならない。このため、クライアントのキーストアには 1 つのプライベート キーと X.509 証明書のペアしか格納できません。
この手順には、Cert Gen ユーティリティまたは Sun Microsystems の keytool ユーティリティを使用します。開発が目的の場合は、keytool
ユーティリティを使用すると簡単に開始できます。
「プライベート キー、デジタル証明書、信頼性のある認証局の取得」を参照してください。
-Djavax.net.ssl.trustStore=
trustStore
-Djavax.net.ssl.trustStorePassword=
trustStorePassword
trustStore
には、信頼性のある証明書 (そのうちの 1 つはサーバの証明書でなければならない) のリストを格納するクライアントサイドのトラストストアの名前を指定し、trustStorePassword
には、トラストストアのパスワードを指定します。
上記のプロパティは、クライアントサイド キーストアを指定するために設定する必要のある標準的なプロパティに追加されるものです。
-Djavax.net.ssl.keyStore=
keyStore
-Djavax.net.ssl.keyStorePassword=
keyStorePassword
dev2dev CodeShare は、BEA の技術に関するアイデア、コード、およびベスト プラクティスを共有する、開発者向けのコミュニティです。このサイトでは、BEA のさまざまなの技術のコード例が紹介されており、Web サービスでの SSL の使い方に関するコード例もあります。
dev2dev サイトで SSL Web サービスのサンプル コードの表示とダウンロードを行うには、メインの「プロジェクト」ページに移動し、[By Technology] カラムで [Web Services] リンクをクリックします。
アクセス制御セキュリティとは、アクセスできるユーザを制御するように Web サービスをコンフィグレーションし、クライアントがオペレーションの 1 つを呼び出したときに Web サービスに対して HTTP/S またはユーザ名トークンを使用して自身を認証するようにクライアント アプリケーションをコーディングすることです。
Web サービスのアクセス制御セキュリティを指定するには、JWS ファイル内で、以下のアノテーションを 1 つ以上、使用します。
注意 : | @weblogic.security.jws.SecurityRoles および @weblogic.security.jws.SecurityIdentity JWS アノテーションは、WebLogic Server 9.1 から非推奨となっています。 |
以下では、これらのアノテーションを使用してアクセス制御セキュリティを有効化する高度な手順について説明します。手順の詳細についてはこの章の後の節で説明します。
注意 : | 次の手順では、WebLogic Web サービスを実装する JWS ファイルがすでに作成されていることを前提として、そのファイルをアクセス制御セキュリティの設定で更新します。また、Ant ビルド スクリプトを使用して Web サービスを反復的に開発することと、新しい情報で更新できる作業用の build.xml ファイルがあることも前提となっています。さらに、保護されていない Web サービスを呼び出すクライアント アプリケーションも用意されているものとします。これらの前提条件が満たされていない場合は、以下を参照してください。 |
@weblogic.jws.security.RolesAllowed
、@weblogic.jws.security.SecurityRole
、@weblogic.jws.security.RolesReferenced
または @weblogic.jws.security.SecurityRoleRef
アノテーションを追加し、JWS ファイルを更新します。
「セキュリティ関連アノテーションでの JWS ファイルの更新」を参照してください。
@weblogic.jws.security.RunAs
JWS アノテーションを追加することで、WebLogic Server が実際に Web サービスを呼び出すユーザに割り当てられているロールではなく、特定のロールを使用して Web サービスを内部で実行することを指定します。
「@RunAs アノテーションでの JWS ファイルの更新」を参照してください。
@weblogic.jws.security.UserDataConstraint
JWS アノテーションを追加することで、Web サービスが HTTPS を使用して呼び出し可能であること、または呼び出される必要があることを指定します。
詳細については、「転送レベルのセキュリティのコンフィグレーション」を参照してください。この節ではまた、SSL を使用するようにクライアント アプリケーションを更新する方法についても説明します。
「Java から開始する WebLogic Web サービスの反復的な開発 : 主な手順」を参照してください。
@SecurityRole
アノテーションで指定されているロールを作成し、ユーザをロールにマッピングします。注意 : | Web サービスを呼び出せるすべてのユーザがリストされるように、JWS ファイルで @SecurityRole アノテーションの mapToPrincipals 属性を指定していない場合、ユーザのロールへのマッピングは外部で定義されます。 |
「ユーザ、グループ、セキュリティ ロール」を参照してください。
HttpTransportInfo
WebLogic API を使用し、JAX-RPC Service
オブジェクトの作成時に適切なユーザおよびパスワードを指定するよう、クライアント アプリケーションを更新します。
「JAX-RPC サービス オブジェクト作成時のユーザ名とパスワードの設定」を参照してください。
build.xml
ファイル内の clientgen
Ant タスクを更新して、有効な WebLogic ユーザのユーザ名およびパスワード (Web サービスで @RolesAllowed
アノテーションを使用する場合)、および WebLogic Server のものを含む信頼性のある証明書のリストが格納されたトラストストア (@UserDataConstraint
を指定する場合) を指定します。
これは以下のサンプルに示すように、clientgen
Ant タスクに標準の Ant のネストされた要素である <sysproperty>
を追加して、必要な Java プロパティに key
属性を設定することで指定できます。
<clientgen
wsdl="http://example.com/myapp/myservice.wsdl"
destDir="/output/clientclasses"
packageName="myapp.myservice.client"
serviceName="StockQuoteService"<sysproperty key="javax.net.ssl.trustStore"
</clientgen>
value="/keystores/DemoTrust.jks"/>
<sysproperty key="weblogic.wsee.client.ssl.stricthostchecking"
value="false"/>
<sysproperty key="javax.xml.rpc.security.auth.username"
value="juliet"/>
<sysproperty key="javax.xml.rpc.security.auth.password"
value="secret"/>
JWS ファイルで WebLogic 固有の @weblogic.jws.security.RolesAllowed
アノテーションを使用し、Web サービスの呼び出しが許可されているロールをリストする @weblogic.jws.security.SecurityRoles
アノテーションの配列を指定します。これら 2 つのアノテーションは、クラス レベルまたはメソッド レベルのいずれでも指定できます。クラスレベルで設定した場合、ロールはすべてのパブリック オペレーションに適用されます。このアノテーションをメソッド レベルで指定することで、特定のオペレーションにロールを追加できます。
@SecurityRole
アノテーションには、以下の 2 つの属性があります。
@RolesAllowed
アノテーションは、属性を持ちません。
また、@weblogic.jws.security.RolesReferenced
アノテーションを使用して、既存のロールへの参照をリストする @weblogic.jws.security.SecurityRoleRef
アノテーションの配列を指定することもできます。たとえば、ロール manager
にすでに Web サービスの呼び出しが許可されている場合は、mgr
ロールの manager
ロールへのリンクを指定でき、mgr
にマップされるユーザも Web サービスを呼び出せるようになります。これら 2 つのアノテーションは、クラス レベルのみで指定できます。
@SecurityRoleRef
アノテーションには、以下の 2 つの属性があります。
@RolesReferenced
アノテーションは、属性を持ちません。
次の例では、この節で説明されているアノテーションの JWS ファイルでの使い方を示します。該当する個所は太字で表示しています。
package examples.webservices.security_roles;
import javax.jws.WebMethod;
import javax.jws.WebService;
// WebLogic JWS アノテーション
import weblogic.jws.WLHttpTransport;
import weblogic.jws.security.RolesAllowed;
import weblogic.jws.security.RolesReferenced;
import weblogic.jws.security.SecurityRole;
import weblogic.jws.security.SecurityRoleRef;
@WebService(name="SecurityRolesPortType",
serviceName="SecurityRolesService",
targetNamespace="http://example.org")
@WLHttpTransport(contextPath="security",
serviceUri="SecurityRolesService",
portName="SecurityRolesPort")
@RolesAllowed ( {
@SecurityRole (role="manager",
mapToPrincipals={ "juliet","amanda" }),
@SecurityRole (role="vp")
} )
@RolesReferenced (
@SecurityRoleRef (role="mgr", link="manager")
)
/**
* この JWS ファイルは、1 つのオペレーション sayHello を含む簡単な
* Java クラス実装の WebLogic Web サービスの基本となる
*
*/
public class SecurityRolesImpl {
@WebMethod()
public String sayHello(String message) {
System.out.println("sayHello:" + message);
return "Here is the message: '" + message + "'";
}
}
この例では、manager
、vp
、および mgr
ロールのみが、Web サービスの呼び出しを許可されると指定する方法を示しています。mgr
ロールは、実際には manager
ロールへの参照です。Web サービスのコンテキスト内で、ユーザ juliet
および amanda
は manager
ロールにマップされます。vp
ロールにマップされるユーザがないので、WebLogic Server セキュリティ レルムを更新するためには、通常 Administration Console を使用して、外部でマッピングが行われることが前提です。
これらのアノテーションのリファレンス情報については、「JWS アノテーション リファレンス」を参照してください。
Web サービスが常に特定のロールとして実行されることを指定するには、JWS ファイル内で WebLogic 固有の @weblogic.jws.security.RunAs アノテーションを使用します。これはつまり、Web サービスを最初に呼び出すユーザが誰であろうと、またそのユーザがどのロールにマップされていようと、サービスは指定されたロールとして内部で実行されるということです。
@RunAs
アノテーションは、クラス レベルのみで指定できます。このアノテーションには次の属性があります。
次の例では、@RunAs
アノテーションの JWS ファイルでの使い方を示します。該当する個所は太字で表示しています。
package examples.webservices.security_roles;
import javax.jws.WebMethod;
import javax.jws.WebService;
// WebLogic JWS アノテーション
import weblogic.jws.WLHttpTransport;
import weblogic.jws.security.RunAs;
@WebService(name="SecurityRunAsPortType",
serviceName="SecurityRunAsService",
targetNamespace="http://example.org")
@WLHttpTransport(contextPath="security_runas",
serviceUri="SecurityRunAsService",
portName="SecurityRunAsPort")
@RunAs (role="manager", mapToPrincipal="juliet")
/**
* この JWS ファイルは、1 つのオペレーション sayHello を含む簡単な
* WebLogic Web サービスの基本となる
*
*/
public class SecurityRunAsImpl {
@WebMethod()
public String sayHello(String message) {
System.out.println("sayHello:" + message);
return "Here is the message: '" + message + "'";
}
}
Web サービスの保護に @RolesAllowed
JWS アノテーションを使用する場合、指定されたロールだけが Web サービス オペレーションの呼び出しを許可されます。つまり、保護されている Web サービスを呼び出すクライアント アプリケーションで JAX-RPC Service
オブジェクトを作成する際には、ロールにマップするユーザのユーザ名およびパスワードを指定する必要があります。
WebLogic Server では、ユーザ名およびパスワードを設定して Service
コンストラクタに渡すための HttpTransportInfo
クラスが用意されています。以下の例は、スタンドアロン Java クライアントから Web サービスを呼び出す標準的な方法 (「Web サービスの呼び出し」を参照) に基づいていますが、同時に、HttpTransportInfo
クラスを使用してユーザ名およびパスワードを設定する方法も示しています。太字の箇所については、サンプルの後で説明します。
package examples.webservices.sec_wsdl.client;
import weblogic.wsee.connection.transport.http.HttpTransportInfo;
import java.rmi.RemoteException;
import javax.xml.rpc.ServiceException;
import javax.xml.rpc.Stub;
/**
* SecWsdlService Web サービスの sayHello オペレーションを呼び出す
* 簡単なスタンドアロンのクライアント アプリケーション
*
* @author Copyright (c) 2004 by BEA Systems. All Rights Reserved.
*/
public class Main {
public static void main(String[] args)
throws ServiceException, RemoteException{
HttpTransportInfo info = new HttpTransportInfo();
info.setUsername("juliet".getBytes());
info.setPassword("secret".getBytes());
SecWsdlService service = new SecWsdlService_Impl(args[0] + "?WSDL", info);
SecWsdlPortType port = service.getSecWsdlPort();
try {
String result = null;
result = port.sayHello("Hi there!");
System.out.println( "Got result: " + result );
} catch (RemoteException e) {
throw e;
}
}
}
HttpTransportInfo
クラスをインポートする。import weblogic.wsee.connection.transport.http.HttpTransportInfo;
HttpTransportInfo
クラスの setXXX()
メソッドを使用して、ユーザ名およびパスワードを設定する。HttpTransportInfo info = new HttpTransportInfo();
info.setUsername("juliet".getBytes());
info.setPassword("secret".getBytes());
この例では、パスワード secret
を伴うユーザ juliet
は有効な WebLogic Server ユーザであり、Web サービスの @RolesAllowed
JWS アノテーションで指定されたロールにマップ済みであることが前提となっています。
プロキシを使用して Web サービスにアクセスしている場合、Java コードは以下のようになります。
HttpTransportInfo info = new HttpTransportInfo();
Proxy p = new Proxy(Proxy.Type.HTTP, new InetSocketAddress(proxyHost, Integer.parseInt(proxyPort)));
info.setProxy(p);
info.setProxyUsername(user.getBytes());
info.setProxyPassword(pass.getBytes());
info
オブジェクトを 2 番目の引数として Service
コンストラクタに渡す。SecWsdlService service = new SecWsdlService_Impl(args[0] + "?WSDL", info);
保護されていない Web サービスの呼び出しの概要については、「Web サービスの呼び出し」を参照してください。
![]() ![]() ![]() |