BigAdmin System Administration Portal
GlassFish アプリケーションサーバーの Java Web Start テクノロジとアプリケーションクライアント
Print-friendly VersionPrint-friendly Version

記事一覧

パート 1 - はじめに
パート 2 - JNLP と Java Web Start テクノロジ
パート 3 - GlassFish アプリケーションクライアント: Java Web Start の体験
パート 4 - セキュリティー、高度なトピック、および展望


Sun Java System Application ServerJava EE SDK は無料でダウンロードできます。
 

この記事のこのパートでは高度なトピックについて説明し、GlassFish アプリケーションサーバーの Java Web Start 機能に対して予定されている改善の展望を示します。

ユーザーがネットワーク経由で実行コードをダウンロードするときは常に、システム上でそのコードを実行可能にすることに慎重になるべきです。Java Runtime、Java Web Start テクノロジ、およびアプリケーションクライアントを起動する Java Web Start をサポートする GlassFish はすべて、セキュリティーを重要視しており、ユーザーが希望するようにアプリケーションクライアントを信頼することも、懐疑的になることもできます。このセクションでは、Java Web Start ソフトウェアとそれをサポートする GlassFish の機能における、セキュリティーの重要点をいくつか要約しています。

Java Web Start セキュリティーサンドボックス

Java Web Start テクノロジでは、セキュリティーサンドボックスをアプレットのサンドボックスのように強化しています。Java Web Start のセキュリティー規則は、ユーザーが許可しないかぎり、アプリケーションがユーザーのローカルシステムに影響を与えることを許可しません。Java Web Start テクノロジを使用して起動されたアプリケーションは、2 つの方法でユーザーのシステムに作用することがあります。最初に、格上げされたアクセスを必要なコードが署名付き JAR 内に存在し、ユーザーが証明書を承認します (詳細は後述)。Java Web Start テクノロジでは、コードの出所が信頼できる署名付き JAR か未署名の JAR のどちらかにより、アプリケーションの一部分を署名付き、残りの部分を未署名にすることができます。ダウンロードしたコードを署名するのに使用されている証明書をユーザーが承認すると、Java Web Start サンドボックスは署名付きコードがユーザーのシステムに作用することを許可します。

Java Web Start テクノロジによってアプリケーションがユーザーのシステムに影響することを認める 2 番目の方法は、Java Web Start API を経由することです。未署名のアプリケーションコードはこの API を使用して、ファイルの読み取りや書き込み、ドキュメントの印刷などの動作が可能になります。ただし、Java Web Start ソフトウェアが要求を遮断し、操作を許可するか、または入力や出力するファイルを選択するかをユーザーに尋ねます。GlassFish ソフトウェア自体はこの API を使用しませんが、クライアントでは使用できます。

デジタル証明書と署名付き JAR

非常に単純化したレベルでは、デジタル証明書は識別情報の主張です。次のことを本質的に表明する、自己署名付き証明書と呼ばれる自分自身の証明書を作成できます。

私は Tim Quinn であることを主張し、私はこの主張を支持します。

少なくとも一般社会に対して、この主張はあまり説得力がありません。次の証明書だと、さらに多くの説得力があります。

私は Tim Quinn であることを主張し、VeriSign がこの主張を支持します。

VeriSign を知っていて信頼している人は、少なくともより納得する可能性があります。VeriSign、Thawte などは認証局 (CA) です。申請者が CA の満足する識別情報を証明した場合、これらの会社が支持することを示すデジタル証明書を有償で申請者に提供します。このような証明書を承認する人が、申請者の識別情報のほかに証明書所有者の識別情報を確認する CA のプロセスも承認します。

自己署名付き証明書やほかの証明書を持っている場合、さまざまな方法で使用できます。1 つの方法は、JAR ファイルなどのデジタルコンテンツに署名することです。私の証明書を使って署名した JAR ファイルに含まれるコードの実行にあなたが同意した場合、明示的な識別情報の主張 (JAR の出所が私) と暗黙的な信頼性の主張 (内部のコードがシステムに悪影響を及ぼさない) の両方を承認することになります。識別情報と信頼は別のものです。よく知っているが、信頼しない人、会社、またはコードプロバイダがいるかもしれません。

Java Web Start ソフトウェアは署名付きの JAR からのコードに対してのみ格上げされたアクセス権を付与します。これは、エンドユーザーが JAR への署名に使用される証明書を承認する場合に限ります。この文脈では、識別情報と信頼が再度登場します。

自動署名付き JAR と手動署名付き JAR

いくつかの GlassFish ACC コードでは、格上げされたアクセス権が必要です。さらに、バックエンドサーバーの EJB と通信するコードのように、クライアントコードによりトリガーされたいくつかのコードも格上げされたアクセス権が必要です。起動に appclient コマンドを使用しても、Java Web Start サポートを使用しても、いずれを使用する場合でも、これは当てはまります。違う点は、これまで説明したように、Java Web Start のセキュリティー規則では、格上げしたアクセス権を持つコードを実行するためには、コードに署名が必要だということです。

GlassFish アプリケーションサーバーでは、Java Web Start が起動中に、ACC を実行する appserv-jwsacc.jar ファイルに自動的に署名します。エンドユーザーが Java Web Start ソフトウェアを使用してアプリケーションクライアントを起動するときに、まだアプリケーションクライアントが署名されていない場合、GlassFish サーバーはそのアプリケーションクライアントに対して生成されたアプリケーションクライアントの JAR ファイルに署名します。いずれの場合でも、GlassFish サーバーは GlassFish ドメインの作成中に生成される自己署名付き証明書を使用します。

エンドユーザーが、自己署名付き GlassFish 証明書を信頼しないことがあります。開発者は自身の証明書を使用して、それらのファイルの署名付きコピーを提供できます。この場合、GlassFish サーバーがそれらのファイルを代わりに提供します。GlassFish のインストール後はいつでも、appserv-jwsacc.jar ファイルに署名できます。アプリケーションクライアントを含むアプリケーションの配備後はいつでも、生成したアプリケーションクライアントの JAR ファイルに署名できます。アプリケーションを再配備しないかぎり、GlassFish アプリケーションサーバーは署名付きファイルを上書きしません。再配備した場合は、新しく生成されたアプリケーションクライアントの JAR に簡単に署名できます。

以降の数セクションでは、アプリケーションクライアントを起動する Java Web Start テクノロジへの移行を準備するときに検討する、価値のあるいくつかの項目について簡単に説明します。

実行時の情報の受け渡し

Java Web Start テクノロジを使用して起動するように構築する新しいアプリケーションクライアントでは、必要な情報の収集に古典的な GUI または Java Web Start API を使用するはずです。この主な理由は、Java Web Start ソフトウェアがコマンド行アプリケーションよりも GUI アプリケーションとよりよく動作するからです。ただし、コマンド行引数やシステムプロパティーに依存する可能性のある新規または既存のアプリケーションクライアントなど、いずれのアプリケーションクライアントも Java Web Start テクノロジを使用して起動できます。

次の一般的な形式を使用して、アプリケーションクライアントを起動する URL のクエリー文字列を使ってこれらの設定を渡します。

http://host:port/path?runtime-settings
 

コマンド行引数を渡すには、次の引数を

arg=first-word &arg=second-word &...
 

runtime-setting に含めます。各「word」は、コマンド行に単語として通常入力するものです。前述の描画ツールの例に戻ると、次の引数をクエリー文字列で使用して、

arg=circle
 

最初の円の形状を要求できます。

同様に、システムプロパティー設定を渡すには、次の行を

prop=name-1=value-1 &prop=name-2=value-2 &...
 

runtime-setting の一部として使用します。次の古典的な Java コマンド行フラグメントと同じ効果があります。

-Dname-1=value-1 -Dname-2=value-2
 

引数の設定とプロパティー設定を混在できます。プロパティーは任意の順序にできます。引数は、クエリー文字列内に表示される順序でアプリケーションクライアントに渡されます。

例として、描画ツールを起動するための URL を示します。

http://host:port/drawTool?prop=color=blue&arg=circle
 

System.out、System.err、および System.in

既存のアプリケーションクライアントが System.out または System.err に書き込む場合、エンドユーザーシステム上でいくつかの Java 設定を変更しないかぎり、クライアントの実行時には何も表示されません。これは、何が起こったかを理解しようとするときに、開発者やユーザーを困惑させる可能性があります。Java Web Start アプリケーションは、System.outSystem.err のメッセージをコンソールとトレースファイルの両方、またはどちらか一方に表示できます。ただし、これはデフォルトではありません。

これらの設定を変更するには、次の手順に従います。

  1. Java コントロールパネルを開きます。
  2. 「詳細」タブをクリックします。
  3. 「デバッグ」と「Java コンソール」のノードを展開します。
  4. 「トレースを有効にする」と「コンソールを表示する」のチェックボックスをオンにします。
  5. 「了解」ボタンをクリックします。

図 1: Java コントロールパネルの「詳細」タブ
図 1: Java コントロールパネルの「詳細」タブ
 

アプリケーションクライアントを含む、このシステムで起動するすべての Java Web Start アプリケーションは、エラーメッセージと出力メッセージをすべてトレースファイルに書き込むか、または画面にそれらのメッセージを表示するコンソールウィンドウを開きます。トレースファイルは、使用しているオペレーティングシステムにより、次に示す場所のいずれかにあります。

/your-home-directory/.java/deployment/log
 

または

C:\Documents and Settings\your-username\Application Data\Sun\Java\Deployment\log
 

System.in から入力を読み取るアプリケーションクライアントは、現在 Java Web Start テクノロジと連動していません。Java Web Start ソフトウェアは、キーボードから Java Web Start アプリケーションへの入力ストリームを提供しておらず、アプリケーションが System.in を使用しようとすると例外が発生し失敗します。

ライブラリの処理 (前提条件なし)

古典的な方法で起動したアプリケーションクライアントを手動で配布していた場合、それらのアプリケーションクライアントをサポートするエンドユーザーのシステムにライブラリ JAR もインストールしていた可能性があります。アプリケーションクライアントの起動に Java Web Start テクノロジを使用することを計画するときに必要な唯一の前提条件は、エンドユーザーのシステムに Java Runtime があることです。この理由は、Java Web Start ソフトウェア、ひいてはその GlassFish のサポートがアプリケーションクライアント用の環境を設定するために、アプリケーションクライアントを起動する JNLP ドキュメントのみを調べるからです。

アプリケーションクライアントがライブラリ JAR を必要な場合、アプリケーションクライアント JAR にそれらのクラスを含めるか、またはアプリケーションクライアントが EAR に組み込まれる場合、その EAR に JAR をパッケージします。

GlassFish プロジェクトのエンジニアリングチームは、GlassFish サーバーでの Java Web Start によるサポートの最初の実装で、開発者や管理者が余分な手順や作業を行わずにこのテクノロジを使用できるようにしたいと思っていました。そのチームのメンバーである私も、GlassFish コミュニティのメンバーがこのテクノロジで気に入った点や、追加、変更してほしい点を知らせてくれることを希望していました。チームはこれまでのフィードバックを非常に喜んでいます。この機能の将来について、チームは独自の考えをいくつか持っていました。それらの考えの多くは、機能を使用した体験に関するユーザーの意見により裏付けられています。

私達は明確な強化や変更について約束できませんが、将来のリリースに含めたいと希望している改善点を 2 点示します。

フットプリントの小型化

appclient スクリプトと Java Web Start によるいずれの起動でも、アプリケーションクライアントを簡単に実行するには、私達やユーザーが望むよりもより多くのかつ大きい JAR ファイルが必要です。これは、改善点の 1 つです。JAR の数とサイズの両方を減らすことで改善を考えたいと思っています。

また、特定のアプリケーションクライアントの起動に不要な JAR のダウンロードを遅延させたり除外したりするために、Java Platform, Standard Edition (Java SE) 6 の JAR のインデックス指定に対する Java Web Start テクノロジでの処理について、改善の突破口を探すことを考えています。

生成された JNLP ドキュメントのよりよいカスタマイズ

この記事の前のセクションでは、アプリケーションクライアント用に生成した JNLP ドキュメントのいくつかの項目をカスタマイズできる方法について説明しました。私達は、JAR をネイティブライブラリとして指定可能にしたり (Java Web Start テクノロジがすでにサポート)、カスタムアイコンやスプラッシュ画像を指定するなど、JNLP の特定のカスタマイズに対していくつかの要望を受け取っていました。この 2 番目の要望について、GlassFish V2 で限定的な方法で対応しました。

GlassFish アプリケーションサーバーは、JNLP ドキュメントのいくつかの主要要素を制御する必要があります。しかし、開発者が省略する情報のデフォルトを GlassFish アプリケーションサーバーが提供すると同時に、開発者がアプリケーションクライアント用の JNLP の残りの多くを指定できることが理想的です。機能を提供する上で興味深い課題がいくつかありますが、私達は達成することを希望しています。最後に、私達が機能にもっとも望むことは、Java Web Start テクノロジを使用して起動されたアプリケーションクライアントの幅広い使用を促進し、エンタープライズアプリケーションのエンドユーザーに一層充実した体験を提供することです。

参照情報
BigAdmin