Novell exteNd WebサービスSDKはセキュアなWebサービスを実施するために展開された環境の既存のセキュリティ機能に依存しています。サーバ側では、ServletコンテナがSSLおよび認証をサポートします。 クライアント側ではBasic、Digest、およびNTLMのHTTP認証がサポートされています。 SSLはJDK1.4から組込み｢https｣URLハンドラまたはSSLハンドラいずれかの使用をサポートします。
Basic認証
Basic認証スキーマはユーザ名およびパスワードをbase64エンコードテキストメッセージとして送信します。 このスキーマは、最低限のセキュア機能です。 Basic認証は、ユーザ名およびパスワードがスタブの環境設定で指定された場合のデフォルトの認証形式です。Digest認証
Digest認証スキームは、サーバから提供された臨時の値を持つハッシュされたユーザ名およびパスワードを送信します。 ハッシュ値はある程度解読が困難なためBasic認証よりセキュアですが、パスワード重視のセキュリティという欠点があります。 Digest認証を使用する際、スタブにユーザ名およびパスワードのプロパティを設定し、digestの使用を指定する必要があります。NTLM認証
NTLM認証スキーマはDigest認証と類似しています。 Microsoft社独自のプロトコルですが、このプロトコルを使用するセキュリティを提供するサーバには制限があります。 NTLMプロトコルでは、 サーバがまずクライアントにNTLMを使用して認証するよう要求する401 HTTPエラーコードで応答します。 次にクライアントは特別な認証ヘッダで応答します。 サーバは再度401 HTTPエラーコードおよびチャレンジで応答します。 クライアントは最終的にチャレンジに応答し、提供された資格情報が正しい場合は、該当するリソースへアクセスできます。
BasicおよびDigest認証
Webサービスの実装は、要求された保護およびアクセス制御を記述する展開記述子を含むサービスServletを展開することによって確保されます。 関連するServlet展開記述子要素にはrealm-name、auth-constraint、role-name、およびtransport-guaranteeなどがあります。展開記述子ブロックはJ2EEコンテナのWebリソースのBasic認証を有効にする方法を示します。 Digest認証を有効にする方法は、auth-method要素のコンテンツがBASICの代わりにDIGESTであることを除いて同じです。
... <security-role>
<role-name>manager</role-name>
</security-role><security-constraint>
<web-resource-collection>
<web-resource-name>mywebservice</web-resource-name>
<url-pattern>/quotes</url-pattern>
<http-method>POST</http-method>
<http-method>GET</http-method>
<description>Quote Servcie</description>
</web-resource-collection>
<auth-constraint>
<role-name>manager</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint><login-config>
<auth-method>BASIC</auth-method>
<realm-name>acme.com</realm-name>
</login-config>...
NTLM認証
NTLM認証はIISサーバによって実行され、Webサーバのディレクトリセキュリティ設定の編集によって有効になります。 詳細については、Microsoft社のIISマニュアルを参照してください。
Novell exteNd WebサービスSDKにはBasic、Digest、およびNTLM認証構造を使用するユーザ名、パスワードベースのクライアント認証があります。 スキームはすべてスタブ上のプロパティを使用するよう指定できます。 公開鍵ベースのクライアントの認証、保全および機密保護はSSLでサポートされます。Basic認証
ユーザ名およびパスワードを使用するBasic認証はそれぞれAUTH_SCHEME、USERNAMEおよびPASSWORDプロパティを使用するスタブ上で指定できます。たとえば、次のように入力します。
StockService service = (StockService) ctx.lookup("xmlrpc:soap:StockService");
StockQuote stub = service.getStockQuotePort();
stub._setProperty(stub.AUTH_SCHEME, stub.BASIC_AUTH_SCHEME);
stub._setProperty(stub.USERNAME, username);
stub._setProperty(stub.PASSWORD, password);
float quote = stub.getQuote("SSSW");com.sssw.jbroker.web.portable.Stubクラスのスタブプロパティのマニュアルを参照してください。
Digest認証
Digest認証はAUTH_SCHEMEプロパティがDIGEST_AUTH_SCHEMEに設定されていることを除き、Basic認証と同じ方法で規定されます。 プロパティ定数はstubクラスで定義されています。NTLM認証
NTLM認証は次の通りBasic認証と同様に規定されます。
StockService service = (StockService) ctx.lookup("xmlrpc:soap:StockService");
StockQuote stub = service.getStockQuotePort();
stub._setProperty(stub.AUTH_SCHEME, stub.NTLM_AUTH_SCHEME);
stub._setProperty(stub.USERNAME, username);
stub._setProperty(stub.PASSWORD, password);
stub._setProperty(stub.NTLM_HOST, host);
stub._setProperty(stub.NTLM_DOMAIN, domain);
float quote = stub.getQuote("SSSW");JDK1.3でNTLMを使用する場合、JCEなどの暗号化プロバイダをCLASSPATHに組み込む必要があります。 暗号化ライブラリはJDK1.4に組み込まれます。 別の暗号化プロバイダを使用する場合、jbroker.web.security.providerシステムプロパティを指定します。
NTLMはDigestより安全ですが、認証するためにはDigestよりHTTP要求が1つ多く必要です。 機密性、整合性、検証可能なIDなどの機能を提供するユーザ名/パスワードベースの認証プロトコルはありません。 このような機能については、SSL署名およびXML署名を参照してください。
SSLはTCP/IPを使用するクライアントおよびサーバ間の安全な通信のためのプロトコルです。 SSLの使用によって、第三者からのSOAPメッセージを保護するだけでなく、メッセージの整合性および送信者のIDを検証できます。 Novell exteNd WebサービスSDKはSSL保護されたURLへのアクセスをすべてサポートします。Novell exteNd WSSDKによってクライアントはクライアント認証を含む複数のSSLプロパティの環境設定が可能です。 クライアントのSSLプロパティの設定方法については、SSLHelloの例を参照してください。 Novell exteNd WSSDKの組み込みSSLサポートを使用するには、wssdk-ssl.jarファイルをCLASSPATHに組み込む必要があります。XML署名
XML署名はW3Cの仕様です。 SOAPメッセージをデジタル署名する方法を説明しています。 デジタル署名によって電子ドキュメントの認定が可能です。 SSLと同様、受信したメッセージの識別および整合性を確認できます。 メッセージ送信者のエンティティを検証し、そのエンティティを認証します。 メッセージの整合性が検証できるため、第三者によって途中で不正に変更されることはありません。 Novell exteNd WebサービスSDKは、SOAPメッセージのデジタル署名を完全にサポートします。 開発者は発信SOAPメッセージの署名または着信メッセージの検証、あるいはその両方を実行できます。 特定のプロパティをスタブ/スケルトン上に設定し、署名または検証、あるいはその両方を設定します。 一度設定すると、スタブ/スケルトンから生成されたSOAPメッセージはすべて署名されたSOAPメッセージとなり、スタブ/スケルトンへの着信メッセージはすべて検証されます。 詳細については、Signatureの例 を参照してください。