test

Sun GlassFish Enterprise Server v3 管理ガイド

パート II セキュリティー管理

第 11 章 システムセキュリティーの管理

ここでは、次のテーマを取り上げます。

これらのタスクの多くを 管理コンソール を使用して実行する場合の手順は、管理コンソール のオンラインヘルプで説明します。

セキュリティーの設定に関するその他の手順は、第 12 章ユーザーセキュリティーの管理および第 13 章メッセージセキュリティーの管理で説明します。

アプリケーションのセキュリティーについては、『Sun GlassFish Enterprise Server v3 Application Development Guide』の第 5 章「Securing Applications」で説明します。

Enterprise Server のシステムセキュリティーについて

セキュリティーとはデータを保護すること、つまり、記憶領域のデータまたは搬送中のデータに対する許可されていないアクセスや損傷を防ぐための方法です。Enterprise Server は Java セキュリティーモデルをベースに構築され、アプリケーションが安全に動作できるサンドボックスを使用するため、システムやユーザーにリスクが及ぶ可能性がありません。「システムセキュリティー」は、Enterprise Server 環境内のすべてのアプリケーションに影響します。

システムセキュリティーには次のような機能があります。

認証

「認証」とは、あるエンティティー (ユーザー、アプリケーション、またはコンポーネント) が、別のエンティティーが主張している本人であることを確認する方法です。エンティティーは、セキュリティー「資格」を使用して自らを認証します。資格には、ユーザー名、パスワード、デジタル証明書などが含まれます。通常、サーバーまたはアプリケーションはクライアントに自身を認証するように要求します。また、クライアントがサーバーに自身を認証するように要求する場合もあります。双方向で認証する場合は、これを「相互認証」と呼びます。

エンティティーが保護対象リソースにアクセスを試行する場合、Enterprise Server はそのリソースに対して設定されている認証メカニズムを使用してアクセスを認可するかどうかを決定します。たとえば、ユーザーが Web ブラウザでユーザー名およびパスワードを入力でき、アプリケーションがその資格を確認する場合、そのユーザーは認証されます。それ以降のセッションで、ユーザーはこの認証済みのセキュリティー ID に関連付けられます。

認証のタイプ

アプリケーションは、使用する認証のタイプを配備記述子内で指定します。Enterprise Server では、次のタイプの認証がサポートされます。

BASIC

サーバーに組み込まれているログインダイアログボックスを使用します。通信プロトコルは HTTP です (SSL を指定可能)。SSL を使用しなければ、ユーザー証明書は暗号化されません

FORM

アプリケーションが独自仕様のカスタムログインおよびエラーページを提供します。通信プロトコルは HTTP です (SSL を指定可能)。SSL を使用しなければ、ユーザー証明書は暗号化されません。

CLIENT-CERT

サーバーは公開鍵証明書を使用してクライアントを認証します。通信プロトコルは HTTPS (HTTP over SSL) です。ユーザー認定された暗号化は SSL です。

DIGEST

サーバーは、ユーザー名とパスワードに基づいてユーザーを認証します。認証はパスワードを暗号化された形式で送信することによって実行され、この暗号化形式は BASIC 認証で使用される単純な Base64 エンコーディングよりも安全です。通信プロトコルは HTTPS です。

パスワード

パスワードは、Enterprise Server のコンポーネントおよびデータへの許可されていないアクセスを防ぐもっとも重要な手段です。Enterprise Server でパスワードを使用する方法については、「パスワードの管理」を参照してください。

マスターパスワードとキーストア

「マスターパスワード」は、全体で共有されるパスワードで、システムでもっとも重要なデータです。これを認証に使用したり、ネットワークを介して送信したりすることは決してありません。マスターパスワードは要求されたときに手動で入力するか、ファイルに隠蔽化することができます。

マスターパスワードは、セキュリティー保護されたキーストアのパスワードです。新しいアプリケーションサーバードメインが作成されると、新しい自己署名付き証明書が生成されて、関連キーストアに格納されます。このキーストアは、マスターパスワード (デフォルトのパスワードは changeit) を使用してロックされます。マスターパスワードが変更済みで、デフォルト以外の値に設定されている場合は、マスターパスワードの入力を要求されます。正しいマスターパスワードを入力したあと、ドメインが起動します。

管理用パスワード

管理パスワードは、管理コンソールおよび asadmin ユーティリティーの呼び出しに使用されます。通常、このパスワードはインストール時に設定されますが、変更可能です。手順については、「管理パスワードを変更する」を参照してください。

符号化されたパスワード

符号化されたパスワードを含むファイルは、ファイルシステムのアクセス権を使用して保護する必要があります。これらのファイルには次のものが含まれます。

手順については、「パスワードをファイルから設定する」を参照してください。

パスワードエイリアス

パスワードをドメイン構成ファイルに平文で保存するのを避けるために、パスワードのエイリアスを作成できます。この処理は、パスワードの「暗号化」とも呼ばれます。詳細は、「パスワードエイリアスの管理」を参照してください。

シングルサインオン

「シングルサインオン」によって、1 つのアプリケーションにログインしたユーザーは、同じ認証情報が必要なほかのアプリケーションに暗黙的にログインするようになります。シングルサインオンはグループに基づいています。配備記述子が同じグループを定義し、かつ同じ認証方法 (BASIC、FORM、または CLIENT-CERT) を使用するすべての Web アプリケーションは、シングルサインオンを共有します。

Enterprise Server では、仮想サーバーのシングルサインオンがデフォルトで有効に設定されます。これにより、同じ仮想サーバー内の複数のアプリケーションが、ユーザーの認証状態を共有できます。

承認

「承認」は、アクセス制御とも呼ばれ、データにアクセスする許可または操作を実行する許可を、ユーザーに与えるための手段です。ユーザーが承認されたあと、ユーザーの承認のレベルにより、その所有者が実行できる操作の範囲が決定されます。ユーザーの承認は、ユーザーのロールに基づきます。

ロール

「ロール」は、ユーザーがアクセスできるアプリケーションおよび各アプリケーションの部分、およびこれらのユーザーまたはグループがアプリケーションで実行できる操作の内容を定義します。たとえば、人事アプリケーションの場合、すべての社員は電話番号とメールアドレスの情報を表示できますが、給与情報にアクセスできるのは管理職だけです。このアプリケーションでは、employee と manager の少なくとも 2 つのロールを定義しています。manager ロールのユーザーだけが、給与情報の表示を許可されています。

ロールはアプリケーション内での役割を定義するのに対し、グループはある方法で関連付けられているユーザーの集まりに過ぎません。この点で、ロールとグループは異なります。たとえば、人事アプリケーションで、full-time、part-time、および on-leave といったグループがあるとします。これらのグループのユーザーは、すべて社員 (employee ロール) です。これに加え、各ユーザーには追加の雇用レベルを定義する各自の役職が指定されます。

ロールは、アプリケーションの配備記述子内で定義されます。アプリケーションの開発者または配備担当者は、各アプリケーションの配備記述子で、ロールを 1 つまたは複数のグループにマッピングします。アプリケーションがパッケージ化されて配備される場合、次の図に例示されているように、アプリケーションはユーザーまたはグループとロールとの間のマッピングを指定します。

図 11–1 ロールマッピング

図は、ユーザーをグループに割り当てる方法、ユーザーやグループをロールに割り当てる方法、およびアプリケーションがグループやロールを使用する方法を示しています。

Java Authorization Contract for Containers

JACC (Java Authorization Contract for Containers) は Java EE 仕様の一部で、プラグイン可能な承認プロバイダ用のインタフェースを定義します。これにより、認証を行うためにサードパーティー製のプラグインモジュールを設定できます。デフォルトで、Enterprise Server は JACC 仕様に準拠する単純なファイルベースの承認エンジンを提供します。サードパーティー製の JACC プロバイダを追加指定することもできます。

JACC プロバイダは JAAS (Java Authentication and Authorization Service) の API を使用します。JAAS によって、サービスが認証およびユーザーに対するアクセス制御を行うことが可能になります。JAAS は、標準 PAM (Pluggable Authentication Module) フレームワークの Java テクノロジバージョンを実装しています。

JSR 196 により、別のレイヤーでプラグインを開発できます。AuthConfigProvider や AuthConfigFactory などの、新しい認証メカニズムを設定する方法を変更するプラグインを定義できます。また、ServerAuthModule や ClientAuthModule などの、新しい認証メカニズムを定義することもできます。

監査

「監査」は、セキュリティー対策の効果を評価するために、セキュリティーに関するイベントを取得するための手段です。Enterprise Server は、監査モジュールを使用して、すべての認証と承認の決定に関する監査証跡を取得します。Enterprise Server は、デフォルトの監査モジュールのほか、監査モジュールのカスタマイズ機能も提供します。

管理の手順については、「監査モジュールの管理」を参照してください。

ファイアウォール

「ファイアウォール」は、2 つ以上のネットワーク間のデータフローを制御し、ネットワーク間のリンクを管理します。ファイアウォールは、ハードウェア要素およびソフトウェア要素で構成できます。Enterprise Server では、主に次のようなガイドラインが適しています。

証明書と SSL

ここでは、次のテーマを取り上げます。

管理の手順については、「JSSE 証明書の管理 」を参照してください。

証明書

「証明書」 (または、デジタル証明書) は、インターネット上の人物やリソースを一意に識別する電子ファイルです。さらに証明書は 2 つのエンティティー間の安全で機密保護された通信を可能にします。証明書にはさまざまな種類があります。

証明書は「公開鍵暗号化」に基づき、意図した受信者だけが情報を解読できるように、デジタルの鍵 (非常に長い数値) のペアを使用して暗号化または符号化します。そして受信者は、情報を「復号化」して解読します。「鍵のペア」には公開鍵と非公開鍵が含まれます。所有者は公開鍵を配布して、だれでも利用できるようにします。しかし、所有者は非公開鍵を決して配布せず、常時秘密にしておきます。鍵は数学的に関連付けられているので、一方の鍵で暗号化されたデータは、そのペアのもう一方の鍵でしか復号化することができません。

証明書は、「証明書発行局」(CA) と呼ばれる、信頼できるサードパーティーが発行します。CA はパスポートセンターに似ています。CA は、証明書の所有者の身元を確認したあと、偽造や改ざんができないように証明書に署名します。CA が証明書に署名したあと、所有者は ID の証明としてこれを提出することで、暗号化され、機密保護された通信を確立できます。もっとも重要な点は、証明書によって所有者の公開鍵が所有者の ID と結び付けられることです。

公開鍵のほかに、通常、証明書には次のような情報が含まれています。

証明書は、X.509 形式の技術仕様で管理されます。certificate レルムのユーザー ID を検証するために、 certificate 認証サービスは X.509 証明書の共通名フィールドを主体名として使用して、X.509 証明書を検証します。

証明書チェーン

「証明書チェーン」とは、最後がルート CA 証明書で終わる、継続的な CA によって発行される一連の証明書です。

Web ブラウザは、ブラウザが自動的に信頼する一連の「ルート」CA 証明書で事前に設定されます。別の場所で発行されたすべての証明書は、有効性を検証するために「証明書チェーン」を備えている必要があります。

証明書が最初に生成される場合、それは「自己署名付き」証明書です。自己署名付き証明書とは、発行者 (署名者) が被認証者 (公開鍵が証明書で認証されているエンティティー) と同じものです。所有者は、証明書の署名要求 (CSR) を CA に送信するとき、その応答をインポートし、自己署名付き証明書が証明書のチェーンによって置き換えられます。チェーンの元の部分には、被認証者の公開鍵を認証する CA によって発行された証明書 (応答) があります。このチェーンの次の証明書は、CA の公開鍵を認証するものです。通常、これは自己署名付き証明書 (つまり、自らの公開鍵を認証する CA からの証明書) およびチェーンの最後の証明書です。

CA が証明書のチェーンに戻ることができる場合もあります。この場合、チェーンの元の証明書は同じ (キーエントリの公開鍵を認証する、CA によって署名された証明書) ですが、チェーン 2 番目の証明書が、CSR の送信先の CA の公開鍵を認証する、異なる CA によって署名された証明書です。そして、チェーンのその次の証明書は 2 番目の鍵を認証する証明書というように、自己署名付き「ルート」証明書に到達するまで続きます。こうして、チェーンの最初以降の各証明書は、チェーンの前にある証明書の署名者の公開鍵を認証します。

証明書ファイル

Enterprise Server のインストール中に、証明書が内部テストに適した JSSE (Java Secure Socket Extension) 形式で生成されます。デフォルトでは、Enterprise Server は証明書情報を domain-dir/config ディレクトリの証明書データベースに格納します。

キーストアファイル

key3.db ファイルには、非公開鍵を含む Enterprise Server の証明書が格納されます。キーストアファイルはパスワードで保護されています。

各キーストアエントリには一意のエイリアスがあります。インストール後の Enterprise Server のキーストアには、s1as のエイリアスを持つ 1 つのエントリが含まれています。

トラストストアファイル

cert8.db ファイルには、ほかのエンティティーの公開鍵を含む、Enterprise Server の信頼できる証明書が格納されます。信頼できる証明書では、サーバーは証明書の公開鍵が証明書の所有者に属していることを確認しています。通常、信頼できる証明書には CA の証明書も含まれています。

デフォルトでは、Enterprise Server は、サンプルアプリケーションで開発目的のために動作するキーストアおよびトラストストアを使用して設定されています。

Secure Sockets Layer

「SSL」(Secure Sockets Layer) とは、インターネットの通信およびトランザクションのセキュリティー保護でもっとも普及している標準仕様です。セキュリティー保護された Web アプリケーションは HTTPS (HTTP over SSL) を使用します。HTTPS プロトコルは証明書を使用して、サーバーとクライアント間のセキュリティー保護された機密通信を保証します。SSL 接続では、クライアントとサーバーの両方が送信の前にデータを暗号化します。データは受信時に復号化されます。

クライアントの Web ブラウザがセキュリティー保護されたサイトに接続するときに、次のように「SSL ハンドシェーク」が行われます。

  1. ブラウザはネットワークを介してセキュアなセッションを要求するメッセージを送信します。通常は、http ではなく https で始まる URL を要求します。

  2. サーバーは、公開鍵を含む証明書を送信することで応答します。

  3. ブラウザは、サーバーの証明書が有効であること、またサーバーの証明書が証明書をブラウザのデータベースに持つ信頼されている CA によって署名されていることを検証します。さらに、CA の証明書の有効期限が切れていないことも検証します。

  4. 証明書が有効な場合、ブラウザは 1 回かぎりの一意の「セッション鍵」を生成し、サーバーの公開鍵でそれを暗号化します。そして、ブラウザは暗号化されたセッション鍵をサーバーに送信し、両方でコピーを持てるようにします。

  5. サーバーは、非公開鍵を使用してメッセージを復号化し、セッション鍵を復元します。

ハンドシェークの後、クライアントは Web サイトの ID を検証し、クライアントと Web サーバーだけがセッション鍵のコピーを持ちます。これ以降、クライアントとサーバーはセッション鍵を使用して互いにすべての通信を暗号化します。こうすると、通信は確実にセキュアになります。

SSL 標準の最新バージョンは TLS (Transport Layer Security) と呼ばれています。Enterprise Server は、SSL 3.0 および TLS 1.0 の暗号化プロトコルをサポートしています。

SSL を使用するには、セキュリティー保護された接続を受け付ける外部インタフェースまたは IP アドレスごとに、Enterprise Server が証明書を所持しておく必要があります。ほとんどの Web サーバーの HTTPS サービスは、証明書がインストールされるまで実行されません。HTTP リスナーに SSL を適用する手順については、「SSL の HTTP リスナーを構成する」を参照してください。

暗号化方式

「暗号化方式」とは、暗号化と復号化に使用される暗号化アルゴリズムです。SSL および TLS プロトコルは、サーバーとクライアントでお互いを認証するために使用される多くの暗号化方式のサポート、証明書の送信、およびセッション鍵の確立を行います。

安全度は、暗号化方式によって異なります。クライアントとサーバーは異なる暗号化方式群をサポートできます。クライアントとサーバーは安全な接続のために、双方で通信に使用可能なもっとも強力な暗号化方式を使用します。したがって、通常はすべての暗号化方式を有効にすれば十分です。

名前ベースの仮想ホスト

セキュアなアプリケーションに名前ベースの仮想ホストを使用すると、問題が発生する場合があります。これは、SSL プロトコル自体の設計上の制約です。クライアントブラウザがサーバーの証明書を受け付ける SSL ハンドシェークは、HTTP 要求がアクセスされる前に行われる必要があります。その結果、認証より前に仮想ホスト名を含む要求情報を特定できないので、複数の証明書を単一の IP アドレスに割り当てできません。

単一の IP すべての仮想ホストが同じ証明書に対して認証を必要とする場合、複数の仮想ホストを追加しても、サーバーの通常の SSL 動作を妨害する可能性はありません。ただし、証明書 (主に正式な CA の署名済みの証明書が該当) に表示されているドメイン名がある場合、ほとんどのブラウザがサーバーのドメイン名をこのドメイン名と比較することに注意してください。ドメイン名が一致しない場合、これらのブラウザは警告を表示します。一般的には、アドレスベースの仮想ホストだけが本稼働環境の SSL で広く使用されています。

システムセキュリティー管理用ツール

Enterprise Server には、次のシステムセキュリティー管理用ツールがあります。

管理コンソール

管理コンソール は、サーバー全体のセキュリティーを設定するための、ブラウザベースのユーティリティーです。証明書、ユーザー、グループ、およびレルムの管理や、システム全体に関するその他のセキュリティータスクの実行に使用します。管理コンソール の概要については、「管理コンソール」を参照してください。

asadmin ユーティリティー

asadmin コマンド行ユーティリティーでは、管理コンソール と同じ多数のタスク 実行できます。管理コンソール では実行できない操作を、asadmin ユーティリティーで実行できる場合もあります。asadmin の概要については、「asadmin ユーティリティー」を参照してください。

keytool ユーティリティー

keytool Java 2 Platform, Standard Edition (J2SE) コマンド行ユーティリティーは、デジタル証明書および鍵のペアを管理するために使用します。詳細は、「JSSE 証明書の管理 」を参照してください。

policytool ユーティリティー

policytool J2SE グラフィカルユーティリティーは、システム全体の Java セキュリティーポリシーを管理するために使用します。管理者が policytool を使用することはほとんどありません。

keytool、policytool、およびその他の Java セキュリティーツールの使用方法については、http://java.sun.com/j2se/1.4.2/docs/tooldocs/tools.html#security の『Java 2 SDK Tools and Utilities』を参照してください。

パスワードの管理

パスワードの管理には複数の方法があります。各管理者には、パスワードを秘密にして定期的に変更するように指示します。ユーザーにコマンドを入力させず、asadmin のサブコマンドがパスワードを格納したファイルにアクセスできるように、これらのファイルを設定することができます。domain.xml ファイルで重要なパスワードが表示されないように、エイリアスを設定してパスワードを暗号化することができます。

ここでは、次のテーマを取り上げます。

Procedureマスターパスワードを変更する

マスターパスワードは、ドメインで使用される暗号化ストア (NSS cert8.db トラストストアまたは Java JKS キーストア) へのアクセスを許可します。このパスワードは、UNIX ユーザーに結び付けられません。この全体で共有されるパスワードは、システムでもっとも重要なデータです。マスターパスワードを認証に使用したり、ネットワークを介して送信したりすることは決してありません。

パスワードを要求されたときに手動で入力するか、パスワードファイルに隠蔽化することができます。パスワードファイルがない場合は、マスターパスワードの入力を要求されます。パスワードファイルがある場合に、入力を必要とするようにアクセスを変更する場合は、ファイルを削除します。デフォルトのマスターパスワードは changeit です。

change-master-password サブコマンドをローカルモードで使用して、マスターパスワードを変更します。

マスターパスワードを変更すると、マスターパスワードキーストアにパスワードが再保存されます。これは、Java JCEKS タイプのキーストアです。

始める前に

ドメインが停止していない場合、このサブコマンドは機能しません。

  1. パスワードを変更するドメインを停止します。

    「ドメインの停止」を参照してください。

  2. change-master-password(1) サブコマンドを使用して、ドメインのマスターパスワードを変更します。

    旧パスワードと新しいパスワードの入力を要求されます。依存しているすべての項目が再暗号化されます。

  3. ドメインを起動します。

    「ドメインの起動」を参照してください。

例 11–1 マスターパスワードの変更

change-master-password サブコマンドは対話形式で動作し、旧マスターパスワードと新しいマスターパスワードの入力を要求します。この例では、domain44ps のマスターパスワードを変更します。


asadmin> change-master-password domain44ps

login(1) サブコマンドを使用してすでにドメインにログインしている場合は、新しいマスターパスワードの入力を要求されます。


Please enter the new master password>
Please enter the new master password again>

ドメインにログインしていない場合は、旧マスターパスワードと新しいマスターパスワードの両方の入力を要求されます。


Please enter the master password again>
Please enter the new master password>
Please enter the new master password again>

次のような情報が表示されます。

Master password changed for domain44ps
参照

コマンド行に asadmin help change-master-password と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

Procedure管理パスワードを変更する

管理パスワードを変更するには、リモートモードで change-admin-password サブコマンドを使用します。デフォルトの管理パスワードは admin です。確認のために、旧パスワードと新しいパスワードの入力を要求されます。

注 –

ZIP インストール中に、パスワードが設定されていないデフォルトの admin ユーザーを受け入れている場合は、このユーザーにパスワードを追加できます。パスワードが設定されていない admin というユーザーしか存在しない場合は、ログイン情報を要求されません。その他の状況ではログインが必要です。

管理パスワードの暗号化は強く推奨されています。

始める前に

パスワードのエイリアスを作成する (暗号化する) 前に管理パスワードを変更する場合は、set サブコマンドを使用できます。次に例を示します。


asadmin set --user admin server.jms-service.jms-host.default_JMS_host.admin-password=
new_pwd

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. change-admin-password(1) サブコマンドを使用して、管理パスワードを変更します。

  3. 要求に従って、旧管理パスワードと新しい管理パスワードを入力します。

例 11–2 管理パスワードの変更

この例では、ユーザー anonymous の管理パスワードを、adminadmin から newadmin に変更します。


asadmin> change-admin-password --user anonymous

旧管理パスワードと新しい管理パスワードの入力を要求されます。


Enter admin password>adminadmin
Enter new admin password>newadmin
Enter new admin password again>newadmin

次のような情報が表示されます。


Command change-admin-password executed successfully.
参照

コマンド行に asadmin help change-admin-password と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

Procedureパスワードをファイルから設定する

コマンド行にパスワードを入力する代わりに、passwords.txt などのファイルからコマンドのパスワードにアクセスできます。asadmin ユーティリティーの --passwordfile オプションは、パスワードを含むファイルの名前を受け取ります。ファイル内のパスワードのエントリには、パスワード名の前に AS_ADMIN_ というプレフィックス (大文字) を付ける必要があります。

次のタイプのパスワードも指定できます。 


AS_ADMIN_MASTERPASSWORD
AS_ADMIN_USERPASSWORD
AS_ADMIN_ALIASPASSWORD

  1. パスワードファイルを編集します。

    たとえば、ドメイン管理サーバー (DAS) のパスワードを指定するには、パスワードファイルに次のようなエントリを追加します。adminadmin は管理者パスワードです。

    AS_ADMIN_PASSWORD=adminadmin

  2. パスワードファイルを保存します。

    これで、asadmin サブコマンドにパスワードファイルを指定できるようになりました。この例では、passwords.txt がパスワードを含むファイルです。


    asadmin>delete-jdbc-resource --user admin --password passwords.txt jdbc/DerbyPool
注意事項

AS_ADMIN_PASSWORD がグローバル環境にエクスポートされている場合、--passwordfile オプションを指定すると、--passwordfile オプションの使用に関する警告が表示されます。この警告が生成されないようにするには、AS_ADMIN_PASSWORD を設定解除します。

パスワードエイリアスの管理

パスワードエイリアスは、パスワード自体が構成ファイルに現れないように、パスワードに間接的にアクセスするために使用します。

ここでは、次のテーマを取り上げます。

Procedureパスワードエイリアスを作成する

パスワードのエイリアスをドメインのキーストアに作成するには、リモートモードで create-password-alias サブコマンドを使用します。エイリアス名に対応するパスワードは、ドメイン構成ファイルに暗号化された形式で保存されます。create-password-alias サブコマンドの形式には、ユーザーにすべての情報を要求するセキュリティー保護された対話形式と、パスワードがコマンド行で伝達されるスクリプトに適した形式があります。

set(1) サブコマンドを使用して、構成ファイル中のパスワードを削除および置換することもできます。次に例を示します。


asadmin set --user admin server.jms-service.jms-host.default_JMS_host.
admin-password='${ALIAS=jms-password}'

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. 構成ファイルが保存されているディレクトリに移動します。

    デフォルトでは、構成ファイルは domain-dir /config に保存されています。

  3. create-password-alias(1) サブコマンドを使用して、パスワードエイリアスを作成します。

  4. 要求に応じて、エイリアスのパスワードを入力します。

  5. エイリアスをパスワードファイルに追加します。

    パスワードファイル (たとえば、passwords.txt) に、AS_ADMIN_PASSWORD=${ALIAS=admin-password-alias} という行を追加します。admin-password-alias は新しいパスワードエイリアスです。

  6. Enterprise Server ドメインを停止します。

    「ドメインの停止」を参照してください。

  7. エイリアスを含むファイルを指定して、ドメインを起動します。

    次に例を示します。


    asadmin start-domain --user admin --passwordfile /path-to/passwords.txt domain1
例 11–3 パスワードエイリアスの作成

この例では、admin ユーザーの新しい jms-password エイリアスを作成します。


asadmin> create-password-alias --user admin jms-password

エイリアスのパスワードを入力するように要求されます。


Please enter the alias password>secret-password
Please enter the alias password again>secret-password
Command create-password-alias executed successfully.
参照

コマンド行に asadmin help create-password-alias と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

Procedureパスワードエイリアスを一覧表示する

既存のパスワードエイリアスを一覧表示するには、リモートモードで list-password-aliases サブコマンドを使用します。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. list-password-aliases(1) サブコマンドを使用して、パスワードエイリアスを一覧表示します。

例 11–4 パスワードエイリアスの一覧表示

この例では、既存のパスワードエイリアスを一覧表示します。


asadmin> list-password aliases
jmspassword-alias
Command list-password-aliases executed successfully
参照

コマンド行に asadmin help list-password-aliases と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

Procedureパスワードエイリアスを削除する

既存のパスワードエイリアスを削除するには、リモートモードで delete-password-alias サブコマンドを使用します。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. list-password-aliases(1) サブコマンドを使用して、エイリアスをすべて表示します。

  3. list-password-aliases(1) サブコマンドを使用して、パスワードエイリアスを削除します。

例 11–5 パスワードエイリアスの削除

この例では、パスワードエイリアス jmspassword-alias を削除します。


asadmin> delete-password-alias jmspassword-alias
Command list-password-aliases executed successfully
参照

コマンド行に asadmin help delete-password-alias と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

Procedureパスワードエイリアスを更新する

既存のパスワードエイリアスのパスワードを変更するには、リモートモードで update-password-alias サブコマンドを使用します。update-password-alias サブコマンドでは、セキュリティー保護された対話形式 (ユーザーがすべての情報の入力を求められる) と、スクリプトの処理しやすい形式 (パスワードがコマンド行で伝達される) の両方を使用できます。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. update-password-alias(1) サブコマンドを使用して、エイリアスを更新します。

  3. 要求に応じて、パスワードを入力します。

例 11–6 パスワードエイリアスの更新

この例では、jmspassword-alias エイリアスのパスワードを更新します。


asadmin> update-password-allias /home/password.txt jsmpassword-alias

エイリアスの新しいパスワードを入力するように要求されます。


Please enter the alias password>new-secret-password
Please enter the alias password again>new-secret-password
Command update-password-alias executed successfully
参照

コマンド行に asadmin help update-password-alias と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

監査モジュールの管理

ここでは、次のテーマを取り上げます。

Procedure監査モジュールを作成する

監査機能を実装するアドオンコンポーネントの監査モジュールを作成するには、リモートモードで create-audit-module サブコマンドを使用します。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. create-audit-module(1) サブコマンドを使用して、監査モジュールを作成します。

    このサブコマンドのプロパティーについては、このマニュアルページに記載されています。

例 11–7 監査モジュールの作成

この例では、sampleAuditModule という名前の監査モジュールを作成します。


asadmin> create-audit-module 
--classname com.sun.appserv.auditmodule --property defaultuser=
admin:Password=admin sampleAuditModule
Command create-audit-module executed successfully.
参照

コマンド行に asadmin help create-audit-module と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

Procedure監査モジュールを一覧表示する

次のいずれか対象の監査モジュールを一覧表示するには、リモートモードで list-audit-modules サブコマンドを使用します。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. list-audit-modules(1) サブコマンドを使用して、監査モジュールを一覧表示します。

例 11–8 監査モジュールの一覧表示

この例では、localhost 上の監査モジュールを一覧表示します。


asadmin> list-audit-modules
audit-module : default
audit-module : sampleAuditModule
Command list-audit-modules executed successfully.
参照

コマンド行に asadmin help list-audit-modules と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

Procedure監査モジュールを削除する

既存の監査モジュールを削除するには、リモートモードで delete-audit-module サブコマンドを使用します。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. list-audit-modules(1) サブコマンドを使用して、監査モジュールを一覧表示します。

  3. delete-audit-module(1) サブコマンドを使用して、監査モジュールを削除します。

例 11–9 監査モジュールの削除

この例では、sampleAuditModule を削除します。


asadmin> delete-audit-module sampleAuditModule
Command delete-audit-module executed successfully.

JSSE 証明書の管理

開発者プロファイルでは、Enterprise Server v3 はサーバー側で JSSE 形式を使用して証明書とキーストアを管理します。すべてのプロファイルで、クライアント側 (アプリケーションクライアントまたはスタンドアロン) は JSSE 形式を使用します。

J2SE SDK には JSSE (Java Secure Socket Extension) デジタル証明書を設定および操作することができる keytool ユーティリティーが付属しています。公開鍵と非公開鍵のペアおよび関連する証明書を管理し、通信しているピアの公開鍵を (証明書の形式で) キャッシュすることができます。

ここでは、次のテーマを取り上げます。

Procedurekeytool による証明書の生成

デフォルトでは、keytool ユーティリティーは実行元のディレクトリにキーストアファイルを作成します。

始める前に

keytool ユーティリティーを実行するには、シェル環境を設定して、J2SE の /bin ディレクトリがパスに含まれるようにする必要があります。そうでない場合は、ユーティリティーのフルパスをコマンド行に指定する必要があります。

  1. キーストアファイルおよびトラストストアファイルが格納されているディレクトリに移動します。

    証明書の生成は常に、キーストアファイルとトラストストアファイルが格納されているディレクトリ内で行います。デフォルトは、domain-dir/config です。

  2. 次のコマンド形式を使用して、キーストアファイル keystore.jks に証明書を生成します。


    keytool -genkey -alias keyAlias-keyalg RSA
 -keypass changeit
 -storepass changeit
keystore keystore.jks

    keyAlias には任意の一意名を指定します。キーストアまたは非公開鍵のパスワードをデフォルト (changeit) から変更している場合は、changeit を新しいパスワードで置き換えてください。デフォルトのキーパスワードエイリアスは s1as です。

    名前、組織、およびその他の情報を尋ねるプロンプトが表示されます。

  3. 次のコマンド形式を使用して、生成された証明書を server.cer ファイル (または、必要に応じて client.cer) にエクスポートします。


    keytool -export -alias keyAlias-storepass changeit
 -file server.cer
 -keystore keystore.jks

  4. 認証局によって署名された証明書が必要な場合は、「keytool を使用して証明書に署名する」を参照してください。

  5. 次のコマンド形式を使用して、cacerts.jks トラストストアファイルを作成し、証明書をトラストストアに追加します。


    keytool -import -v -trustcacerts
-alias keyAlias
 -file server.cer
-keystore cacerts.jks
 -keypass changeit

    キーストアまたは非公開鍵のパスワードをデフォルト (changeit) から変更している場合は、新しいパスワードで置き換えてください。

    証明書に関する情報が表示され、証明書を信頼するかどうかを確認するプロンプトが表示されます。

  6. yes と入力し、続いて Enter キーを押します。

    次のような情報が表示されます。


    Certificate was added to keystore
[Saving cacerts.jks]

  7. 変更内容を適用するために、Enterprise Server を再起動します。「ドメインの再起動」を参照してください。

例 11–10 RSA 鍵アルゴリズムを使用した JKS キーストアへの自己署名付き証明書の作成

RSA は RSA Data Security, Inc. によって開発された、公開鍵暗号化テクノロジです。


keytool  -genkey -noprompt -trustcacerts -keyalg RSA -alias ${cert.alias} 
-dname  ${dn.name} -keypass ${key.pass} -keystore ${keystore.file} 
-storepass ${keystore.pass}
例 11–11 デフォルトの鍵アルゴリズムを使用した JKS キーストアへの自己署名付き証明書の作成


keytool -genkey -noprompt -trustcacerts -alias ${cert.alias} -dname  
${dn.name} -keypass ${key.pass} -keystore ${keystore.file} -storepass 
${keystore.pass}
例 11–12 JKS キーストア内の使用可能な証明書の表示


keytool -list -v  -keystore ${keystore.file} -storepass ${keystore.pass}
例 11–13 JKS キーストア内の証明書情報の表示


keytool -list -v  -alias ${cert.alias} -keystore ${keystore.file} 
-storepass ${keystore.pass}
参照

keytool の詳細は、keytool のドキュメント (http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html) を参照してください。

Procedurekeytool を使用して証明書に署名する

証明書の作成後、所有者は証明書に署名して偽造を防止する必要があります。E コマースのサイト、または ID の認証が重要であるサイトは、既知の証明書発行局 (CA) から証明書を購入できます。

注 –

認証に心配がない場合 (たとえば、非公開の安全な通信だけが必要な場合) は、自己署名付き証明書を使用して、CA 証明書の取得に必要な時間と費用を節約することができます。

  1. CA の Web サイトの指示に従って、証明書の鍵のペアを生成します。

  2. 生成された証明書の鍵のペアをダウンロードします。

    キーストアファイルとトラストストアファイルが格納されているディレクトリに、証明書を保存します。デフォルトは、domain-dir/config です。

  3. 使用しているシェルで、証明書を含むディレクトリに変更します。

  4. 次のコマンド形式を使用して、証明書をローカルキーストアと、必要な場合はローカルトラストストアにインポートします。


    keytool -import -v -trustcacerts
-alias keyAlias
 -file server.cer
-keystore cacerts.jks
 -keypass changeit
-storepass changeit

    キーストアまたは非公開鍵のパスワードがデフォルト以外の値である場合は、デフォルトのパスワード (changeit) を新しいパスワードで置き換えてください。

  5. 変更内容を適用するために、Enterprise Server を再起動します。「ドメインの再起動」を参照してください。

例 11–14 RFC/テキスト形式の証明書の JKS キーストアへのインポート

証明書は、バイナリエンコーディングではなく、RFC (Internet Request for Comments) 1421 標準によって定義された印刷可能なエンコーディング形式を使って格納されることがしばしばあります。Base 64 エンコーディングとしても知られるこの証明書形式を使用すれば、電子メールなどの機構を使って証明書をほかのアプリケーションにエクスポートしやすくなります。


keytool -import -noprompt -trustcacerts -alias ${cert.alias} -file 
${cert.file} -keystore ${keystore.file} -storepass ${keystore.pass}
例 11–15 JKS キーストアからの PKCS7 形式による証明書のエクスポート

「Public Key Cryptography Standards #7, Cryptographic Message Syntax Standard」によって定義された応答形式には、発行される証明書に加え、それをサポートする証明書チェーンも含まれます。


keytool -export -noprompt -alias ${cert.alias} -file ${cert.file} 
-keystore ${keystore.file} -storepass ${keystore.pass}
例 11–16 JKS キーストアからの RFC/テキスト形式による証明書のエクスポート


keytool -export -noprompt -rfc -alias ${cert.alias} -file 
${cert.file} -keystore ${keystore.file} -storepass ${keystore.pass}
参照

keytool の詳細は、keytool のドキュメント (http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html) を参照してください。

Procedurekeytool を使用して証明書を削除する

keytool -delete コマンドを使用して、既存の証明書を削除します。

  1. 次のコマンド形式を使用して、証明書を削除します。

    keytool -delete
 -alias keyAlias
 -keystore keystore-name
 -storepass password
例 11–17 JKS キーストアからの証明書の削除


keytool -delete -noprompt -alias ${cert.alias}  -keystore ${keystore.file} 
-storepass ${keystore.pass}
参照

keytool の詳細は、keytool のドキュメント (http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html) を参照してください。

第 12 章 ユーザーセキュリティーの管理

この章では、asadmin コマンド行ユーティリティーを使用して、Sun GlassFishTM Enterprise Server 環境でユーザーセキュリティーを管理する手順について説明します。Enterprise Server は、レルム、ユーザー、およびグループに対して、認証と承認のポリシーを適用します。この章の説明では、認証、承認、証明書などのセキュリティー機能について理解していることを前提とします。これらのセキュリティー機能については、第 11 章システムセキュリティーの管理を参照してください。

ここでは、次のテーマを取り上げます。

これらのタスクを 管理コンソール を使用して実行する場合の手順は、管理コンソール のオンラインヘルプで説明します。

認証レルムの管理

「認証レルム」は、セキュリティーポリシードメインまたはセキュリティードメインとも呼ばれ、Enterprise Server によって共通のセキュリティーポリシーが定義および適用される範囲を表します。Enterprise Server は、ファイル、証明書、および管理のレルムで事前設定されます。これらに加え、LDAP、JDBC、ダイジェスト、Solaris、またはカスタムのレルムを設定できます。アプリケーションは使用するレルムを配備記述子で指定できます。アプリケーションでレルムが指定されていない場合、Enterprise Server はデフォルトのレルム (file) を使用します。

ファイルレルム

Enterprise Server は、ユーザー資格を keyfile という名前のファイルにローカルに格納します。ファイルレルムは、初期状態のデフォルトレルムです。

管理レルム

管理レルムはファイルレルムでもあり、管理者のユーザー資格を admin-keyfile という名前のファイルにローカルに格納します。

証明書レルム

Enterprise Server はユーザー資格を証明書データベースに格納します。証明書レルムを使用する場合、サーバーは HTTPS プロトコルで証明書を使用して Web クライアントを認証します。

LDAP レルム

Enterprise Server は、ユーザー資格を DirectoryServer などの LDAP (Lightweight Directory Access Protocol) サーバーから取得します。LDAP とは、一般のインターネットまたは会社のイントラネットのどちらであっても、ネットワークでの組織、個人、およびファイルやデバイスなどその他のリソースの検出をだれにでもできるようにするプロトコルです。LDAP レルムのユーザーとグループの管理については、LDAP サーバーのドキュメントを参照してください。

JDBC レルム

Enterprise Server はユーザー資格をデータベースから取得します。サーバーは、データベース情報と構成ファイル内の有効な JDBC レルムオプションを使用します。

ダイジェストレルム

ダイジェスト認証は、ユーザー名とパスワードに基づいてユーザーを認証します。ただし、認証はパスワードを暗号化された形式で送信することで実行されます。

Solaris レルム

Enterprise Server はユーザー資格を Solaris オペレーティングシステムから取得します。このレルムは、Solaris 9 および Solaris 10 オペレーティングシステムでサポートされます。Solaris レルムのユーザーおよびグループの管理については、Solaris のドキュメントを参照してください。

カスタムレルム

リレーショナルデータベースや他社のコンポーネントなど、その他のリポジトリを作成してユーザー資格に使用できます。カスタムレルムの詳細は、管理コンソール のオンラインヘルプを参照してください。カスタムレルムを作成する手順については、『Sun GlassFish Enterprise Server v3 Application Development Guide』の「Creating a Custom Realm」を参照してください。

Enterprise Server の認証サービスは、複数のレルムでユーザーを管理できます。

次のタスクと情報を使用して、認証レルムを管理します。

Procedure認証レルムを作成する

認証レルムを作成するには、リモートモードで create-auth-realm サブコマンドを使用します。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. create-auth-realm(1) サブコマンドを使用して、レルムを作成します。

    このサブコマンドのプロパティーについては、このマニュアルページに記載されています。

例 12–1 レルムの作成

この例では、db という名前のレルムを作成します。


asadmin> create-auth-realm --classname com.iplanet.ias.security.
auth.realm.DB.Database --property defaultuser=admin:Password=admin db
Command create-auth-realm executed successfully.
参照

コマンド行に asadmin help create-auth-realm と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

カスタムレルムの作成については、『Sun GlassFish Enterprise Server v3 Application Development Guide』の「Creating a Custom Realm」を参照してください。

Procedure認証レルムを一覧表示する

既存の認証レルムを一覧表示するには、リモートモードで list-auth-realms サブコマンドを使用します。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. list-auth-realms(1) サブコマンドを使用して、レルムを一覧表示します。

例 12–2 レルムの一覧表示

この例では、localhost 上の認証レルムを一覧表示します。


asadmin> list-auth-realms
db
certificate
file
admin-realm
Command list-auth-realms executed successfully.
参照

コマンド行に asadmin help list-auth-realms と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

Procedure認証レルムを更新する

set サブコマンドを使用して、既存の認証レルムを変更します。

注 –

カスタムレルムでは、サーバーの再起動は必要ありません。

  1. list-auth-realms(1) サブコマンドを使用して、レルムを一覧表示します。

  2. set(1) サブコマンドを使用して、指定したスレッドプールの値を変更します。

    スレッドプールはドット表記名で識別されます。

  3. 変更内容を適用するために、Enterprise Server を再起動します。

    「ドメインの再起動」を参照してください。

Procedure認証レルムを削除する

既存の認証レルムを削除するには、リモートモードで delete-auth-realm サブコマンドを使用します。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. list-auth-realms(1) サブコマンドを使用して、レルムを一覧表示します。

  3. 必要に応じて、レルムを削除することをユーザーに通知します。

  4. delete-auth-realm(1) サブコマンドを使用して、レルムを削除します。

  5. 変更内容を適用するために、Enterprise Server を再起動します。「ドメインの再起動」を参照してください。

例 12–3 レルムの削除

この例では、db という名前の認証レルムを削除します。


asadmin> delete-auth-realm db
Command delete-auth-realm executed successfully.
参照

コマンド行に asadmin help delete-auth-realm と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

ProcedureJDBC レルムまたはダイジェスト認証レルムを設定する

Enterprise Server では、接続プールの代わりに JDBC レルムにユーザー資格 (ユーザー名とパスワード) を指定できます。接続プールの代わりに jdbc タイプのレルムを使用すると、ほかのアプリケーションがユーザー資格のデータベース表を参照するのを防止できます。

注 –

JDBC レルムでは、デフォルトでは平文によるパスワードの保存はサポートされません。通常の状況では、パスワードを平文で保存しないでください。

  1. レルムのユーザー資格を格納するデータベース表を作成します。

    データベース表の作成方法は、使用しているデータベースによって異なります。

  2. 作成したデータベース表にユーザー資格を追加します。

    データベース表にユーザー資格を追加する方法は、使用しているデータベースによって異なります。

  3. データベースの JDBC 接続プールを作成します。

    「JDBC 接続プールを作成する」を参照してください。

  4. データベースの JDBC リソースを作成します。

    「JDBC リソースを作成する」

  5. レルムを作成します。

    手順については、「認証レルムを作成する」を参照してください。

    注 –

    JAAS コンテキストは、ダイジェスト認証では jdbcDigestRealm に、その他の認証タイプでは jdbcRealm になります。

  6. 配備記述子を変更して、jdbc レルムを指定します。

    アプリケーションに関連付けられている配備記述子を変更します。

    • Enterprise Archive (EAR) ファイルのエンタープライズアプリケーションの場合は、sun-application.xml ファイルを変更します。

    • Web Application Archive (WAR) ファイルの Web アプリケーションの場合は、web.xml ファイルを変更します。

    • EJB JAR ファイルのエンタープライズ Bean の場合は、sun-ejb-jar.xml ファイルを変更します。

    レルムの指定方法については、『Sun GlassFish Enterprise Server v3 Application Development Guide』の「How to Configure a Realm」を参照してください。

  7. レルム内のユーザーにセキュリティーロールを割り当てます。

    ユーザーにセキュリティーロールを割り当てるには、変更した配備記述子に security-role-mapping 要素を追加します。

  8. データベースが動作していることを確認します。

    必要に応じて、「データベースを起動する」を参照してください。

  9. 認証を適用するには、サーバーを再起動します。

    「ドメインの再起動」を参照してください。

例 12–4 セキュリティーロールの割り当て

この例では、セキュリティーロール Employee をユーザー Calvin に割り当てる security-role-mapping 要素を示します。

<security-role-mapping>
    <role-name>Employee</role-name>
    <principal-name>Calvin</principal-name>
  </security-role-mapping>

ファイルユーザーの管理

「ユーザー」は、Enterprise Server で定義される個人またはアプリケーションプログラムの ID です。認証されたユーザーを「主体」と呼ぶ場合もあります。

管理者には、ユーザーを Enterprise Server 環境に統合し、これらのユーザーの資格を安全に確立して、ユーザーが使用権限を持つアプリケーションおよびサービスにアクセスできるようにする責任があります。

次のタスクを使用してユーザーを管理します。

Procedureファイルユーザーを作成する

keyfile に新しいエントリを追加し、新規ユーザーを作成するには、リモートモードで create-file-user サブコマンドを使用します。エントリにはユーザー名、パスワード、およびユーザーのグループが含まれます。グループ名をコロン (:) で区切ることで、複数のグループを指定できます。

新しい file レルムユーザーの作成は動的なイベントであり、サーバーの再起動は必要ありません。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. ユーザーを特定のグループに所属させる場合は、list-file-groups(1) サブコマンドを使用して現在のグループを表示します。

  3. create-file-user(1) サブコマンドを使用して、ファイルユーザーを作成します。

例 12–5 ユーザーの作成

この例では、デフォルトレルムの file に Jennifer というユーザーを作成します。グループは指定しません。


asadmin> create-file-user --user admin 
--passwordfile=c:\tmp\asadminpassword.txt Jennifer
Command create-file-user executed successfully.
参照

コマンド行に asadmin help create-file-user と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

Procedureファイルユーザーを一覧表示する

keyfile 内のユーザーを一覧表示するには、リモートモードで list-file-users サブコマンドを使用します。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. list-file-users(1) サブコマンドを使用して、ユーザーを一覧表示します。

例 12–6 ファイルユーザーの一覧表示

この例では、デフォルトの file レルムファイルのファイルユーザーを一覧表示します。


asadmin> list-file-users
Jennifer
Command list-file-users executed successfully.
参照

コマンド行に asadmin help list-file-users と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

Procedureファイルグループを一覧表示する

「グループ」は、肩書きや顧客のプロファイルなどの共通の特性で分類されたユーザーのカテゴリです。たとえば、E コマースアプリケーションのユーザーは customer グループに属し、お得意様は preferred グループにも属します。ユーザーをグループに分類すると、大量のユーザーによるアクセスを容易に制御できます。グループはサーバーおよびレルム全体で定義されます。ユーザーは複数のユーザーグループに関連付けることができます。

ロールはアプリケーション内での役割を定義するのに対し、グループはある方法で関連付けられているユーザーの集まりに過ぎません。この点で、グループとロールは異なります。たとえば、人事アプリケーションで、full-time、part-time、および on-leave といったグループがあるとします。これらのグループのユーザーは、すべて社員 (employee ロール) です。これに加え、各ユーザーには追加の雇用レベルを定義する各自の役職が指定されます。

ファイルユーザーのグループを一覧表示するには、リモートモードで list-file-groups サブコマンドを使用します。--name オプションを指定しない場合は、ファイルグループがすべて表示されます。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. list-file-groups(1) サブコマンドを使用して、ファイルグループを一覧表示します。

例 12–7 ユーザーのグループの一覧表示

この例では、ユーザー joesmith のグループを一覧表示します。


asadmin> list-file-groups --name joesmith
staff
manager
Command list-file-groups executed successfully

Procedureファイルユーザーを更新する

指定したユーザーの keyfile の情報を変更するには、リモートモードで update-file-user サブコマンドを使用します。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. update-file-user(1) サブコマンドを使用して、ユーザー情報を更新します。

  3. 変更内容を適用するために、Enterprise Server を再起動します。

    「ドメインの再起動」を参照してください。

例 12–8 ユーザーの更新

次のサブコマンドは、ユーザー Jennifer のグループを更新します。


asadmin> update-file-user --passwordfile c:\tmp\asadminpassword.txt --groups 
staff:manager:engineer Jennifer
Command update-file-user executed successfully.
参照

コマンド行に asadmin help update-file-user と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

Procedureファイルユーザーを削除する

指定したユーザーのエントリを keyfile から削除するには、リモートモードで delete-file-user サブコマンドを使用します。自分自身を削除することはできません。つまり、ログインしているユーザーを、そのセッション中に削除することはできません。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. list-file-users(1) サブコマンドを使用して、ユーザーを一覧表示します。

  3. delete-file-user(1) サブコマンドを使用して、ユーザーを削除します。

例 12–9 ユーザーの削除

この例では、ユーザー Jennifer をデフォルトの file レルムから削除します。


asadmin> delete-file-user Jennifer
Command delete-file-user executed successfully.
参照

コマンド行に asadmin help delete-file-user と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

第 13 章 メッセージセキュリティーの管理

この章では、Sun GlassFishTM Enterprise Server 環境で、Web サービスのメッセージレイヤーセキュリティーを設定する際の情報と手順について説明します。

注 –

メッセージセキュリティー (JSR 196) は、Enterprise Server の Full Platform Profile のみでサポートされ、Web Profile ではサポートされません。

ここでは、次のテーマを取り上げます。

この章の一部の内容は、セキュリティーと Web サービスに関する基本概念の理解を前提としてます。セキュリティーの詳細は、「Enterprise Server のシステムセキュリティーについて」を参照してください。

本章で説明するタスクを 管理コンソール から実行する手順については、管理コンソール オンラインヘルプを参照してください。

Enterprise Server のメッセージセキュリティーについて

「メッセージセキュリティー」により、サーバーはメッセージレイヤーで Web サービスの呼び出しと応答をエンドツーエンドで認証できます。セキュリティー情報がメッセージ内に挿入され、その情報が完全なメッセージとともにネットワークレイヤー経由でメッセージの送信先に届けられます。メッセージセキュリティーはトランスポートレイヤーセキュリティーと異なり、メッセージの伝送と保護を分離できるため、メッセージは伝送後も保護されたままとなります。

Enterprise Server 上に配備された Web サービスをセキュリティー保護するには、アプリケーションの配備先コンテナ、またはそのアプリケーションがサービスを提供する Web サービスエンドポイントのいずれかに対し、SOAP レイヤーメッセージセキュリティープロバイダとメッセージ保護ポリシーをバインドします。Enterprise Server のクライアント側コンテナで SOAP レイヤーメッセージセキュリティー機能を設定するには、クライアントコンテナ、またはクライアントアプリケーションによって宣言されたポータブルサービス参照のいずれかに対し、SOAP レイヤーメッセージセキュリティープロバイダとメッセージ保護ポリシーをバインドします。

メッセージレベルのセキュリティーは、Enterprise Server 全体に対して、または特定のアプリケーションやメソッドに対して設定できます。アプリケーションレベルでのメッセージセキュリティーの設定については、『Sun GlassFish Enterprise Server v3 Application Development Guide 』を参照してください。

ここでは、次のテーマを取り上げます。

セキュリティートークンとセキュリティーメカニズム

WS-Security は、Web サービスにセキュリティーを適用するための通信プロトコルを提供する仕様です。セキュリティーメカニズムはこの仕様を実装します。WSIT (Web Services Interoperability Technologies) は、WS-Security を実装して、メッセージが送信先のエンドポイントに達するまでに中間ノードを通過する場合でも、相互運用可能なメッセージコンテンツの完全性と機密性を提供します。WSIT によって提供される WS-Security は、既存のトランスポートレベルのセキュリティーに付加され、トランスポートレベルのセキュリティーもそのまま使用できます。Enterprise Server とともにインストールされる SOAP (Simple Object Access Protocol) レイヤーメッセージセキュリティープロバイダを使用すると、ユーザー名とパスワードのセキュリティートークンおよび X.509 証明書セキュリティートークンを利用して、SOAP Web サービスメッセージを認証および暗号化することができます。

認証プロバイダ

「認証レイヤー」とは、認証処理を実行する必要のあるメッセージレイヤーです。Enterprise Server は、SOAP レイヤーで Web サービスメッセージセキュリティーを適用します。サポートされている認証には次のタイプが含まれます。

Enterprise Server は、「認証プロバイダ」を呼び出して SOAP メッセージレイヤーセキュリティーを処理します。メッセージセキュリティープロバイダは、要求メッセージおよび応答メッセージに必要な認証のタイプなどの情報を提供します。Enterprise Server には、次のメッセージセキュリティープロバイダが用意されています。

「デフォルトサーバープロバイダ」は、特定のサーバープロバイダがバインドされていない任意のアプリケーションに対して呼び出されるサーバー側プロバイダを識別するために使用されます。

メッセージ保護ポリシー

「要求ポリシー」は、認証プロバイダが実行する要求処理に関連付けられた認証ポリシー要件を定義します。ポリシーはメッセージ送信者による順序で示されるので、「コンテンツのあと」ではメッセージ受信者が署名の検証前にメッセージを復号化することを意味します。「応答ポリシー」は、認証プロバイダが実行する応答処理に関連付けられた認証ポリシー要件を定義します。

メッセージ保護ポリシーは、要求メッセージの処理および応答メッセージの処理に対して定義されます。ポリシーは、ソース認証または受信者認証に関する要件として表現されます。プロバイダは、特定のメッセージセキュリティーメカニズムを適用することで、SOAP Web サービスメッセージにおけるメッセージ保護ポリシーを実現します。

要求および応答メッセージ保護ポリシーは、セキュリティープロバイダがコンテナ内に設定されるときに定義されます。また、アプリケーションやアプリケーションクライアントの Sun 固有の配備記述子内で、アプリケーション固有のメッセージ保護ポリシー (Web サービスのポートまたは処理の範囲でのポリシー) を設定することも可能です。メッセージ保護ポリシーを定義する場合は常に、クライアントの要求と応答に対するメッセージ保護ポリシーが、サーバー側の要求と応答に対するメッセージ保護ポリシーと同じである必要があります。アプリケーション固有のメッセージ保護ポリシーの定義については、『Sun GlassFish Enterprise Server v3 Application Development Guide』の第 5 章「Securing Applications」を参照してください。

アプリケーション固有の Web サービスセキュリティー

アプリケーション固有の Web サービスセキュリティー機能を (アプリケーション構築上で) 設定するには、対象アプリケーションの Sun 固有の配備記述子内で message-security-binding 要素を定義します。これらの message-security-binding 要素は、特定のセキュリティープロバイダまたはメッセージ保護ポリシーを Web サービスエンドポイントまたはサービス参照に関連付けるために使用されます。また、この要素を修飾することで、それらのプロバイダやポリシーが対応するエンドポイントまたは参照サービスの特定のポートやメソッドに適用されるようにすることも可能です。

アプリケーション固有のメッセージ保護ポリシーの定義については、『Sun GlassFish Enterprise Server v3 Application Development Guide』の第 5 章「Securing Applications」を参照してください。

メッセージセキュリティーの管理

Enterprise Server のインストール時に、SOAP レイヤーメッセージセキュリティープロバイダが Enterprise Server のクライアント側コンテナとサーバー側コンテナ内に設定され、コンテナまたはコンテナ内に配備された個々のアプリケーションまたはクライアントからバインドして利用できるようになります。インストール中、デフォルトのプロバイダには単純なメッセージ保護ポリシーが設定されます。このポリシーをコンテナまたはコンテナ内のアプリケーションまたはクライアントにバインドした場合、すべての要求メッセージと応答メッセージに含まれるコンテンツのソースが、XML デジタル署名によって認証されるようになります。

Enterprise Server の管理インタフェースを使用して、次の操作を実行できます。

アプリケーションクライアントコンテナの SOAP メッセージレイヤーセキュリティー構成でも、これと同様の管理操作を実行できます。Enterprise Server に配備されたすべての Web サービスアプリケーションを Web サービスセキュリティーで保護する場合は、「アプリケーションクライアントのメッセージセキュリティーの有効化」を参照してください。

Enterprise Server では、メッセージレイヤーセキュリティーはデフォルトで無効になっています。Enterprise Server でメッセージレイヤーセキュリティーを設定するには、「Web サービスのデフォルトメッセージセキュリティープロバイダの有効化」を参照してください。

ほとんどの場合、管理タスクを実行したあとに Enterprise Server を再起動する必要があります。特に、操作実行時に Enterprise Server にすでに配備されているアプリケーションに対して管理上の変更を適用する場合は、これに該当します。

メッセージセキュリティーのタスク

メッセージセキュリティーの一般的な実装タスクには、次のタスクの一部またはすべてが含まれます。

  1. バージョン 1.5.0 より前のバージョンの Java SDK を使用し、暗号化テクノロジを使用する場合は、JCE プロバイダを設定します。

  2. ユーザー名トークンを使用している場合は、ユーザーデータベースが適切なレルムに対して設定されていることを確認します。

    ユーザー名およびパスワードトークンを使用する場合は、適切なレルムを設定し、このレルムに対してユーザーデータベースを設定する必要があります。

  3. 必要に応じて証明書と非公開鍵を管理します。

  4. Enterprise Server のデフォルトのプロバイダを有効にします。

  5. 新しいメッセージセキュリティープロバイダを設定します。

メッセージセキュリティーのロール

Enterprise Server では、メッセージセキュリティー設定の主要責任者として、管理者とアプリケーション配備担当者が適任です。状況に応じて、アプリケーション開発者もこれに加わります。

システム管理者

システム管理者は、次のメッセージセキュリティータスクに責任を持ちます。

アプリケーション配備担当者

アプリケーション配備担当者は、次のメッセージセキュリティータスクに責任を持ちます。

アプリケーション開発者およびアセンブリ担当者

アプリケーション開発者およびアセンブリ担当者は、次のメッセージセキュリティータスクに責任を持ちます。

Web サービスのサンプルアプリケーション

Enterprise Server には、xms という名前のサンプルアプリケーションが用意されています。xms アプリケーションは、Java EE EJB エンドポイントと Java サーブレットエンドポイントの両方を使って実装された、単純な Web サービスです。両エンドポイントは同一のサービスエンドポイントインタフェースを共有しています。サービスエンドポイントインタフェースには、sayHello という処理のみが定義されています。この処理は、文字列の引数を 1 つ受け取り、その呼び出し引数の前に Hello を付加した String を返します。

xms サンプルアプリケーションは、Enterprise Server の WS-Security 機能を使って、既存の Web サービスアプリケーションをセキュリティー保護する方法を示すことを目的としています。サンプルに付属する手順では、Enterprise Server の WS-Security 機能を有効にして xms アプリケーションを保護する方法が説明されています。また、このサンプルは、「アプリケーション固有の Web サービスセキュリティー」アプリケーションで説明されているように、WS-Security 機能をアプリケーションに直接バインドする方法も示しています。

xms サンプルアプリケーションのコンパイル、パッケージ化、および実行については、『Sun GlassFish Enterprise Server v3 Application Development Guide』の第 5 章「Securing Applications」を参照してください。

xms サンプルアプリケーションは、as-install/samples/webservices/security/ejb/apps/xms/ にインストールされます。

Web サービスのデフォルトメッセージセキュリティープロバイダの有効化

Enterprise Server では、メッセージセキュリティーはデフォルトで無効になっています。デフォルトメッセージセキュリティープロバイダは作成されていますが、有効化するまではアクティブになりません。プロバイダを有効にしたあと、メッセージセキュリティーが有効になります。

ここでは、次のテーマを取り上げます。

Procedureデフォルトサーバープロバイダを有効にする

Enterprise Server に配備された Web サービスエンドポイントのメッセージセキュリティーを有効にするには、サーバー側でデフォルトで使用されるセキュリティープロバイダを指定する必要があります。メッセージセキュリティーのデフォルトのプロバイダを有効にする場合、Enterprise Server に配備された Web サービスのクライアントが使用するプロバイダも有効にする必要があります。

  1. set(1) サブコマンドを使用して、デフォルトサーバープロバイダを指定します。

    次の構文を使用します。


    asadmin  set --port admin-port 
server-config.security-service.message-security-config.SOAP.
default_provider=ServerProvider

  2. すでに実行されているアプリケーションに変更を適用するには、Enterprise Server を再起動します。

    「ドメインの再起動」を参照してください。

Procedureデフォルトクライアントプロバイダを有効にする

配備済みエンドポイントからの Web サービス呼び出しに対してメッセージセキュリティーを有効にするには、デフォルトクライアントプロバイダを指定する必要があります。Enterprise Server のデフォルトクライアントプロバイダを有効にした場合、Enterprise Server に配備されたエンドポイントから呼び出されるすべてのサービスが、メッセージ層セキュリティーと互換性を持つように設定されていることを確認する必要があります。

  1. set(1) サブコマンドを使用して、デフォルトクライアントプロバイダを指定します。

    次の構文を使用します。


    asadmin  set --port admin-port 
server-config.security-service.message-security-config.SOAP.
default_client_provider=ClientProvider

  2. すでに実行されているアプリケーションに変更を適用するには、Enterprise Server を再起動します。

    「ドメインの再起動」を参照してください。

メッセージ保護ポリシーの設定

メッセージ保護ポリシーは、要求メッセージの処理および応答メッセージの処理に対して定義されます。ポリシーは、ソース認証または受信者認証に関する要件として表現されます。プロバイダは、特定のメッセージセキュリティーメカニズムを適用することで、SOAP Web サービスメッセージにおけるメッセージ保護ポリシーを実現します。

ここでは、次のテーマを取り上げます。

メッセージ保護ポリシーの設定と処理の対応

次の表に、メッセージ保護ポリシーの構成と、その設定の結果として WS-Security SOAP メッセージセキュリティープロバイダが実行するメッセージセキュリティー処理を示します。

表 13–1 メッセージ保護ポリシーと WS-Security SOAP 処理の対応

メッセージ保護ポリシー 

結果として実行される WS-Security SOAP メッセージ保護処理 

auth-source="sender"

メッセージに wsse:Security ヘッダーが格納され、そのヘッダー内に wsse:UsernameToken (パスワード付き) が格納されます。

auth-source="content"

SOAP メッセージ本体のコンテンツが署名されます。メッセージに wsse:Security ヘッダーが格納され、そのヘッダー内にメッセージ本体の署名が ds: Signature として格納されます。

auth-source="sender"

auth-recipient="before-content"

または 

auth-recipient="after-content"

SOAP メッセージ本体のコンテンツが暗号化され、その結果得られた xend:EncryptedData で置換されます。メッセージに wsse:Security ヘッダーが格納され、そのヘッダー内に wsse:UsernameToken (パスワード付き) と xenc:EncryptedKey が格納されます。また、xenc:EncryptedKey には SOAP メッセージ本文の暗号化に使用する鍵が含まれます。この鍵は、受信者の公開鍵内で暗号化されています。

auth-source="content"

auth-recipient="before-content"

SOAP メッセージ本体のコンテンツが暗号化され、その結果得られた xend:EncryptedData で置換されます。xenc:EncryptedData は署名されています。メッセージに wsse:Security ヘッダーが格納され、そのヘッダー内に xenc:EncryptedKey と ds: Signature が格納されます。また、xenc:EncryptedKey には SOAP メッセージ本文の暗号化に使用する鍵が含まれます。この鍵は、受信者の公開鍵内で暗号化されています。

auth-source="content"

auth-recipient="after-content"

SOAP メッセージ本体のコンテンツが、署名されたあと暗号化され、その結果得られた xend:EncryptedData で置換されます。メッセージに wsse:Security ヘッダーが格納され、そのヘッダー内に xenc:EncryptedKey と ds:Signature が格納されます。また、xenc:EncryptedKey には SOAP メッセージ本文の暗号化に使用する鍵が含まれます。この鍵は、受信者の公開鍵内で暗号化されています。

auth-recipient="before-content"

または 

auth-recipient="after-content"

SOAP メッセージ本体のコンテンツが暗号化され、その結果得られた xend:EncryptedData で置換されます。メッセージには、xenc:EncryptedKey を含む wsse:Security ヘッダーが含まれます。また、xenc:EncryptedKey には SOAP メッセージ本文の暗号化に使用する鍵が含まれます。この鍵は、受信者の公開鍵内で暗号化されています。

ポリシーを何も指定しない。 

モジュールはセキュリティー処理を一切行いません。 

Procedureプロバイダのメッセージ保護ポリシーを設定する

一般的には、プロバイダを再設定することはありません。ただし必要な場合は、プロバイダのタイプ、実装クラス、およびプロバイダ固有の構成プロパティーを変更して、プロバイダのメッセージ保護ポリシーを変更できます。設定の組み合わせの結果については、表 13–1 を参照してください。

set(1) サブコマンドを使用して応答ポリシーを設定します。そのあと、各コマンドの request の文字を response に置き換えて実行します。

  1. set(1) サブコマンドを使用して、要求ポリシーをクライアントに追加し、認証のソースを設定します。

    次に例を示します。


    asadmin> set server-config.security-service.message-security-config.SOAP.
provider-config.ClientProvider.request-policy.auth_source=[sender | content]

  2. set サブコマンドを使用して、要求ポリシーをサーバーに追加し、認証のソースを設定します。

    次に例を示します。


    asadmin> set server-config.security-service.message-security-config.SOAP.
provider-config.ServerProvider.request-policy.auth_source=[sender | content]

  3. set サブコマンドを使用して、要求ポリシーをクライアントに追加し、認証の受信者を設定します。

    次に例を示します。


    asadmin> set server-config.security-service.message-security-config.SOAP.
provider-config.ClientProvider.request-policy.auth_recipient=[before-content | after-content]

  4. set サブコマンドを使用して、要求ポリシーをサーバーに追加し、認証の受信者を設定します。

    次に例を示します。


    asadmin> set server-config.security-service.message-security-config.SOAP.
provider-config.ServerProvider.request-policy.auth_recipient=[before-content | after-content]

アプリケーションクライアント構成の要求および応答ポリシーの設定

「要求および応答ポリシー」は、認証プロバイダが実行する要求および応答処理に関連付けられた認証ポリシー要件を定義します。ポリシーはメッセージ送信者による順序で示されるので、「コンテンツのあと」ではメッセージ受信者が署名の検証前にメッセージを復号化することを意味します。

メッセージセキュリティーを実現するには、サーバーとクライアントの両方で要求ポリシーと応答ポリシーが有効化されている必要があります。クライアントおよびサーバーのポリシーを設定する場合は、クライアントポリシーがアプリケーションレベルのメッセージのバインドで要求および応答保護のサーバーポリシーと一致する必要があります。

アプリケーションクライアント構成の要求ポリシーを設定するには、「アプリケーションクライアントのメッセージセキュリティーの有効化」の説明に従って、アプリケーションクライアントコンテナの Enterprise Server 固有の構成を変更します。

例 13–1 アプリケーションクライアントのメッセージセキュリティーのポリシー設定

アプリケーションクライアント構成ファイルの request-policy 要素および response-policy 要素は、次のコード例に示すように、要求ポリシーの設定に使用されます (要素を定義している箇所以外のコードは説明用のものです。実際のインストールでは異なる場合があります。これらのコードは変更しないでください)。


<client-container>
  <target-server name="your-host" address="your-host"
      port="your-port"/>
  <log-service file="" level="WARNING"/>
  <message-security-config auth-layer="SOAP"
      default-client-provider="ClientProvider">
    <provider-config
        class-name="com.sun.enterprise.security.jauth.ClientAuthModule"
        provider-id="ClientProvider" provider-type="client">
      <request-policy auth-source="sender | content"
        auth-recipient="after-content | before-content"/>
      <response-policy auth-source="sender | content"
        auth-recipient="after-content | before-content"/>
       <property name="security.config"
           value="as-install/lib/appclient/wss-client-config.xml"/>
    </provider-config>
  </message-security-config>
</client-container>

auth-source の有効な値には、sender と content があります。auth-recipient の有効な値には、before-content と after-content があります。これらの値の組み合わせの結果については、「メッセージ保護ポリシーの設定」の表を参照してください。

要求または応答ポリシーを指定しない場合は、この要素を空白のままにします。次に例を示します。


<response-policy/>

デフォルト以外のメッセージセキュリティープロバイダの管理

ここでは、次のテーマを取り上げます。

Procedureメッセージセキュリティープロバイダを作成する

セキュリティーサービスの新しいメッセージプロバイダを作成するには、リモートモードで create–message–security–provider サブコマンドを使用します。メッセージレイヤーが存在しない場合は、メッセージレイヤーが作成され、そのレイヤーにプロバイダが作成されます。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. create-message-security-provider(1) サブコマンドを使用して、メッセージセキュリティープロバイダを作成します。

    このサブコマンドのプロパティーについては、このマニュアルページに記載されています。

  3. (省略可能) 必要な場合は、サーバーを再起動します。

    プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。

例 13–2 メッセージセキュリティープロバイダの作成

この例では、mySecurityProvider という名前の新しいメッセージセキュリティープロバイダを作成します。


asadmin> create-message-security-provider 
--classname com.sun.enterprise.security.jauth.ClientAuthModule
--providertype client mySecurityProvider
Command create-message-security-provider executed successfully.
参照

コマンド行に asadmin help create–message–security–provider と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

Procedureメッセージセキュリティープロバイダを一覧表示する

セキュリティーレイヤーのメッセージプロバイダを一覧表示するには、リモートモードで list–message–security–providers サブコマンドを使用します。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. list-message-security-providers(1) サブコマンドを使用して、メッセージセキュリティープロバイダを一覧表示します。

例 13–3 メッセージセキュリティープロバイダの一覧表示

この例では、メッセージレイヤーのメッセージセキュリティープロバイダを一覧表示します。


asadmin> list-message-security-providers --layer SOAP
XWS_ClientProvider 
ClientProvider
XWS_ServerProvider
ServerProvider
Command list-message-security-providers executed successfully.
参照

コマンド行に asadmin help list–message–security–providers と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

Procedureメッセージセキュリティープロバイダを更新する

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. list-message-security-providers(1) サブコマンドを使用して、メッセージセキュリティープロバイダを一覧表示します。

  3. set(1) サブコマンドを使用して、指定したメッセージセキュリティープロバイダの値を変更します。

    メッセージセキュリティープロバイダは、ドット表記名で識別されます。

Procedureメッセージセキュリティープロバイダを削除する

メッセージセキュリティープロバイダを削除するには、リモートモードで delete-message-security-provider サブコマンドを使用します。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. list-message-security-providers(1) サブコマンドを使用して、メッセージセキュリティープロバイダを一覧表示します。

  3. delete-message-security-provider(1) サブコマンドを使用して、メッセージセキュリティープロバイダを削除します。

例 13–4 メッセージセキュリティープロバイダの削除

この例では、myServerityProvider という名前のメッセージセキュリティープロバイダを削除します。


asadmin> delete-message-security-provider --layer SOAP myServerityProvider
Command delete-message-security-provider executed successfully.
参照

コマンド行に asadmin help delete–message–security–provider と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

アプリケーションクライアントのメッセージセキュリティーの有効化

クライアントプロバイダのメッセージ保護ポリシーは、通信相手となるサーバー側プロバイダのメッセージ保護ポリシーと等しくなるように設定する必要があります。Enterprise Server のインストール時に、プロバイダはデフォルトでそのように設定されます (ただし、有効化されていません)。

クライアントアプリケーションのメッセージセキュリティーを有効にするには、アプリケーションクライアントコンテナの Enterprise Server 固有の構成を変更します。処理は、「メッセージ保護ポリシーの設定」の処理と同様です。

メッセージセキュリティープロバイダに関する追加情報

メッセージセキュリティーの追加情報については、次を参照してください。