プライマリ・コンテンツに移動
Java Platform, Standard Editionデプロイメント・ガイド
リリース9
E90918-01
目次へ移動
目次
前
前 		次
次

5 アプリケーション開発時の考慮点

この章の内容は次のとおりです。

Webデプロイメントの概要

Java Web Startでデプロイ可能なアプリケーションを開発する方法は、Java Platform, Standard Edition向けのスタンドアロン・アプリケーションを開発する方法と、基本的には同じです。たとえば、アプリケーションのエントリ・ポイントは、通常のpublic static void main(String[] argv)です。

ただし、Webデプロイメント(アプリケーションを自動的にダウンロードして起動すること)をサポートし、アプリケーションを安全なサンドボックス内で実行するには、考慮する点がいくつかあります。

  • アプリケーションは一連の署名付きJARファイルとして配信される必要がある。各JARファイル内のすべてのエントリに署名する必要がある。

  • ファイルやイメージなど、すべてのアプリケーション・リソースは、JARファイルに格納する必要がある。リソースは、Java Platform, Standard EditionのgetResourceメカニズムを使用して参照される必要がある。

  • 安全なサンドボックス内で実行されるように記述されたアプリケーションには、次の制限が適用される。

    • ローカル・ディスクにアクセスできない。

    • すべてのJARファイルを同一ホストからダウンロードする必要がある。

    • ユーザー・プロンプトを使用しないネットワーク接続は、JARファイルのダウンロード元のホストに対してのみ有効になる。他のホストへの接続は、ユーザーからの承認を必要とする。

    • セキュリティ・マネージャはインストールできない。

    • ネイティブ・ライブラリは使用できない。

    • システム・プロパティへのアクセスが制限される。アプリケーションは、JNLPファイル内に定義されたすべてのセキュア・システム・プロパティに対する読取り/書込みアクセス権を持つほか、アプレットからアクセス可能なプロパティ・セットに対する読取り専用アクセス権を持つ。

    JNLP APIを使用すると、これらの制限の一部を克服してファイル・システムなどのシステム・リソースにアクセスできる。

  • アプリケーションはSystem.exit呼出しを使用できる。 

JARファイルからのリソースの取得

Java Web StartによってWebサーバーからクライアント・マシンに転送されるのは、JARファイルだけです。また、JARファイルをローカル・マシン上のどこに格納するかも判断されます。したがって、イメージや設定ファイルといったリソースへのディスク相対参照を、アプリケーション内で使用することはできません。

すべてのアプリケーション・リソースは、JNLPファイルのresourcesセクションに指定されたJARファイルから取得するか、WebサーバーへのHTTP要求を通じて明示的に取得する必要があります。JARファイル内にリソースを格納することをお薦めします。それらのリソースは、Java Web Startによってローカル・マシン上にキャッシュされるためです。

次のコード例は、JARファイルからイメージを取り出す方法を示したものです。

// Get current classloader
ClassLoader cl = this.getClass().getClassLoader();
// Create icons
Icon saveIcon  = new ImageIcon(cl.getResource("images/save.gif"));
Icon cutIcon   = new ImageIcon(cl.getResource("images/cut.gif"));
...

この例では、アプリケーションのJARファイルのいずれかに、次のエントリが存在することを前提にしています。

images/save.gif
images/cut.gif

JNLP APIを使用したクライアントへのアクセス

JNLP APIを使用して、クライアントのファイル・システムなどのリソースにアクセスできます。JNLPI APIを使用してクライアントにアクセスする方法の詳細は、次のトピックを参照してください。

セキュリティとコード署名

Java Web Startは、次のセキュリティ上の問題に対応しています。

  • ローカル・ファイルに影響を及ぼす可能性のある有害なコード(意図的かどうかにかかわらず)から、ユーザーを保護する
  • ネットワーク上のデータに対してアクセスや破壊を試みる可能性のあるコードから、企業を保護する

Java Web Startで起動されたアプリケーションはデフォルトで、制限された環境内で実行されます。このため、記憶装置やローカル・ネットワークなど、ローカルのコンピューティング・リソースへのアクセスが制限されます。

Java Web Startがサポートするもう1つのセキュリティ機能は、デジタル・コード署名です。起動対象のアプリケーションが1つ以上の署名付きJARファイルとして配信された場合、Java Web Startは、それらのJARファイルの内容が署名後に変更されていないかどうか検証します。デジタル署名の検証に失敗した場合、そのアプリケーションは第三者によって改ざんされた可能性があるため、Java Web Startはアプリケーションの実行を中止します。

コード署名のサポートは、ユーザーとアプリケーション・サービス・プロバイダの双方にとって重要です。このサービスを使えば、ユーザーは、アプリケーションの提供元が信頼できるかどうかを検証できます。また、ユーザーによって信頼された署名付きのアプリケーションは、ローカル・ディスクへのアクセスなど、追加のシステム権限を要求することもできます。

Java Web Startは、アプリケーションを起動する前に、署名者の証明書に基づいて、アプリケーションの提供元を示すダイアログ・ボックスを表示します。これにより、ユーザーは、ダウンロードされたコードに追加の権限を許可するかどうかを、具体的な情報に基づいて決定できます。

アプリケーションのすべてのJARファイルが署名されていれば、JNLPファイル内に次の設定を含めることで、アプリケーションはクライアント・システムへの完全なアクセスを要求できるようになります。

<security>
   <all-permissions/>
</security>

Java Web Startにおけるコード署名の実装は、コアJava Platform, Standard EditionのセキュリティAPIに基づいています。

開発者がJava Web Start用のコードに署名する方法は、Javaアプレットの場合と同じです。つまり、Java Platform, Standard Editionに付属する標準ツールjarsignerを使用します。jarsignerツールのマニュアルでは、コードの署名方法とテスト証明書の作成方法の具体例を示すとともに、署名に関するその他の問題について説明しています。

テスト証明書によるJARファイルの署名

テストの目的で、自己署名証明書を使用してJARファイルに署名できます。本番用には、信頼できる認証局によって発行されたコード署名証明書を使用します。

次に、自己署名テスト証明書を使用してJARファイルに署名する手順を示します。

  1. SDKのkeytoolとjarsignerにパスが通っていることを確認します。これらのツールは、SDKのbinディレクトリに格納されています。

  2. 新しいkeystore内に新しいキーを作成します。次のようにします。

    keytool -genkey -keystore myKeystore -alias myself

    パスワードや名前など、新しいキーに関する情報の入力を求められます。これによって、ディスクにmyKeystoreファイルが作成されます。

  3. 次のように、自己署名テスト証明書を作成します。

    keytool -selfcert -alias myself -keystore myKeystore

    これによって、パスワードの入力を求められます。証明書の生成には数分かかります。

  4. すべてが正常であることを確認します。キーストアの内容を一覧表示するには、次のコマンドを使用します。

    keytool -list -keystore myKeystore

    出力は次のようになります。

    Keystore type: jks
Keystore provider: SUN

Your keystore contains 1 entry:

myself, Tue Jan 23 19:29:32 PST 2001, keyEntry,
Certificate fingerprint (MD5):
C2:E9:BF:F9:D3:DF:4C:8F:3C:5F:22:9E:AF:0B:42:9D

  5. 次のように、テスト証明書を使用してJARファイルに署名します。

    jarsigner -keystore myKeystore test.jar myself

    この手順を、すべてのJARファイルに対して繰り返します。

    自己署名テスト証明書はあくまでも内部テスト専用であることに注意してください。この証明書はユーザーの身元を保証できず、信頼性に欠けるためです。アプリケーションを本番環境に移す際には、VeriSignやThawteなどの認証局から信頼できる証明書を取得し、それを使用するようにしてください。

自己署名テスト証明書を使用して署名されたアプリケーションを実行するには、アプリケーションを実行するコンピュータで次のいずれかを実行します。

  • アプリケーションの場所を、Javaコントロール・パネルから管理される例外サイト・リストに追加します。

  • テスト証明書を、Javaコントロール・パネルを使用してユーザー署名者のCAストアにインポートするか、keytoolユーティリティを使用してシステム署名者のCAストアにインポートします。

JNLPファイルのエンコード方式

Java Platform, Standard Editionでサポートされている任意の文字エンコーディングでJNLPファイルをエンコードします。リストについては、Java Platform, Standard Edition国際化ガイドのサポートされているエンコーディングを参照してください。

JNLPファイルをエンコードするには、そのファイルのXML prologでエンコーディングを指定します。たとえば、次の行は、JNLPファイルをUTF-16でエンコードすることを示しています。

<?xml version="1.0" encoding="utf-16"?>

XML prologそのものは、UTF-8でエンコードする必要があります。

HTTPS証明書の動的ダウンロード

Java Web Startでは、ブラウザと同様の方法で証明書が動的にインポートされます。このため、Java Web Startでは、java.protocol.handler.pkgsシステム・プロパティを使用してSSLSocketFactoryとHostnameVerifierの両デフォルトを初期化するHTTPSハンドラが独自に設定されています。デフォルトの設定には、HttpsURLConnection.setDefaultSSLSocketFactoryとHttpsURLConnection.setDefaultHostnameVerifierが使用されます。

アプリケーション内でこれら2つのメソッドが使用されている場合、Java Web StartのHTTPSハンドラの初期化後にそれらのメソッドを呼び出すようにしてください。そうしないと、アプリケーションのカスタム・ハンドラが、Java Web Startのデフォルト・ハンドラで置き換えられてしまいます。独自にカスタマイズされたSSLSocketFactoryとHostnameVerifierが使用されるようにするには、次のいずれかを実行します。

  1. 独自のHTTPSハンドラをインストールします(これにより、Java Web StartのHTTPSハンドラが完全に置き換えられます)。
  2. HttpsURLConnection.setDefaultSSLSocketFactoryまたはHttpsURLConnection.setDefaultHostnameVerifierの呼出しを、必ず最初のHttpsURLConnectionオブジェクトが作成された後で行います(そうすれば、Java Web StartのHTTPSハンドラの初期化コードが最初に実行されます)。
前
前 		次
次
目次へ移動
目次