前へ 目次 DocHome 索引 次へ
Identrus システムへの iPlanet Portal Server Plug-in インストール、管理、およびユーザガイド



第 2 章   管理


Identrus システムへの iPlanet Portal Server Plug-in の管理作業の一環として、Identrus のメンバーユーザを認証および認可するための、適切な証明書を設定する必要があります。この章には、次の項目があります。


管理者のログイン手順

  • ブラウザで Portal Server の URL を選択します。 通常、この URL は http://<machine name>:<port>/console になります(例 : http://firestorm.jcp.co.uk:8080/console)。

図 2-1 管理者のログイン画面

  • 管理者のアカウントにログインすると、次の画面が表示されます。

図 2-2 管理メインメニュー

  • 「Manage Identrus Plug-in」を選択します。このリンクを初めて選択した場合には、信頼できる証明書ストアのパスワードを入力するための画面が表示されます。 証明書ストアへのアクセスに使用するパスワードを入力します。 このパスワードは、PKCS11 トークンのパスワードと同じにします (「HSM の構成」を参照)。 これは、外部 HSM を使用している場合にのみ該当します。

図 2-3 証明書ストアのパスワード

  • 「次へ」を選択します。RDB を次のように設定します。

図 2-4 RDB 設定

  • 次の設定は必須です。

    • 接続 URL : Oracle データベースの場所

    • ユーザ名 : Oracle フレームワークデータベースへのアクセスに使用するユーザ名

    • パスワード : Oracle フレームワークデータベースへのアクセスに使用するパスワード

    • PBE パスワード : Oracle データベース内で動作する証明書ストア内にある暗号化されたデータへのアクセスに使用するパスワード

  • 入力し終えたら、「次へ」を選択します。

  • これ以降、「Manage Identrus Plug-in」を選択すると次のメニューが表示されるようになります。

図 2-5 Identrus システムへの iPlanet Portal Server Plug-in メインメニューのオプション

まず、証明書を入手するためのさまざまな手続きを紹介し、次のオプションについて順番に説明します。

  • Generate Identrus Certificate : 確認の必要な証明書用

  • ログイン認可、Netmail : システムを使用できるユーザ、および各ユーザの権限を決定

  • CSC の構成、RC ホスト、証明書ステータス

  • SSL コミュニケーション : トランスポートの認証を可能にする


    注 すべての構成オプションを順番に検討し、適切なオプションを選択します。選択が終了したら画面右下に向かってスクロールし、

    をクリックして選択を有効にします。



Identrus 証明書を生成する

次の証明書は署名用に使用され、変更されることを防ぎ、変更された電子メールメッセージが使用されることを防ぎます。このため、これらの証明書には、Identrus システムからの PKCS10 リクエストと、CA からの PKCS7 レスポンスが必要です。

  • リクエスト署名証明書

  • レスポンス署名証明書

  • SSL クライアント証明書 : ハンドシェイクリクエストに署名

その他の証明書は確認/検証のために必要で、認証や認可を可能にします。これらの証明書は CA から直接入手します。

  • 信頼できるログイン CA 証明書

  • 信頼できる電子メール証明書

  • 信頼できるレスポンス確認証明書


    注 CA により指定される手続きは、CA のセキュリティポリシーによって異なります。 確かでない場合は、CA のオペレータに証明書の処理を依頼してください。



認証および認可用に証明書を追加する

この場合、PKCS10 リクエストは必要ありません。次の手順に従います。

  • iPlanet Portal Server のメイン画面で「Manage Identrus Plug-in」を選択します。

図 2-6 Portal 管理者のメイン画面

  • 「CSC の構成」を選択し、たとえば次の図の「信頼できるレスポンス確認証明書」で「追加」を選択します。

図 2-7 CSC の構成

  • 証明書は、CA から直接入手した証明書を貼り付けることによって追加できます。

図 2-8 Identrus システムへの iPlanet Portal Server Plug-in に base64 エンコードの証明書を貼り付ける


署名用に証明書を追加する

ここでは、主に 2 つの段階に分けて作業を行います。まず Identrus システムからの PKCS 10 リクエストを使用して署名リクエストを生成し、次に CA から PKCS 7 レスポンスを入手します。

  • メインメニューから「Generate Identrus Certificate」を選択します。

図 2-9 Portal 管理者のメイン画面

  • 証明書に関する次の情報を指定します。

図 2-10 PKCS#10 証明書リクエストを生成する

  • 鍵の長さ : 512 ビットまたは 1024 ビットから選択

  • 共通名 : 証明書に付ける名前 (例 : Portal SSL Certificate)

  • 組織単位 : ユーザ/エンティティが所属する組織内の部署

  • 組織 : ユーザが作成する証明書の所属先 (例 : iPlanet)

  • 国 : ユーザが所在する国。ISO3611 標準(http://www.iso.ch) および X500 標準 (http://www.itu.int/itudoc/itu-t/rec/x/x500up/x500.html) によって定義された国名コードに基づく



  • を選択することによって、証明書リクエストを生成します。 このリクエストは、base64 でエンコードされた PKCS 10 リクエストです。

図 2-11 PKCS10 リクエストをコピーする

  • CA の Web サイトにアクセスし、サーバ証明書の作成に関する説明を参照しながら、PKCS10 リクエストを貼り付けるところまで作業を進めます。

図 2-12 PKCS10 リクエストを CA の Web サイトに貼り付ける

  • 切り取りおよび貼り付けることによって、該当する base64 エンコードの証明書レスポンスを収集します。 証明書をコピーおよび貼り付ける際には、Ctrl + C キーおよび Ctrl + V キーを使用します。

図 2-13 CA からの base64 エンコードの証明書レスポンスをコピーする

  • iPlanet Portal Server のメイン画面で「Manage Identrus Plug-in」を選択します。

  • 「CSC の構成」を選択します。

  • 「追加」を選択します (次の図を参照)。

図 2-14 CSC の構成

  • 証明書は、結果として返される base64 エンコードの PKCS 7 レスポンスを貼り付けることによって追加できます。

図 2-15 base64 エンコードの証明書レスポンスを貼り付ける

  • 「追加」を選択します。


証明書を削除する

証明書は削除することもできます。この場合、ユーザは確認済みのメッセージを送信できなくなります。


注 証明書のインストール方法について疑問がある場合は、現地の製品サポートの担当者に問い合わせてください。



ログインの承認


このオプションでは、ユーザがログインする際に、ユーザに対してどのようなセキュリティ対策を適用するかを設定できます。次のような設定が可能です。

  • ログイン時に証明書ステータスをチェックしない

  • ログイン時に常に証明書ステータスをチェックする

  • 最初のログイン時のみに証明書ステータスをチェックする

  • 証明書ステータスチェックの結果が良好であれば、そのステータスを指定の期間 (分) キャッシュに保存する : キャッシュ期間中に同じユーザが再度ログインすると、最初のログイン時にリクエストされたステータスが使用される。 ただし、良好でないレスポンス (無効/不明など) はキャッシュに保存されない

図 2-16 ログイン認可の主なオプション

RP (Relying Participant) の銀行の証明書をここで入力します。 この Identrus のメンバーである銀行のすべての顧客が、Portal Server にログインできます。 信頼できる証明書は、必要に応じて追加および削除できます。 この構成インタフェースには、1 つまたは複数の base64 エンコードの証明書を貼り付けることができます。 ログイン時に提示されたアイデンティティ証明書をこのスキーマの一部として認識するためには、これらの証明書の 1 つが証明書チェーンに含まれていることが必要です。


注 この証明書を入手するには、CA の管理者に連絡してください。Identrus メンバーであれば、CA の管理者が必要な Identrus ルート証明書と RP 証明書を所有しているはずです。 証明書のインストール方法について疑問がある場合は、現地の製品サポート担当者に問い合わせてください。 また、「認証および認可用に証明書を追加する」も参照してください。



Netmail の構成


請求書発行の観点から、証明書ステータスを自動または手作業で確認するかどうかを決定する際にはいくつかのケースが考えられます。 ほとんどのユーザの身元がわかっている場合には、証明書ステータスのチェックは必要ないこともあります。 次の 3 つのオプションがあります。

  • 自動的に CSC チェックを実行する

  • 手作業によるユーザチェックを許可する

  • 非スキーマ証明書署名チェックを許可する : このオプションを選択すると、非スキーマ署名がチェックされ、該当するアイコンが表示される。選択しないと、非スキーマ証明書によって署名されたメッセージの署名チェックは行われない

図 2-17 Netmail の構成オプション

Identrus ルート証明書をここで入力します。 Identrus メンバーから送信されたすべての電子メールを確認できます。 この構成インタフェースには、その他の base64 エンコードの証明書を貼り付けることもできます。 電子メール署名証明書をこのスキーマの一部として認識するには、これらの証明書の 1 つが証明書チェーンに含まれていることが必要です。

この証明書を入手するには、CA の管理者に連絡してください。Identrus メンバーであれば、CA の管理者が必要な Identrus ルート証明書と RP 証明書を所有しているはずです。


注 証明書のインストール方法について疑問がある場合は、現地の製品サポートの担当者に問い合わせてください。また、「認証および認可用に証明書を追加する」も参照してください。



CSC の構成


証明書ステータスチェックにより、任意の Identrus メンバーの証明書ステータスを確認することが可能になります。 OCSP レスポンダ または Identrus CSC レスポンダが、ローカルのレスポンダに連絡してリクエストにレスポンスする (この組織が証明書を発行した場合) か、証明書を発行した組織のレスポンダにリクエストを転送します。

図 2-18 メッセージの生成および確認に必要な証明書を示す Identrus CSC の例

リクエスト/レスポンス証明書を追加する前に、ルート証明書および対応する CA チェックが構成されていることを確認する必要があります。 証明書が個別の base64 エンコード証明書である場合は、ルートを追加して CA に置換し、さらに対応するリクエストとレスポンスの証明書に再度置換することをお勧めします。 これにより、ルート/CA/リクエスト証明書またはレスポンス証明書の完全なチェーンが構成されます。

図 2-19 CSC の構成

ユーザが証明書ステータスのチェックを実行できるようにするには、次の証明書の構成が必要です。

  • リクエスト署名証明書 : CSC リクエスト (RC ホストから RP へ送信) の署名鍵は、ハードウェアセキュリティモジュール (HSM) に保持される。 鍵の署名を含むすべての秘密鍵に関する処理は、HSM で行われる。 この証明書の入手方法については、「署名用に証明書を追加する」を参照

  • レスポンス署名証明書 : CSC レスポンス (RC ホストから RP へ送信) の署名鍵は、ハードウェアセキュリティモジュール (HSM) に保持される。 鍵の署名を含むすべての秘密鍵に関する処理は、HSM で行われる。 この証明書の入手方法については、「署名用に証明書を追加する」を参照

  • 信頼できるレスポンス確認証明書 : 構成インタフェースには、1 つまたは複数の base64 エンコードの証明書を貼り付けることが可能。 OCSP レスポンダまたは CSC レスポンダを信頼するには、これらの証明書の 1 つがレスポンダの証明書チェーンに含まれていることが必要 (「認証および認可用に証明書を追加する」を参照)。 これは、OCSP レスポンダの役割を果たす CA の場合 (VA 証明書) と、Identrus における RP エンドエンティティ署名用証明書 (図 2-19 を参照) の場合がある


    注 証明書のインストール方法について疑問がある場合は、現地の製品サポート担当者に問い合わせてください。 証明書を追加するには、まず適切な機関から証明書を入手する必要があります。 入手方法については、「Identrus 証明書を生成する」を参照してください。



RC ホストの構成

次の RC (Relying Customer) 設定が必要です。

  • レスポンダタイプ : OCSP (OCSP レスポンダを使用する場合 ) または Identrus 証明書ステータスチェック (Identrus が完全に実装されている場合 ) を選択

  • レスポンダの URL : https://hailstorm.uk.sun.com:8080 など

  • OCSP リクエスタ名 : 署名の際に必要な、OCSP リクエスト元であるエンティティの名前 ( 通常は URL)

図 2-20 RC ホストの構成


証明書ステータス


これらの設定により、システムが定義され、システム全体のために証明書ステータスチェックを行えるかどうかが決定されます。 また、Identrus システムへの iPlanet Portal Server Plug-in で使用されるデータベース接続情報もここで定義されます。 管理者がシステムで実行された証明書ステータスチェックを確認するには、監視ログを使用します。詳細は、「ログ」を参照してください。

  • 「証明書ステータスのチェックを有効にする」をオンにします。

図 2-21 証明書ステータスの構成

次の設定は必須です。

  • 接続 URL : Oracle データベースの場所

  • ユーザ名 : Oracle フレームワークデータベースへのアクセスに使用するユーザ名

  • パスワード : Oracle フレームワークデータベースへのアクセスに使用するパスワード

  • PBE パスワード : Oracle データベース内で動作する証明書ストア内にある暗号化されたデータへのアクセスに使用するパスワード


SSL コミュニケーション

証明書は、SSL ハンドシェイクを行う際に、トランスポート層で必要になります。 次の証明書が必要です。

図 2-22 SSL コミュニケーションの構成

この証明書を入手するには、CA の管理者に連絡してください。Identrus メンバーであれば、CA の管理者が必要な Identrus ルート証明書と RP 証明書を所有しているはずです。


ログ



構成

ログは、有効または無効にすることができます。 ログが無効の場合、新しいエントリが記録されることはありません。

図 2-23 ログを構成する


表示

メインメニューから「ロギング」を選択すると、ログのさまざまな面を表示できます。

図 2-24 ロギングメインメニュー

  • 自分のサーバ名 (例 : firestorm.uk.sun.com:8080) を選択することによって、さまざまなエラーログを表示できます。

  • 「readExceedsMax」エラーのメッセージが表示された場合は、ログファイルが大きいために画面に表示できません。 ただし、この場合でもファイルを見ることは可能です。ファイルは Portal デフォルトログディレクトリにあります。
    /var/opt/SUNWips/logs

図 2-25 サーバログファイルの例

必要に応じて特定のログファイルを削除するオプションもあります。 これらのログファイルについて説明します。

  • iwtAuthentication ： 成功か失敗かにはかかわらず、すべてのログオンの試みを記録。 ログオンに失敗した場合は、理由が記録される

  • iwtGateway : 標準的な Portal Server ログの一部。詳細は、Portal Server の管理者用マニュアルを参照

  • iwtAdmin : 標準的な Portal Server ログの一部。詳細は、Portal Server の管理者用マニュアルを参照

  • iacMessageLog : システムで送受信されたすべての証明書ステータスチェックのメッセージを記録。 次の情報が含まれる

    • RC から受信した CSC リクエスト

    • RP に送信された CSC リクエスト

    • RP から受信した CSC レスポンス

    • RC に送信された CSC レスポンス

  • ログレコードに含まれるフィールド

    • 原初メッセージ - 常にタイムスタンプが付けられ、RC、RC ホスト、または CSC レスポンダによって署名される

    • リクエストしているユーザ - これにより、プロファイル時にリクエスタ当たりのリクエストの量とタイプを判別することが可能

    • SC 証明書チェーン

    • 日時-秒単位で四捨五入して記録される。タイムスタンプの形式は「YYYMMDDhhmmss」

    • レスポンダの URL - システムのレスポンダの URL は現時点では固定されているが、将来、複数のレスポンダのサポートが必要となった場合や、URL が変更された時などに備えて記録される

    • レスポンスステータス - 成功、失敗 (トランザクションの失敗の原因である、特定の業務要件によるエラー、または技術的エラーも記録)、タイムアウトなど

    • 証明書ステータス - 有効、取り消し済み、または不明

    • トランザクション ID

    • 完全なレスポンスメッセージ

    • リクエストのコンテキスト - 現時点ではメールチェックとログイン

  • iacMessageLog-1 : ログファイルのサイズが大きくなった場合、そのファイルの名前は変更され、新しいログファイルが作成される。 これは iacMessageLog の変更後の名前

  • iwtNetMail : NetMail ログの一部。詳細は、Portal Server の管理者用マニュアルを参照

  • iacAppLog : 業務要件によるエラー、技術的エラー、実装上のエラーなど、すべてのエラーを記録。 ログエントリには、次のものがある

    • 日時-秒単位で四捨五入して記録される。タイムスタンプの形式は「YYYMMDDhhmmss」

    • エラーの原因となったソースコードの行を示す、固有の識別子

    • エラーの説明

    • 該当する場合、エラーに関するデータ (接続時のホスト名エラーなど)

    • エラーによっては、Java 例外の呼び出しスタックが含まれる場合もある


      注 場合によっては、より詳細な情報が必要なこともあります。 このような場合、これらのログは /var/opt/SUNWips/logs ディレクトリにテキストファイルとしても保存されます。



前へ 目次 DocHome 索引 次へ
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

最終更新日 2001 年 3 月 14 日