|
記事一覧
この記事のこのパートでは高度なトピックについて説明し、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 と通信するコードのように、クライアントコードによりトリガーされたいくつかのコードも格上げされたアクセス権が必要です。起動に
GlassFish アプリケーションサーバーでは、Java Web Start が起動中に、ACC を実行する
エンドユーザーが、自己署名付き GlassFish 証明書を信頼しないことがあります。開発者は自身の証明書を使用して、それらのファイルの署名付きコピーを提供できます。この場合、GlassFish サーバーがそれらのファイルを代わりに提供します。GlassFish のインストール後はいつでも、 以降の数セクションでは、アプリケーションクライアントを起動する Java Web Start テクノロジへの移行を準備するときに検討する、価値のあるいくつかの項目について簡単に説明します。 実行時の情報の受け渡し Java Web Start テクノロジを使用して起動するように構築する新しいアプリケーションクライアントでは、必要な情報の収集に古典的な GUI または Java Web Start API を使用するはずです。この主な理由は、Java Web Start ソフトウェアがコマンド行アプリケーションよりも GUI アプリケーションとよりよく動作するからです。ただし、コマンド行引数やシステムプロパティーに依存する可能性のある新規または既存のアプリケーションクライアントなど、いずれのアプリケーションクライアントも Java Web Start テクノロジを使用して起動できます。 次の一般的な形式を使用して、アプリケーションクライアントを起動する URL のクエリー文字列を使ってこれらの設定を渡します。
コマンド行引数を渡すには、次の引数を
runtime-setting に含めます。各「word」は、コマンド行に単語として通常入力するものです。前述の描画ツールの例に戻ると、次の引数をクエリー文字列で使用して、
最初の円の形状を要求できます。 同様に、システムプロパティー設定を渡すには、次の行を
runtime-setting の一部として使用します。次の古典的な Java コマンド行フラグメントと同じ効果があります。
引数の設定とプロパティー設定を混在できます。プロパティーは任意の順序にできます。引数は、クエリー文字列内に表示される順序でアプリケーションクライアントに渡されます。 例として、描画ツールを起動するための URL を示します。
System.out、System.err、および System.in
既存のアプリケーションクライアントが これらの設定を変更するには、次の手順に従います。
アプリケーションクライアントを含む、このシステムで起動するすべての Java Web Start アプリケーションは、エラーメッセージと出力メッセージをすべてトレースファイルに書き込むか、または画面にそれらのメッセージを表示するコンソールウィンドウを開きます。トレースファイルは、使用しているオペレーティングシステムにより、次に示す場所のいずれかにあります。
または
ライブラリの処理 (前提条件なし) 古典的な方法で起動したアプリケーションクライアントを手動で配布していた場合、それらのアプリケーションクライアントをサポートするエンドユーザーのシステムにライブラリ JAR もインストールしていた可能性があります。アプリケーションクライアントの起動に Java Web Start テクノロジを使用することを計画するときに必要な唯一の前提条件は、エンドユーザーのシステムに Java Runtime があることです。この理由は、Java Web Start ソフトウェア、ひいてはその GlassFish のサポートがアプリケーションクライアント用の環境を設定するために、アプリケーションクライアントを起動する JNLP ドキュメントのみを調べるからです。 アプリケーションクライアントがライブラリ JAR を必要な場合、アプリケーションクライアント JAR にそれらのクラスを含めるか、またはアプリケーションクライアントが EAR に組み込まれる場合、その EAR に JAR をパッケージします。 GlassFish プロジェクトのエンジニアリングチームは、GlassFish サーバーでの Java Web Start によるサポートの最初の実装で、開発者や管理者が余分な手順や作業を行わずにこのテクノロジを使用できるようにしたいと思っていました。そのチームのメンバーである私も、GlassFish コミュニティのメンバーがこのテクノロジで気に入った点や、追加、変更してほしい点を知らせてくれることを希望していました。チームはこれまでのフィードバックを非常に喜んでいます。この機能の将来について、チームは独自の考えをいくつか持っていました。それらの考えの多くは、機能を使用した体験に関するユーザーの意見により裏付けられています。 私達は明確な強化や変更について約束できませんが、将来のリリースに含めたいと希望している改善点を 2 点示します。 フットプリントの小型化
また、特定のアプリケーションクライアントの起動に不要な 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 SubscriptionsBigAdmin Areas
BigAdmin Sun Center
BigAdmin Topics | ||||||||||||||||