注意:
デプロイメント・ルール・セット機能はオプションであり、制御された環境の組織で内部的にのみ使用されるものとします。ルール・セットを含むJARファイルが配布されたり、公的に入手可能になったりした場合は、そのルール・セットの署名に使用された証明書がブラックリストに登録され、Javaでブロックされます。
この項の内容は次のとおりです。
デプロイメント・ルール・セット機能を使用すると、企業は、セキュリティ・プロンプトなしで実行できる既知のアプリケーションのホワイトリストを作成できます。
Javaアプレット、Java Web Startアプリケーション、およびブラウザに埋め込まれたりブラウザから起動されるJavaFXアプリケーションは、まとめてリッチ・インターネット・アプリケーション(RIA)として知られています。ユーザーを保護し、RIAが損なわれる可能性を最小限に抑えるために、RIAの起動時にセキュリティ・チェックが行われ、ユーザーにRIAの実行を許可するよう求めるプロンプトが表示されます。デプロイメント・ルール・セットによって定義されたホワイトリスト上のアプリケーションは、ほとんどのセキュリティ・プロンプトを表示せずに実行できますが、次のプロンプトは抑止されません。
HTTPSのセキュリティ警告
ユーザーに資格証明を入力して接続するよう要求する認証ダイアログ
ショートカットや関連付けの作成といったアクションを実行する署名なしのJava Web Startアプリケーションからのセキュリティ警告
配備用のルールは、XMLファイルに定義され、署名付きJARファイルにパッケージ化されます。それらのルールは、RIAと一致するものが見つかるまで順次にテストされます。ルールに割り当てられているアクションに応じて、そのあとRIAはセキュリティ・プロンプトなしで実行されるか、実行がブロックされるか、または適用可能ないずれかのセキュリティ・プロンプトを表示するデフォルトの処理で実行されます。一致するルールがない場合は、デフォルトの処理が使用されます。それらのルールでは、RIAの実行に使用されるJREのバージョンを指定したり、古いJREの通知を抑止したりすることもできます。
システムにインストールされているアクティブなルール・セットは、Javaコントロール・パネルの「Webの設定」タブから参照できます。
ルール・セットはXMLファイルで、ruleset.xml
という名前を付ける必要があります。このファイルの作成には、任意のテキスト・エディタを使用できます。
所属組織内でRIAを実行またはブロックするために必要なルールを定義します。ルール・セットの構文については、「Javaデプロイメント・ルール・セットのDTD」を参照してください。不明な要素または属性がルール・セットに含まれる場合、Javaコンソールに警告が書き込まれます。
次の要素が有効です。
ルール・セットが無効な場合は、その問題について説明するエラーが表示され、すべてのRIAがブロックされます。RIAを実行できるようにするには、ruleset.xml
ファイルを修正するか、DeploymentRuleSet.jar
ファイルをデプロイメント・ディレクトリから削除する必要があります(このディレクトリの場所についてはルール・セットのインストールを参照)。ルール・セットが無効と報告される場合は、表示されたエラーに基づいて、次の問題をチェックします。
ファイルが読取り不可です。
ファイルの構造が無効です。
ルールが適切に定義されていません。
run
というアクションを持つルールに選択条件が指定されていないため、そのルールがすべてのRIAと一致します。
JARファイルが有効な証明書で正しく署名されていません。
DeploymentRuleSet.jar
ファイルが削除された場合、RIAはデフォルトの配備プロセスによって処理されます。
ルール・セットの例については、「例」を参照してください。
表10-1 <ruleset>の属性
属性 | 説明 | 必須 |
---|---|---|
|
このファイルの処理に必要なデプロイメント・ルール・セット仕様の最小バージョン。それ以降のバージョンも使用できることを示すには、プラス記号(+)を使用します(例: |
はい |
<rule>
要素は、ルールに指定された条件に一致するRIAまたはRIAのセットのために実行されるアクションを定義します。
この要素には、1つの<id>要素、1つの<action>要素およびオプションの<customer>要素が含まれます。ルールは、1つのルールが一致するまで順次に処理されます。一致するものが見つかると、それ以上のルールは処理されません。一致するルールがない場合は、デフォルトの処理が使用され、関連するセキュリティ・プロンプトまたは警告がすべて表示されます。
注意:
RIAに、別の証明書で署名されているか、別の場所にあるアーティファクトが含まれている場合は、ルール・セットにそのRIAのすべてのアーティファクトのルールが必ず含まれるようにしてください。混合コードのケース(異なる権限レベルを持つJARファイル間の呼出しや、JavaScriptコードから特権付きJavaコードへの呼出し)の場合は、混合コード用のルールの設定を参照してください。
有効な親要素は<ruleset>です。有効な子要素は<id>および<action>です。
この要素に属性はありません。
<id>
要素は、ルールが適用されるRIAまたはRIAのセットを識別します。一致と見なされるには、RIAが、存在しているすべての属性および子要素と一致する必要があります。属性または子要素が存在しない場合、ルールはすべてのRIAと一致します。
注意:
ルールのアクションがrun
の場合は、少なくとも1つの属性または子要素が存在する必要があります。
有効な親要素は<rule>です。有効な子要素は<certificate>、<checksum>および<jnlp-checksum>です。署名付きJARファイルには<certificate>
要素を使用します。署名なしのJARファイルには、デプロイメント・ルール・セット1.2以上の<checksum>
要素を使用します。署名なしのJNLPファイルでセキュアでないプロパティを使用できるようにするには、場所ベースの実行ルールとともにデプロイメント・ルール・セット1.3以上の<jnlp-checksum>
要素を使用します。
次の表は、有効な属性について説明しています。
表10-2 <id>の属性
属性 | 説明 | 必須 |
---|---|---|
|
RIAのソースのURL。JNLPを使用するRIAの場合、この値はメインJNLPファイルの 潜在的なman-in-the-middle攻撃を回避するために、HTTPSプロトコルの使用を強くお薦めします。 場所の一致は、次のガイドラインに基づいて行われます。
|
いいえ |
|
JNLPファイルのtitle要素に使用される文字列、またはJava Plug-inによって使用される文字列。 ルールのアクションが |
いいえ |
<certificate>
要素は、RIAの署名に使用された証明書を識別します。hash
属性が必須です。
有効な親要素は<id>です。この要素に子要素はありません。
次の表は、有効な属性について説明しています。
表10-3 <certificate>の属性
属性 | 説明 | 必須 |
---|---|---|
|
hash属性の値の生成に使用されるハッシュ・アルゴリズムを定義する文字列。現時点では、セキュリティ・ハッシュ・アルゴリズムSHA-256のみがサポートされています。その値がnullの場合は、SHA-256が使用されます。 |
いいえ |
|
コード署名証明書のハッシュ値を表す16進数の文字列。この値は、 |
はい |
<checksum>
要素は、署名なしのJARファイルのチェックサムを識別します。hash
属性が必須です。この要素はデプロイメント・ルール・セット1.2以上で使用可能です。
有効な親要素は<id>です。この要素に子要素はありません。
次の表は、有効な属性について説明しています。
表10-4 <checksum>の属性
属性 | 説明 | 必須 |
---|---|---|
|
hash属性の値の生成に使用されるハッシュ・アルゴリズムを定義する文字列。現時点では、セキュリティ・ハッシュ・アルゴリズムSHA-256のみがサポートされています。その値がnullの場合は、SHA-256が使用されます。SHA-256以外の非nullの値が使用されている場合、警告が発行されてSHA-256が使用されます。 |
いいえ |
|
圧縮されていない形式のJARファイル(圧縮レベル0)のチェックサムのハッシュ値を表す16進数の文字列。この値は、 |
はい |
<jnlp-checksum>
要素は、JNLPファイルのチェックサムを識別します。hash
属性が必須です。この要素はデプロイメント・ルール・セット1.3以上で使用可能です。
有効な親要素は<id>です。この要素に子要素はありません。
<id>
要素のlocation
属性がnullの場合、<jnlp-checksum>
要素は無視されます。複数の<jnlp-checksum>
要素を指定できます。JNLPファイルのチェックサムがルール内のいずれかの<jnlp-checksum>
要素のhash属性と等しい場合、ルールは一致します。次の表は、有効な属性について説明しています。
表10-5 <jnlp-checksum>の属性
属性 | 説明 | 必須 |
---|---|---|
|
チェックサムのハッシュ値を表す16進数の文字列。この値は、 |
はい |
<action>
要素は、ルールと一致するすべてのRIAに対して実行されるアクションを定義します。
有効な親要素は<rule>です。有効な子要素は<message>です。
次の表は、有効な属性について説明しています。
表10-6 <action>の属性
属性 | 説明 | 必須 |
---|---|---|
|
実行されるアクション。有効な値は
runアクションでカスタム・メッセージを含めるには、バージョン1.2以上のデプロイメント・ルール・セットを使用して<message>要素を含めます。 |
はい |
|
RIAの実行に使用するJREのバージョンを識別する文字列。この属性は、 有効な値は次のとおりです。
使用されるJREのバージョンは、次の優先順位によって決まります。
それらの基準を満たすバージョンが入手できない場合、そのRIAはブロックされ、メッセージがユーザーに表示されます。カスタム・メッセージを表示するには、 |
いいえ |
|
たとえば、RIAが1.7ファミリ(1.7*)のJREを要求し、企業で実行されているJRE 8のバージョンのみを保護する必要がある場合、 この属性は、デプロイメント・ルール・セットの1.1以降のバージョンで使用できます。 |
いいえ |
<message>
要素は、ユーザーに表示されるカスタム・メッセージを定義します。このメッセージを使用して、RIAがブロックされる理由を説明したり、追加情報をユーザーに提供することができます。
プレーン・テキストのみを使用でき、HTMLタグやその他の特殊フォーマットはサポートされていません。この要素が存在しない場合は、RIAがブロックされたときにデフォルトのメッセージが表示されます。デプロイメント・ルール・セット1.2以上では、実行するように設定されたアクションのあるルールに対してこの要素が存在する場合、追加のダイアログがユーザーに表示されます。複数のロケールをサポートするには、ロケールごとにmessage
要素を含めます。
locale
属性を指定しない場合は、message
要素が指定されていないすべてロケールに対してそのメッセージが使用されます。ユーザーのロケール用のmessage
要素が指定されず、ロケールのないmessage
要素も存在しない場合は、デフォルトのメッセージが表示されます。
メッセージが表示されるダイアログ・ボックスが画面に収まるようにするには、メッセージを1024文字未満に保ち、指定されたすべてのロケールをテストします。
有効な親要素は<action>です。この要素に子要素はありません。
次の表は、有効な属性について説明しています。
表10-7 <message>要素の属性
属性 | 説明 | 必須 |
---|---|---|
|
メッセージが適用されるロケール。 |
いいえ |
<customer>
要素に指定された情報は、トレースおよびコンソールが有効な場合はデプロイメント・トレース・ファイルおよびJavaコンソールに書き込まれます。この要素を使用して、デバッグ情報を提供したり、カスタム・データをルールまたはルール・セットと関連付けます。
<customer>
要素に、プレーン・テキストまたは有効なXMLとして任意の情報を入力できます。ルールに固有の情報を指定するには、そのルール内に<customer>
要素を含めます。ルール・セットに関する情報を指定するには、ルールの外側に要素を含めます。デプロイメント・ルール・セット1.2よりも前では、この要素は無視されます。デプロイメント・ルール・セット1.2以上では、この要素からの情報は、トレース・ファイルおよびJavaコンソールが有効な場合はそれらにコピーされます。
有効な親要素は<ruleset>および<rule>です。この要素に子要素はありません。
この要素に属性はありません。
JavaScriptコードからRIAへの呼出しを行う必要がある場合は、次のガイドラインに従ってそれらの呼出しがブロックされないようにします。
ルール・セットに、RIAと一致する、run
というアクションを持つルールが含まれている場合、そのルール・セットには、JavaScriptコードの場所と一致する、run
というアクションを持つルールも含まれている必要があります。
ルール・セットに、RIAと一致する、default
というアクションを持つルールが含まれている場合、またはRIAと一致するルールがないためにデフォルトの処理が使用される場合は、次のいずれかが当てはまる必要があります。
ルール・セットに、JavaScriptコードの場所と一致する、run
というアクションを持つルールが含まれています。
ルール・セットに、JavaScriptコードの場所と一致する、default
というアクションを持つルールが含まれています。
JavaScriptコードの場所と一致するルールがないため、デフォルトの処理が使用されます。
JavaScriptコードが特権付きコードを呼び出していて、混合コードの警告を抑止する必要がある場合は、「混合コードのルールを設定する」を参照してください。
ルール・セットを作成するときは、RIAに関連付けられているすべてのアーティファクトのルールが必ず含まれるようにしてください。異なる権限レベルを持つコード間の呼出し時、またはJavaScriptコードから特権付きJavaコードへの呼出し時に生成される混合コードのセキュリティ警告を抑止するために、追加のルールが必要になることがあります。
混合コードのセキュリティ警告を抑止するには、次のRIAの要件に基づいたルールをルール・セットに含めます。
異なる権限レベルを持つJavaコード間で呼出しを行うには、呼び出されるコードと一致する、run
というアクションを持つルールを追加します。
たとえば、次のルールでは、サンドボックス・コードから、https://host.example.com/apps
に置かれた特権付きコードへの呼出しで混合コードのプロンプトが表示されないようにします。
<rule> <id location="https://host.example.com/apps"/> <action permission="run"/> </rule>
JavaScriptコードから特権付きJavaコードへの呼出しを行うには、JavaScriptコードの場所と一致する、run
というアクションを持つルールを追加します。
たとえば、次のルールでは、https://host.example.com
上のいずれかのページに置かれているJavaScriptコードから特権付きJavaコードへの呼出しで混合コードのプロンプトが表示されないようします。
<rule> <id location="https://host.example.com/"/> <action permission="run"/> </rule>
ルール・セットに、JavaScriptコードの場所と一致する、run
またはdefault
というアクションを持つルールが1つも含まれていない場合、JavaScriptコードからの呼出しはブロックされます。JavaScriptコードからの呼出しで適用可能ないずれかのセキュリティ・プロンプトが表示されるようにする場合は、JavaScriptコードの場所と一致する、default
というアクションを持つルールを定義する必要があります。
このセクションに示されている、混合コードのプロンプトを抑止するためのルールが、そのルールと一致するRIAのほかのセキュリティ・プロンプトも抑止することに注意してください。必要な制御を行うために必要とされる順序でルールが定義されていることを確認してください。
ruleset.xml
ファイルに定義されているルール・セットを、DeploymentRuleSet.jar
という名前の署名付きJARファイルにパッケージ化する必要があります。このJARファイルは、信頼できる認証局からの有効な証明書で署名されている必要があります。
JARファイルの作成と署名については、「Javaチュートリアル」の「Packaging Programs in JAR Files」レッスンを参照してください。
ルール・セットは、Javaアプリケーションを実行する必要があるすべてのシステムにインストールする必要があります。
DeploymentRuleSet.jar
ファイルをユーザーのシステムの次のディレクトリにインストールします。
Windowsプラットフォームでは、そのファイルを<Windows-directory>
\Sun\Java\Deployment
ディレクトリ(c:\Windows\Sun\Java\Deployment
など)にインストールします。
SolarisおよびLinuxプラットフォームでは、そのファイルを/etc/.java/deployment
ディレクトリにインストールします。
macOSプラットフォームでは、そのファイルを/Library/Application Support/Oracle/Java/Deployment/
ディレクトリにインストールします。
一度にアクティブにできるデプロイメント・ルール・セットは1つのみです。アクティブなルール・セットはJavaコントロール・パネルから表示できます。
アクティブなルール・セットを表示するには、次の手順を実行します。
デプロイメント・ルール・セット機能を使用すると、ユーザーに潜在的なセキュリティ・リスクを通知せずにRIAを実行できます。次のセキュリティ上の考慮事項を確認して、ルール・セットの使用に伴うリスクを認識し、提示されるすべての推奨事項に従ってください。
id
要素のlocation
属性は、次の情報と比較されます。
HTMLファイルの場所(JNLPを使用しないアプレットの場合)
JNLPファイルのhref
属性の値(JNLPを使用するJava Web Startアプリケーションおよびアプレットの場合)
アプレット・タグのjnlp_href
パラメータの値(JNLPを使用するアプレットおよびJNLPファイルでhref
属性を指定しない場合)
一致した場合は、HTMLファイルまたはJNLPファイル内のすべてのコンテンツが信頼できるものと見なされます。ただし、そのファイルをホストするWebサイトがクロスサイト・スクリプティング攻撃に脆弱である場合は、悪意のあるコンテンツがHTMLファイルやJNLPファイルに注入される可能性があります。
JNLPを使用するアプレットの場合、HTMLファイルの場所がチェックされないため、アプレットがどこからでも起動される可能性があります。
ルールをRIAと一致させるためにlocation
属性を使用しない場合は、RIAの起動に使用されるHTMLファイルまたはJNLPファイルが損なわれる可能性があります。location
属性を使用することをお薦めします。
サーバー全体を信頼する場合、実行のアクションを含むルールのlocation
属性でのパスのみを含めます。サーバー上の他の場所が信頼されない可能性がある場合、実行ルールでパスを使用すると、セキュリティ・リスクが発生することがあり、お薦めしません。
location
属性にパスが含まれる場合は、可能であれば、複雑なパスやマルチバイト文字の使用を避けてください。パスは大文字と小文字が区別され、UTF-8エンコーディングが使用されるものとします。サポートされていない文字、デコード・エラー、または長すぎるエンコーディングが検出されると、セキュリティ例外が発生します。Webサーバー、ファイル・システム、またはブラウザがそのパスを別々に正規化した場合は、location
属性に基づいたルールが予期しない結果を返す可能性があります。
特定のURIのブロッキング・ルールは、堅牢なセキュリティ施行メカニズムになるよう意図されていません。たとえば、ドメイン名を使って作成されたルールは、ユーザーが代わりにIPアドレスを使用すればパイパスできます。識別子が1つもなく、ブロックというアクションを持つ最終ルールをルール・セットに含めることが推奨されます。RIAをセキュリティ・プロンプトなしで実行するか、デフォルトの処理で実行するために必要なルールを定義し、ほかのすべてのRIAを最終ルールで一致させることで、それらの実行をブロックします。
すべての場所に対してHTTPSプロトコルを使用することをお薦めします。
デプロイメント・ルール・セット内のルールの順序は、きわめて重要な意味を持ちます。ルールは、ファイルの先頭から順次に処理されます。一致するものが見つかると、それ以上のルールは処理されません。最終ルール・セットを確認し、肯定的なケースと否定的なケースの両方に目を向けて、それらのルールが管理する予定のRIAをカバーし、不明なRIAとの一致を許可しないようにします。
複数のJARファイルやJNLP拡張など、RIAのすべてのアーティファクトにルールが必要です。アーティファクト用のルールを定義するときは、そのルールと一致するほかのRIAの実行を間違って許可しないように注意してください。
デプロイメント・ルールでは、互換性を確保する必要がある場合にRIAが古いバージョンのJREで実行されることを許可しますが、古いバージョンにはセキュリティに関する既知の問題が含まれている可能性があります。可能なかぎり最新のJREを使用し、version
属性をSECURE
またはSECURE-version
に設定します。古いバージョンのJREを使用する必要がある場合は、古いバージョンを要求するルールをできるだけ限定的なものにすることで、そのルールと一致し、古いバージョンで実行されるRIAを制限してください。この場合は、識別子location、title、およびcertificate hashをすべて使用することをお薦めします。
run
というアクションを持つルールがRIA用に存在する場合、そのRIAは、RIAの署名に使われた証明書の有効期限が切れている場合でも実行されます。
デプロイメント・ルールを使用してアプリケーションの実行をブロックまたは許可する方法を示すために、サンプル・デプロイメント・ルール・セットが提供されています。
例10-1 単一の場所からのRIAの実行
この例では、https://host.example.com/
からのすべてのRIAがセキュリティ・プロンプトなしで実行されることを許可します。ほかの場所からのRIAはそのルールと一致しないため、デフォルトの処理が使用され、該当する場合はセキュリティ・プロンプトが表示されます。
<ruleset version="1.0+"> <rule> <id location="https://host.example.com" /> <action permission="run" /> </rule> </ruleset>
例10-2 一致しないすべてのRIAのブロック
ルール・セットによってすべてのRIAが確実に処理されるように、前のルールで一致しなかったすべてのRIAと一致する最終ルールを指定できます。このルールのアクションは、block
またはdefault
のどちらかにする必要があります。この例では、https://host.example.com:8080
からのすべてのRIAがセキュリティ・プロンプトなしで実行されることを許可し、他のすべてのRIAをブロックします。カスタム・メッセージは指定されないため、RIAがブロックされると、デフォルトのメッセージが表示されます。
<ruleset version="1.0+"> <rule> <id location="https://host.example.com:8080" /> <action permission="run" /> </rule> <rule> <id /> <action permission="block" /> </rule> </ruleset>
例10-3 ルールの順序は重要
ルールは、それらがルール・セットに表示される順序で処理されます。一致ルールに複雑なパターンを定義するには、それらのルールを正しい順序で並べます。この例では、https://host.example.com
からのRIAには、セキュアなバージョンのJava 1.7プラットフォームを使用してセキュリティ・プロンプトなしで実行されることを許可しますが、https://host.example.com/games
からのRIAには、適用可能なセキュリティ・プロンプトが表示されるデフォルトの処理を使用します。ほかの場所からのRIAはどちらのルールとも一致しないため、デフォルトの処理が使用されます。
<ruleset version="1.0+"> <rule> <id location="https://host.example.com/games" /> <action permission="default" /> </rule> <rule> <id location="https://host.example.com" /> <action permission="run" version="SECURE-1.7" /> </rule> </ruleset>
例10-4 特定のRIAの管理
この例では、例10-3のルール・セットを変更し、デフォルトの処理で実行するにはhttps://host.example.com/games
からのSolitaireという名前のRIAのみを必要とします。https://host.example.com
からのほかのRIAは、セキュアなバージョンのJava 1.7プラットフォームを使用してセキュリティ・プロンプトなしで実行されることが許可されます。ほかのすべてのRIAはブロックされ、カスタム・メッセージが表示されます。
<ruleset version="1.0+"> <rule> <id title="Solitaire" location="https://host.example.com/games" /> <action permission="default" /> </rule> <rule> <id location="https://host.example.com" /> <action permission="run" version="SECURE-1.7" /> </rule> <rule> <id /> <action permission="block"> <message>Blocked by corporate. Contact J. Smith, smith@host.example.com, if you need to run this app.</message> </action> </rule> </ruleset>
例10-5 署名証明書に基づいたRIAの管理
複数の場所からの複数のRIAの実行を許可し、すべてのRIAが同じ証明書で署名されるようにするには、場所とタイトルごとにルールを作成するかわりに、certificate
要素を使用して1つのルールでそれらのRIAを識別できます。この例では、Oracleが使用する証明書で署名されているすべてのRIAが、セキュアなバージョンのJavaプラットフォームを使用してセキュリティ・プロンプトなしで実行されることを許可します。example.com
で終わるホストからのRIAは、デフォルトの処理で実行されることが許可されます。ほかのすべてのRIAはブロックされ、カスタム・メッセージが表示されます。
<ruleset version="1.0+"> <rule> <!-- allow anything signed with company's public cert --> <id> <certificate hash="794F53C746E2AA77D84B843BE942CAB4309F258FD946D62A6C4CCEAB8E1DB2C6" /> </id> <action permission="run" version="SECURE" /> </rule> <rule> <id location="*.example.com" /> <action permission="default" /> </rule> <rule> <id /> <action permission="block"> <message>Blocked by corporate. Contact J. Smith, smith@host.example.com, if you need to run this app.</message> </action> </rule> </ruleset>
例10-6 特定のJREの使用を強制
特定のJREを強制的に使用するには、action
要素のforce
属性を使用します。この属性は、デプロイメント・ルール・セットの1.1バージョンで導入されました。この例では、https://host.example.com/apps
からのRIAがバージョン1.8_20のJREを使用してセキュリティ・プロンプトなしで実行されることを許可します。RIAによって要求されたバージョンは無視されます。バージョン1.8_20を使用できない場合、RIAはブロックされます。ほかのすべてのRIAはブロックされ、カスタム・メッセージが表示されます。
<ruleset version="1.1+"> <rule> <id location="https://host.example.com/apps" /> <action permission="run" version="1.8_20" force="true" /> </rule> <rule> <id /> <action permission="block"> <message>Blocked by corporate. Contact J. Smith, smith@host.example.com, if you need to run this app.</message> </action> </rule> </ruleset>
例10-7 ルール・セットに顧客データを含める
customer
要素を使用すると、コメント、デバッグ情報、またはルールおよびルール・セットに関するその他のデータを提供できます。デプロイメント・ルール・セット1.2以降では、この情報は、デプロイメント・トレース・ファイルおよびJavaコンソールが有効な場合はそれらに書き込まれます。この例は、ルール・セットおよび2つのルールに対する顧客情報を示しています。customer
要素で使用されているXML要素は説明のためのものであり、任意の有効なXMLを使用できます。
<ruleset version="1.2+"> <rule> <id location="https://host.example.com/verified-apps" /> <action permission="run" /> <customer>Allowing applications from https://host.example.com, which has been validated as a secure site</customer> </rule> <customer> <warning font=bold>Run rule not matched.</warning> <text>Application will either be blocked or will show security dialogs.</text> </customer> <rule> <id location="*.example.com" /> <action permission="default" /> </rule> <rule> <id /> <action permission="block"> <message>Blocked by corporate. Contact J. Smith, smith@host.example.com, if you need to run this app.</message> </action> <customer> <warning font=bold>Blocked</warning> <text>No rule matched, application blocked by final rule.</text> </customer> </rule> </ruleset>
次の例は、デプロイメント・ルール・セットのバージョン1.3のDTDを示しています。バージョン1.3は、8u72以上でサポートされています。バージョン1.2は、JRE 8u60以上でサポートされています。バージョン1.1は、JRE 8u20以上でサポートされています。バージョン1.0は、JRE 7u40以上でサポートされています。バージョン1.0の後で導入されたアイテムが記載されます。
<!ELEMENT ruleset (rule*, customer*)> <!ATTLIST ruleset version CDATA #REQUIRED> <!ELEMENT rule (id, action, customer*)> <!-- checksum introduced in 1.2, jnlp-checksum introduced in 1.3 --> <!ELEMENT id (certificate?, checksum?, jnlp-checksum*)> <!ATTLIST id title CDATA #IMPLIED> <!ATTLIST id location CDATA #IMPLIED> <!-- jnlp-checksum introduced in 1.3 --> <!ELEMENT jnlp-checksum EMPTY> <!ATTLIST jnlp-checksum hash CDATA #REQUIRED> <!ELEMENT certificate EMPTY> <!ATTLIST certificate algorithm CDATA #IMPLIED> <!ATTLIST certificate hash CDATA #REQUIRED> <!-- checksum introduced in 1.2 --> <!ELEMENT checksum EMPTY> <!ATTLIST checksum algorithm CDATA #IMPLIED> <!ATTLIST checksum hash CDATA #REQUIRED> <!ELEMENT action (message?)> <!ATTLIST action permission (run | block | default) #REQUIRED> <!ATTLIST action version CDATA #IMPLIED> <!ATTLIST action force (true|false) "false"> <!-- force introduced in 1.1 --> <!ELEMENT message (#PCDATA)> <!ATTLIST message locale CDATA #IMPLIED> <!ELEMENT customer ANY>