WebSphere Application Server - Express Version 5.1

򔻐򗗠򙳰
IBM Systems - iSeries
e-business および Web サービス
WebSphere Application Server - Express Version 5.1
セキュリティー
バージョン 5 リリース 4
򔻐򗗠򙳰
IBM Systems - iSeries
e-business および Web サービス
WebSphere Application Server - Express Version 5.1
セキュリティー
バージョン 5 リリース 4
ご注意
本書および本書で紹介する製品をご使用になる前に、 199 ページの『特記事項』に記載されている情
報をお読みください。
本書は、IBM WebSphere Application Server - Express for iSeries (製品番号 5722-E51) のバージョン 5.1 に適用され
ます。また、改訂版で断りがない限り、それ以降のすべてのリリースおよびモディフィケーションに適用されます。
このバージョンは、すべての RISC モデルで稼働するとは限りません。また CISC モデルでは稼働しません。
本マニュアルに関するご意見やご感想は、次の URL からお送りください。今後の参考にさせていただきます。
http://www.ibm.com/jp/manuals/main/mail.html
なお、日本 IBM 発行のマニュアルはインターネット経由でもご購入いただけます。詳しくは
http://www.ibm.com/jp/manuals/
の「ご注文について」をご覧ください。
(URL は、変更になる場合があります)
お客様の環境によっては、資料中の円記号がバックスラッシュと表示されたり、バックスラッシュが円記号と表示さ
れたりする場合があります。
原 典： IBM Systems - iSeries
e-business and Web serving
WebSphere Application Server - Express Version 5.1 Security
Version 5 Release 4
発 行： 日本アイ・ビー・エム株式会社
担 当： ナショナル・ランゲージ・サポート
第1刷 2006.2
この文書では、平成明朝体™W3、平成明朝体™W7、平成明朝体™W9、平成角ゴシック体™W3、平成角ゴシック体™
W5、および平成角ゴシック体™W7を使用しています。この(書体*)は、
（財）日本規格協会と使用契約を締結し使用し
ているものです。フォントとして無断複製することは禁止されています。
注*
平成明朝体™W3、平成明朝体™W7、平成明朝体™W9、平成角ゴシック体™W3、
平成角ゴシック体™W5、平成角ゴシック体™W7
© Copyright International Business Machines Corporation 2004, 2006. All rights reserved.
© Copyright IBM Japan 2006
目次
セキュリティー . . . . . . . . . . . . 1
iSeries セキュリティー・リソース . . . . . . . 2
IBM HTTP Server for i5/OS での Web リソースの保
護 . . . . . . . . . . . . . . . . . . 4
getRemoteUser() および getAuthType() メソッドの
使用 . . . . . . . . . . . . . . . . 6
WebSphere セキュリティーによるリソース保護 . . . 6
WebSphere セキュリティーの概要 . . . . . . 7
保護アプリケーションの開発 . . . . . . . 12
セキュア Web アプリケーションの開発 . . . 13
例: セキュア Web アプリケーション・コー
ド . . . . . . . . . . . . . . 15
フォーム・ログイン処理用のサーブレット・フ
ィルターの開発 . . . . . . . . . . . 16
例: サーブレット・フィルター . . . . . 18
フォーム・ログイン・ページの開発 . . . . 20
例: フォーム・ログイン . . . . . . . 21
プログラマチック・ログインのための JAAS
を使用した開発 . . . . . . . . . . . 24
例: JAAS プログラマチック・ログイン . . 26
JAAS 認証およびログイン構成のカスタマ
イズ . . . . . . . . . . . . . . 27
JAAS ログインからの根本原因となるログ
イン例外の検出 . . . . . . . . . . 30
独自の J2C プリンシパル・マッピング・モジ
ュールの開発 . . . . . . . . . . . . 32
カスタム・ユーザー・レジストリーの開発 . . 34
カスタム・ユーザー・レジストリー . . . 35
UserRegistry インターフェース・メソッド
37
例: UserRegistry.java ファイル . . . . . 43
例: FileRegistrySample.java ファイル . . . 49
例: Groups.props ファイル . . . . . . 65
例: Users.props ファイル . . . . . . . 65
例: Results.java ファイル . . . . . . . 65
カスタム・クラスのインスタンスにクラ
ス・サブディレクトリーを作成する . . . 66
保護アプリケーションのアセンブル . . . . . 68
web.xml ファイルを編集してセキュリティー設
定を追加する . . . . . . . . . . . . 68
アプリケーションへの was.policy ファイルの
追加 . . . . . . . . . . . . . . . 70
保護アプリケーションの配置 . . . . . . . 72
役割へのユーザーおよびグループの割り当て
72
WebSphere セキュリティーの構成 . . . . . . 74
グローバル・セキュリティーの構成 . . . . 75
グローバル・セキュリティー . . . . . 75
ユーザー・レジストリーの構成 . . . . . 75
認証メカニズムの構成 . . . . . . . . 94
シングル・サインオンの構成 . . . . . 99
デフォルトの SSL 鍵ストア・ファイルと
トラストストア・ファイルの変更. . . . 113
© Copyright IBM Corp. 2004, 2006
グローバル・セキュリティーの使用可能化
役割ベースの権限 . . . . . . . . . .
管理役割へのユーザーの割り当て. . . . .
ネーミング役割へのユーザーの割り当て . .
内部 HTTP トランスポートのトラステッド・
モードの構成 . . . . . . . . . . .
WebSphere Application Server - Express での
SSL の構成 . . . . . . . . . . . .
ブラウザー用の SSL を構成する . . . .
Web サーバーでの SSL の構成 . . . .
SSL クライアント認証のための IBM
HTTP Server for i5/OS の構成 . . . . .
WebSphere Application Server での SSL の
構成 . . . . . . . . . . . . .
WebSphere アプリケーションでの SSL の
構成 . . . . . . . . . . . . .
WebSphere Application Server - Express お
よび LDAP サーバー間の SSL 接続の構成
Java 2 セキュリティーの構成 . . . . . .
Java 2 セキュリティー . . . . . . .
Java 2 ポリシー・ファイルの構成 . . .
Java 認証および許可サービス・ログインの構
成 . . . . . . . . . . . . . . .
J2C 認証データ項目の構成 . . . . . . .
セキュリティー構成の調整 . . . . . . . .
セキュリティー全般の調整のヒント . . . .
セキュリティー・キャッシュ・プロパティ
ー . . . . . . . . . . . . . .
CSIv2 の調整 . . . . . . . . . . .
LDAP 認証の調整 . . . . . . . . . .
Web 認証の調整 . . . . . . . . . .
権限の調整 . . . . . . . . . . . .
SSL パフォーマンスのヒント . . . . . .
例: HTTP トランスポートに対するカスタ
ム・プロパティーの設定. . . . . . .
特定のユーザー・プロファイルでのアプリケーショ
ン・サーバーの実行 . . . . . . . . . . .
ユーザー・プロファイルを使用可能にして
iSeries ナビゲーターでアプリケーション・サー
バーを実行する. . . . . . . . . . . .
iSeries オブジェクトおよびファイルの保護 . . .
パスワードのエンコード. . . . . . . . . .
115
116
118
120
122
123
124
124
124
125
137
153
155
157
161
177
179
180
181
181
182
182
183
183
183
186
187
188
189
190
付録. 特記事項 . . . . . . . . . . . 199
プログラミング・インターフェース情報 . .
商標 . . . . . . . . . . . . . .
資料に関するご使用条件. . . . . . . .
コードに関するライセンス情報および特記事項
.
.
.
.
.
.
.
.
200
201
201
202
iii
iv
WebSphere Application Server - Express Version 5.1 セキュリティー
セキュリティー
WebSphere(R) Application Server - Express はインターネット・テクノロジーであるため、WebSphere
Application Server - Express を実装する前に、適切なセキュリティー・ポリシーが定められていることが不
可欠です。たとえご使用のアプリケーションが企業のイントラネット上でのみ稼働するものであっても、危
険は存在するため、システムを保護する必要があります。
どのようなシステムも完璧に保護することは不可能ですが、システムへの攻撃を防ぐ安全保護策を実装する
ことはできます。 WebSphere Application Server - Express ソリューションを配置する前に、これを実装す
ると、システムのセキュリティー・ポリシーにどのように影響を与えるか調べて理解し、それに応じてプラ
ンを修正してください。システム全体を対象としたセキュリティー・プランの作成に関しては、 2 ページの
『iSeries セキュリティー・リソース』にあるリンク集を参照してください。
このトピックでは、WebSphere リソース (サーブレット、JSP ファイル、HTML ファイルなど) の保護お
よび WebSphere 製品自体 (WebSphere のファイル、ディレクトリー、およびユーザー・プロファイル) の
保護という、WebSphere Application Server - Express の 2 つ分野のセキュリティー事項を扱います。
WebSphere リソースの保護
WebSphere Application Server - Express および WebSphere リソースを保護するには、以下の選択肢があり
ます。
4 ページの『IBM HTTP Server for i5/OS での Web リソースの保護』
Web サーバー・ディレクティブを使用し、サーブレットおよび JSP ファイルへのアクセスを制限で
きます。 Web サーバー・ディレクティブに基づいたセキュリティーは通常、WebSphere セキュリテ
ィーよりも簡単に構成でき、またより高いパフォーマンスを提供することがあります。
6 ページの『WebSphere セキュリティーによるリソース保護』
WebSphere Application Server - Express は、階層化された役割ベースのセキュリティー・アーキテク
チャーを提供します。 WebSphere セキュリティーは、Java(TM) 2 セキュリティー、J2EE、および
CORBA セキュリティーをサポートしています。保護アプリケーションの開発、アセンブル、および
配置と、管理コンソールを使った WebSphere セキュリティーの構成方法については、このトピック
を参照してください。
WebSphere 製品の保護
追加のセキュリティー情報については、以下のトピックを参照してください。
187 ページの『特定のユーザー・プロファイルでのアプリケーション・サーバーの実行』
デフォルトでは、アプリケーション・サーバーは QEJBSVR ユーザー・プロファイルの下で実行され
ます。別のユーザー・プロファイルを使用する場合は、このトピックの説明を参照してください。
189 ページの『iSeries オブジェクトおよびファイルの保護』
このトピックでは、i5/OS(R) セキュリティーで保護する必要のある iSeries オブジェクトおよびファイ
ルについて説明します。
© Copyright IBM Corp. 2004, 2006
1
190 ページの『パスワードのエンコード』
このトピックでは、構成ファイルおよびプロパティー・ファイル内のパスワードのエンコードについ
て説明します。
iSeries セキュリティー・リソース
これらのリソースは、iSeries サーバーの強力なセキュリティー・ポリシーのセットアップに役立ちます。
資料
Tips and Tools for Securing your iSeries
この資料には、iSeries のセキュリティー機能の使用、およびセキュリティーを重視した操作手順の確
立のための一連の実用的な提案が記載されています。
i5/OS Security Reference
この資料には、iSeries システム上でのセキュリティーの計画、セットアップ、管理、および監査につ
いての情報が記載されています。 iSeries システム上でのすべてのセキュリティー機能についての説
明、およびセキュリティー機能がワーク・マネージメント、バックアップおよびリカバリー、アプリ
ケーション設計などの、システムの他の側面とどのように関連しているかについての説明が記載され
ています。
Redbook および Redpaper
WebSphere Application Server - Express V5.0 for iSeries
この IBM Redpaper では、WebSphere Application Server - Express のインストールおよび構成に関す
る基本情報を提供します。
WebSphere Application Server Version 5.0 セキュリティー (WebSphere Application Server Version
5.0 Security)
この IBM Redbook は、J2EE セキュリティーおよびプログラマチック・セキュリティー技法を含
む、 WebSphere Application Server バージョン 5.0 のセキュリティーの概要を提供しています。この
Redbook はまた、WebSphere Application Server バージョン 5.0 を e- ビジネス・ソリューションの
一部として含むエンドツーエンド・セキュリティー・ソリューションに関する情報も含みます。
AS/400インターネット・セキュリティー: ご使用の AS/400 をインターネット被害から保護する
SG24-4929-00 (AS/400 Internet Security: Protecting Your AS/400 from HARM in the Internet,
SG24-4929-00)
この資料は、iSeries のセキュリティーについての必要なすべての知識、および、さまざまなセキュリ
ティー要素がどのように適合し合うかについて説明しています。システムおよびデータの保護に使用
可能な、包括的な iSeries のセキュリティー・オプションの理解に役立ちます。
HTTP Server (Apache で稼働): IBM iSeries Servers の統合ソリューション、SG24-6716-00 (HTTP
Server (powered by Apache): An Integrated Solution for IBM iSeries Servers, SG24-6716-00)
2
WebSphere Application Server - Express Version 5.1 セキュリティー
この IBM Redbook は、IBM iSeries サーバー上で実行されている HTTP Server (Apache で稼働) の
計画、インストール、構成、トラブルシューティング、および理解を助けるよう作成されています。
Redbook には、基本認証用 HTTP サーバー、アクセス制御、および SSL の構成について記載されて
います。また、Java 機能を持つ WebSphere Application Server のもとで動作する Web アプリケーシ
ョンを実装するためのステップを、段階的に説明します。
Web サイト
AS/400 Technical Studio: AS/400 Security
AS/400 Security では、インターネット・セキュリティーなどのトピックを扱っています。 iSeries サ
ーバーの Security Advisor を使用して、最適なセキュリティー設定の判別に役立ててください。
コモン・セキュリティー・インターオペラビリティー バージョン 2 (CSIv2) 仕様 (Common
Security Interoperability Version 2 (CSIv2) Specification)
WebSphere セキュリティーは、CSIv2 の認証プロトコルとしての使用をサポートしています。 CSIv2
について詳しくは、この仕様を参照してください。
Java 2 Platform Security for Java 2 SDK, Standard Edition, 1.4
Java 2 セキュリティー・アーキテクチャー、ポリシー権限、および証明書のサポートについては、こ
の資料を参照してください。 WebSphere Application Server - Express は、Java 2 セキュリティーの
使用をサポートします。
プログラミング・モデル
Java Secure Socket Extension (JSSE)
アプリケーション・プログラミング・インターフェース (API) の Javadoc、「JSSE 参照ガイド (JSSE
Reference Guide)」、および JSSE サンプルについては、
http://www.ibm.com/developerworks/java/jdk/security/jsseDocs.zip
をダウンロードします。
IBM 鍵管理 (iKeyman) ユーティリティー
から「SSL の概要および
http://www.ibm.com/developerworks/java/jdk/security/iKeymanDocs.zip
iKeyman ユーザーズ・ガイド (SSL Introduction and iKeyman User’s Guide)」をダウンロードします。
Java Cryptography Extension (JCE)
Java Cryptography Architecture (JCA) 仕様および JCE API 使用ガイド、JCE サンプル・アプリケー
ション、「Java Cryptography Architecture リファレンス (Java Cryptography Architecture
Reference)」、「JCE プロバイダーのインプリメント方法 (How to implement a JCE provider)」、JCE
API 資料、および「IBM JCE の概説 (Overview of IBM JCE)」については、
http://www.ibm.com/developerworks/java/jdk/security/jceDocs.zip
をダウンロードします。
セキュリティー
3
Java 認証・承認サービス (JAAS)
製品資料
iSeries Information Center (V5R2)
デジタル証明書マネージャー
ディジタル証明書マネージャー (DCM) はフリーな iSeries 機能であり、アプリケーションの証
明書を集中して管理するために使用します。
IBM HTTP Server for i5/OS
このトピックの情報は、HTTP Server (powered by Apache) に適用されます。
セキュリティーおよび Directory Services
iSeries(TM) e-business セキュリティーおよび Directory Services のオファリングを理解するに
は、この情報をご覧ください。
iSeries Information Center (V5R3)
デジタル証明書マネージャー
ディジタル証明書マネージャー (DCM) はフリーな iSeries 機能であり、アプリケーションの証
明書を集中して管理するために使用します。
IBM HTTP Server for i5/OS
このトピックの情報は、HTTP Server (powered by Apache) に適用されます。
セキュリティーおよび Directory Services
iSeries(TM) e-business セキュリティーおよび Directory Services のオファリングを理解するに
は、この情報をご覧ください。
iSeries Information Center (V5R4)
デジタル証明書マネージャー
ディジタル証明書マネージャー (DCM) はフリーな iSeries 機能であり、アプリケーションの証
明書を集中して管理するために使用します。
IBM HTTP Server for i5/OS
このトピックの情報は、HTTP Server (powered by Apache) に適用されます。
セキュリティーおよび Directory Services
iSeriesTM e-business セキュリティーおよび Directory Services のオファリングを理解するには、
この情報をご覧ください。
IBM HTTP Server for i5/OS での Web リソースの保護
IBM HTTP Server for i5/OS の保護ディレクティブを使用して、Web リソースを保護することができま
す。このメカニズムを使用すると、パフォーマンスは改善されますが、WebSphere 管理アプリケーション
のすべてのセキュリティー情報を管理する機能は失われてしまいます。
セキュリティー検査を適用する必要のないイメージなどの静的リソースがある場合は、それらの静的リソー
スは HTTP サーバーによる直接サービスが可能であり、WebSphere セキュリティーの検査を行う上でのパ
フォーマンスの影響を受けません。
4
WebSphere Application Server - Express Version 5.1 セキュリティー
例えば、WebSphere で URI /webapp/SecureWebApplication/servlet/* 内にリソースがある場合、ディレ
クティブを指定して、WebSphere セキュリティー検査なしでイメージの提供を可能にすることができま
す。例えば、IBM HTTP Server (powered by Apache) では、このディレクティブを Web サーバー・イン
スタンス構成に追加することができます。
Alias /images/ /nonsecure/images/
これらのリソースには WebSphere セキュリティーは適用されないため、WebSphere Application Server Express は要求を認証または拒否することはありません。
注: WebSphere 管理コンソールを保護できるのは、Web サーバー保護ではなく、WebSphere セキュリティ
ーを使用した場合だけです。ただし、WebSphere セキュリティーが使用可能になっている場合は、サーブ
レットの Web サーバー保護はサポートされません。現在 Web サーバー保護を使用しており、WebSphere
セキュリティーを使用可能にしたい場合は、最初に Web サーバー構成から保護ディレクティブを除去し、
次に Web リソースを保護するよう WebSphere セキュリティーを構成します。
さらに、Web サーバーによって保護されているサーブレットは、WebSphere セキュリティーがアプリケー
ション・サーバーに対して使用可能になっており、WebSphere 保護がサーブレットに対して構成されてい
ない場合には、要求オブジェクトの getRemoteUser() または getAuthType() メソッドを呼び出すと、ヌルを
取得します。詳しくは、 6 ページの『getRemoteUser() および getAuthType() メソッドの使用』を参照して
ください。
WebSphere Application Server - Express 製品には、内部 HTTP サーバーが含まれています。Web リソース
を保護するように内部 HTTP サーバーを構成することはできません。実動レベルの環境では、内部 HTTP
ポート番号が、Web モジュールに関連付けられている仮想ホストで構成されないようにする必要がありま
す。
IBM HTTP Server インスタンス (Apache で稼働) を構成するには、Location ディレクティブを使用しま
す。以下の例で、Location ディレクティブを使用してサーブレット
/webapp/SecureServerWebApp/BasicServlet を保護する方法を示します。
Location /webapp/SecureServerWebApp/BasicServlet
AuthName happywas
ProfileToken off
AuthType Basic
order deny,allow
require valid-user
allow from all
deny from all
PasswdFile %%SYSTEM%%
UserID %%SERVER%%
/Location>
IBM HTTP Server インスタンスの構成について詳しくは、iSeries Information Center にある IBM HTTP
Server for i5/OS 資料を参照してください。
v V5R2の場合
v V5R3 の場合
v V5R4 の場合
注: WebSphere Application Server - Express 製品には、アプリケーションのテストに使用され、外部 HTTP
サーバーを使用せずに管理アプリケーションにサービスを提供するために使用される内部 HTTP サーバー
が含まれています。外部 HTTP サーバーの IBM HTTP Server (powered by Apache) を使って WebSphere
リソースを保護する場合は、内部 HTTP サーバーにアクセスできないようにする必要があります。
セキュリティー
5
内部 HTTP サーバーにアクセスできないようにするには、WebSphere 管理コンソールで以下のステップを
実行します。
1. ナビゲーション・メニューで、「環境 (Environment)」―>「仮想ホスト (Virtual Hosts)」をクリック
します。
2. 「仮想ホスト (Virtual Hosts)」ページで、仮想ホストの名前 (例えば、default_host) をクリックします。
3. 「追加プロパティー (Additional Properties)」の「ホストの別名 (Host Aliases)」をクリックします。
4. 外部 HTTP サーバー・ポートに対応しないポート番号を持つ項目を選択します。(デフォルトでは、外
部ポート番号は 80 です。この場合は、80 以外のポートを持つホスト名を選択します。)
5. 「削除 (Delete)」をクリックします。
6. 「保管 (Save)」をクリックして構成を保管します。
getRemoteUser() および getAuthType() メソッドの使用
getRemoteUser() および getAuthType() メソッドは、HttpServletRequest インターフェース
(javax.servlet.http.HttpServletRequest) のメソッドです。ユーザーが認証されている場合、getRemoteUser() メ
ソッドは要求を行っているユーザーのログインを戻します。ユーザーが認証されていない場合には、
getRemoteUser() メソッドはヌルを戻します。getAuthType() メソッドは、サーブレット (例えば、BASIC
または SSL) を保護するために使用する認証スキームの名前を戻します。サーブレットが保護されていな
い場合、getAuthType() メソッドはヌルを戻します。
どちらのメソッドでも、戻されるデータは、サーブレットが配置されているアプリケーション・サーバーで
セキュリティーが使用可能になっているかどうかで異なります。
v セキュリティーが使用不能で、サーブレットが要求され、そのサーブレットが Web サーバー保護で構成
されている場合、getRemoteUser() メソッドはログインを戻し、getAuthType() は認証スキームを戻しま
す。
v セキュリティーが使用可能で、サーブレットが要求された場合、WebSphere 保護がサーブレットに構成
されていないときは、いずれのメソッドともヌルを戻します。
v セキュリティーが使用可能で、サーブレットが要求され、そのサーブレットが WebSphere 保護で構成さ
れている場合、getRemoteUser() メソッドはログインを戻し、getAuthType() メソッドは構成済み認証スキ
ームを戻します。
WebSphere セキュリティーによるリソース保護
WebSphere セキュリティー・システムでは、WebSphere リソース (サーブレット、JSP ファイル、および
HTML ファイルなど) へのアクセスを制御することができます。また、セキュリティー・システムの提供
するインフラストラクチャーにより、選択したセキュリティーが確実に実行されます。
WebSphere セキュリティーについての詳細は、以下のトピックを参照してください。
7 ページの『WebSphere セキュリティーの概要』
このトピックでは、WebSphere セキュリティー・アーキテクチャーの概要およびその機能について説
明します。
12 ページの『保護アプリケーションの開発』
WebSphere Application Server - Express の保護アプリケーションの作成については、このトピックを
参照してください。
6
WebSphere Application Server - Express Version 5.1 セキュリティー
68 ページの『保護アプリケーションのアセンブル』
配置のためにアプリケーションをアセンブルする場合、セキュリティー設定を指定することができま
す。詳しくは、このトピックを参照してください。
72 ページの『保護アプリケーションの配置』
このトピックでは、実行時に WebSphere Application Server - Express に保護アプリケーションを配置
またはインストールする場合のセキュリティーの考慮事項について説明します。
74 ページの『WebSphere セキュリティーの構成』
このトピックでは、WebSphere セキュリティーのさまざまなレベルを使用可能および構成する方法に
ついて説明します。
180 ページの『セキュリティー構成の調整』
WebSphere セキュリティーのパフォーマンス向上については、このトピックを参照してください。
WebSphere セキュリティーの概要
WebSphere Application Server - Express セキュリティーは、以下の図に示すように、階層的セキュリティ
ー・アーキテクチャーに基づいて構築されています。このトピックでは、各セキュリティー・レイヤーによ
って提供されるセキュリティー保護について説明します。以下の図に、WebSphere Security の稼働環境を構
成する構築ブロックを示します。
WebSphere セキュリティーの構築ブロックは以下のとおりです。
セキュリティー
7
v オペレーティング・システム (OS) セキュリティー
基底のオペレーティング・システム・セキュリティー・インフラストラクチャーは、WebSphere Security
Application にセキュリティー・サービスを提供します。このセキュリティーには、インストールされて
いる WebSphere 製品の機密ファイルを保護するため、ファイル・システム・セキュリティー・サポート
が組み込まれています。WebSphere 製品は、オペレーティング・システムのユーザー・レジストリーか
ら直接認証情報を取得するように構成することができます。
v ネットワーク・セキュリティー
ネットワーク・セキュリティー・レイヤーは、トランスポート・レベル認証だけでなく、メッセージ保
全性と暗号化も提供します。WebSphere Application Server - Express のサーバー間通信は、Secure
Socket Layer (SSL) および HTTPS を使用するように構成することができます。さらに、メッセージ保
護強化のために、IP Security および Virtual Private Network (VPN) を使用することもできます。
v JVM 1.4
Java 仮想マシン・セキュリティー・モデルは、オペレーティング・システム・レイヤーの上位セキュリ
ティー・レイヤーを提供します。
v Java 2 セキュリティー
Java 2 セキュリティー・モデルは、ファイル・システム、システム・プロパティー、ソケット接続、ス
レッド化、クラス・ロードなどを始めとし、システム・リソースに対するきめの細かいアクセス・コン
トロールを提供します。アプリケーション・コードは、保護リソースにアクセスするために必要な許可
を明示的に付与する必要があります。
v CORBA セキュリティー
セキュア ORB 間の呼び出しは、セキュリティー・コンテキストおよび必要な保護品質をセットアップ
する Common Security Interoperability Version 2 (CSIv2) セキュリティー・プロトコルを通して起動され
ます。WebSphere Application Server - Express は、Secure Authentication Service (SAS) セキュリティ
ー・プロトコルもサポートしています。
v J2EE セキュリティー
セキュリティー・コラボレーターは、J2EE ベース・セキュリティー・ポリシーを強制し、J2EE セキュ
リティー API をサポートします。
v WebSphere セキュリティー
WebSphere セキュリティーは、Web リソースおよび Java Management Extensions (JMX) 管理リソース
に対するアクセスにセキュリティー・ポリシーとサービスを統合的に強制します。セキュアな環境の要
件をサポートする WebSphere セキュリティー・テクノロジーと機能から構成されています。
WebSphere Application Server - Express 構成データは、XML 記述子ファイルに格納されます。この XML
構成ファイルは、普通、オペレーティング・システム・セキュリティーから保護を受けます。パスワード、
その他の機密構成データは、管理コンソールから変更することができます。したがって、管理コンソール
Web アプリケーションのセットアップに使用するデータ制約においては、グローバル・セキュリティーが
有効な場合に、管理コンソール・サーブレットおよび JSP ファイルに対するアクセスを SSL 接続経由に
限定します。
インストール後、管理コンソール HTTPS ポートは、デフォルトの自己署名証明書を持つ
DummyServerKeyFile.jks と DummyServerTrustFile.jks を使用するように構成されます。ダミー鍵とトラス
ト・ファイル証明書の使用は、安全ではありません。即時に、ユーザー自身の証明書を生成する必要があり
ます。最大限のセキュリティーを確保するには、まず、グローバル・セキュリティーを有効にした後、その
他の構成タスクを実行します。
WebSphere Application Server - Express サーバー同士は、CSIv2 と SAS の両セキュリティー・プロトコル
だけでなく、少なくとも、HTTP プロトコル または HTTPS プロトコルの一方を通して連携動作します。
CSIv2 と SAS の両プロトコルは、WebSphere Application Server グローバル・セキュリティーが有効にな
8
WebSphere Application Server - Express Version 5.1 セキュリティー
ったときに SSL を使用するように構成することができます。WebSphere Application Server - Express 管理
サブシステムは、SOAP JMX コネクターまたは RMI/IIOP JMX コネクターを使用して、管理コマンドと
構成データを引き渡します。
グローバル・セキュリティーが無効な場合、SOAP JMX コネクターは、HTTP プロトコルを使用し、
RMI/IIOP コネクターは TCP/IP プロトコルを使用します。グローバル・セキュリティーが有効な場合、
SOAP JMX コネクターは、常時、HTTPS プロトコルを使用します。グローバル・セキュリティーが有効
な場合、RMI/IIOP JMX コネクターは、SSL または TCP/IP を使用するように構成することが可能です。
機密構成データを保護するには、グローバル・セキュリティーを有効にした上で、SSL も有効にします。
アプリケーション・サーバー・セキュリティーを無効にしても、そのアプリケーション・サーバー内の管理
サブシステムは影響を受けません。管理サブシステムは、グローバル・セキュリティー構成のみによって制
御されます。アプリケーション・サーバー内の管理サブシステムとアプリケーション・コードの両方が、オ
プションのサーバー単位セキュリティー・プロトコル構成を共有します。
J2EE リソースに対するセキュリティーは、Web コンテナーによって提供されます。コンテナーには、宣言
セキュリティーとプログラム式セキュリティーという 2 種類のセキュリティーが用意されています。
宣言セキュリティーでは、データ保全性と機密性、認証要件、セキュリティー役割、およびアクセス・コン
トロールが、アプリケーション・セキュリティー構造にアプリケーションの外部形式で組み込まれていま
す。特に、デプロイメント記述子が、J2EE プラットフォームにおける、宣言セキュリティーの主要な手段
となります。WebSphere は、デプロイメント記述子から派生される情報、および開発者と管理者によって
XML 記述子ファイルで指定された情報を含む J2EE セキュリティー・ポリシーを維持しています。実行
時、コンテナーは、XML 記述子ファイルで定義されているセキュリティー・ポリシーを使用して、データ
制約とアクセス・コントロールを実行します。
宣言セキュリティーだけでは、アプリケーションのセキュリティー・モデルとして不足がある場合は、プロ
グラム・コードにプログラム式セキュリティーを使用してアクセス決定を行うことが可能です。
グローバル・セキュリティーが有効で、アプリケーション・サーバー・セキュリティーが、サーバー・レベ
ルで無効でない場合は、J2EE アプリケーション・セキュリティーが強制されます。セキュリティー・ポリ
シーが、Web リソースに対して指定されている場合は、その Web リソースが、Web クライアントから要
求されたときに、Web コンテナーがアクセス・コントロールを実行します。Web コンテナーは、指定され
た認証方法に従って、認証データが存在しない場合に、Web クライアントに対して認証データを要求しま
す。この要求により、データ制約に適合することが確認され、認証されたユーザーが、必要なセキュリティ
ー役割を持っていることが判別されます。
Web セキュリティー・コラボレーターは、実装されたアクセス・マネージャーを使用して、役割ベースの
アクセス・コントロールを実行します。アクセス・マネージャーは、デプロイメント記述子から派生したセ
キュリティー・ポリシーに基づいて与信決定を行います。認証されたユーザー・プリンシパルは、自身の持
つセキュリティー役割が、必須のセキュリティー役割の中に存在する場合に要求したサーブレットまたは
JSP ファイルにアクセスすることが許されます。
「サーブレット (Servlets)」ページと「JSP」ページでは、HttpServletRequest メソッドの isUserInRole() と
getUserPrincipal() を使用することができます。
WebSphere Application Server - Express の管理リソースには、セキュリティー役割に基づくアクセス制御の
概念が適用されています。これらのリソースには、JMX システム管理サブシステム、ユーザー・レジスト
リー、および JNDI ネーム・スペースが含まれます。WebSphere 管理サブシステムは、以下の 4 つの管理
セキュリティー役割を定義します。
セキュリティー
9
v モニター役割。構成情報と状況の表示のみを行うことができます。
v オペレーター役割。アプリケーション・サーバーの始動、アプリケーションの停止など実行時状態変更
を行うことのできるモニターですが、構成情報を変更することはできません。
v コンフィギュレーター役割。構成情報を変更できますが、実行時状態の変更はできないモニターです。
v 管理者役割。オペレーターとコンフィギュレーターを兼ねます。
役割がコンフィギュレーターである場合は、新規のアプリケーションやアプリケーション・サーバーのイン
ストールを含め、ほとんどの管理作業を実行することができます。グローバル・セキュリティーが有効な場
合、コンフィギュレーターでは、権限不足で実行できない構成タスクがあります。それらの構成タスクに
は、WebSphere Application Server - Express サーバーの識別情報とパスワードおよび LTPA パスワードと
鍵の変更、ユーザーへの管理セキュリティー役割の割り当てがあります。このような機密構成タスクでは、
管理役割が必要になります。
WebSphere Application Server - Express 管理セキュリティーは、グローバル・セキュリティーが有効なとき
に強制されます。WebSphere Application Server - Express グローバル・セキュリティーを有効にして、管理
サブシステム保全性を保護することを推奨します。アプリケーション・サーバー・セキュリティーは、保護
対象の機密情報が存在しない場合に選択的に無効にすることができます。
WebSphere Application Server - Express は、Java 2 セキュリティー・モデルを使用して、アプリケーショ
ン・コードを実行する機密保護機能のある環境を作成します。Java 2 セキュリティーでは、きめの細か
い、ポリシー・ベースのアクセス・コントロールを提供して、ファイル、システム・プロパティー、ソケッ
ト接続のオープン、ライブラリーのロードなどのシステム・リソースを保護します。J2EE 1.3 仕様では、
Web コンポーネントが持つべき一般的な Java 2 セキュリティー許可のセットが定義されています。それ
らのセキュリティー許可を、以下のテーブルに示します。
Web コンポーネントに対する J2EE セキュリティー許可セット
セキュリティー許可
ターゲット
アクション
java.lang.RuntimePermission
loadLibrary
java.lang.RuntimePermission
queuePrintJob
java.net.SocketPermission
*
接続
java.io.FilePermission
*
読み取り、書き込み
java.util.PropertyPermission
*
読み取り
WebSphere Application Server - Express Java 2 セキュリティーの実装は、J2EE 1.3 仕様に準拠していま
す。J2EE 1.3 仕様は、ファイル・システム内の任意のファイルに対する読み取りと書き込みファイル・ア
クセス許可を Web コンポーネントに付与しますが、アクセス許可が広範過ぎる場合があります。
WebSphere Application Server - Express デフォルト・ポリシーにより、Web コンポーネントには、Web モ
ジュールのインストール先であるサブディレクトリーとサブツリーに対する読み取り書き込み許可が付与さ
れます。すべての Java 仮想マシンと WebSphere Application Server - Express サーバー・プロセスに対す
るデフォルトの Java 2 セキュリティー・ポリシーは、java.policy ファイル (Java 仮想マシンに対するデフ
ォルト・ポリシー) と server.policy ファイル (すべての製品サーバー・プロセスに対するデフォルト・ポリ
シー) に格納されています。
ポリシー管理を簡単にするため、WebSphere Application Server - Express ポリシーは、コード・ベース (場
所) ではなくリソース・タイプに基づいています。埋め込みリソース、複数のアプリケーションに共有され
るライブラリー、および J2EE アプリケーションに対して、以下のようなデフォルト・ポリシー・ファイ
ルがあります。
10
WebSphere Application Server - Express Version 5.1 セキュリティー
v spi.policy。JavaMail および JDBC ドライバーなど、resources.xml に定義されている埋め込みリソースに
対するポリシー・ファイルです。
v library.policy。管理コンソールによって定義されている共有ライブラリーに対するポリシー・ファイルで
す。
v app.policy。J2EE アプリケーションに対するデフォルト・ポリシーです。
一般的に、アプリケーションは、J2EE 仕様の推奨許可の範囲内に、実行許可を収めるようにし、アプリケ
ーション・サーバー間で移植可能にします。ただし、アプリケーションによっては、より多くの許可を必要
とするものもあります。WebSphere Application Server - Express では各アプリケーションに対して 1 つの
ポリシー・ファイル (was.policy) が許され、アプリケーションと同梱にすることが可能であり、アプリケー
ションには、そのポリシー・ファイルによって特別な許可が付与されます。アプリケーションに特別な許可
を付与することは、システム保全性を損なう危険性があるため、慎重に処理する必要があります。
WebSphere Application Server - Express は、許可フィルター操作ポリシー・ファイルを使用して、アプリケ
ーション・インストール時にフィルター・リスト上にある許可を、アプリケーションが要求した場合にユー
ザーに警告を発し、違反したアプリケーションのインストールを失敗させることもできます。
例えば、アプリケーション・コードによる、WebSphere Application Server - Express アプリケーション・サ
ーバーの終了を防止するには、java.lang.RuntimePermission exitVM 許可をアプリケーションに付与しないよ
うにします。フィルター操作ポリシーは、filter.policy ファイル内の filterMask 要素によって定義されま
す。
WebSphere Application Server - Express は、実行時フィルター操作ポリシーに基づいて実行時許可フィルタ
ー操作許可を実行し、システム保全性に有害と思われる許可がアプリケーション・コードに付与されていな
いことも確認します。
WebSphere Application Server - Express は、そのセキュリティー実装の一部として、Java 2 セキュリティ
ーをサポートします。ただし、トラステッド・アプリケーションをデプロイする場合は、アプリケーショ
ン・サーバーの Java 2 セキュリティーを使用不可にすることができます。
グローバル・セキュリティー構成と Java 2 セキュリティー構成は、XML 構成ファイルのセット内に格納
されています。役割ベースのアクセス・コントロールと Java 2 セキュリティー許可ベースのアクセス・コ
ントロールの両方を使用して、構成データの保全性を保護します。システム・セキュリティーは、以下の方
法で維持されます。
v Java 2 セキュリティーが強制されると、アプリケーション・コードは、必須の WebSphere Application
Server - Express 実行時許可を付与された場合を除いて、構成データを管理する WebSphere Application
Server - Express 実行時クラスにアクセスできなくなります。
v Java 2 セキュリティーが強制されると、アプリケーション・コードは、必要なファイルの読み取りと書
き込み許可を付与された場合を除いて、WebSphere Application Server - Express 構成 XML ファイルに
アクセスできなくなります。
v JMX 管理サブシステムは、HTTP(S) 経由 SOAP および RMI/IIOP リモート・インターフェースを提供
して、アプリケーション・プログラムが、構成ファイルとデータの抽出および変更を行うことを許しま
す。グローバル・セキュリティーが有効な場合、アプリケーション・プログラムは、有効な認証データ
の提示を行うこと、およびセキュリティー識別情報が必要なセキュリティー役割を持っていることを条
件に、WebSphere Application Server - Express 構成を変更することができます。
セキュリティー
11
v Java 2 セキュリティーを無効にすることを許されているユーザーの場合は、WebSphere Application
Server - Express セキュリティー識別情報や認証データを含めて、WebSphere Application Server 構成を
変更することができます。したがって、管理者セキュリティー役割を持つユーザーに限り、Java 2 セキ
ュリティーを無効にすることが許されます。
v WebSphere Application Server - Express セキュリティー識別情報には、管理者役割が付与されているた
め、管理者役割を持つユーザーに限り、グローバル・セキュリティーの無効化、サーバー ID とパスワ
ードの変更、およびユーザーとグループに管理役割の対応付けを行うことが許されます。
その他の WebSphere Application Server - Express 実行時リソースも、同様な方法で保護されます。
WebSphere Application Server - Express グローバル・セキュリティーを有効にし、Java 2 セキュリティー
を強制することは非常に重要です。J2EE 仕様では、Web コンポーネントに対して、いくつかの認証方法が
定義されています。WebSphere Application Server - Express は、HTTP 基本認証、フォーム・ベース認証、
および HTTPS クライアント証明書認証をサポートします。HTTPS は、SSL 接続を使用して HTTP プロ
トコルを実行することを示します。SSL 接続においてサーバーは、認証ハンドシェーク中、クライアント
に対して必ず証明書を提示します。HTTPS クライアント証明書の認証では、認証ハンドシェークでクライ
アントもサーバーに対して認証のための証明書を提示する追加ステップが必要になります。これは、相互認
証とも呼ばれます。
クライアント証明書ログインの使用時、ブラウザー・クライアントにとっては、Web リソースが必要不可
欠または機密のデータ制約により構成されている場合の方が好都合です。ブラウザーが HTTP を使用し
て、Web リソースにアクセスする場合、Web コンテナーは自動的にアクセス先を HTTPS に変更します。
CSIv2 セキュリティー・プロトコルは、クライアント証明書認証もサポートします。相互認証による SSL
接続を構成することにより、HTTP サーバーと WebSphere Application Server - Express サーバー間に信頼
関係を確立することができます。
WebSphere Application Server - Express には、IBM HTTP Server (powered by Apache) または Domino
HTTP Server で使用することのできるプラグイン・モジュールが提供されています。このプラグインは、
クライアントの HTTP および HTTPS 要求を WebSphere Application Server - Express サーバーに転送し
ます。これらの要求および応答の交換が行われるトランスポートは、追加保護用に SSL を使用するよう構
成することができます。構成では、プラグインも WebSpehere Application Server - Express サーバーへの認
証に証明書を提供するよう指定できます。
保護アプリケーションの開発
IBM WebSphere Application Server - Express には、単独または他のサービスと共同で認証、許可、代行、
およびデータ保護を提供するセキュリティー・コンポーネントが用意されています。 WebSphere
Application Server - Express は、Java 2 Enterprise Edition (J2EE) の仕様に記載されているセキュリティー
機能もサポートしています。
アプリケーションの実行の準備ができるまでに 3 つの段階があります。
1. 開発
2. アセンブリー
3. 配置
ほとんどのセキュリティーは、アセンブリーの段階でアプリケーション用に構成されます。アセンブリーの
段階で構成されたセキュリティーは、デプロイメント記述子で宣言または定義されることから、宣言セキュ
リティーと呼ばれます。宣言セキュリティーは、セキュリティー・ランタイムによって実行されます。アプ
リケーション開発者は、このセキュリティー・ランタイムを認識する必要がありません。アプリケーション
12
WebSphere Application Server - Express Version 5.1 セキュリティー
によっては、アプリケーションのセキュリティー・モデルを表すのに宣言セキュリティーだけでは不十分な
場合があります。そのようなアプリケーションに対しては、方針に基づいたセキュリティーを使用します。
方針に基づいたセキュリティーの詳細については、次のトピックを参照してください。
v 『セキュア Web アプリケーションの開発』
v
16 ページの『フォーム・ログイン処理用のサーブレット・フィルターの開発』
v
20 ページの『フォーム・ログイン・ページの開発』
v
24 ページの『プログラマチック・ログインのための JAAS を使用した開発』
v
32 ページの『独自の J2C プリンシパル・マッピング・モジュールの開発』
v
34 ページの『カスタム・ユーザー・レジストリーの開発』
セキュア Web アプリケーションの開発
プログラマチック・セキュリティーは、宣言セキュリティーのみではアプリケーションのセキュリティー・
モデルを表すのに不十分であるときに、セキュリティー意識の高いアプリケーションによって使用されま
す。プログラマチック・セキュリティーは、以下の手順で構成されます。
1. 必要なセキュリティー・メソッドをサーブレットまたは JSP コードで追加する。
2. 役割名フィールドを使用して security-role-ref 要素を作成します。セキュリティー API の
isUserInRole() メソッドは、実際の役割名をパラメーターとして使用できるので、この要素は厳密には必
須ではありません。ただし、ソフトウェア・コンポーネントが再使用可能になるように役割参照を使用
するのを習慣としておいた方がよいでしょう。
フル・コードの例については、 15 ページの『例: セキュア Web アプリケーション・コード』を参照して
ください。
必要なセキュリティー・メソッドのサーブレット・コードでの追加
プログラマチック・セキュリティーは、HttpServletRequest インターフェースの以下の手順で構成されま
す。
v getRemoteUser()
このメソッドは、クライアントが認証に使用したユーザー名を戻します。いずれのユーザーも認証され
ない場合には、ヌルを戻します。
v isUserInRole (ストリング役割名)
このメソッドは、指定のセキュリティー役割がリモート・ユーザーに認可された場合に true を戻しま
す。指定の役割がリモート・ユーザーに認可されない場合、またはいずれのユーザーも認証されない場
合には、false を戻します。
v getUserPrincipal()
このメソッドは、リモート・ユーザー名が含まれている java.security.Principal オブジェクトを戻しま
す。いずれのユーザーも認証されない場合には、ヌルを戻します。
プログラマチック・サーブレット・セキュリティー・メソッドは、サーブレットの
doGet()、doPost()、doPut()、doDelete() サービス・メソッドのいずれかに追加することができます。次に、
プログラマチック・セキュリティー API の使用法を例示します。
public void doGet(HttpServletRequest request, HttpServletResponse response) {
...
// to get remote user using getUserPrincipal()
java.security.Principal principal = request.getUserPrincipal();
String remoteUser = principal.getName();
// to get remote user using getRemoteUser()
セキュリティー
13
remoteUser = request.getRemoteUser();
// to check if remote user is granted Mgr role
boolean isMgr = request.isUserInRole(“Mgr”);
// use the above information in any way as needed by the application
...
}
役割名フィールドでの security-role-ref 要素の作成
このステップは、アプリケーションをプログラマチックにセキュアにするのに必要です。開発時に
security-role-ref が作成されていない場合には、それがアセンブリー段階で作成されていることを確認してく
ださい。
isUserInRole() メソッドを使用した場合には、このメソッドに渡されている役割名が含まれる役割名要素に
よりデプロイメント記述子で security-role-ref 要素を宣言する必要があります。実際の役割は、アプリケー
ションのアセンブリー・ステージで作成されるため、開発者は論理的役割を論理名として使用し、
security-role-ref 要素の記述でその役割を実際の役割にリンクさせるのに十分なヒントをアセンブラーに提供
することができます。アセンブリー・ステージでアセンブラーは、役割名を実際の役割にリンクするための
役割リンクのサブ要素を作成します。
次のステップを実行すると、WebSphere Development Studio Client を使用した開発中に、security-role-ref
要素を作成することができます。
1. アプリケーションの web.xml ファイルを開きます。このファイルは、WEB-INF ディレクトリーにあり
ます。
2. 「セキュリティー (Security)」タブをクリックします。
3. 「セキュリティー役割 (Security roles)」ウィンドウの横の「追加 (Add)」をクリックします。セキュリ
ティー役割の名前と説明を入力します。必要な役割をすべて追加し終えるまで、このステップを繰り返
します。
4. 「サーブレット (Servlets)」タブをクリックします。
5. 「サーブレット (Servlets)」ウィンドウで、security-role-ref 要素を定義するサーブレットを選択します。
6. 「許可された役割 (Authorized roles)」ウィンドウの横の「編集 (Edit)」をクリックします。
7. 該当する役割を選択します。「OK」をクリックします。
8. web.xml ファイルを保管します。
論理的役割の定義が役立つ例としては、Web アプリケーションで外部リソースにアクセスし、その固有の
許可テーブル (リモート・ユーザー・マッピングへの外部リソース) を使用して外部リソースへのアクセス
を制御する場合があります。この場合には、getUserPrincipal() または getRemoteUser() メソッドを使用して
リモート・ユーザーを取得できます。続いてアプリケーションは、それ自体の許可テーブルを参照して許可
をチェックすることができます。リモート・ユーザー情報を使用しても、データベースなどの外部ソースか
ら対応するユーザー情報を取り出すことができます。isUserInRole() も同様に使用することができます。
その例を以下に示します。
<security-role-ref>
<description>Provide hints to assembler for linking
this role-name to actual role here</description>
<role-name>Mgr</role-name>
</security-role-ref>
アセンブリー時に、アセンブラーは以下に示すような役割リンクを作成します。
14
WebSphere Application Server - Express Version 5.1 セキュリティー
<security-role-ref>
<description>Hints provided by developer to
map role-name to role-link</description>
<role-name>Mgr</role-name>
<role-link>Manager</role-link>
</security-role-ref>
例: セキュア Web アプリケーション・コード: この例では、プログラマチック・セキュリティー・モデ
ルを使用する Web アプリケーション (サーブレット) について説明します。この例は、プログラマチッ
ク・セキュリティー・モデルを使用する 1 つの方法であり、必ずしも唯一の方法ではありません。アプリ
ケーションは、getUserPrincipal()、isUserInRole()、および getRemoteUser() メソッドによって、そのアプリ
ケーションにとって意味のある方法で戻される情報を使用することができます。ただし、可能な場合には、
宣言セキュリティー・モデルを使用することを強くお勧めします。
import javax.servlet.*;
public class HelloServlet extends HttpServlet {
public void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, java.io.IOException {
}
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, java.io.IOException {
String s = “Hello”;
// get remote user using getUserPrincipal()
java.security.Principal principal = request.getUserPrincipal();
String remoteUserName = “”;
if (principal != null) {
remoteUserName = principal.getName();
}
// get remote user using getRemoteUser()
String remoteUser = request.getRemoteUser();
// check if remote user is granted Mgr role
boolean isMgr = request.isUserInRole(“Mgr”);
// display Hello username for managers and bob.
if (isMgr || remoteUserName.equals(“bob”)) {
s = “Hello ” + remoteUserName;
}
String message = “<html> ¥n” +
“<head><title>Hello Servlet</title></head>¥n” +
“<body> ¥n” +
“<h1> ” + s + “</h1>¥n ”;
byte[] bytes = message.getBytes();
// displays “Hello” for ordinary users and
// displays “Hello username” for managers and “bob.”
response.getOutputStream().write(bytes);
}
}
以下に示すように、サーブレットを開発後に、HelloServlet 用のセキュリティー役割参照を作成することが
できます。
<security-role-ref>
<description>Manager</description>
<role-name>Mgr</role-name>
</security-role-ref>
セキュリティー
15
フォーム・ログイン処理用のサーブレット・フィルターの開発
フォーム・ベースのログインのメカニズムを備えたログイン画面のルック・アンド・フィールは制御するこ
とができます。このメカニズムを使用すると、フォーム・ベースのログイン・ページを定義して、ユーザー
ID とパスワードを取り出すことができます。また、認証が失敗したときに表示されるエラー・ページを指
定することもできます。
サーブレット・フィルターを使用すると、要求と応答を動的にインターセプトして、要求または応答に含ま
れる情報を変換または使用することができます。単一のサーブレットまたは複数のサーブレットのグループ
に、1 つ以上のサーブレット・フィルターを接続できます。サーブレット・フィルターは、JSP ページおよ
び HTML ページにも接続することができます。接続されたサーブレット・フィルターはすべて、サーブレ
ットの起動前に呼び出されます。
フォーム・ベースのログインとサーブレット・フィルターの両方が、 Servlet 2.3 仕様に準拠したすべての
Web コンテナーでサポートされています。フォーム・ログイン・サーブレットは認証を実行し、サーブレ
ット・フィルターは追加の認証や情報の監査またはロギングに使用されます。
サーブレット・フィルターでログイン前やログイン後のアクションを実行するために、フォーム・ログイ
ン・ページまたは /j_security_check URL に対してサーブレット・フィルターを構成することができま
す。j_security_check は、 j_username パラメーター (ユーザー名を含む) および j_password パラメーター
(パスワードを含む) とともにフォーム・ログイン・ページによってポストされます。その後、サーブレッ
ト・フィルターはユーザー名とパスワードの情報を使用して追加の認証やその他の処理を実行することがで
きます。 18 ページの『例: サーブレット・フィルター』で例を参照してください。
サーブレット・フィルターは、javax.servlet.Filter クラスを実装する必要があります。実装する必要がある
Filter クラスを次に示します。
v init(javax.servlet.FilterConfig cfg)
このメソッドは、サーブレット・フィルターのサービスが開始されたときに一度だけコンテナーによっ
て呼び出されます。このメソッドに渡される FilterConfig パラメーターには、サーブレット・フィルタ
ーの初期化パラメーターが含まれています。
v destroy()
このメソッドは、サーブレット・フィルターのサービスが休止したときにコンテナーによって呼び出さ
れます。
v doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
このメソッドは、コンテナーがサーブレットそのものを呼び出す前に、このフィルターにマップされた
すべてのサーブレット要求について、コンテナーによって呼び出されます。このメソッドに渡される
FilterChain パラメーターを使用すると、フィルター・チェーン内の次のフィルターを呼び出すことがで
きます。要求された元のサーブレットは、チェーン内の最後のフィルターが chain.doFilter() メソッドを
呼び出したときに実行されます。したがって、すべてのフィルターが chain.doFilter() メソッドを呼び出
す必要があります。フィルター・コードで追加の認証検査が失敗した場合、元のサーブレットのインス
タンスを生成する必要はありません。この場合、chain.doFilter() メソッドを呼び出す必要はありません。
代わりに別のエラー・ページに転送することができます。
サーブレットが多数のサーブレット・フィルターにマップされている場合、各サーブレット・フィルター
は、アプリケーションのデプロイメント記述子 (web.xml) にリストされている順序で呼び出されます。
サーブレット・フィルターの例を次に示します。このログイン・フィルターは、ログイン前およびログイン
後のアクションを実行するために /j_security_check にマップすることができます。
16
WebSphere Application Server - Express Version 5.1 セキュリティー
import javax.servlet.*;
public class LoginFilter implements Filter {
protected FilterConfig filterConfig;
// Called once when this filter is instantiated. If this is mapped to
// j_security_check, called very first time j_security_check is invoked.
public void init(FilterConfig filterConfig) throws ServletException {
this.filterConfig = filterConfig;
}
public void destroy() {
this.filterConfig = null;
}
// Called for every request that is mapped to this filter. If mapped to
// j_security_check, called for every j_security_check action
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws java.io.IOException, ServletException {
// perform pre-login action here
// calls the next filter in chain. j_security_check if
// this filter is mapped to j_security_check.
chain.doFilter(request, response);
// perform post-login action here.
}
}
サーブレット・フィルターのクラス・ファイルは、アプリケーションの WEB-INF/classes ディレクトリー
に置く必要があります。
サーブレット・フィルターの構成
WebSphere Development Studio Client を使用して、サーブレット・フィルターを構成できます。以下のス
テップに従ってください。
1. Web プロジェクトの web.xml ファイル (WEB-INF ディレクトリーにあります) を開きます。
2. サーブレット・フィルターに名前を割り当て、対応するインプリメンテーション・クラスをサーブレッ
ト・フィルターに割り当てることができます。オプションで、サーブレット・フィルターの init() メソ
ッドに渡される初期化パラメーターを割り当てることもできます。
サーブレット・フィルターを構成するには、web.xml グラフィカル・インターフェースの「サーブレッ
ト (Servlets)」タブをクリックします。「初期設定 (Initialization)」をクリックして、パラメーターを指
定します。
サーブレット・フィルターの構成後、アプリケーションのデプロイメント記述子 (web.xml) に次のよう
なサーブレット・フィルター構成が組み込まれます。
<filter id=“Filter_1”>
<filter-name>LoginFilter</filter-name>
<filter-class>LoginFilter</filter-class>
<description>Performs pre-login and post-login operation</description>
<init-param>// optional
<param-name>ParamName</param-name>
<param-value>ParamValue</param-value>
</init-param>
</filter>
注:「ソース (Source)」タブをクリックすると、web.xml ファイルのソースを表示できます。
セキュリティー
17
3. サーブレットまたは URL パターンを、サーブレット・フィルターにマップすることができます。
「URL マッピング (URL mappings)」で、「追加 (Add)」をクリックし、サーブレットまたは URL
パターンを指定します。
サーブレットまたは URL へサーブレット・フィルターをマップすると、アプリケーションのデプロイ
メント記述子 (web.xml) に次のようなサーブレット・マッピングが組み込まれます。
<filter-mapping>
<filter-name>LoginFilter</filter-name>
<url-pattern>/j_security_check</url-pattern> // can be servlet
<servlet>servletName</servlet>
</filter-mapping>
サーブレット・フィルターは、CustomLoginServlet の置換に使用できます。サーブレット・フィルターは、
追加認証、監査、およびロギングの実行にも使用できます。
例: サーブレット・フィルター: 以下の例では、フォーム・ログイン時にログイン前およびログイン後の
処理を行うためのサーブレット・フィルターの 1 つの使用法について説明します。このコード例のリーガ
ル情報については、 202 ページの『コードに関するライセンス情報および特記事項』を参照してください。
// Servlet Filter source code: LoginFilter.java
/**
* A Servlet filter example: This example filters j_security_check and
* performs pre-login action to determine if the user trying to log in
* is in the revoked list. If the user is in revoked list, an error is
* sent back to the browser.
*
* This filter reads the revoked list file name from the FilterConfig
* passed in the init() method. Reads the revoked user list file and
* creates a revokedUsers list.
*
* When doFilter method is called, the user being logged in is checked
* to make sure that the user is not in the revoked User list.
*
*/
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
public class LoginFilter implements Filter {
protected FilterConfig filterConfig;
java.util.List revokeList;
/**
* init() : init() method called when the filter is instantiated. This
* filter is instantiated first time j_security_check is invoked for the
* application (when a protected servlet in the application is accessed).
*/
public void init(FilterConfig filterConfig) throws ServletException {
this.filterConfig = filterConfig;
// read revoked user list
revokeList = new java.util.ArrayList();
readConfig();
}
/**
* destroy() : destroy() method called when the filter is taken out of service.
*/
public void destroy() {
18
WebSphere Application Server - Express Version 5.1 セキュリティー
this.filterConfig = null;
revokeList = null;
}
/**
* doFilter() : doFilter() method called before the servlet that this filter
* is mapped is invoked. Since this filter is mapped to j_security_check,
* this method is called before j_security_check action is posted.
*/
public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain chain)
throws java.io.IOException, ServletException {
HttpServletRequest req = (HttpServletRequest)request;
HttpServletResponse res = (HttpServletResponse)response;
// pre login action
// get username
String username = req.getParameter(“j_username”);
// if user is in revoked list send error
if ( revokeList.contains(username) ) {
res.sendError(javax.servlet.http.HttpServletResponse.SC_UNAUTHORIZED);
return;
}
// call next filter in the chain : let j_security_check authenticate user
chain.doFilter(request, response);
// post login action
}
/**
* readConfig() : Reads revoked user list file and creates a revoked user list.
*/
private void readConfig() {
if ( filterConfig != null ) {
// get the revoked user list file and open it.
BufferedReader in;
try {
String filename = filterConfig.getInitParameter(“RevokedUsers”);
in = new BufferedReader( new FileReader(filename));
}
catch (FileNotFoundException fnfe) {
return;
}
// read all the revoked users and add to revokeList.
String userName;
try {
while ( (userName = in.readLine()) != null ) {
revokeList.add(userName);
}
}
catch (IOException ioe) {
}
}
}
}
以下の例では、LoginFilter 構成および j_security_check へのマッピングをリストするアプリケーション・デ
プロイメント記述子 (web.xml) の一部を示します。
セキュリティー
19
<filter id=“Filter_1”>
<filter-name>LoginFilter</filter-name>
<filter-class>LoginFilter</filter-class>
<description>Performs pre-login and post-login operation</description>
<init-param>
<param-name>RevokedUsers</param-name>
<param-value>
/QIBM/UserData/WebASE51/ASE/instance/installedApps/application/revokedUsers.lst
</param-value>
</init-param>
</filter-id>
<filter-mapping>
<filter-name>LoginFilter</filter-name>
<url-pattern>/j_security_check</url-pattern>
</filter-mapping>
取り消されたユーザー・リスト・ファイルの例を以下に示します。
user1
cn=user1,o=ibm,c=us
user99
cn=user99,o=ibm,c=us
フォーム・ログイン・ページの開発
Web クライアント (ブラウザー) は、以下のメカニズムのいずれかを使用して、Web サーバーに対してユ
ーザーを認証します。
v HTTP 基本認証
Web サーバーは Web クライアントに認証を要求し、Web クライアントは HTTP ヘッダー内のユーザ
ーおよびパスワード情報を渡します。
v HTTPS クライアント認証
このメカニズムでは、ユーザー (Web クライアント) は公開鍵証明書を所有する必要があります。Web
クライアントは、クライアント証明書を要求している Web サーバーにこの証明書を送信します。これ
は、HTTPS プロトコルを使用する強力な認証メカニズムです。
v フォーム・ベース認証
この認証メカニズムを使用して、ログイン画面の外観を制御することができます。
HTTP 基本認証では、ユーザー・パスワードは単純な Base64 エンコード方式で Web クライアントから
Web サーバーに送信されます。フォーム・ベース認証では、ユーザー・パスワードは非暗号化テキストで
ブラウザーから Web サーバーに送信されます。したがって、HTTP 基本認証もフォーム・ベース認証もと
もに、HTTPS が使用されない場合にはそれほど安全ではありません。
Web アプリケーションのデプロイメント記述子には、使用する認証メカニズムに関する情報が含まれてい
ます。フォーム・ベース認証が使用されるときには、デプロイメント記述子にもログインおよびエラー・ペ
ージ用のエントリーが含まれています。ログイン・ページは、HTML ページまたは JSP ページのいずれか
です。このログイン・ページは、セキュアなリソース (サーブレット、JSP、HTML ページなど) がアプリ
ケーションからアクセスされるときに Web クライアント上に表示されます。認証が失敗した場合には、エ
ラー・ページが表示されます。独自のログイン・ページとエラー・ページを作成して、アプリケーションの
ニーズに適合させることができます。アプリケーションのアセンブラー時に、アセンブラーはアプリケーシ
ョンのための認証メカニズムを設定し、デプロイメント記述子内のログインおよびエラー・ページを設定す
ることができます。
フォーム・ログインは、サーブレットの sendRedirect() メソッドを使用しますが、このメソッドは、ユーザ
ーと何度か関係するからです。sendRedirect() メソッドは、以下に説明するように、フォーム・ログイン中
に 2 回使用されます。
20
WebSphere Application Server - Express Version 5.1 セキュリティー
v sendRedirect() メソッドは、最初はフォーム・ログイン・ページを Web ブラウザーに表示します。この
メソッドは後で、Web ブラウザーを最初に要求された保護ページにリダイレクトします。
sendRedirect(String URL) メソッドは Web ブラウザーに対して、HTTP GET (HTTP POST ではありま
せん) 要求を使用して、URL で指定されたページを取得するように指示します。HTTP POST が保護サ
ーブレットまたは JSP ファイルへの最初の要求で、それよりも前に認証またはログインが行われていな
かった場合は、HTTP POST は要求されたページに配信されません。ただし、HTTP GET は配信されま
す。それは、フォーム・ログインは、ログインが行われた後に要求されたページを表示しようとする
HTTP GET 要求として機能する sendRedirect() メソッドを使用するからです。
v HTTP POST を使用すると、保護されていない HTML フォームがユーザーからデータを収集し、そのデ
ータを処理するために、保護されているサーブレットまたは JSP ファイルにこのデータをポストしたの
に、そのユーザーはリソースを得るためにログインしていない、というシナリオを経験するかもしれま
せん。このシナリオを回避するには、保護されているサーブレットまたは JSP ファイルに対してアプリ
ケーションが HTTP POST アクションを実行する前に、ユーザーに強制的にフォーム・ログイン・ペー
ジを使用させるよう、Web アプリケーションまたは許可を構成します。
詳細およびコード・サンプルについては、『例: フォーム・ログイン』を参照してください。
1. フォーム・ベース認証を行うためにフォーム・ログイン・ページおよびコンポーネントを作成する。
2. エラー・パージを作成する。エラー・ページは、認証を再試行するように、または適切なエラー・メッ
セージを表示するようにプログラムすることができます。
3. (オプション) フォーム・ログアウト・ページを作成する。
4. WAR ファイル内でログイン、エラー、およびログアウト・ページをアセンブルする。これらのページ
は、WAR ファイルのルート・ディレクトリーに相対的に配置してください。例えば、ログイン・ペー
ジがデプロイメント記述子内で /login.html として構成されている場合には、このログイン・ページは
WAR ファイルのルート・ディレクトリー内に配置します。
例: フォーム・ログイン: 以下の例は、フォームを HTML ページにコード化する方法を示しています。
<form method=“POST” action=“j_security_check”>
<input type=“text” name=“j_username”>
<input type=“text” name=“j_password”>
<¥form>
ログイン・フォームのアクションは、常に j_security_check である必要があります。j_username 入力フ
ィールドは、ユーザー名を取得するために使用してください。j_password 入力フィールドは、ユーザーの
パスワードを取得するために使用してください。
Web クライアントから要求を受信すると、Web サーバーは構成した Form ページをクライアントに送信
し、オリジナルの要求を保存します。Web サーバーは、Web クライアントから入力済みのフォーム・ペー
ジを受信すると、そのフォームからユーザー名とパスワードを抽出し、ユーザーを認証します。認証が正常
に行われると、Web サーバーは呼び出しをオリジナルの要求にリダイレクトします。認証が失敗した場
合、Web サーバーは呼び出しを構成済みのエラー・ページにリダイレクトします。
HTML ログイン・ページの例を次に示します。
<!-- login.html -->
<!DOCTYPE HTML PUBLIC “-//W3C/DTD HTML 4.0 Transitional//EN”>
<html>
<head>
<meta http-equiv=“Pragma” content=“no-cache”>
<title>Security FVT Login Page </title>
</head>
<body>
セキュリティー
21
<h2>Form Login</h2>
<form method=“post” action=“j_security_check”>
<p>
<strong>You may have entered an invalid user ID
or password. To correct the problem, please enter
your correct user ID and password. If you have
forgotten your user ID or password, please contact
the server administrator.</strong>
</p>
<p>
<strong>Please enter user ID and password:</strong>
<br>
<strong>User ID</strong>
<input type=“text” size=“20” name=“j_username”>
<strong>Password</strong>
<input type=“password” size=“20” name=“j_password”>
</p>
<p>
<strong>And then click this button:</strong>
<input type=“submit” name=“login” value=“Login”>
</p>
</form>
</body>
</html>
以下に、JSP ファイルにおけるエラー・ページの例を示します。
<!DOCTYPE HTML PUBLIC “-//W3C/DTD HTML 4.0 Transitional//EN”>
<html>
<head><title>A Form login authentication failure occurred</head></title>
<body>
<H1><B>A Form login authentication failure occurred</H1></B>
<P>Authentication may fail one of many reasons. Some possibilities include:
<OL>
<LI>The user-id or password may be entered incorrectly; either misspelled or the
wrong case was used.
<LI>The user-id or password does not exist, has expired, or has been disabled.
</OL>
</P>
</body>
</html>
フォーム・ベース認証を使用するように Web アプリケーションを構成すると、デプロイメント記述子に
は、次に示すようなログイン構成が含まれます。
<login-config id=“LoginConfig_1”>
<auth-method>FORM</auth-method>
<realm-name>Example Form-Based Authentication Area</realm-name>
<form-login-config id=“FormLoginConfig_1”>
<form-login-page>/login.html</form-login-page>
<form-error-page>/error.jsp</form-error-page>
</form-login-config>
</login-config>
次に、サンプル Web アプリケーション・アーカイブ (WAR) のディレクトリー構造を示します。これらの
例のログインおよびエラー・ページを示しています。
META-INF
META-INF/MANIFEST.MF
login.html
22
WebSphere Application Server - Express Version 5.1 セキュリティー
error.jsp
WEB-INF/
WEB-INF/classes/
WEB-INF/classes/aServlet.class
フォーム・ログアウト
フォーム・ログアウトというメカニズムを使用して、ユーザーは、すべての Web ブラウザー・セッション
を閉じることなく、アプリケーションからログアウトすることができます。ユーザーがログアウトした後
は、保護されている Web リソースへのアクセスには再認証が必要となります。この機能は、J2EE 規格で
は必須ではありませんが、WebSphere セキュリティーでの追加機能として提供されています。
フォーム・ログアウトは、以下の方法で機能します。
1. ログアウト・フォーム URI の URI が Web ブラウザーに指定される。
2. ブラウザーがフォームをロードする。
3. ユーザーがフォームのサブミット・ボタンをクリックしてログアウトする。
4. WebSphere セキュリティー・コードがユーザーをログアウトする。
5. ログアウトに際し、ユーザーは、ログアウトの出口ページにリダイレクトされる。
フォーム・ログアウトは、いかなるデプロイメント記述子内の属性も必要としません。これは、単に、Web
アプリケーションと共に含まれている HTML ファイルまたは JSP ファイルです。フォーム・ログアウ
ト・ページは、大半の HTML フォームに類似しています。ただし、フォーム・ログアウト・ページには、
フォーム・ログイン・ページと同様に、Web コンテナーによって認識される専用の POST アクションがあ
ります。これにより、Web コンテナーはこのアクションを専用の内部 WebSphere フォーム・ログアウ
ト・サーブレットにディスパッチします。フォーム・ログアウト・ページ内の POST アクションは
ibm_security_logout の値を持つ必要があります。
ログアウト出口ページは、ログアウト・フォームに指定することができます。出口ページは、ユーザーがロ
グアウトした後でリダイレクトされる先の HTML または JSP ファイルとすることができます。ログアウ
ト出口ページは、ログアウト・フォームと同じ Web アプリケーション内に常駐させる必要があります。ロ
グアウト出口ページは、単に、フォーム・ログアウト・ページ内のパラメーターとして指定されます。ログ
アウト出口ページが指定されていない場合は、デフォルトのログアウト HTML メッセージがユーザーに戻
されます。
以下は、HTML ログアウト・フォームの例です。このフォームは、ログアウト後にユーザーをログイン・
ページへリダイレクトして戻すログアウト出口ページを構成します。
<!DOCTYPE HTML PUBLIC “-//W3C/DTD HTML 4.0 Transitional//EN”>
<html>
<head>
<meta http-equiv=“Pragma” content=“no-cache”>
<title>Logout Page </title>
<head>
<body>
<h2>Sample Form Logout</h2>
<form method=“post” action=“ibm_security_logout” name=“logout”>
<p>
<strong> Click this button to logout:</strong>
<input type=“submit” name=“logout” value=“Logout”>
<input type=“hidden” name=“logoutExitPage” value=“/login.html”>
</p>
</form>
</body>
</html>
セキュリティー
23
プログラマチック・ログインのための JAAS を使用した開発
Java Authentication and Authorization Service (JAAS) は、認証のための戦略的 API を表し、CORBA プロ
グラマチック・ログイン API に置き換わるものです。 さらに、WebSphere Application Server - Express
には、JAAS への拡張機能がいくつか備わっています。
アプリケーションがカスタム JAAS ログイン構成を使用している場合は、カスタム JAAS ログイン構成が
正しく定義されていることを確認してください。詳しくは、 177 ページの『Java 認証および許可サービ
ス・ログインの構成』を参照してください。
JAAS API の一部は Java 2 セキュリティー許可によって保護されています。これらの API がアプリケー
ション・コードによって使用されている場合には、これらの許可がアプリケーションの was.policy ファイ
ルに追加されていることを確認してください。詳細については、 169 ページの『was.policy ファイルの構
成』を参照してください。Java 2 セキュリティー許可によって保護されている API について詳しくは、
J2SDK、JAAS、および WebSphere Application Server - Express API の javadoc を参照してください。 次
に、本文書に記載のサンプル・コードで使用されている API の一部と、これらの API が必要とする Java
2 セキュリティー許可をリストします。
v javax.security.auth.login.LoginContext コンストラクターは、javax.security.auth.AuthPermission
createLoginContext によって保護されます。
v javax.security.auth.Subject.doAs() および com.ibm.websphere.security.auth.WSSubject.doAs() は、
javax.security.auth.AuthPermission doAs によって保護されます。
v javax.security.auth.Subject.doAsPrivileged() および
com.ibm.websphere.security.auth.WSSubject.doAsPrivileged() は、javax.security.auth.AuthPermission
doAsPrivileged によって保護されます。
WebSphere Application Server - Express には、以下の JAAS への拡張機能が提供されています。
v com.ibm.websphere.security.auth.WSSubject
JAAS 1.0 仕様での設計上のミスのため、javax.security.auth.Subject.getSubject() は、
java.security.AccessController.doPrivileged() コード・ブロック内での実行のスレッドに関連付けられている
Subject を戻しません。このことは、問題含みで望ましくない作業の原因となる一貫性のない振る舞いを
示す可能性があります。com.ibm.websphere.security.auth.WSSubject は Subject を実行のスレッドに関連付
ける予備手段となります。
com.ibm.websphere.security.auth.WSSubject は、JAAS モデルを許可検査のための J2EE リソースに拡張し
ます。Subject が com.ibm.websphere.security.auth.WSSubject.doAs() 内での実行のスレッドと関連付けられ
ている場合、または、com.ibm.websphere.security.auth.WSSubject.doAsPrivileged() コード・ブロックに製品
証明書が含まれている場合には、Subject は、J2EE リソース許可検査のために使用されます。詳しく
は、『com.ibm.websphere.security.auth.WSSubject』を参照してください。
v WebSphere JAAS ログイン構成
WebSphere は、アプリケーションの JAAS ログイン構成を提供し、WebSphere セキュリティー・ランタ
イムへのプログラマチック認証を実行します。これらの WebSphere JAAS ログイン構成は、入力された
認証データに基づいて、WebSphere で構成された認証メカニズム (SWAM または LTPA) およびユーザ
ー・レジストリー (LocalOS、LDAP または Custom) に対して認証を行います。これらの JAAS ログイ
ン構成からの認証済みサブジェクトには、J2EE 役割ベースで保護されているリソースの許可検査を行う
ために WebSphere セキュリティー・ランタイムが使用できる必須のプリンシパルおよび証明書が含まれ
ています。 以下に WebSphere Application Server - Express よって提供される JAAS ログイン構成を示
します。
24
WebSphere Application Server - Express Version 5.1 セキュリティー
– WSLogin JAAS ログイン構成
これは、Java サーブレットおよび JavaServer Pages が使用することのできる汎用 JAAS ログイン構
成で、例えば、認証を実行します。認証は、WebSphere セキュリティー・ランタイムへ受け渡される
ユーザー ID とパスワード、またはトークンを基にしています。しかし、これはクライアント・コン
テナー・デプロイメント記述子内で指定された CallbackHandler を認めません。
注: WSLogin JAAS ログイン構成で認証されるサブジェクトには、
com.ibm.websphere.security.auth.WSPrincipal および com.ibm.websphere.security.auth.WSCredential が含ま
れます。 認証済みの Subject が com.ibm.websphere.security.auth.WSSubject.doAs() (またはその他の
doAs() メソッド) で渡された場合には、WebSphere セキュリティー・ランタイムは、Subject
com.ibm.websphere.security.auth.WSCredential に基づいて、J2EE リソースの許可検査を行うことができ
ます。
WSLoginModuleImpl インスタンスおよび WSClientLoginModuleImpl インスタンスによって生成され
た Subject オブジェクトには、WSPrincipal インターフェースを実装するプリンシパルが含まれていま
す。 WSPrincipal オブジェクトに getCredential() メソッドを使用すると、WSCredential インターフェ
ースを実装しているオブジェクトが戻されます。WSCredential オブジェクト・インスタンスは、
Subject インスタンスの PublicCredentials リストにも含まれています。getCredential() メソッドを使用
する代わりに、PublicCredentials リストから WSCredential オブジェクトを取り出してください。
WSSubject クラスの getCallerPrincipal() メソッドは、呼び出し側のセキュリティー ID を表すストリ
ングを戻します。 戻りの型は、EJBContext インターフェース (java.security.Principal である) の
getCallerPrincipal() メソッドとは異なります。
J2C DefaultPrincipalMapping モジュールによって生成される Subject オブジェクトには、リソース・
プリンシパルと PasswordCredentials リストが含まれています。このリソース・プリンシパルは、呼び
出し元を表します。
v ユーザー定義の JAAS ログイン構成
ユーザーは、他の JAAS ログイン構成を定義することができます。 詳細については、 177 ページの
『Java 認証および許可サービス・ログインの構成』を参照してください。これらのログイン構成を使用
して、カスタマー認証メカニズムに対してプログラマチック認証を行います。ただし、これらのカスタ
マー定義の JAAS ログイン構成からのサブジェクトに、必須のプリンシパルおよび信任状が含まれてい
ない場合には、許可検査を行うための WebSphere セキュリティー・ランタイムは、そのサブジェクトを
使用できないことがあります。
JAAS でのプログラマチック・ログインの場合、製品には javax.security.auth.callback.CallbackHandler イン
ターフェースのインプリメンテーションが提供されています。これは、
この
com.ibm.websphere.security.auth.callback.WSCallbackHandlerImpl と呼ばれています。
com.ibm.websphere.security.auth.callback.WSCallbackHandlerImpl によって、アプリケーションは認証データを
WebSphere LoginModule に “push” して認証を行うことができます。これは、サーバー・サイド・アプリケ
ーション・コードで ID を認証し、その ID を使用してダウンストリーム J2EE リソースを起動する場合
に役立ちます。詳細については、 26 ページの『例: JAAS プログラマチック・ログイン』を参照してくだ
さい。
WebSphere Application Server - Express での JAAS の使用についての詳細は、次のトピックを参照してく
ださい。
v
27 ページの『JAAS 認証およびログイン構成のカスタマイズ』
v
30 ページの『JAAS ログインからの根本原因となるログイン例外の検出』
セキュリティー
25
例: JAAS プログラマチック・ログイン: 次の例で、アプリケーション・プログラムが JAAS 認証を使用
してプログラマチック・ログインを行う方法を示します。
LoginContext lc = null;
try {
lc = new LoginContext(“WSLogin”,
new WSCallbackHandlerImpl(“userName”, “realm”, “password”));
}
catch (LoginException le) {
System.out.println(“Cannot create LoginContext. ” + le.getMessage());
// insert error processing code
}
catch(SecurityException se) {
System.out.println(“Cannot create LoginContext.” + se.getMessage();
// Insert error processing
}
try {
lc.login();
}
catch(LoginExcpetion le) {
System.out.printlin(“Fails to create Subject. ” + le.getMessage());
// Insert error processing code
}
上記の例で示したように、新規 LoginContext は WSLogin ログイン構成および WSCallbackHandlerImpl
CallbackHandler で初期化されます。WSCallbackHandlerImpl は、プロンプトが望ましくないサーバー・サイ
ド・アプリケーションに適しています。WSCallbackHandlerImpl インスタンスは、指定されたユーザー
ID、パスワード、およびレルム情報によって初期化されます。WSLogin によって指定された現在の
WSLoginModuleImpl クラス・インプリメンテーションは、指定された CallbackHandler からのみ認証情報
を取り出すことができます。LoginContext は Subject オブジェクトで構成することができますが、Subject
は現在の WSLoginModuleImpl インプリメンテーションによって無視されます。
さらに、デフォルトの WSLoginModuleImpl インプリメンテーションがユーザーの要件のすべてを扱うこと
ができない場合には、ユーザー独自の LoginModule を開発することもできます。WebSphere には、カスタ
ム LoginModule ユーティリティー機能が提供されています。これらの機能については次のセクションで説
明します。
java.naming.provider.url がシステム・プロパティーとして設定されていない場合、または jndi.properties フ
ァイルに存在しない場合、アプリケーション・サーバーが localhost:2809 の場所になければ、デフォルトの
InitialContext は機能しません。この状態では、JAAS ログインの前に、プログラマチックに新規の
InitialContext を実行してください。JAAS は、ユーザー ID とパスワードが正しいことを検証するために、
commit() を実行する前に、SecurityServer の常駐場所を知っておく必要があります。以下に示しているよう
に、新規の InitialContext を実行することにより、セキュリティー・コードは、SecurityServer の場所とター
ゲット領域を見つけるのに必要な情報を得ます。
...
import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.InitialContext;
...
// Perform an InitialContext and default lookup prior to logging
// in so that target realm and bootstrap host/port can be determined
// for SecurityServer lookup.
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
“com.ibm.websphere.naming.WsnInitialContextFactory”);
26
WebSphere Application Server - Express Version 5.1 セキュリティー
env.put(Context.PROVIDER_URL, “corbaloc:iiop:myhost.mycompany.com:2809”);
Context initialContext = new InitialContext(env);
Object obj = initialContext.lookup(“”);
LoginContext lc = null;
try {
lc = new LoginContext(“WSLogin”,
new WSCallbackHandlerImpl(“userName”, “realm”, “password”));
} catch (LoginException le) {
System.out.println(“Cannot create LoginContext.” + le.getMessage());
// insert error processing code
} catch(SecurityException se) {
System.out.printlin(“Cannot create LoginContext.” + se.getMessage();
// Insert error processing
}
try {
lc.login();
} catch(LoginException le) {
System.out.printlin(“Fails to create Subject.” + le.getMessage());
// Insert error processing code
}
JAAS 認証およびログイン構成のカスタマイズ: WebSphere Application Server - Express は、WebSphere
Application Server - Express システム・ログイン・モジュールの前、または後の、カスタム Java 認証およ
び許可サービス (JAAS) ログイン・モジュールの使用をサポートします。ただし、WebSphere Application
Server - Express は、サブジェクト内の WSCredential および WSPrincipal を作成するために使用される
WebSphere Application Server - Express システム・ログイン・モジュールの置換をサポートしません。カス
タム・ログイン・モジュールを使用することによって、Java 2 Platform, Enterprise Edition (J2EE) アプリケ
ーション内部で、追加の認証判断を作成するか、または追加の、潜在的により細分化された権限判断を作成
するためにサブジェクトに情報を追加するかのどちらかを行うことができます。
Lightweight Third Party Authentication (LTPA) は、WebSphere Application Server - Express のサーバー・サ
イドの認証メカニズムですが、JAAS LoginModule として実装されています。 LTPA ログイン構成は、セ
ル・レベル security.xml XML ファイル内および wsjaas.conf プロパティー・ファイル内の WebSphere
Common Configuration Module (WCCM) モデルで、定義されます。 WCCM モデル内で定義される JAAS
ログイン構成は 2 つあります。アプリケーション・ログイン構成およびシステム・ログイン構成です。
LTPA はシステム・ログイン構成内で定義されます。
WebSphere Application Server - Express によって LTPA システム構成をカスタマイズすることが可能にな
ります。新規の LTPA_WEB ログイン構成は WCCM モデル内にありますが、これは Web コンテナーに
よってのみ使用されます。 LTPA ログイン構成は、EJB コンテナーによって使用されます。 LTPA_WEB
ログイン構成には com.ibm.ws.security.web.AuthenLoginModule モジュールが含まれ、LTPA ログイン構成に
は com.ibm.ws.security.server.lm.ltpaLoginModule モジュールが含まれます。新規の AuthenLoginModule は拡
張された ltpaLoginModule で、これは CallbackHandler を使用して受け渡される HttpServletRequest オブジ
ェクト、HttpServletResponse オブジェクト、および Web アプリケーション名を処理することができます。
WebSphere Application Server - Express は、サーバー・サイドのログイン構成を公開し、それによって
LTPA 認証プロセスのカスタマイズが可能になります。 LTPA ログイン構成および LTPA_WEB ログイン
構成の両方によって、ltpaLoginModule および AuthenLoginModule の前と後の両方で、カスタム
LoginModule を追加することが可能になります。例えば、認証の前後のどちらかで、プリンシパルまたは証
明書マッピング関数を実行するために LoginModule を追加することができます。 Web 構成内で、カスタ
ム LoginModule は、認証済みユーザー名、アプリケーション名、および URL パターンの組み合わせを使
用してプリンシパル・マッピングを実行することができます。 WebSphere Application Server - Express
は、LTPA および LTPA_WEB ログイン構成の名前変更も削除も許可しません。
セキュリティー
27
WebSphere Application Server - Express バージョン 5.1.1 は、管理コンソールを介して、および wsadmin
スクリプト記述ユーティリティーを使用して、システムのログイン構成の変更をサポートします。管理コン
ソールを使用してシステムのログイン構成を構成するには、「セキュリティー (Security)」 ―> 「JAAS
構成 (JAAS Configuration)」 ―> 「システム・ログイン (System logins)」とクリックします。
WebSphere Application Server - Express バージョン 5.1 で、システム・ログイン構成は管理コンソール内
に公開されていません。ただし、wsadmin スクリプト記述ユーティリティーを使用して、システム・ログ
イン構成を変更することができます。次のサンプル JACL スクリプトは、Lightweight Third-party
Authentication (LTPA) Web システム・ログイン構成内に customLoginModule を追加します。
# Open security.xml
set sec [$AdminConfig getid /Cell:hillside/Security:/]
# Locate systemLoginConfig
set slc [$AdminConfig showAttribute $sec systemLoginConfig]
set entries [lindex [$AdminConfig showAttribute $slc entries] 0]
# Append a new LoginModule to LTPA_WEB
foreach entry $entries {
set alias [$AdminConfig showAttribute $entry alias]
if {$alias == “LTPA_WEB”} {
set newJAASLoginModuleId [$AdminConfig create JAASLoginModule $entry
{{moduleClassName
“com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy”}}]
set newPropertyId [$AdminConfig create Property $newJAASLoginModuleId
{{name delegate}{value “com.ABC.security.auth.CustomLoginModule”}}]
$AdminConfig modify $newJAASLoginModuleId {{authenticationStrategy REQUIRED}}
break
}
}
# save the change
$AdminConfig save
注: wsadmin スクリプト記述ユーティリティーは、リストの最後に新規のオブジェクトを挿入します。カス
タム LoginModule を AuthenLoginModule の前に挿入するには、AuthenLoginModule を削除し、カスタム
LoginModule を挿入した後に再作成します。 サンプル・スクリプトをファイル内に保管し、次のコマンド
でそのサンプル・スクリプトを実行します。
Wsadmin -f sample.jacl
次のサンプル JACL スクリプトを使用して、現行の LTPA_WEB ログイン構成およびすべての
LoginModules を削除することができます。
# Open security.xml
set sec [$AdminConfig getid /Cell:hillside/Security:/]
# Locate systemLoginConfig
set slc [$AdminConfig showAttribute $sec systemLoginConfig]
set entries [lindex [$AdminConfig showAttribute $slc entries] 0]
# Remove the LTPA_WEB login configuration
foreach entry $entries {
set alias [$AdminConfig showAttribute $entry alias]
if {$alias == “LTPA_WEB”} {
$AdminConfig remove $entry
break
}
}
# save the change
$AdminConfig save
28
WebSphere Application Server - Express Version 5.1 セキュリティー
次のサンプル JACL スクリプトを使用して、元の LTPA_WEB 構成を回復することができます。
# Open security.xml
set sec [$AdminConfig getid /Cell:hillside/Security:/]
# Locate systemLoginConfig
set slc [$AdminConfig showAttribute $sec systemLoginConfig]
set entries [lindex [$AdminConfig showAttribute $slc entries] 0]
# Recreate the LTPA_WEB login configuration
set newJAASConfigurationEntryId [$AdminConfig create JAASConfigurationEntry $slc
{{alias LTPA_WEB}}]
set newJAASLoginModuleId [$AdminConfig create JAASLoginModule
$newJAASConfigurationEntryId {{moduleClassName
“com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy”}}]
set newPropertyId [$AdminConfig create Property $newJAASLoginModuleId
{{name delegate}{value “com.ibm.ws.security.web.AuthenLoginModule”}}]
$AdminConfig modify $newJAASLoginModuleId {{authenticationStrategy REQUIRED}}
# save the change
$AdminConfig save
WebSphere Application Server - Express バージョン 5.1 の ltpaLoginModule および AuthenLoginModule
は、共有状態を使用して状態情報を保管し、カスタム LoginModules が情報を変更できるようにします。
ltpaLoginModule は、次のコードを使用して、login() メソッド内のコールバック配列を初期化します。コー
ルバック配列は、配列が共有状態領域内で定義されていない場合のみ、ltpaLoginModule によって作成され
ます。次のコード・サンプルで、エラー処理コードは、サンプルを簡潔にするために削除されています。カ
スタム LoginModule を、ltpaLoginModule の前に挿入する場合、カスタム LoginModule はコールバックを
共有状態に保管するのと同じスタイルに従います。
import com.ibm.wsspi.security.auth.callback.*;
. . .
Callback callbacks[] = null;
if (!sharedState.containsKey(Constants.CALLBACK_KEY)) {
callbacks = new Callback[3];
callbacks[0] = new NameCallback(“Username: ”);
callbacks[1] = new PasswordCallback(“Password: ”, false);
callbacks[2] = new WSCredTokenCallbackImpl(“Credential Token: ”);
try {
callbackHandler.handle(callbacks);
} catch (java.io.IOException e) {
. . .
} catch (UnsupportedCallbackException uce) {
. . .
}
sharedState.put(Constants.CALLBACK_KEY, callbacks);
} else {
callbacks = (Callback []) sharedState.get(Constants.CALLBACK_KEY);
}
ltpaLoginModule および AuthenLoginModule は、WSPrincipal および WSCredential オブジェクトの両方を
生成して、認証済みユーザー ID およびセキュリティー信任状を示します。 WSPrincipal および
WSCredential オブジェクトもまた、共有状態内に保管されます。 JAAS ログインは、2 フェーズ・コミッ
ト・プロトコルを使用します。最初に、ログイン構成内で構成されたログイン・モジュール内のログイン・
メソッドが呼び出されます。次にそのコミット・メソッドが呼び出されます。 ltpaLoginModule および the
AuthenLoginModule の後に挿入されたカスタム LoginModule は、コミットされる前に、WSPrincipal およ
び WSCredential オブジェクトを変更することができます。 WSCredential および WSPrincipal オブジェク
トは、ログインが完了した後で、Subject 内に存在しなければなりません。 Subject 内にこれらのオブジェ
クトがなければ、セキュリティー判断を行うために Subject を使用する場合、WebSphere Application Server
- Express ランタイム・コードによって Subject がリジェクトされます。
セキュリティー
29
AuthenLoginModule は次のコードを使用して、コールバック配列を初期化します。
import com.ibm.websphere.security.auth.callback.*;
import com.ibm.wsspi.security.auth.callback.*;
...
Callback callbacks[] = null;
if (!sharedState.containsKey(Constants.CALLBACK_KEY)) {
callbacks = new Callback[6];
callbacks[0] = new NameCallback(“Username: ”);
callbacks[1] = new PasswordCallback(“Password: ”, false);
callbacks[2] = new WSCredTokenCallbackImpl( “Credential Token: ”);
callbacks[3] = new WSServletRequestCallback( “HttpServletRequest: ”);
callbacks[4] = new WSServletResponseCallback( “HttpServletResponse: ”);
callbacks[5] = new WSAppContextCallback( “ApplicationContextCallback: ”);
try {
callbackHandler.handle(callbacks);
} catch (java.io.IOException e) {
. . .
} catch (UnsupportedCallbackException uce {
. . .
}
sharedState.put(Constants.CALLBACK_KEY, callbacks);
} else {
callbacks = (Callback []) sharedState.get(Constants.CALLBACK_KEY);
}
ログインのためのコールバック情報を含むさらに 3 つのオブジェクトが、Web コンテナーから
AuthenLoginModule へ受け渡されます。java.util.Map、HttpServletRequest、および HttpServletResponse object
です。 これらのオブジェクトは、Web アプリケーション・ コンテキストを表しています。 WebSphere
Application Server - Express バージョン 5.1 アプリケーション・コンテキストである java.util.Map オブジ
ェクトは、アプリケーション名およびエラー・ページ URL を含んでいます。 WSAppContextCallback オブ
ジェクト上で getContext() メソッドを呼び出すことによって、アプリケーション・コンテキストである
java.util.Map object を取得することができます。 java.util.Map オブジェクトは、次のデプロイメント記述
子情報で作成されます。
import com.ibm.wsspi.security.auth.callback.*;
. . .
HashMap appContext = new HashMap(2);
appContext.put(Constants.WEB_APP_NAME, web_application_name);
appContext.put(Constants.REDIRECT_URL, errorPage);
アプリケーション名および HttpServletRequest オブジェクトは、カスタム LoginModule によって読み取ら
れて、マッピング関数を実行します。書式ベースのログインのエラー・ページは、カスタム LoginModule
によって変更することができます。
その他の信任状タイプおよび情報は、カスタム LoginModule を使用して認証プロセスを行う間に、呼び出
し側 Subject に追加できます。呼び出し側 Subject 内のサード・パーティー信任状は、セキュリティー・コ
ンテキストの一部として、WebSphere Application Server - Express によって管理されます。呼び出し側
Subject は、要求処理の間、実行のスレッドにバインドされています。 Web モジュールが呼び出し側 ID
を使用するように構成されている場合は、ユーザー ID は下流のサービスへ伝搬していきます。呼び出し
側 Subject 内の WSCredential およびどのサード・パーティー信任状も、下流へ伝搬しません。代わりに、
情報のいくつかは、伝搬された ID を基にしてターゲット・サーバーで再生成されます。サード・パーテ
ィー信任状を、認証段階で呼び出し側 Subject に追加します。 WSSubject.getCallerSubject() メソッドから
戻された呼び出し側 Subject は、読み取り専用のため、変更することができません。
JAAS ログインからの根本原因となるログイン例外の検出: LoginContext.login() API の実行後に
LoginException を受け取った場合は、構成済みのユーザー・レジストリーからの根本原因である例外を見つ
けることができます。ログイン・モジュールでは、レジストリー例外は、
30
WebSphere Application Server - Express Version 5.1 セキュリティー
com.ibm.websphere.security.auth.WSLoginFailedException でラップされています。この例外には getCause() メ
ソッドがあり、これを使用することで、ラップされている例外を取り出すことができます。
注: 常に WSLoginFailedException という型の例外が得られることが保証されているわけではありません
が、ユーザー・レジストリーから生成される例外のほとんどは、この型に現れることに注意してください。
以下に示したのは、関連する catch ブロックを持つ LoginContext.login() API の例です。getCause() API を
実行する場合は、WSLoginFailedException を com.ibm.websphere.security.auth.WSLoginFailedException にキ
ャストする必要があります。
注: 以下に示した determineCause() の例は、CustomUserRegistry 例外型の処理に使用できます。
try {
lc.login();
} catch (LoginException le) {
// Drill down through the exceptions as they might cascade through the runtime.
Throwable root_exception = determineCause(le);
// Now you can use “root_exception” to compare to a particular exception type.
// For example, if you have implemented a CustomUserRegistry type, you would know
// what to look for here.
}
/* Method used to drill down into the WSLoginFailedException to find the
* “root cause” exception */
public Throwable determineCause(Throwable e) {
Throwable root_exception = e, temp_exception = null;
// Keep looping until there are no more embedded WSLoginFailedException
// or WSSecurityException exceptions.
while (true) {
if (e instanceof com.ibm.websphere.security.auth.WSLoginFailedException) {
temp_exception =
((com.ibm.websphere.security.auth.WSLoginFailedException) e).getCause();
}
else if (e instanceof com.ibm.websphere.security.WSSecurityException) {
temp_exception =
((com.ibm.websphere.security.WSSecurityException) e).getCause();
}
else if (e instanceof com.ibm.ws.security.registry.os400.OS400RegistryException) {
// get OS400 specific error code, if configured
System.out.println (“Error code from OS400 exception: ”
+ ((com.ibm.ws.security.registry.os400.OS400RegistryException)e).getErrorCode());
return e;
}
else if (e instanceof javax.naming.NamingException) {
// check for Ldap embedded exception
temp_exception = ((javax.naming.NamingException)e).getRootCause();
}
else if (e instanceof your_custom_exception_here) {
// your custom processing here, if necessary
}
else {
// This exception is not one of the types we are looking for, return now.
// This is the root from the WebSphere perspective
return root_exception;
}
if (temp_exception != null) {
// We have an exception, let’s go back and see if this has another
// one embedded within it.
root_exception = temp_exception;
e = temp_exception;
continue;
}
セキュリティー
31
else {
// We finally have the root exception from this call path,
// this has to occur at some point.
return root_exception;
}
}
}
独自の J2C プリンシパル・マッピング・モジュールの開発
WebSphere Application Server - Express は、Java 2 Connector (J2C) 接続ファクトリーがコンテナー管理さ
れるサインオンを実行するよう構成されているとき、プリンシパル・マッピングを提供します。 例えば、
アプリケーション・サーバーは、バックエンド・サーバーとの新規接続を開くために、呼び出し側プリンシ
パルをリソース・プリンシパルにマップすることができます。 コンテナー管理されるサインオンを使用し
て、WebSphere Application Server - Express は、EIS セキュリティー・ドメイン証明書が含まれる Subject
インスタンスを作成します。 プリンシパル・マッピング・モジュールによって戻された Subject オブジェ
クトには、呼び出し側 ID、および PasswordCredential または GenericCredential を表す Principal オブジェ
クトが含まれています。
WebSphere Application Server - Express には、認証済みユーザー証明書を EIS セキュリティー・ドメイン
に対するパスワード証明書にマップする、デフォルトのプリンシパル・マッピング・モジュールが提供され
ています。デフォルトのマッピング・モジュールは、DefaultPrincipalMapping 記入項目の「アプリケーショ
ン・ログイン構成」パネルで定義されます。EIS セキュリティー・ドメインのユーザー ID およびパスワ
ードは、管理コンソールの authDataAlias 属性 コンテナー管理認証別名 によってそれぞれの接続ファクト
リー下で定義されます。 authDataAlias 属性には、ユーザー名およびパスワードは実際に含まれません。
authDataAlias 属性には、セキュリティー構成文書で定義されるユーザー名およびパスワードのペアを参照
する別名が含まれます。セキュリティー構成文書には機密データが含まれるため、読み取りおよび書き込み
アクセスのための最高特権の管理者役割が必要となります。 この間接化によって、セキュリティー文書以
外の構成文書での、機密事項であるユーザー名およびパスワードの保管が回避されます。
J2C 接続ファクトリー構成には、プリンシパル・マッピング・モジュール別名 (mappingConfigAlias 属性)
および認証データ別名 (authDataAlias 属性) を定義するマッピング・モジュールが含まれます。ランタイム
時に、J2C 管理接続ファクトリー・コードは、WSPrincipalMappingCallbackHandler オブジェクトを介して
ManagedConnectionFactory および authDataAlias オブジェクトの参照を構成プリンシパル・マッピングに受
け渡します。デフォルトのプリンシパル・マッピング・モジュールによって提供される、1 対 1 マッピン
グで認証されたマッピングが不十分である場合、ユーザーは、WebSphere Application Server - Express によ
って接続ファクトリーのカスタム・プリンシパル・マッピング・モジュールをプラグインにすることができ
ます。カスタム・マッピング・モジュールは、ログイン・メソッドでプリンシパルまたは証明書マッピング
を行う特殊な目的の JAAS LoginModule です。WSSubject.getCallerPrincipal() メソッドは、アプリケーショ
ン・クライアント ID を検索するために使用することができます。カスタム・マッピング・モジュールの
プラグインはとても簡単です。 mappingConfigAlias の値を、そのカスタム・マッピング・モジュールに変
更します。 構成は管理コンソールまたは wsadmin スクリプト・ツールで実行することができます。
以下のステップに従って、カスタム・マッピング・モジュールを構成してください。
1. 管理コンソールを始動します。アプリケーション・サーバーのカスタム・マッピング・モジュールを追
加するには、「サーバー (Server)」 ―> 「アプリケーション・サーバー (Application Servers)」 とク
リックする。 ご使用のサーバーの名前をクリックする。
2. 「セキュリティー (Security)」―>「JAAS 構成 (JAAS Configuration)」をクリックする。
3. 「JAAS 構成およびアプリケーション・ログイン (JAAS Configuration and Application Login)」を選
択する。 「新規」をクリックします。
4. 新規マッピング・モジュールの固有の別名を入力して、「適用 (Apply)」をクリックする。
32
WebSphere Application Server - Express Version 5.1 セキュリティー
5. 「JAAS ログイン・モジュール (JAAS Login Modules)」をクリックして、カスタム・マッピング・モ
ジュール・クラスを定義する。
6. 「新規 (New)」をクリックして、マッピング LoginModule クラス名を入力する。
7. 「適用」をクリックします。「保管 (Save)」をクリックして、新規の構成を保管します。
8. J2C 接続ファクトリーを構成して、新規マッピング・モジュールを使用します。管理コンソールまたは
wsadmin のどちらかを使用してこれを行うことができます。
v 管理コンソールを使用する場合は、以下のステップを実行します。
a. 「リソース (Resources)」 ―> 「リソース・アダプター (Resource Adapters)」 ―>
「resource_adapter」とクリックします。ここで resource_adapter はご使用のリソース・アダプタ
ーの名前です。
b. 「追加プロパティー (Additional Properties)」で、「CMP 接続ファクトリー (CMP Connection
Factories)」をクリックします。
c. ご使用の接続ファクトリーの名前をクリックします。
d. リソース名、Java Naming and Directory Interface (JNDI) 名、リソースの記述、およびリソースを
分類するためのカテゴリーを入力します。
e. 「OK」をクリックします。
f. 管理コンソールの左上のセクションで、「保管 (Save)」をクリックして、構成変更を保管しま
す。
v wsadmin を使用する場合は、以下のステップを実行します。
a. wsadmin プロンプトで、list コマンドを実行して、J2CConnectionFactory オブジェクトのリスト
を表示する。
wsadmin>$AdminConfig list J2CConnectionFactory
b. J2C 接続ファクトリーを選択するには、show コマンドを実行して、すべての属性を表示する。例
えば、次のようにします。
wsadmin>$AdminConfig show PetStore_CF
(cells/hillsideNetwork/nodes/hillside/servers/myserver:
resources.xml#CMPConnectorFactory_4)
c. 現行のマッピング・モジュール構成を調べる。show コマンドを実行します。
wsadmin>$AdminConfig show {mapping
(cells/hillsideNetwork/nodes/hillside/servers/myserver:
resources.xml#MappingModule_7)}
次に、コマンドのサンプル結果を示します。
{authDataAlias {}} {mappingConfigAlias DefaultPrincipalMapping}
前の例で示したように、J2C 接続ファクトリーは、DefaultPrincipalMapping ログイン構成を使用す
るように構成されます。
d. マッピング・モジュール構成を変更して、新規のマッピング・モジュールを使用する。modify コ
マンドを実行します。
wsadmin>$AdminConfig modify {mapping
(cells/hillsideNetwork/nodes/hillside/servers/myserver:
resources.xml#MappingModule_7)} {{mappingConfigAlias myMappingModule}}
e. show コマンドで、結果を確認することができます。
wsadmin>$AdminConfig show {mapping
(cells/hillsideNetwork/nodes/hillside/servers/myserver:
resources.xml#MappingModule_7)} {authDataAlias {}}
{mappingConfigAlias myMappingModule}
セキュリティー
33
注: authDataAlias プロパティーは未定義のままに残されます。実際には、authDataAlias はランタ
イムにカスタム・マッピング・モジュールへ渡されます。authDataAlias プロパティーを使用して
ユーザー ID およびパスワードを検索するには、WebSphere Common Configuration Model
(WCCM) プログラミング・インターフェースが必要です。
f. 変更を保管する。 save コマンドを実行します。
wsadmin>save
上記のタスクによって、ユーザーは自分のアプリケーション環境に適合する独自のマッピング・モジュール
を使用することができます。WebSphere Application Server - Express のデフォルトのプリンシパル・マッピ
ング・モジュールは、すべての認証済みユーザー証明書を EIS セキュリティー・ドメインの同じユーザー
ID およびパスワード証明書にマップします。ユーザー ID およびパスワードはセキュリティー構成文書に
保管され、構成された別名をキーとして使用して検索されます。ユーザーのマッピング・モジュールは、よ
り洗練されたマッピングを行い、パスワードをほかの永続的な記憶域に保管したり、リモート・サービスか
ら保管したりするようにプログラムすることができます。
独自のプリンシパルおよび証明書マッピング LoginModule を開発するには、「JAAS LoginModule 開発者
ガイド (JAAS LoginModule Developer’s Guide)」
参照してください。
(http://java.sun.com/security/jaas/doc/module.html) を
特に、マッピング・モジュールには、呼び出し側のセキュリティー ID を入手する必要があります。
WSSubject.getCallerPrincipal() 静的メソッドは、呼び出し側のセキュリティー ID を表す java.lang.String オ
ブジェクトを戻します。戻りの型は、EJBContext インターフェースの getCallerPrincipal() メソッドの戻り
の型 (java.security.Principal オブジェクト) とは異なることに注意してください。
カスタム・ユーザー・レジストリーの開発
WebSphere Application Server - Express セキュリティーは、認証および許可の目的で、LocalOS レジスト
リーと LDAP レジストリーに加えてカスタム・レジストリーの使用をサポートしています。カスタム・ユ
ーザー・レジストリーとは、ユーザーが実装するユーザー・レジストリーです。WebSphere Application
インターフェースを実装する必要があります。カスタム実
Server - Express が提供する UserRegistry
装されたユーザー・レジストリーは、リレーショナル・データベースやフラット・ファイルなど、どのよう
なタイプのユーザー・レジストリーでも仮想的にサポートすることができます。(カスタム・ユーザー・レ
ジストリー・データベースに接続するために JDBC を使用できます。)カスタム・ユーザー・レジストリー
を使用すると、LDAP または LocalOS 以外の何らかの概念のユーザー・レジストリーがすでに存在するさ
まざまな環境に対して、WebSphere Application Server - Express セキュリティーをかなり柔軟に適応させる
ことができます。
カスタム・ユーザー・レジストリーの実装は、ソフトウェア開発の作業になります。 UserRegistry インタ
ーフェースで定義されたメソッドを使用して希望するレジストリーを呼び出し、ユーザー情報とグループ情
報を取得します。このインターフェースは、きわめて一般的なメソッドのセットを定義しているので、広範
なレジストリーのカプセル化に使用できます。詳しくは、 37 ページの『UserRegistry インターフェース・
メソッド』を参照してください。カスタム・ユーザー・レジストリーは、WebSphere Application Server Express グローバル・セキュリティーの構成時にアクティブ・ユーザー・レジストリーとして構成できま
す。
注: カスタム・レジストリーのインプリメンテーションは、データ・ソースなどの WebSphere Application
Server - Express のコンポーネントには依存しないようにしてください。この依存性があってはいけませ
ん。それは、セキュリティーは、始動中に他のほとんどの WebSphere Application Server - Express のコン
34
WebSphere Application Server - Express Version 5.1 セキュリティー
ポーネントよりも前に初期設定され、使用可能になるからです。例えば、インプリメンテーションがデー
タ・ソースを使用してデータベースに接続する場合は、その代わりに、JDBC を使用してそのデータベース
に接続してください。
次のコード例には、カスタム・ユーザー・レジストリーの簡単なインプリメンテーションが示されていま
す。
v
43 ページの『例: UserRegistry.java ファイル』
v
49 ページの『例: FileRegistrySample.java ファイル』
v
65 ページの『例: Groups.props ファイル』
v
65 ページの『例: Users.props ファイル』
v
65 ページの『例: Results.java ファイル』
カスタム・ユーザー・レジストリーを開発するには以下のステップを実行します。
1. カスタム・ユーザー・レジストリーの概念に慣れていない場合は、『カスタム・ユーザー・レジストリ
ー』を参照してください。このトピックでは、インターフェースの各メソッドについて、詳細に説明し
ます。
2. WebSphere Application Server - Express によって実装されている createCredential() メソッドを除き、イ
ンターフェース内のメソッドをすべて実装します。
3. インプリメンテーションを構築します。
4. コードをコンパイルするには、クラスパス内に sas.jar ファイルと wssec.jar ファイルが必要です。例え
ば、次のようになります。
javac -extdirs /QIBM/ProdData/WebASE51/ASE/java/ext:/QIBM/UserData/Java400/ext:
/QIBM/ProdData/Java400/jdk14/lib/ext:/QIBM/ProdData/WebASE51/ASE/lib
-classpath /QIBM/ProdData/WebASE51/ASE/lib/sas.jar:
/QIBM/ProdData/WebASE51/ASE/lib/wssec.jar
com/ibm/websphere/security/FileRegistrySample.java
5.
66 ページの『カスタム・クラスのインスタンスにクラス・サブディレクトリーを作成する』。
6. WebSphere 管理コンソールを使用してインプリメンテーションを構成するには、 93 ページの『カスタ
ム・ユーザー・レジストリーの構成』のステップに従います。
カスタム・ユーザー・レジストリー: カスタム・ユーザー・レジストリーとは、本製品で提供されている
UserRegistry Java インターフェースを使用して実装するユーザー・レジストリーです。カスタム実装され
たユーザー・レジストリーは、リレーショナル・データベースやフラット・ファイルなど、どのようなタイ
プのユーザー・レジストリーでも仮想的にサポートすることができます。カスタム・ユーザー・レジストリ
ーを使用すると、Lightweight Directory Access Protocol (LDAP) または Local Operating System (LocalOS)
以外の何らかの概念のユーザー・レジストリーがすでに稼働環境に存在するようなさまざまな環境に対し
て、製品のセキュリティーをかなり柔軟に適応させることができます。
WebSphere Application Server - Express セキュリティーは、さまざまなローカル・オペレーティング・シス
テム・ベースのレジストリー (Windows、AIX、Solaris、Linux、i5/OS およびさまざまな Lightweight
Directory Access Protocol (LDAP) ベースのレジストリーを使用するインプリメンテーションを提供しま
す。ただし、ユーザーおよびグループのデータがその他のリポジトリー (データベースなど) にある場合
や、この情報を LocalOS または LDAP へ移動することが不可能な場合もあります。そうした場合のため
に、WebSphere Application Server - Express セキュリティーには、現行レジストリーと対話するために実装
できる SPI が用意されています。 SPI は、UserRegistry インターフェースです。このインターフェースに
は、製品のセキュリティーとセキュリティー関連の全タスクのレジストリーとの対話を可能にするために実
装しなければならない一連のメソッドがあります。提供される LocalOS および LDAP レジストリー・イ
セキュリティー
35
ンプリメンテーションもこのインターフェースを実装します。カスタム・ユーザー・レジストリーは、プラ
グ可能ユーザー・レジストリーまたは略してカスタム・レジストリーと呼ばれます。
UserRegistry インターフェースは、(パスワードまたは証明書のどちらかを使用して) 個人ユーザーを認証す
るのに必要なメソッド、または許可の目的で個人ユーザーに関する情報 (特権属性) を収集するのに必要な
メソッドのコレクションです。このインターフェースには、ユーザーおよびグループにリソースへのアクセ
スを与えることができるよう、彼らの情報を取得するメソッドも含まれています。UserRegistry インターフ
ェースは、いくつかの情報の断片を基に動作します。このインターフェース内のメソッドを実装する場合
は、UserRegistry インターフェースで操作される情報を、レジストリー内の情報にマップする方法を決定す
る必要があります。UserRegistry インターフェースのメソッドは、ユーザーの以下の情報に対して動作しま
す。
v ユーザー・セキュリティー名
これは、i5/OS Local OS レジストリー内のユーザー・プロファイル名に似たユーザー名を参照していま
す。この名前は、セキュア・アプリケーションでプロンプト要求された場合に、ログインするのに使用
されます。デフォルトでは、サーブレットのメソッドである getRemoteUser() と getUserPrincipal() がこ
の名前を戻します。ユーザー・セキュリティー名は、userSecurityName、userName、またはユーザー名と
も呼ばれます。
v 固有 ID
この ID は、ユーザーの固有の ID を表します。UserRegistry インターフェースは、この ID が固有で
あることを要求します。この固有 ID は、i5/OS システムのユーザー ID 番号、Windows システムのシ
ステム ID (SID)、UNIX システムの固有 ID (UID)、および Lightweight Directory Authentication Protocol
(LDAP) の識別名 (DN) に似ています。これは、uniqueUserId とも呼ばれます。固有 ID は、保護されて
いるリソースに対して、権限の決定を行うのに使用されます。
v 表示名
表示名は、ユーザーの説明となる (ただし、必ずしも固有である必要のない) 名前を表す、レジストリー
固有のストリングです。ユーザーが表示名を持っていない場合は、空のストリングが戻されます。i5/OS
の場合は、表示名はユーザー・プロファイルをテキストで説明したものです。
v グループ・セキュリティー名
この名前はセキュリティー・グループを表し、groupSecurityName、groupName、そしてグループ名とも呼
ばれます。
v 固有 ID
固有 ID は、グループの ID です。固有 ID は、uniqueGroupId とも呼ばれます。
v 表示名
表示名は、グループを表すオプションのストリングです。
実装する必要がある UserRegistry インターフェース内のメソッドについては、 37 ページの『UserRegistry
インターフェース・メソッド』を参照してください。
簡単なファイル・ベースのレジストリー・サンプルが提供されています。このサンプルは、カスタム・ユー
ザー・レジストリーに慣れるためのものなので、実際の実稼働環境では使用しないでください。
v
43 ページの『例: UserRegistry.java ファイル』
v
49 ページの『例: FileRegistrySample.java ファイル』
v
65 ページの『例: Groups.props ファイル』
v
65 ページの『例: Users.props ファイル』
v
65 ページの『例: Results.java ファイル』
36
WebSphere Application Server - Express Version 5.1 セキュリティー
このコード例のリーガル情報については、 202 ページの『コードに関するライセンス情報および特記事項』
を参照してください。
UserRegistry インターフェース・メソッド: このインターフェースを実装すると、WebSphere Application
Server - Express セキュリティーでカスタム・レジストリーを使用できるようになります。この機能によっ
て、java.rmi ファイルが拡張されます。リモート・レジストリーを使用すると、このプロセスをリモート側
で完了できます。
このインターフェースを実装する場合は、以下のメソッドを提供する必要があります。
v initialize(java.util.Properties)
v checkPassword(String,String)
v mapCertificate(X509Certificate[])
v getRealm
v getUsers(String,int)
v getUserDisplayName(String)
v getUniqueUserId(String)
v getUserSecurityName(String)
v isValidUser(String)
v getGroups(String,int)
v getGroupDisplayName(String)
v getUniqueGroupId(String)
v getUniqueGroupIds(String)
v getGroupSecurityName(String)
v isValidGroup(String)
v getGroupsForUser(String)
v getUsersForGroup(String,int)
v createCredential(String)
public void initialize(java.util.Properties props) は、 CustomRegistryException、RemoteException をスロ
ーします
このメソッドは、UserRegistry を初期化するために呼び出されます。カスタム・ユーザー・レジストリー・
パネルで定義されたすべてのプロパティーがこのメソッドに伝達されます。
サンプルでは、initialize() メソッドにより、ユーザー情報およびグループ情報を含むレジストリー・ファイ
ルの名前が検索されます。
このメソッドは、レジストリーを初期化するために、サーバーの立ち上げ中に呼び出されます。セキュリテ
ィーがオンの場合、このメソッドは、管理コンソールによる検証の実行時にも呼び出されます。
public String checkPassword(String userSecurityName, String password) は、
PasswordCheckFailedException、CustomRegistryException、RemoteException をスローします
checkPassword メソッドは、ユーザーが名前 (ID) とパスワードを使用してログインしたときに、ユーザー
を認証するために呼び出されます。このメソッドはストリングを戻します。ほとんどの場合、これは認証さ
れるユーザーを示すストリングです。次に、ユーザーに対して許可のための証明書が作成されます。このユ
ーザー名は、サーブレット呼び出しの getUserPrincipal() および getRemoteUser() の場合にも戻されます。
セキュリティー
37
レジストリーに表示名がある場合の詳細については、getUserDisplayName メソッドを参照してください。
ログインしたユーザー以外のユーザーが戻された場合は、そのユーザーがレジストリーで有効であることを
確認してください。
サンプルでは、mapCertificate メソッドが証明書チェーンから Distinguish Name (DN) を取得し、ユーザー
を戻す前に、それがレジストリーで有効なユーザーであることを確認します。 checkPassword メソッド
は、サンプルでは、レジストリー内の名前とパスワードの組み合わせを確認し、一致する場合に認証中のユ
ーザーを戻すだけです。
このメソッドは、さまざまなシナリオで呼び出されます。これは、レジストリーが初期化された後、ユーザ
ー情報を検証するために管理コンソールによって呼び出されます。また、ユーザーを認証するために製品内
の保護リソースにアクセスするときや認証を続行する前にも呼び出されます。
public String mapCertificate(X509Certificate[] cert) は、CertificateMapNotSupportedException、
CertificateMapFailedException、CustomRegistryException、RemoteException をスローします
mapCertificate メソッドは、ブラウザーが提供する X509 証明書チェーンからユーザー名を取得するために
呼び出されます。完全な証明書チェーンがこのメソッドに渡されるので、必要に応じてインプリメンテーシ
ョンでチェーンを検証して、ユーザー情報を取得することができます。このユーザーに対して許可のための
証明書が作成されます。ブラウザーの証明書が構成でサポートされていない場合は、例外
CertificateMapNotSupportedException をスローすることができます。証明書がサポートされていないと、ブ
ラウザーに有効な証明書があっても、チャレンジ・タイプが証明書である場合、認証は失敗します。
このメソッドは、認証のために証明書が提供されたときに呼び出されます。 Web アプリケーションの場合
には、その Web アプリケーションの web.xml で auth-constraints が CLIENT-CERT に設定されている場
合に、レジストリー内の有効なユーザーに証明書をマップするためにこのメソッドが呼び出されます。ま
た、Identity Assertion Token (CSIv2 認証プロトコルを使用している場合) が特定の証明書に設定されてい
る場合、このメソッドはその証明書を有効なユーザーにマップするために呼び出されます。
このパラメーターは、X509Certificate 証明書の配列 (例えば、証明書チェーン) を受け取ります。
public String getRealm() は、CustomRegistryException、 RemoteException をスローします
getRealm メソッドは、セキュリティー・レルムの名前を取得するために呼び出されます。レルムの名前に
より、レジストリーがユーザー認証を行うセキュリティー・ドメインが識別されます。このメソッドがヌル
値を戻した場合は、デフォルト名 customRealm が使用されます。
サンプルでは、getRealm メソッドはストリング customRealm を戻します。このメソッドは、例えば、レジ
ストリー情報を検証するときに呼び出されます。
public Result getUsers(String pattern, int limit) は、 CustomRegistryException、RemoteException をスロ
ーします
getUsers メソッドは、レジストリーからユーザーのリストを戻します。ユーザーの名前は、pattern パラメ
ーターによって決まります。ユーザーの数は、limit パラメーターによって制限されます。多数のユーザー
がいるレジストリーでは、すべてのユーザーを取得することは実際的ではありません。そのため、レジスト
リーから取り出すユーザーの数を制限するための limit パラメーターが導入されています。制限をゼロ (0)
にすると、パターンと一致するすべてのユーザーが戻されるので、大規模なレジストリーの場合は問題が発
生する可能性があります。この制限は注意して使用してください。カスタム・レジストリーのインプリメン
38
WebSphere Application Server - Express Version 5.1 セキュリティー
テーションは、少なくともアスタリスク (*) ワイルドカード検索文字をサポートしていることが期待され
ます。例えば、パターンに (*) を指定すると、すべてのユーザーが戻され、パターンに (b*) を指定する
と、“b.” で始まるユーザー名が戻されます。
このオブジ
return パラメーターは、タイプ com.ibm.websphere.security.Result のオブジェクトです。
ェクトには、java.util.List と java.lang.boolean の 2 つの属性が含まれています。リストには戻されるユー
ザーのリストが含まれ、検索パターンに使用できるユーザーがレジストリー内にまだいるかどうかがブー
ル・フラグで示されます。このブール・フラグは、使用可能なユーザーがレジストリー内にまだいるかどう
かをクライアントに示すために使用されます。
サンプルでは、getUsers は要求された数のユーザーをレジストリーから取り出し、 Result オブジェクトで
それらをリストとして設定します。サンプルでは、要求された数より多くのユーザーがいるかどうかを確認
するためにユーザーがもう 1 人取得され、その追加ユーザーが検出された場合はブール・フラグが真に設
定されます。パターン・マッチングのために RegExpSample クラス内の match メソッドが使用されます。
このメソッドは、アスタリスク (*) や疑問符 (?) などのワイルドカード文字をサポートしています。
このメソッドは、ユーザーを役割にマップするための各パネルでユーザーを役割に追加するために、管理コ
ンソールによって呼び出されます。管理コンソールは Result オブジェクト内のブール設定を使用して、パ
ターンに一致する項目がまだレジストリー内にあることを示します。
このメソッドは、パターンと制限をパラメーターとして受け取ります。リストと、さらに多くの項目がある
かどうかを示すフラグで構成される Result オブジェクトが戻されます。リストが戻される場合は、
Result.setList(List) を使用して、Result オブジェクトにリストを設定します。Limit パラメーターで要求され
た数より多くの項目がある場合は、 Result.setHasMore() を使用して Result オブジェクト内のブール属性を
真に設定します。 Result オブジェクト内のブール属性のデフォルト値は偽です。
public String getUserDisplayName(String userSecurityName) は、
EntryNotFoundException、CustomRegistryException、RemoteException をスローします
getUserDisplayName メソッドは、ユーザーの表示名がある場合にそれを戻します。表示名は、ユーザーを
表すオプションのストリングです。これは、いくつかのレジストリーで設定できます。これは、ユーザーの
記述名であり、レジストリー内で固有である必要はありません。例えば、Windows システムでは、ユーザ
ーの氏名を表示できます。レジストリー内で表示名が必要ない場合、このメソッドに対してヌルまたは空ス
トリングを戻します。
サンプルでは、このメソッドは、指定されたユーザー名と名前が一致するユーザーの表示名を戻します。表
示名が存在しない場合は、空ストリングが戻されます。
このメソッドは、管理コンソールに表示名を示すために製品によって呼び出されることもありますし、
wsadmin ツールを使用してコマンド行で呼び出されることもあります。このメソッドは、表示のためにの
み使用します。
public String getUniqueUserId(String userSecurityName) は、
EntryNotFoundException、CustomRegistryException、RemoteException をスローします
このメソッドは、セキュリティー名が与えられた場合に、ユーザーの uniqueId を戻します。
サンプルでは、このメソッドは、指定された名前と一致するユーザーの uniqueId を戻します。このメソッ
ドは、ユーザーの証明書の形成時やアプリケーションの許可テーブルの作成時に呼び出されます。
セキュリティー
39
public String getUserSecurityName(String uniqueUserId) は、
EntryNotFoundException、CustomRegistryException、RemoteException をスローします
このメソッドは、uniqueId が与えられた場合に、ユーザーのセキュリティー名を戻します。サンプルで
は、このメソッドは、指定された ID と一致する uniqueId を持つユーザーのセキュリティー名を戻しま
す。
このメソッドは、与えられた uniqueUserId に対して有効なユーザーが存在することを確認するために呼び
出されます。このメソッドは、例えば、uniqueUserId がトークンから取得された場合にユーザーのセキュリ
ティー名を取得するために呼び出されます。
public boolean isValidUser(String userSecurityName) は、CustomRegistryException、RemoteException を
スローします
このメソッドは、指定されたユーザーがレジストリー内で有効なユーザーかどうかを示します。
サンプルでは、このメソッドは、レジストリー内でユーザーが検出された場合に真を戻し、検出されない場
合は偽を戻します。このメソッドは主に、ユーザーがディレクトリー内に存在するかどうかを確認すること
で後の問題が回避される場合に呼び出されます。例えば、mapCertificate 呼び出しでは、レジストリー内で
ユーザーが無効なユーザーであることがわかった場合に証明書からその名前が取得されるので、そのユーザ
ーに対する証明書を作成しないようにすることができます。
public Result getGroups(String pattern, int limit) は、CustomRegistryException、RemoteException をス
ローします
getGroups メソッドは、レジストリーからグループのリストを戻します。グループの名前は、pattern パラメ
ーターによって決まります。グループの数は、limit パラメーターによって制限されます。多数のグループ
がいるレジストリーでは、すべてのグループを取得することは実際的ではありません。そのため、レジスト
リーから取り出すグループの数を制限するための limit パラメーターが導入されています。制限をゼロ (0)
にすると、パターンと一致するすべてのユーザーが戻されるので、大規模なレジストリーの場合は問題が発
生する可能性があります。この制限は注意して使用してください。カスタム・レジストリーのインプリメン
テーションは、少なくともアスタリスク (*) ワイルドカード検索文字をサポートしていることが期待され
ます。例えば、パターンに (*) を指定すると、すべてのユーザーが戻され、パターンに (b*) を指定する
と、“b.” で始まるユーザー名が戻されます。
return パラメーターは、タイプ com.ibm.websphere.security.Result のオブジェクトです。このオブジェクト
には、java.util.List と java.lang.boolean の 2 つの属性が含まれています。リストには、戻されるグループ
のリストと、パターン検索に使用できるグループがレジストリー内にまだあるかどうかを示すブール・フラ
グが含まれます。 このブール・フラグは、使用可能なグループがレジストリー内にまだあるかどうかをク
ライアントに示すために使用されます。
サンプルでは、getUsers は要求された数のグループをレジストリーから取り出し、 Result オブジェクトで
それらをリストとして設定します。サンプルでは、要求された数より多くのグループがあるかどうかを確認
するためにユーザーがもう 1 人取得され、その追加ユーザーが検出された場合はブール・フラグが真に設
定されます。パターン・マッチングのために RegExpSample クラス内の match メソッドが使用されます。
これは、* や ? などのワイルドカードをサポートしています。
このメソッドは、グループを役割にマップするための各パネルでグループを役割に追加するために、管理コ
ンソールによって呼び出されます。管理コンソールは Result オブジェクト内のブール設定を使用して、パ
ターンに一致する項目がまだレジストリー内にあることを示します。
40
WebSphere Application Server - Express Version 5.1 セキュリティー
このメソッドは、パターンと制限をパラメーターとして受け取ります。リストと、さらに多くの項目がある
かどうかを示すフラグで構成される Result オブジェクトが戻されます。リストが戻される場合は、
Result.setList(List) を使用して、Result オブジェクトにリストを設定します。Limit パラメーターで要求され
た数より多くの項目がある場合は、 Result.setHasMore() を使用して Result オブジェクト内のブール属性を
真に設定します。 Result オブジェクト内のブール属性のデフォルト値は偽です。
public String getGroupDisplayName(String groupSecurityName) は、
EntryNotFoundException、CustomRegistryException、RemoteException をスローします
getGroupDisplayName メソッドは、グループの表示名がある場合にそれを戻します。表示名は、グループを
表すオプションのストリングです。これは、いくつかのレジストリーで設定できます。この名前は、グルー
プの記述名であり、レジストリー内で固有である必要はありません。レジストリー内でグループの表示名が
必要ない場合は、このメソッドに対してヌルまたは空ストリングを戻します。
サンプルでは、このメソッドは、指定されたグループ名と名前が一致するグループの表示名を戻します。表
示名が存在しない場合、このメソッドは空ストリングを戻します。
このメソッドは、管理コンソールに表示名を示すために製品によって呼び出されることもありますし、
wsadmin ツールを使用してコマンド行で呼び出されることもあります。このメソッドは、表示のためにの
み使用します。
public String getUniqueGroupId(String groupSecurityName) は、
EntryNotFoundException、CustomRegistryException、RemoteException をスローします
このメソッドは、セキュリティー名が与えられた場合に、グループの uniqueId を戻します。
サンプルでは、このメソッドは、指定された名前と一致するグループの uniqueId を戻します。このメソッ
ドは、アプリケーションの許可テーブルの作成時に呼び出されます。
public List getUniqueGroupIds(String uniqueUserId) は、
EntryNotFoundException、CustomRegistryException、RemoteException をスローします
このメソッドは、指定された ID と一致する uniqueId を持つユーザーが属するすべてのグループの
uniqueId を戻します。
サンプルでは、このメソッドは、この uniqueUserId を含むすべてのグループの uniqueId を戻します。この
メソッドは、ユーザーの証明書の作成時に呼び出されます。証明書の作成の一環として、このユーザーが属
するすべての groupUniqueId が収集され、各グループにリソースへのアクセス権が与えられる際に許可の
ため証明書に書き込まれます。
public String getGroupSecurityName(String uniqueGroupId) は、
EntryNotFoundException、CustomRegistryException、RemoteException をスローします
このメソッドは、uniqueId が与えられた場合に、そのグループのセキュリティー名を戻します。
サンプルでは、このメソッドは、指定された ID と一致する uniqueId を持つグループのセキュリティー名
を戻します。このメソッドは、与えられた uniqueGroupId に対して有効なグループが存在することを確認
するために呼び出されます。
public boolean isValidGroup(String groupSecurityName) は、CustomRegistryException、RemoteException
をスローします
セキュリティー
41
このメソッドは、指定されたグループがレジストリー内で有効なグループかどうかを示します。
サンプルでは、このメソッドは、レジストリー内でグループが検出された場合に真を戻し、検出されない場
合は偽を戻します。このメソッドは、ディレクトリー内にグループが存在するかどうかを確認することで後
の問題が回避される場合に使用できます。
public List getGroupsForUser(String userSecurityName) は、
EntryNotFoundException、CustomRegistryException、RemoteException をスローします
このメソッドは、指定された名前と一致する名前を持つユーザーが属するすべてのグループを戻します。こ
のメソッドは、uniqueId の代わりに securityNames を使用する点を除いて、 getUniqueGroupIds メソッドに
類似しています。
サンプルでは、このメソッドは、userSecurityName を含むグループ securityName をすべて戻します。
public Result getUsersForGroup(String groupSecurityName, int limit) は、
NotImplementedException、EntryNotFoundException、CustomRegistryException、 RemoteException をス
ローします
このメソッドは、指定されたグループからユーザーを取り出します。戻されるユーザーの数は、limit パラ
メーターによって制限されます。制限を 0 にすると、そのグループ内のすべてのユーザーが戻されます。
このメソッドは、WebSphere Security コンポーネントから直接呼び出されるわけではありません。ただし、
Workflow のような製品クライアントなど、他のコンポーネントから呼び出すことは可能です。あまりない
ことですが、複数のグループのいずれかからすべてのユーザーを取得するのが実際的ではないような場合に
(例えば、大量のユーザーが存在している場合)、レジストリーを操作するのであれば、1 つ以上の特定のグ
ループに対して NotImplementedException をスローすることができます。グループのユーザーをレジストリ
ーに戻さないのであれば、このメソッドを実装する場合は、NotImplemented exception をスローしないこと
をお勧めします。
return パラメーターは、タイプ com.ibm.websphere.security.Result のオブジェクトです。このオブジェクト
には、java.util.List と java.lang.boolean の 2 つの属性が含まれています。リストには戻されるユーザーの
リストが含まれ、検索パターンに使用できるユーザーがレジストリー内にまだいるかどうかがブール・フラ
グで示されます。このブール・フラグは、使用可能なユーザーがレジストリー内にまだいるかどうかをクラ
イアントに示すために使用されます。
この例では、limit パラメーターが 0 に設定されていない場合は、このメソッドは、要求された数より 1
人多いユーザーを取得します。1 人多いユーザーの取得が成功した場合は、ブール・フラグが真に設定され
ます。
このメソッドはオプションです。このメソッドを実装しないのであれば、NotImplementedException をスロ
ーすることができます。このメソッドは、パターンと制限という 2 つのパラメーターを受け取ります。リ
ストと、さらに多くの項目があるかどうかを示すフラグで構成される Result オブジェクトが戻されます。
このリストが戻される場合は、Result.setList(List) を使用して、Result オブジェクトにリストを設定しま
す。Limit パラメーターで要求された数より多くの項目がある場合は、 Result.setHasMore() を使用して
Result オブジェクト内のブール属性を真に設定します。 Result オブジェクト内のブール属性のデフォルト
値は偽です。
public com.ibm.websphere.security.cred.WSCredential createCredential(String userSecurityName) は、
NotImplementedException、EntryNotFoundException、CustomRegistryException、RemoteException をスロ
ーします
42
WebSphere Application Server - Express Version 5.1 セキュリティー
このリリースの WebSphere Application Server - Express では、このメソッドは呼び出されません。その代
わりに、ヌルを戻す必要があります。上の例では、ヌルが戻されています。このメソッドは、バージョン
4.0 にはありませんでした。
例: UserRegistry.java ファイル:
// 5722-IWE
// (C) COPYRIGHT International Business Machines Corp. 1997, 2003
// All Rights Reserved * Licensed Materials - Property of IBM
//
// DESCRIPTION:
//
//
This is the UserRegistry interface that Custom Registries in WebSphere
//
should implement to enable WebSphere Security to use the Custom Registry.
//
package com.ibm.websphere.security;
import
import
import
import
java.util.*;
java.rmi.*;
java.security.cert.X509Certificate;
com.ibm.websphere.security.cred.WSCredential;
/**
* Implementing this interface enables WebSphere Security to use Custom
* Registries. This should extend java.rmi.Remote as the registry can be in
* a remote process.
*
* To implement this interface, you must provide implementations for:
*
* -- initialize(java.util.Properties)
* -- checkPassword(String,String)
* -- mapCertificate(X509Certificate[])
* -- getRealm
* -- getUsers(String,int)
* -- getUserDisplayName(String)
* -- getUniqueUserId(String)
* -- getUserSecurityName(String)
* -- isValidUser(String)
* -- getGroups(String,int)
* -- getGroupDisplayName(String)
* -- getUniqueGroupId(String)
* -- getUniqueGroupIds(String)
* -- getGroupSecurityName(String)
* -- isValidGroup(String)
* -- getGroupsForUser(String)
* -- getUsersForGroup(String,int)
* -- createCredential(String)
**/
public interface UserRegistry extends java.rmi.Remote
{
/**
* Initializes the registry. This method is called when creating the
* registry.
*
* @param props the registry-specific properties with which to
*
initialize the custom registry
* @exception CustomRegistryException
*
if there is any registry specific problem
* @exception RemoteException
*
as this extends java.rmi.Remote
**/
public void initialize(java.util.Properties props)
throws CustomRegistryException,
セキュリティー
43
RemoteException;
/**
* Checks the password of the user. This method is called to authenticate a
* user when the user’s name and password are given.
*
* @param userSecurityName the name of user
* @param password the password of the user
* @return
a valid userSecurityName. Normally this is
* the name of same user whose password was checked but if the
* implementation wants to return any other valid
* userSecurityName in the registry it can do so
* @exception CheckPasswordFailedException if userSecurityName/
* password combination does not exist in the registry
* @exception CustomRegistryException if there is any registry specific
*
problem
* @exception RemoteException as this extends java.rmi.Remote
**/
public String checkPassword(String userSecurityName, String password)
throws PasswordCheckFailedException,
CustomRegistryException,
RemoteException;
/**
* Maps a Certificate (of X509 format) to a valid user in the Registry.
* This is used to map the name in the certificate supplied by a browser
* to a valid userSecurityName in the registry
*
* @param cert the X509 certificate chain
* @return the mapped name of the user userSecurityName
* @exception CertificateMapNotSupportedException if the particular
*
certificate is not supported.
* @exception CertificateMapFailedException if the mapping of the
*
certificate fails.
* @exception CustomRegistryException if there is any registry specific
*
problem
* @exception RemoteException as this extends java.rmi.Remote
**/
public String mapCertificate(X509Certificate[] cert)
throws CertificateMapNotSupportedException,
CertificateMapFailedException,
CustomRegistryException,
RemoteException;
/**
* Returns the realm of the registry.
*
* @return the realm. The realm is a registry-specific string indicating
*
the realm or domain for which this registry
*
applies. For example, for OS400 or AIX this would be the
*
host name of the system whose user registry this object
*
represents.
*
If null is returned by this method realm defaults to the
*
value of “customRealm”.
* @exception CustomRegistryException if there is any registry specific
*
problem
* @exception RemoteException as this extends java.rmi.Remote
**/
public String getRealm()
throws CustomRegistryException,
RemoteException;
/**
* Gets a list of users that match a pattern in the registy.
* The maximum number of users returned is defined by the limit
* argument.
* This method is called by GUI(adminConsole) and Scripting(Command Line) to
44
WebSphere Application Server - Express Version 5.1 セキュリティー
* make available the users in the registry for adding them (users) to roles.
*
* @param pattern the pattern to match. (For e.g., a* will match all
* userSecurityNames starting with a)
* @param limit the maximum number of users that should be returned.
* This is very useful in situations where there are thousands of
*
users in the registry and getting all of them at once is not
*
practical. A value of 0 implies get all the users and hence
*
must be used with care.
* @return a Result object that contains the list of users
* requested and a flag to indicate if more users exist.
* @exception CustomRegistryException if there is any registry specific
*
problem
* @exception RemoteException as this extends java.rmi.Remote
**/
public Result getUsers(String pattern, int limit)
throws CustomRegistryException,
RemoteException;
/**
* Returns the display name for the user specified by userSecurityName.
*
* This method may be called only when the user information is displayed
* (i.e information purposes only, for example, in GUI) and hence not used
* in the actual authentication or authorization purposes. If there are no
* display names in the registry return null or empty string.
*
* In WAS 4.0 custom registry, if you had a display name for the user and
* if it was different from the security name, the display name was
* returned for the servlet methods getUserPrincipal() and getRemoteUser().
* In WAS 5.1 for the same methods the security name will be returned by
* default. This is the recommended way as the display name is not unique
* and might create security holes.
* However, for backward compatability if one needs the display name to
* be returned set the property WAS_UseDisplayName to true.
*
* See the Infocenter documentation for more information.
*
* @param userSecurityName the name of the user.
* @return the display name for the user. The display name
* is a registry-specific string that represents a descriptive, not
* necessarily unique, name for a user. If a display name does
*
not exist return null or empty string.
* @exception EntryNotFoundException if userSecurityName does not exist.
* @exception CustomRegistryException if there is any registry specific
*
problem
* @exception RemoteException as this extends java.rmi.Remote
**/
public String getUserDisplayName(String userSecurityName)
throws EntryNotFoundException,
CustomRegistryException,
RemoteException;
/**
* Returns the UniqueId for a userSecurityName. This method is called when
* creating a credential for a user.
*
* @param userSecurityName the name of the user.
* @return the UniqueId of the user. The UniqueId for an user is
* the stringified form of some unique, registry-specific, data
* that serves to represent the user. For example, for the UNIX
* user registry, the UniqueId for a user can be the UID.
* @exception EntryNotFoundException if userSecurityName does not exist.
* @exception CustomRegistryException if there is any registry specific
*
problem
* @exception RemoteException as this extends java.rmi.Remote
**/
セキュリティー
45
public String getUniqueUserId(String userSecurityName)
throws EntryNotFoundException,
CustomRegistryException,
RemoteException;
/**
* Returns the name for a user given its uniqueId.
*
* @param uniqueUserId the UniqueId of the user.
* @return the userSecurityName of the user.
* @exception EntryNotFoundException if the uniqueUserId does not exist.
* @exception CustomRegistryException if there is any registry specific
*
problem
* @exception RemoteException as this extends java.rmi.Remote
**/
public String getUserSecurityName(String uniqueUserId)
throws EntryNotFoundException,
CustomRegistryException,
RemoteException;
/**
* Determines if the userSecurityName exists in the registry
*
* @param userSecurityName the name of the user
* @return true if the user is valid. false otherwise
* @exception CustomRegistryException if there is any registry specific
*
problem
* @exception RemoteException as this extends java.rmi.Remote
**/
public boolean isValidUser(String userSecurityName)
throws CustomRegistryException,
RemoteException;
/**
* Gets a list of groups that match a pattern in the registy.
* The maximum number of groups returned is defined by the limit
* argument.
* This method is called by GUI(adminConsole) and Scripting(Command Line) to
* make available the groups in the registry for adding them (groups) to
* roles.
*
* @param pattern the pattern to match. (For e.g., a* will match all
* groupSecurityNames starting with a)
* @param limit the maximum number of groups that should be returned.
* This is very useful in situations where there are thousands of
*
groups in the registry and getting all of them at once is not
*
practical. A value of 0 implies get all the groups and hence
*
must be used with care.
* @return a Result object that contains the list of groups
* requested and a flag to indicate if more groups exist.
* @exception CustomRegistryException if there is any registry specific
*
problem
* @exception RemoteException as this extends java.rmi.Remote
**/
public Result getGroups(String pattern, int limit)
throws CustomRegistryException,
RemoteException;
/**
* Returns the display name for the group specified by groupSecurityName.
*
* This method may be called only when the group information is displayed
* (for example, GUI) and hence not used in the actual authentication or
* authorization purposes. If there are no display names in the registry
* return null or empty string.
*
* @param groupSecurityName the name of the group.
46
WebSphere Application Server - Express Version 5.1 セキュリティー
* @return the display name for the group. The display name
* is a registry-specific string that represents a descriptive, not
* necessarily unique, name for a group. If a display name does
*
not exist return null or empty string.
* @exception EntryNotFoundException if groupSecurityName does not exist.
* @exception CustomRegistryException if there is any registry specific
*
problem
* @exception RemoteException as this extends java.rmi.Remote
**/
public String getGroupDisplayName(String groupSecurityName)
throws EntryNotFoundException,
CustomRegistryException,
RemoteException;
/**
* Returns the Unique id for a group.
* @param groupSecurityName the name of the group.
* @return the Unique id of the group. The Unique id for
* a group is the stringified form of some unique,
* registry-specific, data that serves to represent the group.
*
For example, for the Unix user registry, the Unique id could
* be the GID.
* @exception EntryNotFoundException if groupSecurityName does not exist.
* @exception CustomRegistryException if there is any registry specific
*
problem
* @exception RemoteException as this extends java.rmi.Remote
**/
public String getUniqueGroupId(String groupSecurityName)
throws EntryNotFoundException,
CustomRegistryException,
RemoteException;
/**
* Returns the Unique ids for all the groups that contain the UniqueId of
* a user.
* Called during creation of a user’s credential.
*
* @param uniqueUserId the uniqueId of the user.
* @return a List of all the group UniqueIds that the uniqueUserId
* belongs to. The Unique id for an entry is the stringified
* form of some unique, registry-specific, data that serves
* to represent the entry. For example, for the
* Unix user registry, the Unique id for a group could be the GID
* and the Unique Id for the user could be the UID.
* @exception EntryNotFoundException if uniqueUserId does not exist.
* @exception CustomRegistryException if there is any registry specific
*
problem
* @exception RemoteException as this extends java.rmi.Remote
**/
public List getUniqueGroupIds(String uniqueUserId)
throws EntryNotFoundException,
CustomRegistryException,
RemoteException;
/**
* Returns the name for a group given its uniqueId.
*
* @param uniqueGroupId the UniqueId of the group.
* @return the name of the group.
* @exception EntryNotFoundException if the uniqueGroupId does not exist.
* @exception CustomRegistryException if there is any registry specific
*
problem
* @exception RemoteException as this extends java.rmi.Remote
**/
public String getGroupSecurityName(String uniqueGroupId)
セキュリティー
47
throws EntryNotFoundException,
CustomRegistryException,
RemoteException;
/**
* Determines if the groupSecurityName exists in the registry
*
* @param groupSecurityName the name of the group
* @return true if the groups exists, false otherwise
* @exception CustomRegistryException if there is any registry specific
*
problem
* @exception RemoteException as this extends java.rmi.Remote
**/
public boolean isValidGroup(String groupSecurityName)
throws CustomRegistryException,
RemoteException;
/**
* Returns the securityNames of all the groups that contain the user
*
* This method is called by GUI(adminConsole) and Scripting(Command Line)
* to verify the user entered for role mapping belongs to that role
* in the roles to user mapping. Initially, the check is done to see if
* the role contains the user. If the role does not contain the user
* explicitly, this method is called to get the groups that this user
* belongs to so that check can be made on the groups that the role contains.
*
* @param userSecurityName the name of the user
* @return a List of all the group securityNames that the user
* belongs to.
* @exception EntryNotFoundException if user does not exist.
* @exception CustomRegistryException if there is any registry specific
*
problem
* @exception RemoteException as this extends java.rmi.Remote
**/
public List getGroupsForUser(String userSecurityName)
throws EntryNotFoundException,
CustomRegistryException,
RemoteException;
/**
* Gets a list of users in a group.
*
* The maximum number of users returned is defined by the limit
* argument.
*
* This method is not used by WebSphere Application Server - Express for
* authenticating or authorization purposes. This is, however, used by some
* of the WebSphere clients like Workflow.
*
* If you are working with a registry where getting all the users from
* any of your groups is not practical (for example if there are a large
* number of users) you can through the NotImplementedException. Also,
* if you implement this method, you can still throw this exception if
* the limit exceeds some practical value.
* When the NotImplementedException is thrown the client program should fall
* back to some default implementation which should be documented by the
* client.
*
* @param groupSecurityName the name of the group
* @param limit the maximum number of users that should be returned.
* This is very useful in situations where there are lot of
*
users in the registry and getting all of them at once is not
*
practical. A value of 0 implies get all the users and hence
*
must be used with care.
* @return a Result object that contains the list of users
* requested and a flag to indicate if more users exist.
48
WebSphere Application Server - Express Version 5.1 セキュリティー
* @deprecated This method will be deprecated in future.
* @exception NotImplementedException throw this exception if it is not
*
pratical to get this information from your registry.
* @exception EntryNotFoundException if the group does not exist in
*
the registry
* @exception CustomRegistryException if there is any registry specific
*
problem
* @exception RemoteException as this extends java.rmi.Remote
*
**/
public Result getUsersForGroup(String groupSecurityName, int limit)
throws NotImplementedException,
EntryNotFoundException,
CustomRegistryException,
RemoteException;
/**
* Throw the NotImplementedException for this method.
*
* Create Credential for a user.
*
* This will be implemented internally by WebSphere code and should NOT be
* implemented by the Custom Registry implementations.
*
* @exception NotImplementedException Always throw this.
**/
public WSCredential createCredential(String userSecurityName)
throws NotImplementedException,
EntryNotFoundException,
CustomRegistryException,
RemoteException;
}
例: FileRegistrySample.java ファイル:
import com.ibm.websphere.security.cred.*;
//
// 5639-D57, 5630-A36, 5630-A37, 5724-D18
// (C) COPYRIGHT International Business Machines Corp. 1997, 2003
// All Rights Reserved * Licensed Materials - Property of IBM
//
//---------------------------------------------------------------------// This program may be used, executed, copied, modified and distributed
// without royalty for the purpose of developing, using, marketing, or
// distributing.
//---------------------------------------------------------------------//
// This sample is for the Custom User Registry feature
// in WebSphere Application Server.
import
import
import
import
/**
*
*
*
*
*
*
*
*
*
java.util.*;
java.io.*;
java.security.cert.X509Certificate;
com.ibm.websphere.security.*;
The main purpose of this sample is to demonstrate the use of the
Custom Registry feature available in WebSphere Application Server.
This sample is a file-based registry sample where the users and the
groups information is listed in files (users.props and groups.props).
As such simplicity and not the performance was a major factor behind
this. This sample should be used only to get familiarized with this
feature. An actual implementation of a realistic registry should
consider various factors like performance, scalability, thread safety,
and so on.
セキュリティー
49
**/
public class FileRegistrySample implements UserRegistry {
private static String USERFILENAME = null;
private static String GROUPFILENAME = null;
/** Default Constructor **/
public FileRegistrySample() throws java.rmi.RemoteException {
}
/**
* Initializes the registry. This method is called when creating the
* registry.
*
* @param
props
the registry-specific properties with which to
*
initialize the custom registry
* @exception CustomRegistryException
*
if there is any registry specific problem
**/
public void initialize(java.util.Properties props)
throws CustomRegistryException {
try {
/* try getting the USERFILENAME and the GROUPFILENAME from
* properties that are passed in (i.e from GUI).
* These values should be set in the security center GUI in the
* Special Custom Settings in the Custom User Registry section of
* the Authentication panel.
* For example:
* usersFile
c:/temp/users.props
* groupsFile c:/temp/groups.props
*/
if (props != null) {
USERFILENAME = props.getProperty(“usersFile”);
GROUPFILENAME = props.getProperty(“groupsFile”);
}
} catch(Exception ex) {
throw new CustomRegistryException(ex.getMessage(),ex);
}
if (USERFILENAME == null || GROUPFILENAME == null) {
throw new CustomRegistryException(“users/groups information missing”);
}
}
/**
* Checks the password of the user. This method is called to authenticate a
* user when the user’s name and password are given.
*
* @param
userSecurityName the name of user
* @param
password the password of the user
* @return
a valid userSecurityName. Normally this is
*
the name of same user whose password was checked but
*
if the implementation wants to return any other valid
*
userSecurityName in the registry it can do so
* @exception CheckPasswordFailedException if userSecurityName/
*
password combination does not exist in the registry
* @exception CustomRegistryException if there is any registry specific
*
problem
**/
public String checkPassword(String userSecurityName, String passwd)
throws PasswordCheckFailedException,
CustomRegistryException {
String s,userName = null;
BufferedReader in = null;
50
WebSphere Application Server - Express Version 5.1 セキュリティー
try {
in = fileOpen(USERFILENAME);
while ((s=in.readLine())!=null)
{
if (!(s.startsWith(“#”) || s.trim().length() <=0 )) {
int index = s.indexOf(“:”);
int index1 = s.indexOf(“:”,index+1);
// check if the userSecurityName:passwd combination exists
if ((s.substring(0,index)).equals(userSecurityName) &&
s.substring(index+1,index1).equals(passwd)) {
// Authentication successful, return the userId.
userName = userSecurityName;
break;
}
}
}
} catch(Exception ex) {
throw new CustomRegistryException(ex.getMessage(),ex);
} finally {
fileClose(in);
}
if (userName == null) {
throw new PasswordCheckFailedException(“Password check failed for user: ”
+ userSecurityName);
}
return userName;
}
/**
* Maps a X.509 format certificate to a valid user in the registry.
* This is used to map the name in the certificate supplied by a browser
* to a valid userSecurityName in the registry
*
* @param
cert the X509 certificate chain
* @return
The mapped name of the user userSecurityName
* @exception CertificateMapNotSupportedException if the particular
*
certificate is not supported.
* @exception CertificateMapFailedException if the mapping of the
*
certificate fails.
* @exception CustomRegistryException if there is any registry-specific
*
problem
**/
public String mapCertificate(X509Certificate[] cert)
throws CertificateMapNotSupportedException,
CertificateMapFailedException,
CustomRegistryException {
String name=null;
X509Certificate cert1 = cert[0];
try {
// map the SubjectDN in the certificate to a userID.
name = cert1.getSubjectDN().getName();
} catch(Exception ex) {
throw new CertificateMapNotSupportedException(ex.getMessage(),ex);
}
if(!isValidUser(name)) {
throw new CertificateMapFailedException(“user: ” + name + “ is not valid”);
}
return name;
}
/**
* Returns the realm of the registry.
*
セキュリティー
51
* @return
the realm. The realm is a registry-specific string indicating
*
the realm or domain
*
for which this registry applies. For example, for i5/OS or AIX
*
this would be the host name of the system whose user registry
*
this object represents.
*
If null is returned by this method, realm defaults to the
*
value of “customRealm”.
* @exception CustomRegistryException if there is any registry-specific
*
problem
**/
public String getRealm()
throws CustomRegistryException {
String name = “customRealm”;
return name;
}
/**
* Gets a list of users that match a pattern in the registry.
* The maximum number of users returned is defined by the limit
* argument.
* This method is called by GUI (administrative console) and scripting (command line)
* to make the users in the registry available for adding them (users) to roles.
*
* @param
pattern the pattern to match. (For e.g., a* will match all
*
userSecurityNames starting with a)
* @param
limit the maximum number of users that should be returned.
*
This is very useful in situations where there are thousands of
*
users in the registry and getting all of them at once is not
*
practical. The default is 100. A value of 0 implies get all the
*
users and hence must be used with care.
* @return
a Result object that contains the list of users
*
requested and a flag to indicate if more users exist.
* @exception CustomRegistryException if there is any registry-specific
*
problem
**/
public Result getUsers(String pattern, int limit)
throws CustomRegistryException {
String s;
BufferedReader in = null;
List allUsers = new ArrayList();
Result result = new Result();
int count = 0;
int newLimit = limit+1;
try {
in = fileOpen(USERFILENAME);
while ((s=in.readLine())!=null)
{
if (!(s.startsWith(“#”) || s.trim().length() <=0 )) {
int index = s.indexOf(“:”);
String user = s.substring(0,index);
if (match(user,pattern)) {
allUsers.add(user);
if (limit !=0 && ++count == newLimit) {
allUsers.remove(user);
result.setHasMore();
break;
}
}
}
}
} catch (Exception ex) {
throw new CustomRegistryException(ex.getMessage(),ex);
} finally {
fileClose(in);
}
result.setList(allUsers);
52
WebSphere Application Server - Express Version 5.1 セキュリティー
return result;
}
/**
* Returns the display name for the user specified by userSecurityName.
*
* This method may be called only when the user information is displayed
* ( information purposes only, for example, in GUI) and hence not used
* in the actual authentication or authorization purposes. If there are no
* display names in the registry return null or empty string.
*
* In WebSphere Application Server 4.0 custom registry, if you had a display
* name for the user and if it was different from the security name, the
* display name was returned for the EJB methods getCallerPrincipal() and
* the servlet methods getUserPrincipal() and getRemoteUser(). In WebSphere
* Application Server Version 5, for the same methods, the security name is
* returned by default. This is the recommended way as the display name is
* not unique and may create security holes.
* However, for backward compatability if one needs the display name to
* be returned set the property WAS_UseDisplayName to true.
*
*See the Infocenter documentation for more information.
*
* @param
userSecurityName the name of the user.
* @return
the display name for the user. The display name
*
is a registry-specific string that represents a descriptive, not
*
necessarily unique, name for a user. If a display name does
*
not exist return null or empty string.
* @exception EntryNotFoundException if userSecurityName does not exist.
* @exception CustomRegistryException if there is any registry specific
*
problem
**/
public String getUserDisplayName(String userSecurityName)
throws CustomRegistryException,
EntryNotFoundException {
String s,displayName = null;
BufferedReader in = null;
if(!isValidUser(userSecurityName)) {
EntryNotFoundException nsee = new EntryNotFoundException(“user: ”
+ userSecurityName
+ “ is not valid”);
throw nsee;
}
try {
in = fileOpen(USERFILENAME);
while ((s=in.readLine())!=null)
{
if (!(s.startsWith(“#”) || s.trim().length() <=0 )) {
int index = s.indexOf(“:”);
int index1 = s.lastIndexOf(“:”);
if ((s.substring(0,index)).equals(userSecurityName)) {
displayName = s.substring(index1+1);
break;
}
}
}
} catch(Exception ex) {
throw new CustomRegistryException(ex.getMessage(), ex);
} finally {
fileClose(in);
}
return displayName;
}
セキュリティー
53
/**
* Returns the unique ID for a userSecurityName. This method is called when
* creating a credential for a user.
*
* @param
userSecurityName the name of the user.
* @return
the unique ID of the user. The unique ID for an user is
*
the stringified form of some unique, registry-specific, data
*
that serves to represent the user. For example, for the UNIX
*
user registry, the unique ID for a user can be the UID.
* @exception EntryNotFoundException if userSecurityName does not exist.
* @exception CustomRegistryException if there is any registry-specific
*
problem
**/
public String getUniqueUserId(String userSecurityName)
throws CustomRegistryException,
EntryNotFoundException {
String s,uniqueUsrId = null;
BufferedReader in = null;
try {
in = fileOpen(USERFILENAME);
while ((s=in.readLine())!=null)
{
if (!(s.startsWith(“#”) || s.trim().length() <=0 )) {
int index = s.indexOf(“:”);
int index1 = s.indexOf(“:”, index+1);
if ((s.substring(0,index)).equals(userSecurityName)) {
int index2 = s.indexOf(“:”, index1+1);
uniqueUsrId = s.substring(index1+1,index2);
break;
}
}
}
} catch(Exception ex) {
throw new CustomRegistryException(ex.getMessage(),ex);
} finally {
fileClose(in);
}
if (uniqueUsrId == null) {
EntryNotFoundException nsee =
new EntryNotFoundException(“Cannot obtain uniqueId for user: ”
+ userSecurityName);
throw nsee;
}
return uniqueUsrId;
}
/**
* Returns the name for a user given its uniqueId.
*
* @param
uniqueUserId the unique ID of the user.
* @return
The userSecurityName of the user.
* @exception EntryNotFoundException if the unique user ID does not exist.
* @exception CustomRegistryException if there is any registry-specific
*
problem
**/
public String getUserSecurityName(String uniqueUserId)
throws CustomRegistryException,
EntryNotFoundException {
String s,usrSecName = null;
BufferedReader in = null;
try {
in = fileOpen(USERFILENAME);
while ((s=in.readLine())!=null)
54
WebSphere Application Server - Express Version 5.1 セキュリティー
{
if (!(s.startsWith(“#”) || s.trim().length() <=0 )) {
int index = s.indexOf(“:”);
int index1 = s.indexOf(“:”, index+1);
int index2 = s.indexOf(“:”, index1+1);
if ((s.substring(index1+1,index2)).equals(uniqueUserId)) {
usrSecName = s.substring(0,index);
break;
}
}
}
} catch (Exception ex) {
throw new CustomRegistryException(ex.getMessage(), ex);
} finally {
fileClose(in);
}
if (usrSecName == null) {
EntryNotFoundException ex =
new EntryNotFoundException(“Cannot obtain the user securityName for ”
+ uniqueUserId);
throw ex;
}
return usrSecName;
}
/**
* Determines if the userSecurityName exists in the registry
*
* @param
userSecurityName the name of the user
* @return
true if the user is valid; otherwise false
* @exception CustomRegistryException if there is any registry-specific
*
problem
* @exception RemoteException as this extends java.rmi.Remote
**/
public boolean isValidUser(String userSecurityName)
throws CustomRegistryException {
String s;
boolean isValid = false;
BufferedReader in = null;
try {
in = fileOpen(USERFILENAME);
while ((s=in.readLine())!=null)
{
if (!(s.startsWith(“#”) || s.trim().length() <=0 )) {
int index = s.indexOf(“:”);
if ((s.substring(0,index)).equals(userSecurityName)) {
isValid=true;
break;
}
}
}
} catch (Exception ex) {
throw new CustomRegistryException(ex.getMessage(), ex);
} finally {
fileClose(in);
}
return isValid;
}
/**
* Gets a list of groups that match a pattern in the registy.
* The maximum number of groups returned is defined by the limit
セキュリティー
55
* argument.
* This method is called by GUI (administrative console) and scripting (command line)
* to make available the groups in the registry for adding them (groups) to roles.
*
* @param
pattern the pattern to match. (For example, a * will match all
*
groupSecurityNames starting with a)
* @param
limit the maximum number of groups that should be returned.
*
This is very useful in situations where there are thousands of
*
groups in the registry and getting all of them at once is not
*
practical. The default is 100. A value of 0 implies get all the
*
groups and hence must be used with care.
* @return
a Result object that contains the list of groups
*
requested and a flag to indicate if more groups exist.
* @exception CustomRegistryException if there is any registry-specific
*
problem
**/
public Result getGroups(String pattern, int limit)
throws CustomRegistryException {
String s;
BufferedReader in = null;
List allGroups = new ArrayList();
Result result = new Result();
int count = 0;
int newLimit = limit+1;
try {
in = fileOpen(GROUPFILENAME);
while ((s=in.readLine())!=null)
{
if (!(s.startsWith(“#”) || s.trim().length() <=0 )) {
int index = s.indexOf(“:”);
String group = s.substring(0,index);
if (match(group,pattern)) {
allGroups.add(group);
if (limit !=0 && ++count == newLimit) {
allGroups.remove(group);
result.setHasMore();
break;
}
}
}
}
} catch (Exception ex) {
throw new CustomRegistryException(ex.getMessage(),ex);
} finally {
fileClose(in);
}
result.setList(allGroups);
return result;
}
/**
* Returns the display name for the group specified by groupSecurityName.
* For this version of WebSphereApplication Server, the only usage of this
* method is by the clients (GUI and Scripting) to present a descriptive name
* of the user if it exists.
*
* @param
groupSecurityName the name of the group.
* @return
the display name for the group. The display name
*
is a registry-specific string that represents a descriptive, not
*
necessarily unique, name for a group. If a display name does
*
not exist return null or empty string.
* @exception EntryNotFoundException if groupSecurityName does not exist.
* @exception CustomRegistryException if there is any registry-specific
*
problem
**/
public String getGroupDisplayName(String groupSecurityName)
56
WebSphere Application Server - Express Version 5.1 セキュリティー
throws CustomRegistryException,
EntryNotFoundException {
String s,displayName = null;
BufferedReader in = null;
if(!isValidGroup(groupSecurityName)) {
EntryNotFoundException nsee = new EntryNotFoundException(“group: ”
+ groupSecurityName + “ is not valid”);
throw nsee;
}
try {
in = fileOpen(GROUPFILENAME);
while ((s=in.readLine())!=null)
{
if (!(s.startsWith(“#”) || s.trim().length() <=0 )) {
int index = s.indexOf(“:”);
int index1 = s.lastIndexOf(“:”);
if ((s.substring(0,index)).equals(groupSecurityName)) {
displayName = s.substring(index1+1);
break;
}
}
}
} catch(Exception ex) {
throw new CustomRegistryException(ex.getMessage(),ex);
} finally {
fileClose(in);
}
return displayName;
}
/**
* Returns the Unique id for a group.
* @param
groupSecurityName the name of the group.
* @return
the unique ID of the group. The unique ID for
*
a group is the stringified form of some unique,
*
registry-specific, data that serves to represent the group.
*
For example, for the UNIX user registry, the unique ID might
*
be the GID.
* @exception EntryNotFoundException if groupSecurityName does not exist.
* @exception CustomRegistryException if there is any registry specific
*
problem
* @exception RemoteException as this extends java.rmi.Remote
**/
public String getUniqueGroupId(String groupSecurityName)
throws CustomRegistryException,
EntryNotFoundException {
String s,uniqueGrpId = null;
BufferedReader in = null;
try {
in = fileOpen(GROUPFILENAME);
while ((s=in.readLine())!=null)
{
if (!(s.startsWith(“#”) || s.trim().length() <=0 )) {
int index = s.indexOf(“:”);
int index1 = s.indexOf(“:”, index+1);
if ((s.substring(0,index)).equals(groupSecurityName)) {
uniqueGrpId = s.substring(index+1,index1);
break;
}
}
}
} catch(Exception ex) {
throw new CustomRegistryException(ex.getMessage(),ex);
セキュリティー
57
} finally {
fileClose(in);
}
if (uniqueGrpId == null) {
EntryNotFoundException nsee =
new EntryNotFoundException(“Cannot obtain the uniqueId for group: ”
+ groupSecurityName);
throw nsee;
}
return uniqueGrpId;
}
/**
* Returns the Unique ids for all the groups that contain the UniqueId of
* a user. Called during creation of a user’s credential.
*
* @param
uniqueUserId the unique ID of the user.
* @return
a list of all the group unique IDs that the unique user ID
*
belongs to. The unique ID for an entry is the stringified
*
form of some unique, registry-specific, data that serves
*
to represent the entry. For example, for the
*
UNIX user registry, the unique ID for a group might be the GID
*
and the Unique ID for the user might be the UID.
* @exception EntryNotFoundException if uniqueUserId does not exist.
* @exception CustomRegistryException if there is any registry-specific
*
problem
**/
public List getUniqueGroupIds(String uniqueUserId)
throws CustomRegistryException,
EntryNotFoundException {
String s,uniqueGrpId = null;
BufferedReader in = null;
List uniqueGrpIds=new ArrayList();
try {
in = fileOpen(USERFILENAME);
while ((s=in.readLine())!=null)
{
if (!(s.startsWith(“#”) || s.trim().length() <=0 )) {
int index = s.indexOf(“:”);
int index1 = s.indexOf(“:”, index+1);
int index2 = s.indexOf(“:”, index1+1);
if ((s.substring(index1+1,index2)).equals(uniqueUserId)) {
int lastIndex = s.lastIndexOf(“:”);
String subs = s.substring(index2+1,lastIndex);
StringTokenizer st1 = new StringTokenizer(subs, “,”);
while (st1.hasMoreTokens())
uniqueGrpIds.add(st1.nextToken());
break;
}
}
}
} catch(Exception ex) {
throw new CustomRegistryException(ex.getMessage(),ex);
} finally {
fileClose(in);
}
return uniqueGrpIds;
}
/**
* Returns the name for a group given its uniqueId.
*
* @param
uniqueGroupId the unique ID of the group.
* @return
the name of the group.
58
WebSphere Application Server - Express Version 5.1 セキュリティー
* @exception EntryNotFoundException if the uniqueGroupId does not exist.
* @exception CustomRegistryException if there is any registry specific
*
problem
**/
public String getGroupSecurityName(String uniqueGroupId)
throws CustomRegistryException,
EntryNotFoundException {
String s,grpSecName = null;
BufferedReader in = null;
try {
in = fileOpen(GROUPFILENAME);
while ((s=in.readLine())!=null)
{
if (!(s.startsWith(“#”) || s.trim().length() <=0 )) {
int index = s.indexOf(“:”);
int index1 = s.indexOf(“:”, index+1);
if ((s.substring(index+1,index1)).equals(uniqueGroupId)) {
grpSecName = s.substring(0,index);
break;
}
}
}
} catch (Exception ex) {
throw new CustomRegistryException(ex.getMessage(),ex);
} finally {
fileClose(in);
}
if (grpSecName == null) {
EntryNotFoundException ex =
new EntryNotFoundException(“Cannot obtain the group security name for: ”
+ uniqueGroupId);
throw ex;
}
return grpSecName;
}
/**
* Determines if the groupSecurityName exists in the registry
*
* @param
groupSecurityName the name of the group
* @return
true if the groups exists; otherwise false
* @exception
CustomRegistryException if there is any registry-specific
*
problem
**/
public boolean isValidGroup(String groupSecurityName)
throws CustomRegistryException {
String s;
boolean isValid = false;
BufferedReader in = null;
try {
in = fileOpen(GROUPFILENAME);
while ((s=in.readLine())!=null)
{
if (!(s.startsWith(“#”) || s.trim().length() <=0 )) {
int index = s.indexOf(“:”);
if ((s.substring(0,index)).equals(groupSecurityName)) {
isValid=true;
break;
}
}
}
} catch (Exception ex) {
throw new CustomRegistryException(ex.getMessage(),ex);
} finally {
セキュリティー
59
fileClose(in);
}
return isValid;
}
/**
* Returns the securityNames of all the groups that contain the user
*
* This method is called by GUI (administrative console) and scripting (command line)
* to verify the user entered for RunAsRole mapping belongs to that role
* in the roles to user mapping. Initially, the check is done to see if
* the role contains the user. If the role does not contain the user
* explicitly, this method is called to get the groups that this user
* belongs to so that check can be made on the groups that the role contains.
*
* @param
userSecurityName the name of the user
* @return
a list of all the group securityNames that the user
*
belongs to.
* @exception EntryNotFoundException if user does not exist.
* @exception CustomRegistryException if there is any registry-specific
*
problem
* @exception RemoteException as this extends java.rmi.Remote
**/
public List getGroupsForUser(String userName)
throws CustomRegistryException,
EntryNotFoundException {
String s;
List grpsForUser = new ArrayList();
BufferedReader in = null;
try {
in = fileOpen(GROUPFILENAME);
while ((s=in.readLine())!=null)
{
if (!(s.startsWith(“#”) || s.trim().length() <=0 )) {
StringTokenizer st = new StringTokenizer(s, “:”);
for (int i=0; i<2; i++)
st.nextToken();
String subs = st.nextToken();
StringTokenizer st1 = new StringTokenizer(subs, “,”);
while (st1.hasMoreTokens()) {
if((st1.nextToken()).equals(userName)) {
int index = s.indexOf(“:”);
grpsForUser.add(s.substring(0,index));
}
}
}
}
} catch (Exception ex) {
if (!isValidUser(userName)) {
throw new EntryNotFoundException(“user: ” + userName + “ is not valid”);
}
throw new CustomRegistryException(ex.getMessage(),ex);
} finally {
fileClose(in);
}
return grpsForUser;
}
/**
* Gets a list of users in a group.
*
* The maximum number of users returned is defined by the limit argument.
*
* In rare situations if you are working with a registry where getting all
* the users from any of your groups is not practical (for example if there
60
WebSphere Application Server - Express Version 5.1 セキュリティー
* are a large number of users) you can throw the NotImplementedException
* for that particualar group(s). If there is no concern about
* returning the users from groups in the registry it is recommended that
* this method be implemented without throwing the NotImplemented exception.
*
* @param
groupSecurityName the name of the group
* @param
limit the maximum number of users that should be returned.
*
This is very useful in situations where there are lot of
*
users in the registry and getting all of them at once is not
*
practical. A value of 0 implies get all the users and hence
*
must be used with care.
* @return
a Result object that contains the list of users
*
requested and a flag to indicate if more users exist.
* @deprecated This method will be deprecated in future.
* @exception
NotImplementedException throw this exception in rare situations
*
if it is not pratical to get this information for any of the
*
group or groups from the registry.
* @exception
EntryNotFoundException if the group does not exist in
*
the registry
* @exception
CustomRegistryException if there is any registry-specific
*
problem
**/
public Result getUsersForGroup(String groupSecurityName, int limit)
throws NotImplementedException,
EntryNotFoundException,
CustomRegistryException {
String s, user;
BufferedReader in = null;
List usrsForGroup = new ArrayList();
int count = 0;
int newLimit = limit+1;
Result result = new Result();
try {
in = fileOpen(GROUPFILENAME);
while ((s=in.readLine())!=null)
{
if (!(s.startsWith(“#”) || s.trim().length() <=0 )) {
int index = s.indexOf(“:”);
if ((s.substring(0,index)).equals(groupSecurityName))
{
StringTokenizer st = new StringTokenizer(s, “:”);
for (int i=0; i<2; i++)
st.nextToken();
String subs = st.nextToken();
StringTokenizer st1 = new StringTokenizer(subs, “,”);
while (st1.hasMoreTokens()) {
user = st1.nextToken();
usrsForGroup.add(user);
if (limit !=0 && ++count == newLimit) {
usrsForGroup.remove(user);
result.setHasMore();
break;
}
}
}
}
}
} catch (Exception ex) {
if (!isValidGroup(groupSecurityName)) {
throw new EntryNotFoundException(“group: ”
+ groupSecurityName
+ “ is not valid”);
}
throw new CustomRegistryException(ex.getMessage(),ex);
} finally {
fileClose(in);
セキュリティー
61
}
result.setList(usrsForGroup);
return result;
}
/**
* This method is implemented internally by the WebSphere Application Server code
* in this release. This method is not called for the Custom Registry
* implementations for this release. Return null in the implementation.
*
**/
public WSCredential createCredential(String userSecurityName)
throws CustomRegistryException,
NotImplementedException,
EntryNotFoundException {
// This method is not called.
return null;
}
// private methods
private BufferedReader fileOpen(String fileName)
throws FileNotFoundException {
try {
return new BufferedReader(new FileReader(fileName));
} catch(FileNotFoundException e) {
throw e;
}
}
private void fileClose(BufferedReader in) {
try {
if (in != null) in.close();
} catch(Exception e) {
System.out.println(“Error closing file” + e);
}
}
private boolean match(String name, String pattern) {
RegExpSample regexp = new RegExpSample(pattern);
boolean matches = false;
if(regexp.match(name))
matches = true;
return matches;
}
}
//---------------------------------------------------------------------// The program provides the Regular Expression implementation used in the
// Sample for the Custom User Registry (FileRegistrySample). The pattern
// matching in the sample uses this program to search for the pattern (for
// users and groups).
//---------------------------------------------------------------------class RegExpSample
{
private boolean match(String s, int i, int j, int k)
{
for(; k < expr.length; k++)
label0:
{
Object obj = expr[k];
if(obj == STAR)
{
62
WebSphere Application Server - Express Version 5.1 セキュリティー
if(++k >= expr.length)
return true;
if(expr[k] instanceof String)
{
String s1 = (String)expr[k++];
int l = s1.length();
for(; (i = s.indexOf(s1, i)) >= 0; i++)
if(match(s, i + l, j, k))
return true;
return false;
}
for(; i < j; i++)
if(match(s, i, j, k))
return true;
return false;
}
if(obj == ANY)
{
if(++i > j)
return false;
break label0;
}
if(obj instanceof char[][])
{
if(i >= j)
return false;
char c = s.charAt(i++);
char ac[][] = (char[][])obj;
if(ac[0] == NOT)
{
for(int j1 = 1; j1 < ac.length; j1++)
if(ac[j1][0] <= c && c <= ac[j1][1])
return false;
break label0;
}
for(int k1 = 0; k1 < ac.length; k1++)
if(ac[k1][0] <= c && c <= ac[k1][1])
break label0;
return false;
}
if(obj instanceof String)
{
String s2 = (String)obj;
int i1 = s2.length();
if(!s.regionMatches(i, s2, 0, i1))
return false;
i += i1;
}
}
return i == j;
}
public boolean match(String s)
{
return match(s, 0, s.length(), 0);
}
public boolean match(String s, int i, int j)
{
return match(s, i, j, 0);
}
セキュリティー
63
public RegExpSample(String s)
{
Vector vector = new Vector();
int i = s.length();
StringBuffer stringbuffer = null;
Object obj = null;
for(int j = 0; j < i; j++)
{
char c = s.charAt(j);
switch(c)
{
case 63: /* ’?’ */
obj = ANY;
break;
case 42: /* ’*’ */
obj = STAR;
break;
case 91: /* ’[’ */
int k = ++j;
Vector vector1 = new Vector();
for(; j < i; j++)
{
c = s.charAt(j);
if(j == k && c == ’^’)
{
vector1.addElement(NOT);
continue;
}
if(c == ’¥¥’)
{
if(j + 1 < i)
c = s.charAt(++j);
}
else
if(c == ’]’)
break;
char c1 = c;
if(j + 2 < i && s.charAt(j + 1) == ’-’)
c1 = s.charAt(j += 2);
char ac1[] = {
c, c1
};
vector1.addElement(ac1);
}
char ac[][] = new char[vector1.size()][];
vector1.copyInto(ac);
obj = ac;
break;
case 92: /* ’¥¥’ */
if(j + 1 < i)
c = s.charAt(++j);
break;
}
if(obj != null)
{
if(stringbuffer != null)
{
vector.addElement(stringbuffer.toString());
stringbuffer = null;
}
vector.addElement(obj);
obj = null;
64
WebSphere Application Server - Express Version 5.1 セキュリティー
}
else
{
if(stringbuffer == null)
stringbuffer = new StringBuffer();
stringbuffer.append(c);
}
}
if(stringbuffer != null)
vector.addElement(stringbuffer.toString());
expr = new Object[vector.size()];
vector.copyInto(expr);
}
static
static
static
Object
final char NOT[] = new char[2];
final Integer ANY = new Integer(0);
final Integer STAR = new Integer(1);
expr[];
}
例: Groups.props ファイル:
# 5722-IWE
# (C) COPYRIGHT International Business Machines Corp. 1997, 2003
# All Rights Reserved * Licensed Materials - Property of IBM
#
# Format:
# name:gid:users:display name
# where name
= groupId of the group
#
gid
= uniqueId of the group
#
users = list of all the userIds that the group contains
#
display name = a (optional) display name for the group.
admins:567:bob:Administrative group
operators:678:jay,ted,dave:Operators group
users:789:jay,jeff,vikas,bobby:
例: Users.props ファイル:
# 5722-IWE
# (C) COPYRIGHT International Business Machines Corp. 1997, 2003
# All Rights Reserved * Licensed Materials - Property of IBM
#
# Format:
# name:passwd:uid:gids:display name
# where name
= userId/userName of the user
#
passwd = password of the user
#
uid
= uniqueId of the user
#
gid
= groupIds of the groups that the user belongs to
#
display name = a (optional) display name for the user.
bob:bob1:123:567:bob
dave:dave1:234:678:
jay:jay1:345:678,789:Jay-Jay
ted:ted1:456:678:Teddy G
jeff:jeff1:222:789:Jeff
vikas:vikas1:333:789:vikas
bobby:bobby1:444:789:
例: Results.java ファイル:
// 5722-IWE
// (C) COPYRIGHT International Business Machines Corp. 1997, 2003
// All Rights Reserved * Licensed Materials - Property of IBM
//
// DESCRIPTION:
//
セキュリティー
65
//
This module is used by User Registries in WebSphere when calling the
//
getUsers and getGroups method. The user registries should use this
//
to set the list of users/groups and to indicate if there are more
//
users/groups in the registry than requested
//
package com.ibm.websphere.security;
import java.util.List;
/**
This module is used by User Registries in WebSphere when calling the
getUsers and getGroups method. The user registries should use this
to set the list of users/groups and to indicate if there are more
users/groups in the registry than requested
*/
public class Result implements java.io.Serializable {
/**
Default constructor
*/
public Result() {
}
/**
Returns the list of users/groups
@return the list of users/groups
*/
public List getList() {
return list;
}
/**
indicates if there are more users/groups in the registry
*/
public boolean hasMore() {
return more;
}
/**
Set the flag to indicate that there are more users/groups
in the registry to true
*/
public void setHasMore() {
more = true;
}
/*
Set the list of user/groups
@param list
list of users/groups
*/
public void setList(List list) {
this.list = list;
}
private boolean more = false;
private List list;
}
カスタム・クラスのインスタンスにクラス・サブディレクトリーを作成する: WebSphere Application
Server - Express for iSeries のディレクトリー構造は、他のプラットフォーム上の WebSphere Application
Server - Express とは異なります。iSeries システムでは、WebSphere Application Server - Express は次の 2
つのメイン・ディレクトリーにあります。
v /QIBM/ProdData/WebASE51/ASE
製品 JAR ファイル、スクリプト、そして管理アプリケーション、サンプル、およびプロパティー・ファ
66
WebSphere Application Server - Express Version 5.1 セキュリティー
イルのマスター・コピーが含まれます。これらのディレクトリーは、${WAS_INSTALL_ROOT} と呼ばれま
す。これらのディレクトリー内のファイルは、変更しないことをお勧めします。
v /QIBM/UserData/WebASE51/ASE
固有ファイルと ProdData ディレクトリー内のファイルへの対称リンクの組み合わせであるユーザー・イ
ンスタンス・データが含まれます。アプリケーション・サーバー・インスタンスを作成する場合、ご使
用のインスタンス名のサブディレクトリーが作成され、この中にインスタンスを定義するファイルが配
置されます。/QIBM/UserData/WebASE51/ASE/instance (ここで、instance にはご使用のインスタンスの名
前が入ります) などのインスタンスが含まれるサブディレクトリーは、${USER_INSTALL_ROOT} と呼ばれ
ます。
製品ファイルを分離する理由は 2 つあります。
v ユーザーが (編集、または管理インターフェースを介すことによって) 変更できるファイルから製品を実
行するファイルを分離するため。分離することにより、製品修正によってプロパティー・ファイルに対
する変更などのユーザー定義データが上書きされることが確実になくなります。
v インスタンス間の構成の差を分離します。例えば、各インスタンス・サブディレクトリーは、Java 2 セ
キュリティー・ファイルの独自のコピーを持つことができます。これにより、インスタンスは製品全体
の 1 つの構成のみに準拠するすべてのインスタンスではなく、固有の Java 2 セキュリティー構成を持
つことができます。
WebSphere Application Server - Express には、独自の WebSphere セキュリティー・コンポーネントを開発
するために使用できるアプリケーション・プログラミング・インターフェース (API) が用意されていま
す。例えば、カスタム・ユーザー・レジストリーを作成することができます。他の WebSphere Application
Server - Express プラットフォームの場合、アプリケーション・サーバー・クラスパスで指定される
${WAS_INSTALL_ROOT}/classes ディレクトリーにカスタム・セキュリティー・コンポーネントのファイルを
配置することをお勧めします。これは iSeries プラットフォームでは推奨されません。iSeries では、
${WAS_INSTALL_ROOT}/classes は /QIBM/ProdData/WebASE51/ASE/classes ディレクトリーと同等です。こ
のディレクトリーにカスタム・ファイルを置くと、これらのファイルはすべてのサーバー・インスタンスか
らアクセス可能となります。これは望ましい振る舞い、またはセキュアな振る舞いではない場合がありま
す。
したがって、カスタム・セキュリティー・コンポーネントを配置できるインスタンス内のクラス・サブディ
レクトリーを作成することをお勧めします。さらに、QEJBSVR ユーザー・プロファイルは、このディレク
トリーへの権限を持っていなければなりません。
クラス・サブディレクトリーを作成し、必要な権限を付与するには、iSeries コマンド行から次のコマンド
を実行します。
CRTDIR DIR(’/QIBM/UserData/WebASE51/ASE/instance/classes’)
ここで、instance はインスタンスの名前です。例えば、myInst という名前のインスタンス用にクラス・サ
ブディレクトリーを作成する場合は、次のコマンドを実行します。
CRTDIR DIR(’/QIBM/UserData/WebASE51/ASE/myInst/classes’)
別の方法として、ワークステーション・ネットワーク・ドライブを iSeries サーバーにマップまたはマウン
トして、ワークステーション・コマンド・プロンプトまたはグラフィカル・ファイル・エクスプローラー・
ユーティリティー (Windows エクスプローラなど) からクラス・サブディレクトリーを作成することができ
ます。
セキュリティー
67
Java 2 セキュリティーを使用している場合、${USER_INSTALL_ROOT}/properties/server.policy ファイル
を更新して、ディレクトリー内のクラスに適切な Java 2 セキュリティー許可を付与します。許可について
詳しくは、 174 ページの『server.policy ファイルの構成』を参照してください。
注: Qshell コマンド行からディレクトリーを作成する場合、親ディレクトリーから適切な権限が継承されま
せん。QEJBSVR ユーザー・プロファイル読み取り、書き込み、および実行 (*RWX) 権限をディレクトリ
ーに明示的に付与する必要があります。例えば、以下のコマンドを実行します。
CHGAUT OBJ(’directory’) USER(QEJBSVR) DTAAUT(*RWX)
ここで、directory は、インスタンス内のクラス・サブディレクトリーの完全修飾パスです。
保護アプリケーションのアセンブル
アセンブルとは、アプリケーションをアプリケーション・サーバーのランタイムへインストール (配置) す
るためにパッケージ化するプロセスです。保護アプリケーションを配置用に準備する一環として、WAR フ
ァイルもしくは EAR ファイルのためのデプロイメント記述子の中で、さまざまなセキュリティー設定を指
定します。
保護アプリケーションをアセンブルするには、以下の手順に従います。
1. 『web.xml ファイルを編集してセキュリティー設定を追加する』。
2. (オプション) 70 ページの『アプリケーションへの was.policy ファイルの追加』。
3. アプリケーションを WAR ファイルもしくは EAR ファイルとしてエクスポートします。
アプリケーションを保護すると、結果として生成される WAR ファイルおよび EAR ファイルのデプロイ
メント記述子にセキュリティー情報が格納されます。
以下が、セキュリティー設定を含む WAR ファイルのデプロイメント記述子です。
v web.xml
Web モジュール用のデプロイメント記述子。セキュリティー情報が格納されます。
v was.policy
保護システム・リソースにアクセスするアプリケーションに付与される Java 2 セキュリティー許可が格
納されます。
アプリケーション EAR ファイルは、WAR ファイル用のデプロイメント記述子の他に、以下のデプロイメ
ント記述子を含みます。
v application.xml
アプリケーション内で使用されるすべての役割が格納されます。
v ibm-application-ext.xmi
ユーザーおよびグループの役割マッピングが格納されます。
web.xml ファイルを編集してセキュリティー設定を追加する
Web アプリケーションで構成できる Web ログイン (認証) メカニズムは、基本認証、フォーム・ベース認
証、クライアント証明書ベース認証の 3 種類です。Web アプリケーション内の Web リソースは、各リソ
ースにセキュリティー役割を割り当てることによって保護できます。したがって、どのリソースを保護する
必要があり、そうしたリソースをどのように保護するかを事前に把握しておく必要があります。
WebSphere Development Studio Client で Web アプリケーションのセキュリティーを保護するには、以下の
ステップを実行します。
1. web.xml ファイルを開きます。
68
WebSphere Application Server - Express Version 5.1 セキュリティー
a. Web アプリケーションを含むプロジェクトを開きます。
b. ナビゲーターのウィンドウで WEB-INF ディレクトリーを展開します。 web.xml ファイルをダブル
クリックします。 web.xml ファイルは Web アプリケーションのためのデプロイメント記述子で
す。デプロイメント記述子には、実行時のセキュリティー設定が格納されています。
2. セキュリティー役割を作成します。
a. 「セキュリティー (Security)」タブをクリックします。
b. セキュリティー役割テーブルの横の「追加 (Add)」をクリックします。
c. 役割名と役割の説明を入力します。
d. 必要な各セキュリティー役割につき、ステップ b と c を繰り返します。
3. セキュリティー制約を作成します。
セキュリティー制約は、1 つ以上の Web リソースと役割セットとのマッピングです。セキュリティー
制約を作成するには、次の手順に従います。
a. 「セキュリティー制約 (Security Constraints)」ウィンドウの下で、「追加 (Add)」をクリックしま
す。 ウィンドウに新規のセキュリティー制約が追加され、Web リソース・コレクション・ウィンド
ウに新規の Web リソース・コレクションが追加されます。
b. 「新規の Web リソース・コレクション (New Web Resource Collection)」を選択し、「編集
(Edit)」をクリックします。
c. 「ウェブ・リソース・コレクション (Web Resource Collections)」ダイアログ上で、Web リソース・
コレクションの名前および説明を入力します。
d. 適切な HTTP 方式を選択します。
e. 「URL パターン (URL Patterns)」の横の「追加 (Add)」をクリックします。 URL パターン (例え
ば: /*、*.jsp、/hello など) を入力します。URL パターンをサーブレットにマッピングする方法
の詳細については、『Servlet 2.3 の仕様』を参照してください。セキュリティー・ランタイムは、
最初の完全一致を使用して、受信 URL を URL パターンにマップします。 完全に一致するものが
ない場合、セキュリティー・ランタイムは、最も長い一致 URL を使用します。ワイルドカード
URL パターン (*.* や *.jsp など) は最後に使用されます。「OK」をクリックします。
f. 「許可された役割 (Authorized roles)」ウィンドウの横の「編集 (Edit)」をクリックします。説明を入
力し、必要な役割名を選択してください。役割名を 1 つも選択しない場合、これらのセキュリティ
ー制約で指定されている Web リソースには、どのユーザーもアクセスできないことに注意してくだ
さい。「OK」をクリックします。
g. ドロップダウン・リストから適切なユーザー・データ制約を選択します。ユーザー・データ制約に
NONE を指定すると、Web クライアント (ブラウザー) とサーバー (Web サーバー) 間の通信は、
HTTP でトランスポートされます。ユーザー・データ制約を Confidential もしくは Integral にする
と、Web クライアントと Web サーバー間の通信はセキュアになり、HTTPS を介してトランスポー
トされます。
h. 複数のセキュリティー制約を作成する場合には、上記のステップを繰り返します。
4. セキュリティー役割参照 (security-role-ref) と役割名 (role-name) を役割リンク (role-link) にマップし
ます。
Web アプリケーションの開発時には、WebSphere Development Studio Client などの開発ツールを使用し
てセキュリティー役割参照 (security-role-ref) 要素を作成できます。この段階では、セキュリティー役割
参照 (security-role-ref) 要素に含まれるのは、「役割名 (role-name)」フィールドのみです。「役割名
(role-name)」フィールドには、呼び出し元が指定された役割に含まれているかどうか (つまり、
isUserInRole() メソッドが true を戻すかどうか) を調べるためにサーブレットまたは JSP コード内で参
照される役割の名前が含まれます。セキュリティー役割はアセンブリー段階で作成されるため、開発者
は、「役割名 (role-name)」フィールドに分かりやすい役割名を入力し、説明フィールドに十分な説明を
セキュリティー
69
入れて、アセンブラーが実際の役割 (役割リンク) をマップできるようにします。セキュリティー役割
参照 (security-role-ref) 要素は、サーブレット・レベルの要素です。サーブレットまたは JSP ファイル
には、ゼロまたは 1 つ以上のセキュリティー役割参照 (security-role-ref) 要素を入れることができま
す。
要素を役割リンク (role-link) へマップするには、以下のステップを実行します。
a. 「ソース (Source)」タブをクリックします。
b. 「アウトライン (Outline)」ウィンドウ上で、セキュリティー役割参照 (security-role-ref) 要素を更新
するサーブレットを展開します。
c. セキュリティー役割参照 (security-role-ref) 要素をダブルクリックします。
d. ソース・エディターで役割リンク (role-link) 要素に適切な値を入力します。
e. これらのステップを繰り返し、すべてのサーブレットに対して必要な役割リンク (role-link) 要素を
定義します。
5. ログイン・メカニズムを構成します。
構成したログイン・メカニズムは、Web モジュール内のすべてのサーブレット、JSP ファイル、および
HTML リソースに適用されます。
「ページ (Pages)」タブをクリックし、「ログイン (Login)」セクションで次の設定を指定します。
v 「レルム名 (Realm name)」: HTTP Basic 許可に使用するレルム名を指定します。レルムはサーバー
上で定義されます。レルムを定義することにより、HTTP サーバーでのユーザー許可を分割および制
限することができます。
v 「認証方式 (Authentication method)」: Web アプリケーションの認証メカニズムを指定します。許
可制約によって保護されている Web リソースにアクセスする前提条件として、ユーザーは構成され
たメカニズムを使用して認証されなければなりません。使用可能な認証メカニズムは、
Basic、Digest、Form、およびクライアント証明書 (Client-Cert) です。 Client-Cert の認証を選択した
場合には、Web クライアント (ブラウザー) にクライアント証明書をインストールし、そのクライア
ント証明書をサーバー・トラスト鍵リング・ファイルに入れます。
v (オプション)「ログイン・ページ (Login page)」: ブラウズし、WAR ファイル中のログイン・ペー
ジを選択します。この値はフォーム・ベースの認証方式のみで指定されます。
v (オプション)「エラー・ページ (Error page)」: ブラウズし、WAR 内のエラー・ページを選択しま
す。この値はフォーム・ベースの認証方式のみで指定されます。
6. web.xml ファイルを保管します。
アプリケーションへの was.policy ファイルの追加
WebSphere Application Server で Java 2 セキュリティーが使用可能になっている場合、その WebSphere
Application Server 上で実行されるすべてのアプリケーションは、システム・リソースを使用する前にセキ
ュリティー検査を受けます。アプリケーションが、デフォルトの app.policy ファイルに付与されているよ
りも上のアクセス権が必要なリソースを使用する場合、そのアプリケーションには was.policy が必要で
す。デフォルトでは、製品セキュリティーにより各インスタンスにある app.policy ファイルを読み取り、
app.policy ファイル内のアクセス権をインスタンス内のすべてのアプリケーションに付与します。必要な追
加アクセス権は、was.policy ファイルに追加する必要があります。アプリケーションに追加アクセス権が必
要な場合のみ、was.policy ファイルが必要になります。
was.policy ファイル中で、${application} の codeBase を指定し、必要なアクセス権を追加して、追加ア
クセス権をアプリケーション全体に付与します。同様に、${webComponent} の codeBase を使用して、追加
アクセス権をアプリケーション内のすべての Web モジュールに付与します。以下の例に示すように、追加
アクセス権は各モジュール (WAR ファイル) に割り当てることができます。
70
WebSphere Application Server - Express Version 5.1 セキュリティー
以下に、アプリケーションに追加アクセス権を追加する was.policy ファイルの例を示します。
// grant additional permissions to a WebModule
grant codeBase “ file:aWebModule.war” {
permission java.security.SecurityPermission “printIdentity”;
};
アプリケーションに was.policy ファイルを作成するには、以下のステップを実行してください。
1. Java ポリシー・ツールを使用して、was.policy ファイルを作成します。このポリシー・ツールは、ワ
ークステーションの Java Development Kit またはランタイム環境インストールの bin サブディレクト
リーにあります。例えば、Windows ワークステーションでは、C:¥j2sdk1.4.1_01¥jre¥bin¥policytool.exe
を実行します。
2. ポリシー・ツールを使用して、必要なアクセス権を was.policy ファイルに追加します。
3. WebSphere Development Studio Client を始動します。
4. 対象の Web プロジェクトを開きます。
5. Navigator ウィンドウで META-INF ディレクトリーを選択します。
6. 「ファイル (File)」―>「インポート (Import)」を選択します。
7. インポート・ウィザードで、「ファイル・システム (File system)」を選択し、「次へ (Next)」をクリ
ックします。
8. 「参照 (Browse)」をクリックし、アプリケーションに追加する was.policy ファイルを格納したディレ
クトリーを選択します。「OK」をクリックします。
9. 左側のペインで、ディレクトリーを選択します。右側のペインで、was.policy ファイルを選択します。
10. 「完了」をクリックします。
プロジェクトを WAR ファイルもしくは EAR ファイルにエクスポートし、アプリケーション・サーバー
のランタイムにインストール (配置) すれば、Java 2 セキュリティーが使用可能な状態でアプリケーション
を実行することが可能です。
トラブルシューティング
Java 2 セキュリティーが使用可能なときにアプリケーションを正しく実行するためには、アセンブルされ
たアプリケーションに was.policy ファイルを追加する必要があります。was.policy ファイルが作成されて
おらず、必要なアクセス権が含まれていない場合、アプリケーションがシステム・リソースを使用できない
ことがあります。
アクセス権が欠如している問題の症状は、アプリケーション・プログラムが例外
java.security.AccessControlException を受け取ることです。欠如しているアクセス権は、例外データにリスト
されます。例えば、以下のようになります。
java.security.AccessControlException: access denied
(java.io.FilePermission /QIBM/ProdData/WebASE51/ASE/java/ext/mail.jar read)
アプリケーション・プログラムがこの例外を受け取り、このアクセス権の追加が正しい場合、was.policy フ
ァイルにアクセス権を追加します。例えば、以下のようになります。
grant codeBase “file:${application}” {
permission java.io.FilePermission
“/QIBM/ProdData/WebASE51/ASE/java/ext/mail.jar”, “read”;
};
セキュリティー
71
保護アプリケーションの配置
セキュリティー上の制約があるアプリケーション (保護されたアプリケーション) の開発は、セキュリティ
ー上の制約のないアプリケーションの開発と比べて特に難しいわけではありません。唯一の違いは、保護さ
れたアプリケーション用の役割にユーザーやグループを割り当てなければならない場合があることです。そ
のためには、適切なアクティブ・レジストリーが必要です。
保護されたアプリケーションをインストールすると、アプリケーション内で役割が定義されます。それか
ら、定義された役割にユーザーやグループを割り当てます。
下記の手順は、アプリケーションのインストールおよび既存のアプリケーションの変更のいずれでも共通で
す。アプリケーションに役割が含まれている場合は、 WebSphere 管理コンソールのアプリケーション・イ
ンストール・ウィザードによって、ユーザーおよびグループへセキュリティー役割をマップするように求め
られます (このステップは、インストールしたアプリケーションを管理する際にも実行できます)。
セキュア・アプリケーションをインストール (または配置) するには、WebSphere 管理コンソールで次のス
テップを実行します。
1. 「アプリケーション」―>「新規アプリケーションのインストール」をクリックします。
2. 『ユーザーおよびグループへセキュリティー役割をマップします』というタイトルのステップを実行す
る前に、非セキュリティー関連のステップを完了します。
3. ユーザーおよびグループへセキュリティー役割をマップします。詳しくは、『役割へのユーザーおよび
グループの割り当て』を参照してください。
4. 残りのステップを実行して、アプリケーションのインストールと配置を完了します。以前にインストー
ルしたアプリケーションを更新している場合は、アプリケーションを停止してから始動します。
保護されたアプリケーションの配置後、正しい証明書でアプリケーション内のリソースにアクセスできるこ
とを確認します。例えば、アプリケーションに保護された Web モジュールがある場合は、その Web リソ
ースの役割にリストされているユーザーのみを使用してアクセスするようにしてください。
保護されたアプリケーションの更新と再配置
アプリケーションの配置後、管理コンソールを使用して、役割への既存のユーザーおよびグループのマッピ
ングを変更することができます。
変更が完了したら、必ずその変更を保管します。変更を有効にするために、アプリケーションを停止してか
ら始動します。
他の何らかのセキュリティー関連情報を更新する必要がある場合は、開発ツール (WebSphere Studio など)
を使用して、役割、メソッド許可、認証制約、データ制約、およびその他のセキュリティー関連情報を変更
します。変更が完了したら、EAR ファイルを保管し、古いアプリケーションをアンインストールし、変更
済みのアプリケーションを配置して、変更を有効にするためにアプリケーションを始動します。役割に関す
る情報を変更する場合は、管理コンソールを使用してユーザーおよびグループの情報を必ず更新してくださ
い。
役割へのユーザーおよびグループの割り当て
本トピックでは、役割のすべてがお使いのアプリケーションですでに作成済みであることを前提としていま
す。また、使用するユーザー・レジストリーが現行またはアクティブなユーザー・レジストリーであること
を確認してください。この処理を始める前に、ユーザー選択のユーザー・レジストリーでセキュリティーを
72
WebSphere Application Server - Express Version 5.1 セキュリティー
オンにすることをお勧めします。セキュリティー構成でなんらかの変更を行った場合には (例えば、セキュ
リティーの使用可能化やユーザー・レジストリーの変更など)、変更が有効になる前に、構成を保管して、
サーバーを再始動することを必ず行ってください。
デフォルトのアクティブ・レジストリーは LocalOS であるため、LocalOS レジストリーを使用してユーザ
ーおよびグループを役割に割り当てる場合、セキュリティーを使用可能にすることは (お勧めはしますが)
必要ありません。この場合には、ユーザーおよびグループを割り当てた後でセキュリティーを使用可能にす
ることができます。このタスクを進める前に適切なレジストリーでセキュリティーを使用可能にすると、有
効なセキュリティー・セットアップがなされていることに確信を持てる (ユーザー・レジストリー構成の確
認を含む) という利点があります。そのため、レジストリーに関連した問題の発生を回避することができま
す。
下記の手順は、アプリケーションのインストールおよび既存のアプリケーションの変更のいずれでも共通で
す。アプリケーションに役割が含まれている場合には、インストール・アプリケーションの間に (手順の一
環として)、およびアプリケーション管理時にも、「ユーザー/グループへのセキュリティーのマッピング」
リンクを参照することができます。
ユーザーおよびグループをセキュリティー役割に割り当てるには、下記の手順を管理コンソールで行ってく
ださい。
1. アプリケーション・インストールのプロセス時に、「ユーザー/グループへのセキュリティー役割のマッ
ピング (Map security roles to users/groups)」をクリックする。アプリケーションに属するすべての役
割がリストされます。役割は、ユーザーまたは特定のサブジェクトにすでに割り当て済みである場合に
は (「すべて認証済み (All Authenticated)」および「すべて (Everyone)」など)、ここにリストされま
す。
2. 特定のサブジェクトを割り当てるには、該当する役割に対して「すべて (Everyone)」または「すべて認
証済み (All Authenticated)」を選択する。
3. ユーザーまたはグループを割り当てるには、役割を選択して (同じユーザーまたはグループが役割のす
べてに割り当てられる場合には、複数の役割を同時に選択することができる)、「ユーザーの検索
(Lookup Users)」または「ユーザーの検索 (Lookup groups)」をクリックする。
4. 「制限 (項目数) (limit (number of items))」」および「検索ストリング (Search String)」フィールドに
入力し、続いて「検索 (Search)」をクリックして、レジストリーから該当するユーザーおよびグループ
を取得する。
制限フィールドは、レジストリーから取得して表示するユーザーの数を制限します。パターンは、1 つ
または複数のユーザーまたはグループに一致する検索可能なパターンです。例えば、user* では、user1
および user2 などがリストされます。* のパターンでは、すべてはユーザーまたはグループを示しま
す。レジストリーを圧迫させないように制限と検索ストリングを慎重に使用してください。数千のユー
ザーおよびグループの情報が常駐するような大きなレジストリー (LDAP など) を使用するとき、大き
な数のユーザーまたはグループの検索を行うと、システムが非常に遅くなったり、場合によってはシス
テムが失敗することもあります。
検索の結果、要求した以上の数のエントリーがあったときには、パネルの上部にメッセージが表示され
ます。必要なリストが与えされるまで、検索 (制限または検索パターン) を詳細化することができま
す。
5. 「使用可能 (Available)」ボックスで、役割に割り当てるユーザーおよびグループを選択し、「>>」をク
リックしてそれらのユーザーおよびグループを役割に追加します。
セキュリティー
73
6. 既存のユーザーまたはグループを除去するには、「選択済み (Selected)」ボックスで除去するユーザー
またはグループを選択し、「<<」をクリックすると、選択したユーザーまたはグループが除去されま
す。
7. 「OK」をクリックします。
ユーザーおよびグループ情報は、アプリケーション内のバインディング・ファイルに追加されます。その
後、バインディング・ファイルは許可目的に使用されます。
WebSphere セキュリティーの構成
WebSphere Application Server - Express でのセキュリティーの構成については、以下のトピックを参照して
ください。
75 ページの『グローバル・セキュリティーの構成』
WebSphere グローバル・セキュリティーの構成については、このトピックを参照してください。
116 ページの『役割ベースの権限』
WebSphere Application Server は役割を使用して、保護リソースに対するユーザーの権限を確認しま
す。WebSphere Application Server で役割ベースの権限がどのように機能するかについては、このトピ
ックを参照してください。役割ベースの権限の構成については、次のトピックを参照してください。
118 ページの『管理役割へのユーザーの割り当て』
WebSphere グローバル・セキュリティーは、役割ベースのセキュリティーであるため、ユーザー
とグループには、特定のリソースへのアクセス権を備えた役割を割り当てる必要があります。管
理役割については、このトピックを参照してください。
120 ページの『ネーミング役割へのユーザーの割り当て』
ネーミング・サーバーに関する役割にユーザーやグループを割り当てる方法については、このト
ピックを参照してください。
122 ページの『内部 HTTP トランスポートのトラステッド・モードの構成』
デフォルトでは、WebSphere 内部 HTTP トランスポートは、トラステッド・モード用に構成されて
います。詳しくは、このトピックを参照してください。
123 ページの『WebSphere Application Server - Express での SSL の構成』
WebSphere Application Server - Express で Secure Sockets Layer (SSL) を使用する場合には、このト
ピックを参照してください。
155 ページの『Java 2 セキュリティーの構成』
WebSphere Application Server - Express では、Java 2 セキュリティー・モデルがフル・サポートされ
るようになりました。許可ベースの Java 2 セキュリティーの構成については、このトピックを参照
してください。
177 ページの『Java 認証および許可サービス・ログインの構成』
WebSphere Application Server - Express では、Java Authentication and Authorization Service (JAAS)
ログインが新たに採用されました。ログイン認証の構成については、このトピックを参照してくださ
い。
179 ページの『J2C 認証データ項目の構成』
Java 2 Connector (J2C) 認証データ項目は、リソース・アダプターおよび JDBC データ・ソース間で
共有できる認証データを定義します。詳しくは、このトピックを参照してください。
74
WebSphere Application Server - Express Version 5.1 セキュリティー
グローバル・セキュリティーの構成
インフラストラクチャーの面からセキュリティーを検討し、各種認証メカニズムや、ユーザー・レジストリ
ー、認証プロトコルなどの利点を把握しておくことは有益です。個々のニーズに合った正しいセキュリティ
ー・コンポーネントを選択することは、グローバル・セキュリティー構成の一部です。詳しくは、『グロー
バル・セキュリティー』を参照してください。
セキュリティー・コンポーネントについての知識がある場合は、WebSphere Application Server - Express の
グローバル・セキュリティーの構成作業に進むことができます。
以下のステップを実行します。
1. WebSphere 管理コンソールを始動します。
セキュリティーが現在使用不可になっている場合には、任意のユーザー ID でログインします。セキュ
リティーがすでに使用可能になっている場合には、定義済みの管理 ID およびパスワードを使用してロ
グインします (一般的には、ユーザー・レジストリーの構成時に指定したサーバー・ユーザー ID を使
用してログインします)。
管理コンソールの左側のナビゲーション・メニューで、「セキュリティー (Security)」をクリックしま
す。
2. 『ユーザー・レジストリーの構成』。
WebSphere セキュリティーでは、保護リソースに対するユーザー認証を行うため、ユーザー・レジスト
リーを必要とします。
3.
94 ページの『認証メカニズムの構成』。
WebSphere Application Server - Express がユーザーの認証に使用するメカニズムを構成します。
4. (オプション) 99 ページの『シングル・サインオンの構成』。
LTPA が認証メカニズムとして構成されていて、アプリケーションにフォーム・ベースのログインが含
まれる場合には、シングル・サインオンを構成することもできます。
5. (オプション) 113 ページの『デフォルトの SSL 鍵ストア・ファイルとトラストストア・ファイルの変
更』。
WebSphere Application Server - Express に同梱されているデフォルトの SSL 鍵ストア・ファイルおよ
びトラストストア・ファイルは、テスト環境では使用できますが、実稼働環境では使用するべきではあ
りません。詳しくは、このトピックを参照してください。
6.
115 ページの『グローバル・セキュリティーの使用可能化』。
セキュリティー設定の構成を完了したのち、グローバル・セキュリティーを使用可能にします。
グローバル・セキュリティー: グローバル・セキュリティーは、この環境内で実行されているすべてのア
プリケーションに適用されるセキュリティーで、セキュリティーが使用されているかどうか、認証が行われ
るレジストリーのタイプ、およびその他の値を判別します。これらの値の多くはデフォルトとして動作しま
す。
セキュリティー・ドメインに対するグローバル・セキュリティーの構成は、共通ユーザー・レジストリーの
構成、認証メカニズム、およびその他のセキュリティー情報から構成され、セキュリティー・ドメインの振
る舞いを定義します。ユーザーが構成できるその他のセキュリティー情報には、Java 2 Security
Manager、Java Authentication and Authorization Service (JAAS)、Java 2 Connector 許可データ入力項目、
CSIv2、または SAS 認証プロトコル (IIOP セキュリティーの RMI)、およびその他の属性があります。グ
ローバル・セキュリティー構成は通常、セキュリティー・ドメイン内のすべてのサーバーに適用されます。
ユーザー・レジストリーの構成: URL フォーマットでコード・ベース情報を入力します。さまざまなタイ
プのユーザー・レジストリーがサポートされますが、WebSphere Application Server - Express ですべてのプ
セキュリティー
75
ロセスで使用できるのは 1 つのアクティブ・レジストリーだけです。正しいレジストリーを構成すること
が、アプリケーションについてユーザーおよびグループを役割に割り当てるための前提条件です。LocalOS
は、デフォルトのレジストリーです。しかし、グローバル・セキュリティーを使用可能にする最初のステッ
プとしてレジストリーを構成する必要があり、この後でサーバーを再始動して、すべてのユーザー・アプリ
ケーション用にユーザーとグループを役割に割り当てます。詳しくは、 72 ページの『役割へのユーザーお
よびグループの割り当て』を参照してください。
ユーザーおよびグループをユーザー・アプリケーションの役割に割り当て後、別のユーザー・レジストリー
を選択する場合は、アプリケーションからすべてのユーザーおよびグループを削除し、レジストリーを変更
後、再割り当てすることをお勧めします。すべてのユーザーおよびグループの削除は、管理コンソールまた
は wsadmin スクリプトで実行できます。
次の wsadmin コマンドは、どのアプリケーションからでも、すべてのユーザーおよびグループを除去しま
す。
$AdminApp deleteUserAndGroupEntries yourAppName
ここで、yourAppName はアプリケーションの名前です。旧アプリケーションをバックアップしてから、こ
の操作を実行することをお勧めします。
両レジストリーですべてのユーザーおよびグループ名が同じで、アプリケーション・バインディング・ファ
イルにアクセス ID (同じユーザーまたはグループ名でも、レジストリーごとに固有) が含まれていない場
合は、ユーザーおよびグループ情報を削除しなくてもレジストリーを変更することができます。デフォルト
では、アプリケーションはバインディング・ファイルに accessID を含みません (アプリケーションが開始
されると、すぐに生成されます)。しかし、以前のリリースから既存のアプリケーションを移行したか、ま
たはアプリケーションの accessID を追加するのに wsadmin スクリプトを使用した場合 (パフォーマンス
を向上するため)、新規レジストリーを構成後、既存のユーザーおよびグループ情報を除去してから追加す
る必要があります。
管理ユーザー ID は、すべてのユーザー・レジストリーに共通です。管理 ID は選択したユーザー・レジ
ストリーのメンバーで、WebSphere Application Server - Express では特殊な特権を持っています。しかし、
それが表現するユーザー・レジストリーでは、特殊な特権はありません。つまり、レジストリー内の任意の
ユーザー ID を選択して管理ユーザー ID として使用できます。しかし、LDAP ユーザー・レジストリー
の場合、管理ユーザー ID がレジストリーのメンバーで、LDAP 管理 ID でないことを確認してくださ
い。また、LDAP レジストリーの場合、使用するメンバーは検索可能でなければなりません。
accessID の更新について詳しくは、『管理』トピックの 『スクリプト管理用の AdminApp オブジェク
ト』 の『updateAccessIDs』を参照してください。
特定タイプのユーザー・レジストリーの構成についての説明は、以下のトピックを参照してください。
77 ページの『ローカル・オペレーティング・システムのユーザー・レジストリーの構成』
WebSphere セキュリティーが i5/OS ユーザー・プロファイルを使用して認証を実行するようにする場
合は、このトピックを参照してください。
78 ページの『LDAP ユーザー・レジストリーの構成』
サポートされるサード・パーティー・ユーザー・レジストリーを使用する場合は、このトピックを参
照してください。
93 ページの『カスタム・ユーザー・レジストリーの構成』
ユーザー・レジストリー製品が正式にサポートされるレジストリーの 1 つではないか、または独自の
レジストリーを作成する場合、詳細についてはこのトピックを参照してください。
76
WebSphere Application Server - Express Version 5.1 セキュリティー
ローカル・オペレーティング・システムのユーザー・レジストリーの構成: i5/OS ユーザー・レジストリ
ーを使用して、WebSphere リソースにアクセスするプリンシパルを表す場合、特別なユーザー・レジスト
リーをセットアップする必要はありません。
i5/OS ユーザー・レジストリーは、WebSphere ユーザーの認証および WebSphere リソースにアクセスする
WebSphere ユーザーの許可に使用されますが、i5/OS リソースにアクセスする WebSphere ユーザーの許可
には使用されません。WebSphere Application Server は、WebSphere ユーザーの i5/OS ユーザー・プロファ
イルの下では実行されません。代わりに、WebSphere Application Server は WebSphere 管理者により構成
される i5/OS プロファイルの下で実行されます。
WebSphere リソースに対してユーザーを許可する場合は、ユーザー・プロファイルがそのユーザーの
iSeries システム上になければなりません。iSeries サーバー上で CRTUSRPRF (ユーザー・プロファイルの
作成) コマンドを使用して、WebSphere が使用できる新規ユーザー ID を作成します。
セキュリティーは、インストールされたときのままであると、WebSphere Application Server - Express に対
して使用不可になっています。セキュリティーを使用可能にするには、以下のステップを行う必要がありま
す。これらのステップにおけるセキュリティーの設定は、WebSphere Application Server - Express がインス
トールされている iSeries システム上のローカル・オペレーティング・システムのユーザー・レジストリー
を基にして行います。
WebSphere 管理コンソールで、以下のステップを実行します。
1. ナビゲーション・メニューで、「セキュリティー (Security)」―>「ユーザー・レジストリー (User
Registries)」―>「LocalOS」をクリックします。
2. 「サーバー・ユーザー ID (Server User ID)」フィールドに、有効な iSeries ユーザー・プロファイル名
を入力します。「サーバー・ユーザー ID (Server User ID)」で、基となるオペレーティング・システム
にサーバーを認証するときに使用する iSeries ユーザー・プロファイルを指定します。これは、管理コ
ンソールを使用して管理アプリケーションにアクセスする初期権限を持つユーザーでもあります。管理
ユーザー ID は、すべてのユーザー・レジストリーに共通です。
管理ユーザー ID は、すべてのユーザー・レジストリーに共通です。管理 ID は選択したユーザー・レ
ジストリーのメンバーで、WebSphere Application Server - Express では特殊な特権を持っています。し
かし、それが表現するユーザー・レジストリーでは、特殊な特権はありません。つまり、レジストリー
内の有効な任意のユーザー ID を選択して、管理ユーザー ID (サーバー・ユーザー ID) として使用で
きます。
「サーバー・ユーザー ID (Server User ID)」フィールドには、次の基準を満たす任意の iSeries ユーザ
ー・プロファイルを指定できます。
v *ENABLED という状況を持っている。
v 有効なパスワードを所有している。
v グループ・プロファイルとして使用されていない。
注: グループ・プロファイルには、固有のグループ ID 番号が割り当てられます。この ID 番号は、通
常のユーザー・プロファイルには割り当てられません。ユーザー・プロファイル表示 (DSPUSRPRF) コ
マンドを実行して、サーバー・ユーザーとして使用するユーザー・プロファイルに、定義済みのグルー
プ ID 番号が含まれているかどうかを判別してください。「グループ ID (Group ID)」フィールドが
*NONE に設定されている場合は、そのユーザー・プロファイルを管理ユーザー ID として使用するこ
とができます。
3. 「サーバー・ユーザー・パスワード (Server User Password)」フィールドで、サーバー・ユーザー ID
として指定したユーザー・プロファイルの有効なパスワードを入力します。
セキュリティー
77
4. 「OK」をクリックします。
ユーザーおよびパスワードの検証は、このパネルでは行われません。検証は、「グローバル・セキュリ
ティー (Global Security)」パネルで、「OK」または「適用」をクリックした場合にのみ行われます。セ
キュリティーを使用可能にする処理を初めて行っている場合、他のステップを完了して、「グローバ
ル・セキュリティー (Global Security)」パネルに移動し、アクティブ・ユーザー・レジストリーとして
「Local OS (ローカル OS)」が選択されていることを確認します。変更が検証されない場合、サーバー
を始動できないことがあります。
注: 他のユーザーに管理機能を実行することを許可するまでは、指定したサーバー・ユーザー ID とパスワ
ードを使用して管理コンソールにアクセスできるだけです。詳しくは、 118 ページの『管理役割へのユーザ
ーの割り当て』を参照してください。
LDAP ユーザー・レジストリーの構成: WebSphere セキュリティー用の Lightweight Directory Access
Protocol (LDAP) ユーザー・レジストリーを構成する前に、以下のトピックを参照してください。
v
80 ページの『Lightweight Directory Access Protocol (LDAP)』
v
81 ページの『サポートされているディレクトリー・サービス』
v
81 ページの『LDAP サーバーとしての特定のディレクトリー・サーバーの使用』
v
84 ページの『ユーザー・レジストリーにおけるネストされたグループの使用』
v
85 ページの『LDAP ユーザー・レジストリーへのユーザーの追加』
v
86 ページの『Lightweight Directory Access Protocol におけるユーザーのグループ・メンバーシップの検
索 (バージョン 5.1.1 以降)』 (バージョン 5.1.1 以降)
WebSphere セキュリティーを構成して LDAP ユーザー・レジストリーを使用するには、管理コンソールで
以下のステップを実行します。
1. 「セキュリティー (Security)」―>「ユーザー・レジストリー (User Registries)」―>「LDAP」をクリ
ックします。
2. 「サーバー・ユーザー ID (Server User ID)」フィールドに有効なユーザー名を入力します。ユーザー
の完全な識別名 (DN) か、または「拡張 LDAP 設定 (Advanced LDAP settings)」パネルの「ユーザ
ー・フィルター (User Filter)」で定義されたユーザーの短縮名を入力できます。
3. 「サーバー・ユーザー・パスワード (Server User Password)」フィールドにそのユーザーのパスワー
ドを入力します。
4. 「タイプ (Type)」ドロップダウン・リストから使用する LDAP サーバーのタイプを選択します。
注: i5/OS Directory Services 製品を使用している場合は、「タイプ (Type)」リストから「SecureWay」
を選択してください。
LDAP サーバーのタイプにより、WebSphere Application Server - Express が使用するデフォルトのフ
ィルターが決定されます。これらのデフォルトのフィルターが変更されると、「タイプ (Type)」フィ
ールドは「カスタム (Custom)」に変更され、カスタム・フィルターが使用されることを示します。こ
のアクションは、LDAP 拡張設定パネルで、「OK」または「適用 (Apply)」をクリックした後で行わ
れます。LDAP フィルターの詳細については、 88 ページの『LDAP 検索フィルターの構成』を参照し
てください。
リストからカスタム・タイプを選択し、ユーザーおよびグループ・フィルターを変更して他の LDAP
サーバーを使用します。しかし、他の LDAP サーバーに関するフィルターを構成し検証するのは、お
客様が行う必要があります。また、IBM_Directory_Server かまたは iPlanet を選択した場合は、「大文
字小文字を区別しない (Ignore Case)」フィールドも選択する必要があります。
78
WebSphere Application Server - Express Version 5.1 セキュリティー
5. 「ホスト (Host)」フィールドに、LDAP サーバーの完全修飾ホスト名を入力します。
6. 「ポート (Port)」フィールドに、LDAP サーバーのポート番号を入力します。ホスト名とポート番号
が、WebSphere Application Server - Express セル内のこの LDAP サーバーの領域を表します。したが
って、異なるセル内のサーバーが (LTPA トークンを使用して) 相互に通信する場合、これらの領域は
すべてのセル内で正確に一致する必要があります。
注: WebSphere Application Server - Express バージョン 5 サーバー (5.0 または 5.1) と WebSphere
Application Server バージョン 4 アプリケーション・サーバー間でシングル・サインオンを使用してい
る場合は、管理コンソールで LDAP サーバーのポート番号を指定する必要があります。デフォルト
で、WebSphere Application Server - Express バージョン 5 のデフォルト LDAP ポート番号は 0 です
が、WebSphere Application Server バージョン 4 の場合は 0 ではありません。両方のサーバーに対す
る LDAP ポート番号を同じ値に設定します。バージョン 5 の管理コンソールで、LDAP 設定ページ
上で LDAP ポート番号を設定します。「セキュリティー (Security)」 ―> 「ユーザー・レジストリー
(User registries)」 ―> 「LDAP」とクリックします。
7. 「基本識別名 (Base Distinguished Name)」フィールドに、基本識別名 (DN) を入力します。基本 DN
は、この LDAP ディレクトリー・サーバーでの検索の開始点を示します。例えば、ユーザーの DN
が cn=John Doe, ou=Rochester, o=IBM, c=US の場合、基本 DN は次のいずれかに指定することがで
きます (サフィックスは c=us とします): ou=Rochester, o=IBM, c=us または o=IBM c=us または
c=us。このフィールドは大文字小文字の区別があり、ディレクトリー・サーバーの大文字小文字と一致
するようにしてください。このフィールドは、Domino Directory を除いたすべての LDAP ディレクト
リーで必須です。基本 DN フィールドは、Domino Server ではオプションです。
8. 必要に応じて、「バインド識別名 (Bind Distinguished Name)」フィールドにバインド DN 名を入力し
ます。バインド DN は、LDAP サーバーで不特定バインドを実行してユーザーおよびグループ情報を
取得できない場合に必要です。 LDAP サーバーが不特定バインドを使用するようにセットアップされ
る場合は、このフィールドをブランクのままにしておきます。
9. 必要に応じて、バインド DN に対応するパスワードを、「バインド・パスワード (Bind password)」
フィールドに入力します。
10. 必要に応じて、検索タイムアウト値を変更します。このタイムアウト値は、LDAP サーバーが要求を
打ち切る前に製品のクライアントへの応答の送信を待機する最大時間です。デフォルト値は 120 秒で
す。
11. 「接続の再使用 (Reuse Connection)」フィールドを使用不可にするのは、ルーターを使用して要求を
複数の LDAP サーバーに分散する場合と、ルーターが類縁性をサポートしない場合のみです。他のす
べての場合には、このフィールドを使用可能にしておきます。
12. 必要に応じて、「大文字小文字を区別しない (Ignore Case)」フラグを使用可能にします。これが使用
可能の場合、許可検査は大文字小文字を区別しません。通常は、許可検査ではユーザーの完全な DN
(LDAP サーバー内で固有) を検査し、大文字小文字を区別します。しかし、IBM Directory
Server、i5/OS ディレクトリー・サービス、または iPlanet LDAP サーバーを使用する場合は、LDAP
サーバーから取得するグループ情報は大文字小文字に関して整合性がないので、このフラグを使用可能
にする必要があります。この不整合は許可検査にのみ影響します。
13. LDAP との通信にセキュア・ソケット・レイヤー (SSL) を使用する場合は、SSL を使用可能にしま
す。SSL を使用可能にするには、「SSL 使用可能化 (SSL Enabled)」にチェックマークを付けます。
SSL 用の LDAP のセットアップの詳細については、 153 ページの『WebSphere Application Server Express および LDAP サーバー間の SSL 接続の構成』を参照してください。
14. SSL が使用可能の場合、「SSL 構成 (SSL configuration)」フィールドのドロップダウン・リストから
該当する SSL 別名を選択します。
15. 「OK」をクリックします。
セキュリティー
79
ユーザーおよびパスワードの検証とセットアップは、このパネルでは行われません。検証は、「グロー
バル・セキュリティー (Global Security)」パネルで、「OK」または「適用 (Apply)」をクリックした
場合にのみ行われます。セキュリティーを初めて使用可能にする場合は、残りのステップを完了してか
ら「グローバル・セキュリティー (Global Security)」パネルに進みます。アクティブ・ユーザー・レジ
ストリーとして、「LDAP」を選択します。セキュリティーがすでに使用可能な状態になっているときに
このパネルの情報を変更してしまった場合には、「グローバル・セキュリティー (Global Security)」パ
ネルに進み、「OK」または「適用」をクリックして変更内容を検証します。変更内容の妥当性が確認
されなかった場合には、サーバーを始動できなくなる可能性があります。
16. (バージョン 5.1.1 以降) 動的グループまたはネストされたグループに対するサポートを構成します。
詳しくは、 90 ページの『動的グループおよびネストされたグループのサポート (バージョン 5.1.1 以
降)』および 84 ページの『ユーザー・レジストリーにおけるネストされたグループの使用』を参照して
ください。特定のディレクトリー・サービス製品における動的グループおよびネストされたグループの
サポートの構成については、以下のトピックを参照してください。
v
91 ページの『IBM Directory Server 用の動的およびネストされたグループのサポートの構成 (バー
ジョン 5.1.1 以降)』
v
92 ページの『Sun ONE または iPlanet Directory Server 用の動的およびネストされたグループのサ
ポートの構成』
Lightweight Directory Access Protocol (LDAP): Lightweight Directory Access Protocol (LDAP) とは、
LDAP バインディングを使用して認証が実行されるユーザー・レジストリーのことです。
WebSphere Application Server - Express セキュリティーは、ユーザー情報およびグループ情報用のリポジト
リーとして使用できる主要な LDAP ディレクトリー・サーバー (LDAP サーバー) のインプリメンテーシ
ョンを提供し、サポートします。LDAP サーバーは、ユーザー、その他のセキュリティー関連タスク (例え
ば、ユーザー情報やグループ情報の取得) の認証のため、製品プロセス (サーバー) によって呼び出されま
す。
このサポートは、さまざまなユーザー・フィルターやグループ・フィルターを使用して、ユーザー情報やグ
ループ情報を取得することによって実現されます。それらのフィルターには、実際の要件に適合するように
変更可能なデフォルト値が用意されています。また、カスタム LDAP 機能により、該当するフィルターを
使用して、そのユーザー・レジストリーとして (LDAP サーバーの製品サポート・リストに存在しない) そ
の他の LDAP サーバーも使用することが可能になります。カスタム LDAP 機能を持つ新型の LDAP サー
バーのサポートは、顧客に任せられています。このサポートを実現するには、製品が、どのようにフィルタ
ーを使用してユーザーやグループ情報を取得するかを理解する必要があります。詳しくは、 88 ページの
『LDAP 検索フィルターの構成』を参照してください。フィルターの妥当性や実装に対する試験はお客様
の責任であり、IBM のサポートなしにお客様が独立で行うことになっています。
ユーザー・レジストリーとしての LDAP を使用するには、実際の LDAP サーバーに関して、以下の情報
を把握しておく必要があります。
v 有効なユーザー名
v ユーザー・パスワード
v サーバー・ホストとポート
v ベース識別名 (DN)
v バインド DN とパスワード (必要な場合)
ユーザーは、有効であればレジストリー内の任意のユーザーにできますが、検索可能である必要がありま
す。一部の LDAP サーバーの管理ユーザーの中には、検索可能ではないため、使用できないものもありま
す (例えば、SecureWay における cn=root)。有効で検索可能なユーザーは、この資料では、WebSphere
80
WebSphere Application Server - Express Version 5.1 セキュリティー
Application Server - Express セキュリティー・サーバー ID、サーバー ID、またはサーバー・ユーザー ID
と呼んでいます。サーバー ID となるには、ユーザーが、一部の保護されている内部メソッドを呼び出す
ときに特別な権限を持つ必要があります。通常、この ID とパスワードは、セキュリティーが有効なとき
に管理コンソールにログインするために使用されます (その他のユーザーは、それが管理役割の一部である
場合に、ログインに使用することができます)。
セキュリティーが製品で有効になっている場合、このサーバー ID とパスワードは、製品の始動時にレジ
ストリーで認証を受けます。認証が失敗すると、サーバーは始動しません。有効期限の切れない、または頻
繁に変更しない ID とパスワードを選択することが大切です。レジストリー内の製品サーバー・ユーザー
ID またはパスワードを変更する必要のある場合は、すべての製品サーバーが起動、動作するときに変更内
容が確実に実行されるようにします。レジストリーに対する変更が完了したら、 78 ページの『LDAP ユー
ザー・レジストリーの構成』に説明されている手順を使用して、ID、パスワード、存在すれば、その他の
構成情報も変更します。構成情報を保管し、すべてのサーバーを停止してから、再始動し、新しい ID ま
たはパスワードを製品に使用させるようにします。
セキュリティーが有効なときに、製品の始動に問題がある場合は、セキュリティーを無効にしてから、サー
バーを始動します (まず、第一に、このことを避けるには、このパネルで行った変更を、「グローバル・セ
キュリティー」パネルで検証することを怠らないようにします)。サーバーの始動後、ID、パスワード、そ
の他の構成情報を変更することができます。変更したら、セキュリティーを有効にします。
サポートされているディレクトリー・サービス: WebSphere Application Server - Express セキュリティー
は、いくつかの異なる LDAP サーバーをサポートしています。サポートされているサーバーのリストにつ
いては、WebSphere Application Server: サポートされるハードウェアおよびソフトウェア (Supported
hardware and software)
てください。
(http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html) を参照し
他の LDAP サーバーは、LDAP 仕様に従う限り機能することが期待されます。サポートはこれらの指定さ
れたディレクトリー・サーバーのみに限定されています。その他のディレクトリー・サーバーは、カスタ
ム・ディレクトリー・タイプを使用し、そのディレクトリーに必要なフィルターを入力することによって使
用できます。詳しくは、 88 ページの『LDAP 検索フィルターの構成』を参照してださい。
LDAP 検索効率を改善するため、ユーザーの検索結果には、検索対象ユーザーに関する関連情報のすべて
(ユーザー ID、グループなど) が含まれるように、IBM Directory Server、iPlanet Directory Server、および
Active Directory のデフォルト・フィルターが定義されています。結果として、製品は LDAP サーバーを
複数回呼び出すことがありません。この定義は、完全なユーザー情報が獲得されている検索をサポートする
ディレクトリー・タイプ内でのみ可能です。
また、IBM Directory Server を使用する場合は、管理コンソールで、大文字小文字を区別しない フラグを
使用可能にします。このフラグは、グループ情報がユーザー・オブジェクト属性から獲得されたとき、その
大文字小文字の区別が、グループ情報を直接獲得したときに得られるものと同じではないため必要です。こ
の条件で権限が処理されるために、大文字小文字を区別しないにチェック・マークを付け、大文字小文字を
区別しない フラグの要件も検証してください。
LDAP サーバーとしての特定のディレクトリー・サーバーの使用: このトピックでは、WebSphere セキュ
リティー用に特定のディレクトリー・サーバー製品を使用する際の考慮事項について説明します。
LDAP サーバーとしての i5/OS Directory Services の使用
セキュリティー
81
i5/OS Directory Services は、V5R1 で始まる基本オペレーティング・システム内に含まれ、オプション 32
は V5R2 からは使用可能ではなくなりました。 ディレクトリー・サービスは IBM Directory Server ファ
ミリーの製品とサービスの一部で、iSeries 用のディレクトリー・サーバー (以前は SecureWay Directory)
として参照されることがあります。
V5R1 の場合は、ディレクトリー・サービスを使用している場合は、ディレクトリー・タイプとして
SecureWay を選択します。 V5R2 の場合は、ディレクトリー・タイプとして、SecureWay または
IBM_Directory_Server のどちらかを選択します。 V5R3 の場合は、ディレクトリー・タイプとして
IBM_Directory_Server を選択します。
注: LDAP ディレクトリー・タイプとして IBM_Directory_Server を選択した場合、Directory Services も
LDAP 4.1 にアップグレードしなければなりません。 LDAP 4.1 では、ディレクトリー・サービスは、新
規のグループ・メンバーシップ属性を使用して、グループ・メンバーシップ検索のパフォーマンスを向上す
るようプログラムされています。 LDAP 4.1 に必要な PTF に関する情報は、iSeries Directory Services
(LDAP): V5R2 の新機能 (New V5R2 Enhancements) を参照してください。
(http://www.ibm.com/servers/eserver/iseries/ldap/whatsnew41.htm)
注: 他のグループを含むグループ (ネストされたグループ) のサポートは、WebSphere Application Server お
よび LDAP の特定のバージョンに依存しています。 詳しくは、 84 ページの『ユーザー・レジストリーに
おけるネストされたグループの使用』 を参照してください。
LDAP サーバーとしての IBM Directory Server の使用
IBM Directory Server 製品用に、IBM Directory Server または SecureWay のどちらかのディレクトリ
ー・タイプを選択することができます。この 2 つのタイプの違いは、グループ・メンバーシップの検索方
法にあります。 実行時の最適なパフォーマンスのために IBM Directory Server を選択することをお勧め
します。 IBM Directory Server 製品では、グループ・メンバーシップは運用属性です。項目はメンバーご
とのメンバー・ディレクトリー (uniqueMember) です。 この属性を使用すると、グループ・メンバーシッ
プ検索は、あるグループを選択してから、メンバー・リストをブラウズする代わりに、項目に対して
ibm-allGroups 属性を列挙して行われます。セキュリティー許可アプリケーションでこの属性を利用するに
は、大/小文字を区別しないマッチングを使用して、ibm-allGroups の戻す属性値がすべて、大文字になる
ようにします。 小文字の値は、ディレクトリー・サーバーに格納されます。
注: 他のグループを含むグループ (ネストされたグループ) のサポートは、WebSphere Application Server Express および LDAP の特定のバージョンに依存しています。 詳しくは、 84 ページの『ユーザー・レジ
ストリーにおけるネストされたグループの使用』 を参照してください。
LDAP サーバーとしての iPlanet Directory Server の使用
iPlanet Directory Server として、iPlanet または NetScape のどちらかのディレクトリー・タイプを選択する
ことができます。この 2 つのディレクトリー・タイプの違いは、グループ・メンバーシップの検索にあり
ます。iPlanet ディレクトリー・タイプは、iPlanet 新規グループ化機構のみを使用する場合に選択します。
新規グループ化機構は iPlanet では役割といい、その属性は nsRole です。役割は、エントリーを統合する
iPlanet での新しいエントリー・グループ化機構です。役割は、アプリケーションによる使用をより効率
的、単純にするために設計されています。例えば、アプリケーションは、あるグループを選択し、メンバ
ー・リストを参照する代わりに、あるエントリーが所有しているすべての役割を列挙して、そのエントリー
の役割を探し出すことができます。WebSphere Application Server - Express セキュリティーは、iPlanet デ
ィレクトリーを使用して、nsRole によって定義されているグループのみをサポートします。従来のグルー
プ化メソッドを使用して、iPlanet サーバーでエントリーをグループ化する場合は、ディレクトリー・タイ
プとして、NetScape を選択します。
82
WebSphere Application Server - Express Version 5.1 セキュリティー
LDAP サーバーとしての MS Active Directory サーバーの使用
WebSphere Application Server - Express による認証に LDAP サーバーとして Microsoft Active Directory
を使用するには、特定の手順に従う必要があります。Microsoft Active Directory では、デフォルトで不特定
の LDAP 照会を行うことはできません。 LDAP 照会の作成またはディレクトリーの検索を行うには、
Windows システムの管理者グループに属するアカウントの識別名 (DN) を使用して LDAP クライアント
を、LDAP サーバーにバインドする必要があります。Active Directory におけるグループ・メンバーシップ
検索は、各グループのメンバー・リストを検索する代わりに、あるユーザー・エントリーが所有する属性の
メンバーを列挙して行われます。このデフォルトの振る舞いを変更して、各グループを検索するようにする
場合は、「グループ・メンバー ID マップ (Group Member ID Map)」フィールドで、memberof:member を
group:member に変更します。
Microsoft Active Directory を LDAP サーバーとして設定するには、以下のステップを実行します。
1. 管理者グループ内のアカウントの完全な識別名とパスワードを決定します。
例えば Active Directory の管理者が Active Directory Users and Computers Windows NT または
Windows 2000 システムのコントロール・パネルの「ユーザー (Users)」フォルダーにアカウントを作成
し、DNS ドメインが ibm.com の場合、結果の DN の構造は次のようになります。
cn=adminUsername, cn=users, dc=ibm, dc=com
2. Microsoft Active Directory のアカウントの短縮名とパスワードを決定します。
このパスワードは、前のステップで使用したカウントと同じにする必要はありません。
3. WebSphere 管理コンソールを使用して、Microsoft Active Directory を使用するために必要な情報をセッ
トアップします。
a. 必要に応じて、ドメインの管理サーバーを始動します。
b. 管理コンソールで、「セキュリティー (Security)」―>「ユーザー・レジストリー (User
Registries)」―>「LDAP」とクリックします。
c. LDAP の設定フィールドに次の情報を入力します。
v Security Server ID (セキュリティー・サーバー ID): アカウントの短縮名。
v Security Server Password (セキュリティー・サーバー・パスワード): アカウントのパスワード。
v Directory Type (ディレクトリー・タイプ): Active Directory。
v Host (ホスト): Microsoft Active Directory が動作しているマシンの DNS 名。
v Base Distinguished Name (基本識別名): アカウントの識別名のドメイン・コンポーネント。例え
ば、dc=ibm, dc=com Bind です。
v Distinguished Name: アカウントの完全識別名。例えば、cn=adminUsername, cn=users, dc=ibm,
dc=com です。
v Bind Password (バインド・パスワード): アカウントのパスワード。
d. 「OK」をクリックして変更を保管します。
e. 管理サーバーを停止、再始動し、変更内容を有効にします。
LDAP サーバーとしての Lotus Domino Server の使用
Lotus Domino LDAP Server バージョン 6 を選択し、属性の短い名前がスキーマで定義されていない場合
は、次のいずれかを行うことができます。
v スキーマを変更して、shortname 属性を追加する。
セキュリティー
83
v ユーザー ID マップ・フィルターを変更して、短い名前をそれ以外の定義済みの属性 (uid が望ましい)
で置き換える。例えば、person:shortname を person:uid に変更します。
ユーザー・レジストリーにおけるネストされたグループの使用: グループの使用によって、権限を管理す
るコストを大幅に削減することができます。しかし、WebSphere Application Server - Express のセキュリテ
ィーの場合、ネストされたグループ (すなわち、他のグループを含むグループ) を LocalOS ユーザー・レ
ジストリーで使用することは可能ではなく、またネストされたグループは、WebSphere Application Server Express バージョン 5.0.1 以前では LDAP ユーザー・レジストリーにサポートされていません。
次の理由によって、ネストされたグループの使用は禁止されています。
v i5/OS グループ・プロファイルが、それ以外のグループ・プロファイルのメンバーになることはできませ
ん。
v バージョン 5.0.1 以前では、グループ内のユーザー・メンバーシップを判別するために WebSphere
Application Server - Express が使用するメカニズムは、ネストされたグループを認識しません。このメカ
ニズムは、ユーザーのメンバー属性に対してすべてのグループを検索するだけです。グループそのもの
が他のグループのメンバーであるかどうかを判別することはできません。
再帰的検索機能のない LDAP サーバーの場合は、WebSphere Application Server - Express セキュリティー
は、再帰的機能を提供します。この機能は、拡張 LDAP ユーザー・レジストリー設定内で ネストされた
グループ検索の実行 (Perform a Nested Group Search) オプションを選択することによって使用可能にな
ります。詳しくは、 86 ページの『Lightweight Directory Access Protocol におけるユーザーのグループ・メ
ンバーシップの検索 (バージョン 5.1.1 以降)』 を参照してください。
WebSphere Application Server - Express バージョン 5.0.1 (およびそれ以降) およびバージョン 5.1 は、
LDAP 4.1 で追加されたネストされたグループ機能を使用します。 WebSphere Application Server - Express
のこれらのバージョンは、LDAP 4.1 をサポートするすべての IBM Directory Server 製品内で、ネストさ
れたグループ機能をサポートします。 iSeries 上で実行される IBM Directory Server 製品は i5/OS
Directory Services と呼ばれ、OS/400 V5R2 以降が同梱されています。完全な LDAP 4.1 サポートを提供
するには、修正が必要であることに注意してください。 i5/OS Directory Services および必要な修正につい
て詳しくは、iSeries Directory Services (LDAP): V5R2 の新機能 (New V5R2 Enhancements) を参照してく
ださい。
(http://www.ibm.com/servers/eserver/iseries/ldap/whatsnew41.htm)
WebSphere セキュリティーが IBM_Directory_Server を LDAP サーバー・タイプとして使用するように構
成され、IBM Directory Server LDAP ディレクトリー・サーバーが LDAP 4.1 をサポートしているとき、
グループ・メンバーシップは ibm-allGroups 属性を使用して判別されます。
例えば、group92 が WebSphere 管理コンソールの管理者役割にバインドされているとします。 group2 グ
ループは group92 のメンバーです。 group2 は user2 および user4 を含み、これらのユーザーは管理コ
ンソールにログインし、使用する許可が与えられています。
この例では、LDAP ディレクトリーは次の項目を含んでいます。
dn: c=US
objectclass: top
objectclass: country
c: US
description=United States
dn: o=IBM, c=US
objectclass: top
objectclass: organization
o: IBM
description=International Business Machines
84
WebSphere Application Server - Express Version 5.1 セキュリティー
dn: cn=user2, o=IBM, c=US
objectclass: person
objectclass: inetOrgPerson
objectclass: top
objectclass: organizationalPerson
objectclass: ePerson
cn: user2
sn: Sec Two
uid: user2
userpassword: security
dn: cn=user4, o=IBM, c=US
objectclass: person
objectclass: inetOrgPerson
objectclass: top
objectclass: organizationalPerson
objectclass: ePerson
cn: user4
sn: Sec Four
uid: user4
userpassword: security
dn: cn=group2, o=IBM, c=US
objectclass: top
objectclass: groupOfNames
cn: group2
member: cn=user2, o=IBM, c=US
member: cn=user4, o=IBM, c=US
description: WSA Group Two
dn: cn=group92,o=IBM,c=US
objectclass: top
objectclass: groupOfNames
objectclass: ibm-nestedGroup
cn: group92
description: WSA Group Ninety Two
ibm-memberGroup: cn=group2, o=IBM, c=US
最後の項目で、group2 が group92 のメンバーであることに注意してください。 このメンバーシップは
group92 の ibm-memberGroup 属性内で指定されます。
LDAP ユーザー・レジストリーへのユーザーの追加: iSeries サーバーで Lightweight Directory Access
Protocol (LDAP) ディレクトリー・サービスを使用すると、ユーザー・レジストリー情報を保管することが
できます。このため、WebSphere リソースに許可するユーザーを LDAP ディレクトリーに追加する必要が
あります。
さまざまな方法を使用してユーザーを追加することができますが、LDAP Data Interchange Format (LDIF)
ファイルを作成するのが最も簡単な方法です。このファイルには、ディレクトリーに追加するユーザーのセ
ットを含めます。このファイルは、ldapModify などの LDAP ユーティリティーが使用します。これらのユ
ーティリティーは、i5/OS またはワークステーションから実行することができます。これらの LDAP ユー
ティリティーを i5/OS から実行する場合は、LDIF が iSeries 統合ファイル・システム内になければなりま
せん。
注: これは、iSeries Directory Services 製品に固有の情報です。
以下のステップを実行してください。
1. LDIF ファイルを作成する。 iSeries ファイル編集 (EDTF) ユーティリティーを使用します。あるい
は、ワークステーション・テキスト・エディターを使用してファイルを作成し、マップ済みの (マウン
セキュリティー
85
トされた) ドライブを介して、またはファイル転送プロトコル (FTP) を使用し、そのファイルを iSeries
統合ファイル・システムに保管することができます。
WebSphere Application Server - Express および iSeries LDAP ディレクトリー・サービスの場合、
ePerson スキーマ定義に対応する項目をディレクトリーに作成します。
単純な ePerson LDIF 項目の例を、以下に示します。
dn: cn=John Doe, ou=Rochester, o=IBM, c=US
objectclass: person
objectclass: inetOrgPerson
objectclass: top
objectclass: organizationalPerson
objectclass: ePerson
cn: John Doe
sn: Doe
uid: jdoe
userpassword: secretpass
この LDIF 項目は、ユーザー John Doe に ePerson を定義します。 John のユーザー識別 (uid) は
jdoe に、パスワードは secretpass に設定されています。 この項目は、米国内の組織 IBM の
Rochester 組織単位内にあります。各項目 (ou、o、および c) は、この ePerson 項目を定義する前に、
事前に定義されています。一連の LDIF 項目を同じファイル内に定義して、WebSphere Application
Server - Express の LTPA ユーザーを定義することができます。
userpassword 属性に値を指定しないと、i5/OS LDAP サーバーは、uid 属性値で識別されるローカル
i5/OS ユーザー・プロファイルで、LTPA ユーザーを認証しようとします。このアクションが望ましい
のは、ユーザーが i5/OS ユーザー・プロファイルを持ち、i5/OS ユーザー・レジストリーと LDAP デ
ィレクトリーの両方でパスワードを管理したくない場合です。
ePerson 項目を作成する場合は、cn 属性および uid 属性のそれぞれに固有の値を指定するようにして
ください。つまり、cn 属性と uid 属性の値が同じ 2 つの項目を作成してはいけません。
注: 大規模なユーザー・レジストリーを使用する場合、 Group Member ID Map プロパティーがデフォ
ルト値 (groupOfNames:member と groupOfUniqueNames:uniqueMember の両方) のままであると、ログイ
ンのパフォーマンスに重大な悪影響を及ぼす可能性があります。
このパフォーマンス上の問題に対応するには、これらのオブジェクト・クラスの 1 つ (両方ではなく)
を指定します。次に、選択したオブジェクト・クラスを排他的に使用して、ユーザー・レジストリー内
でグループを実装しなければなりません。
2. iSeries サーバー上のユーザーのディレクトリーに、LDIF ファイル項目をインポートする。 Qshell イ
ンタープリター (QSH)、またはワークステーションで LDAP ldapadd ユーティリティーを使用しま
す。
LDIF 項目のインポートの詳細については、iSeries Information Center のディレクトリー・サービス資料
を参照してください。
v V5R4 の場合
v V5R3 の場合
v V5R2の場合
Lightweight Directory Access Protocol におけるユーザーのグループ・メンバーシップの検索 (バージョン
5.1.1 以降): WebSphere Application Server - Express のセキュリティーを構成して、グループのメンバー
シップを直接または間接的に検索することができます。また、複数の Lightweight Directory Access Protocol
86
WebSphere Application Server - Express Version 5.1 セキュリティー
(LDAP) サーバーに対して、静的グループのみを検索するように構成する、または静的グループ、再帰的
(あるいはネストされた) グループ、および動的グループを検索するように構成することもできます。
v ユーザー・オブジェクトからの直接的なグループ・メンバーシップの評価
いくつかの一般の LDAP サーバーによって、ユーザー・オブジェクトは、そのオブジェクトが属してい
るグループ (Microsoft Active Directory Server、または eDirectory など) についての情報を含むことがで
きます。 または、ユーザーのグループ・メンバーシップは、ユーザー・オブジェクト (IBM Directory
Server または SunOne ディレクトリー・サーバーなど) から計算可能な属性である場合があります。 い
くつかの LDAP サーバーでは、この属性を使用してユーザーの動的グループ・メンバーシップ、ネステ
ィング・グループ・メンバーシップ、および静的グループ・メンバーシップを含むようにして、単一の
属性からすべてのグループ・メンバーシップを見付けることができます。
例えば、IBM Directory Server 内で、静的グループ、動的グループ、およびネストされたグループを含む
すべてのグループ・メンバーシップは、ibm-allGroups 属性を使用して戻すことができます。 Sun ONE
では、管理対象役割、フィルタリングされた役割、およびネストされた役割を含むすべての役割は、
nsRole 属性を使用して計算されます。 LDAP サーバーがユーザー・オブジェクト内にこのような属性
を持って、動的グループ、ネストされたグループ、および静的グループを含んでいる場合、WebSphere
Application Server - Express セキュリティーは、この属性を使用して動的グループ、ネストされたグルー
プ、および静的グループをサポートするように構成することができます。
v グループ・オブジェクトからの間接的なグループ・メンバーシップの評価
一部の LDAP サーバーでは、Lotus Domino LDAP サーバーのようなグループ・オブジェクトのみがユ
ーザーについての情報を含むことが可能です。 LDAP サーバーでは、ユーザー・オブジェクトがグルー
プについての情報を含むことはできません。このタイプの LDAP サーバーの場合は、グループ・メンバ
ーシップの検索は、グループのメンバー・リスト上でユーザーを検索して実行されます。メンバー・リ
スト評価は、現行では、バージョン 5 以前のすべての WebSphere Application Server 製品リリースの静
的グループ・メンバーシップの検索で使用されます。
ご使用の LDAP サーバーがユーザー・オブジェクト内にグループ情報を含むような属性を持っている場合
は、グループ・メンバーシップの検索に対して直接法を使用します。直接法または間接法を使用するために
は、拡張 LDAP 設定パネルで「グループ・メンバー ID マップ (Group Member ID Map)」フィールド
に、以下を使用して適切な値を入力します。
v attribute: 直接法のための attribute ペア
v objectclass: 間接法のための attribute ペア
attribute のサンプル項目: 「グループ・メンバー ID マップ (Group Member ID Map)」フィールド内の
attribute ペアは、次のものを含みます。
v IBM Directory Server 用の ibm-allGroups:member
v グループが SunONE 内の Role を使用して作成された場合の、SunONE ディレクトリー用の
nsRole:nsRole
v Microsoft Active Directory Server 内の memberOf:member
objectClass のサンプル項目: 「グループ・メンバー ID マップ (Group Member ID Map)」フィールド内の
attribute ペアは、次のものを含みます。
v Domino 用の dominoGroup:member
v eDirectory 用の groupOfNames:member
直接法を使用しているとき、動的グループ、再帰的グループ、および静的グループは、単一属性の複数の値
として戻される可能性があります。例えば、IBM Directory Server 内で、静的グループ、動的グループ、お
よびネストされたグループを含むすべてのグループ・メンバーシップは、ibm-allGroups 属性を使用して戻
セキュリティー
87
すことができます。 Sun ONE では、管理対象役割、フィルタリングされた役割、およびネストされた役
割を含むすべての役割は、nsRole 属性を使用して計算されます。LDAP サーバーが nsRole 属性を使用で
きる場合、動的グループ、ネストされたグループ、および静的グループは、すべて WebSphere Application
Server - Express によってサポートされます。
一部の LDAP サーバーは、再帰的コンピューティング機能を持っていません。例えば、Microsoft Active
Directory サーバーは memberOf 属性を使用した直接のグループ検索機能を持っているにもかかわらず、こ
の属性はグループが直接ネストされたグループをその下にリストするだけで、ネストされた先行物の再帰的
リストは含みません。また、例えば Lotus Domino LDAP サーバーは、ユーザーのためのグループ・メン
バーシップを見付けるために間接法しかサポートしません (Domino サーバーから直接再帰的グループ・メ
ンバーシップを獲得することはできません)。 再帰的検索機能のない LDAP サーバーの場合は、
WebSphere Application Server セキュリティーが、拡張 LDAP ユーザー・レジストリー設定内で ネストさ
れたグループ検索の実行 (Perform a Nested Group Search) をクリックすることによって使用可能になる
再帰的機能を提供します。ご使用の LDAP サーバーが再帰的検索を提供していない場合のみ (そして再帰
的検索が要求される場合のみ) このオプションを選択してください。
LDAP 検索フィルターの構成: Lightweight Directory Access Protocol (LDAP) フィルターは、LDAP ディ
レクトリー・サーバーからユーザーおよびグループについての情報を検索し取得するために、WebSphere
Application Server - Express が使用します。製品がサポートする各 LDAP サーバーに関して、デフォルト
のフィルター・セットが用意されています。これらのフィルターは、ユーザーの LDAP 構成に適合するよ
うに変更できます。フィルターが変更されると (および「OK」または「適用 (Apply)」がクリックされ
る)、LDAP レジストリー・パネル内のディレクトリー・タイプがカスタムに変化し、カスタム・フィルタ
ーが使用されることを示します。また、フィルターを作成して任意のタイプの LDAP サーバーをサポート
できます。追加の LDAP ディレクトリーのサポート作業はオプションで、IBM はその他の LDAP ディレ
クトリー・タイプはサポートしません。
LDAP 用の検索フィルターを構成するには、管理コンソールで以下のステップを実行します。
1. 「セキュリティー (Security)」―>「ユーザー・レジストリー (User Registries)」―>「LDAP」をクリッ
クします。「追加プロパティー (Additional Properties)」で、「拡張 LDAP 設定 (Advanced LDAP
Settings)」をクリックします。
2. 必要に応じて、ユーザー・フィルターを変更します。
ユーザー・フィルターは、ユーザーのレジストリーの検索に使用されます。これは、通常、ユーザーへ
のセキュリティー役割の割り当てに使用されます。フィルターに指定された属性を使用して、ユーザー
の認証にも使用されます。これはディレクトリー・サービスでユーザーを検索するためのプロパティー
を指定します。例えば、ユーザー ID (uid) に基づき、またオブジェクト・クラス inetOrgPerson を使用
してユーザーを検索するには、次のプロパティーを指定します。
(&(uid=%v)(objectclass=inetOrgPerson)
実行時に、%v がユーザーの uid 属性で置き換えられます。ユーザーの uid 属性は、固有キーでなけれ
ばなりません。つまり、同一のオブジェクト・クラスを持つ 2 つの LDAP 項目が同一の uid を持つこ
とはできません。
この構文についての詳細は、LDAP ディレクトリー・サービス資料を参照してください。
3. 必要に応じて、グループ・フィルターを変更します。
グループ・フィルターは、グループのレジストリーの検索に使用されます。これは、通常、グループへ
のセキュリティー役割の割り当てに使用されます。ディレクトリー・サービス内でグループを検索する
88
WebSphere Application Server - Express Version 5.1 セキュリティー
ためのプロパティーを指定します。例えば、その共通名 (CN) に基づき、また groupOfNames か
groupOfUniqueNames のいずれかのオブジェクト・クラスを使用してグループを検索するには、次のプ
ロパティーを指定します。
(&(cn=%v)(|(objectclass=groupOfNames)(objectclass=groupOfUniqueNames)))
この構文についての詳細は、LDAP ディレクトリー・サービス資料を参照してください。
4. 必要に応じて、ユーザー ID マップ・フィルターを変更します。
このフィルターにより、ユーザーの短縮名が LDAP エントリーにマップされます。これにより、ユー
ザーが短縮名で表示される場合に、ユーザーを表す情報を指定します。例えば、ID によってタイプ・
オブジェクト・クラス、inetOrgPerson のエントリーを表示する場合は、inetOrgPerson:uid と指定し
ます。
このフィールドには、セミコロン (;) で区切られた objectclass:property の複数のペアが入ります。
getCallerPrincipal() や getUserPrincipal() などのメソッドに関して整合した値を指定するには、このフィ
ルターを使用して取得した短縮名を使用します。例えば、ユーザー CN=Bob Smith, ou=austin.ibm.com,
o=IBM, c=US は、このユーザー用に定義された属性 (例えば、電子メール・アドレス、社会保障番号な
ど) を使用してログインできますが、上記のメソッドが呼び出されると、ログイン方法に関係なくユー
ザー ID Bob が戻ります。
5. 必要に応じて、グループ ID マップ・フィルターを変更します。
このフィルターにより、グループの短縮名が LDAP エントリーにマップされます。これにより、グル
ープが表示されるときにグループを表す情報を指定します。例えば、グループを名前で表示するには、
*:cn を指定します。アスタリスク (*) はワイルドカード文字であり、この場合、すべてのオブジェク
ト・クラスを検索します。このフィールドには、セミコロン (;) で区切られた objectclass:property
の複数のペアが入ります。
6. 必要に応じて、グループ・メンバー ID マップを変更します。
このフィルターにより、ユーザーとグループ・メンバーの対応を識別します。SecureWay、Netscape、お
よび Domino ディレクトリー・タイプでは、ユーザーが指定された属性に含まれている場合、このフィ
ールドは、検出するために指定されたオブジェクト・クラスに一致するすべてのグループを照会するの
に使用されます。例えば、オブジェクト・クラスが groupOfNames のグループに所属し、メンバー属性
に含まれるすべてのユーザーを取得するには、groupOfNames:member を指定します。これにより、オブ
ジェクト・クラスのどのプロパティーが、そのオブジェクト・クラスによって表されるグループに属す
るメンバーのリストを保管するかを指定します。
このフィールドには、セミコロン (;) で区切られた objectclass:property の複数のペアが入ります。この
構文についての詳細は、LDAP ディレクトリー・サービス資料を参照してください。IBM Directory
Server、iPlanet、および Active Directory の場合、これは、ユーザー・オブジェクト内に格納される情報
を使用して (すべてのグループを個々に照会してそのグループにユーザーが存在するかどうかを検出し
ないで) グループ内のすべてのユーザーを照会するのに使用されます。例えば、ユーザーが所属するす
べてのグループを取得するためには、フィルター memberof:member (Active Directory の場合) を使用し
てユーザー・オブジェクトの属性 memberof を取得します。メンバー属性は、グループ・オブジェクト
を使用してグループ内のすべてのユーザーを取得するのに使用されます。ユーザー・オブジェクトを使
用してグループ情報を取得するとパフォーマンスを向上が予想されます。
7. 必要に応じて、証明書マップ・モードを変更します。
ユーザー・レジストリーとして LDAP が選択される場合、ユーザー認証に X.590 証明書を使用できま
す。このフィールドは、EXACT_DN または CERTIFICATE_FILTER のどちらで X.509 証明書を
セキュリティー
89
LDAP ディレクトリーにマップするのかを指定するのに使用されます。EXACT_DN が選択されると、
証明書の識別名が LDAP サーバー内のユーザー・エントリーと正確にマッチングされます (大文字小文
字およびスペースを含む)。LDAP 設定の「大文字小文字を区別しない (Ignore Case)」フィールドを使
用して、許可が大文字小文字を区別しないようにできます。CERTIFICATE_FILTER が選択されると、
LDAP 内のユーザーに証明書をマップするのに使用される該当する証明書フィルター (次フィールド)
に入力します。
8. フィルターの「証明書マッピング (certificate mapping)」オプションを指定した場合、このプロパティー
を使用して使用する LDAP フィルターを指定し、クライアント証明書の属性を LDAP の項目にマップ
します。
実行時に、複数の LDAP 項目がフィルター仕様に一致する場合、あいまい一致となるため、認証は失
敗します。このフィルターの構文、すなわち構造は次のとおりです。
LDAP attribute=${Client certificate attribute}
ここで、attribute は LDAP サーバーで使用するよう構成されたスキーマに依存する LDAP 属性で、
Client certificate attribute はクライアント証明書内のパブリック属性のうちの 1 つです。例:
uid=${SubjectCN}) クライアント証明書属性側は、${ で始まり } で終わる必要があります。
以下は、クライアント証明書属性値のリストです。ストリングの大文字小文字を区別します。
v ${UniqueKey}
v ${PublicKey}
v ${Issuer}
v ${NotAfter}
v ${NotBefore}
v ${SerialNumber}
v ${SigAlgName}
v ${SigAlgOID}
v ${SigAlgParams}
v ${SubjectDN}
v ${Version}
このフィールドを使用可能にするには、証明書マッピングで CERTIFICATE_FILTER を選択します。
9. 「OK」をクリックします。
変更の検証 (あったとしても) は、このパネルでは行われません。検証は、「グローバル・セキュリテ
ィー (Global Security)」パネルで、「OK」または「適用 (Apply)」ボタンが押された場合にのみ行われ
ます。セキュリティーを使用可能にする処理を初めて行なっている場合、残りのステップを完了して、
「グローバル・セキュリティー (Global Security)」パネルに移動し、アクティブ・ユーザー・レジスト
リーとして「LDAP」を選択します。セキュリティーはすでに使用可能になっていて、このパネル上の情
報を変更する場合は、「グローバル・セキュリティー (Global Security)」パネルに移動し、「OK」また
は「適用 (Apply)」をクリックして変更を検証します。変更が検証されない場合、サーバーを始動でき
ないことがあります。
動的グループおよびネストされたグループのサポート (バージョン 5.1.1 以降):
ープ名およびメンバーシップ基準が含まれています。
動的グループ には、グル
v グループのメンバーシップ情報は、ユーザー・オブジェクト上の情報と同様に最新です。
90
WebSphere Application Server - Express Version 5.1 セキュリティー
v グループ・オブジェクト上のメンバーを手動で保守する必要はありません。
v 動的グループは、グループのメンバーであるかどうかを調べるのに、アプリケーションがディレクトリ
ーからの膨大な情報量を必要としないように設計されています。
ネストされたグループ によって、継承されたグループのメンバーシップを定義するために使用される、階
層関係の作成が可能になります。ネストされたグループは、その識別名 (DN) が親グループ項目の属性に
よって参照される、子グループ項目として定義されます。
動的グループおよびネストされたグループによって、WebSphere Application Server - Express セキュリティ
ー管理は単純化され、その有効性と柔軟性が高まります。すべてのネストされたグループが同じ特権を共有
している場合は、より大きな親グループを割り当てる必要があるだけです。単一の親グループに 1 つの役
割を割り当てることによって、ランタイム権限テーブルが単純化されます。
IBM Directory Server 用の動的およびネストされたグループのサポートの構成 (バージョン 5.1.1 以降):
WebSphere Application Server - Express バージョン 5.1 は、IBM Directory Server バージョン 4.1 (または
より新しいバージョン) を使用しているときに、すべての LDAP 動的およびネストされたグループをサポ
ートします。この機能は、IBM Directory Server 内の新機能を利用することによって、デフォルトで使用可
能です。 IBM Directory Server バージョン 4.1 は、自動的にすべてのグループのユーザー用のメンバーシ
ップ (動的および再帰的メンバーシップを含む) を計算する ibm-allGroups 下方参照グループ属性を使用
します。セキュリティー・ディレクトリーは、グループ・メンバーをマッチングするためにすべてのグルー
プを間接的に検索するよりも、ユーザー・オブジェクトから直接ユーザー・グループ・メンバーシップを見
付けます。 IBM Directory Server のこの機能を使用するには、WebSphere Application Server - Express を
構成して、大/小文字を区別しないマッチングを実行し、ibm-allGroups によって戻されたすべての属性値
がすべて大文字であるようにします。小文字の値は、ディレクトリー・サーバーに格納されます。
ネストされた使用および IBM Directory Server について詳しくは、 84 ページの『ユーザー・レジストリー
におけるネストされたグループの使用』 を参照してください。
iSeries 上で実行される IBM Directory Server 製品は i5/OS Directory Services と呼ばれ、OS/400 V5R2 以
降が同梱されています。完全な LDAP 4.1 サポートを提供するには、修正が必要であることに注意してく
ださい。 i5/OS Directory Services および必要な修正について詳しくは、iSeries Directory Services (LDAP):
V5R2 の新機能 (New V5R2 Enhancements) を参照してください。
(http://www.ibm.com/servers/eserver/iseries/ldap/whatsnew41.htm)
OS/400 Directory Services の前のバージョン (V5R1 以前) は、WebSphere Application Server - Express 内
で SecureWay Directory タイプとして構成しなければなりません。動的およびネストされたグループは、
サポートされていません。
グループを作成するとき、ネストされたグループおよび動的グループのメンバーシップが正常に処理されて
いることを確認してください。
WebSphere 管理コンソールで、以下のステップを実行します。
1. 「セキュリティー (Security)」 ―> 「ユーザー・レジストリー (User Registries)」と展開して、
「LDAP」をクリックします。
2. IBM_Directory_Server が Type フィールド内で選択されていることを確認してください。
3. 「大文字小文字を区別しない (Ignore Case)」 フィールドが選択されていることを確認してください。
「OK」をクリックします。
4. 「追加プロパティー (Additional Properties)」で、「拡張 LDAP 設定 (Advanced LDAP Settings)」を
クリックします。
セキュリティー
91
5. 拡張 LDAP 設定パネルで、「グループ・フィルター (Group Filter)」フィールドの値を、次の値に変更
します。
(&(cn=%v)(|(objectclass=groupOfNames)(objectclass=groupOfUniqueNames)
(objectclass=groupOfURLs)))
6. 拡張 LDAP 設定パネルで、「グループ・メンバー ID マップ (Group Member ID Map)」フィールド
の値を、次の値に変更します。
ibm-allGroups:member;ibm-allGroups:uniqueMember
7. 「OK」をクリックします。
Sun ONE または iPlanet Directory Server 用の動的およびネストされたグループのサポートの構成:
ONE または iPlanet Directory Server は、2 つのグループ化メカニズムを使用します。
Sun
v グループ は、メンバーのリストとして、またはメンバーのためのフィルターとして他の項目に名前を付
ける項目です。
v 役割 もまた、メンバーのリストとして、またはメンバーのフィルターとして他の項目に名前を付ける項
目です。 追加の機能は、各役割メンバー上に nsrole 属性を生成することによって提供されます。
次の役割のタイプが使用可能です。
– フィルタリングされた役割
指定された LDAP フィルターと一致する場合、項目はメンバーです。このように、役割は各項目内に
含まれている属性に依存しています。この役割は、動的グループと等価です。
– ネストされた役割
他の役割を含む役割を作成します。この役割はネストされたグループと等価です。
– 管理された役割
明示的に役割をメンバー項目に割り当てます。この役割は静的グループと等価です。
役割とグループは、同様に、追加機能で定義され管理されているので、メンバー項目はアクティブな役割を
示す生成された属性を持つことができます。例えば、アプリケーションは、グループを選択してメンバー・
リストを参照するのではなく、項目の役割を読み取ることができます。この機能は、管理を単純化し、容易
にします。
Sun ONE または iPlanet Directory Server 用の動的およびネストされたグループのサポートを構成するに
は、WebSphere 管理コンソールで次のステップを実行します。
1. 「セキュリティー (Security)」 ―> 「ユーザー・レジストリー (User Registries)」と展開して、
「LDAP」をクリックします。
2. 「タイプ (Type)」フィールドで、LDAP サーバー用の「Sun ONE」を選択します。「大文字小文字を
区別しない」オプション。 「OK」をクリックします。
3. 「追加プロパティー (Additional Properties)」で、「拡張 LDAP 設定 (Advanced LDAP Settings)」を
クリックします。
4. 拡張 LDAP 設定パネルで、「グループ・フィルター (Group Filter)」フィールドの値を、次の値に変更
します。
&(cn=%v)(objectclass=ldapsubentry))
5. 拡張 LDAP 設定パネルで、「グループ・メンバー ID マップ (Group Member ID Map)」フィールド
の値を、次の値に変更します。
nsRole:nsRole
6. 「OK」をクリックします。
92
WebSphere Application Server - Express Version 5.1 セキュリティー
カスタム・ユーザー・レジストリーの構成: この作業を開始する前に、UserRegistry インターフェースの
実装とビルドを行ってください。カスタム・ユーザー・レジストリーの開発に関する詳細については、 34
ページの『カスタム・ユーザー・レジストリーの開発』を参照してください。カスタム・ユーザー・レジス
トリーのコード例は、 35 ページの『カスタム・ユーザー・レジストリー』を参照してください。
管理コンソールからカスタム・ユーザー・レジストリーを構成するには、以下のステップを実行する必要が
あります。
1. 管理コンソールで、左側のナビゲーション・パネルにある「セキュリティー (Security)」―>「ユーザ
ー・レジストリー (User Registries)」―>「カスタム (Custom)」をクリックします。
2. 「サーバー・ユーザー ID (Server User ID)」フィールドに有効なユーザー名を入力します。
3. 「サーバー・ユーザー・パスワード (Server User Password)」フィールドにそのユーザーのパスワード
を入力します。
4. 「カスタム・レジストリー・クラス名 (Custom Registry Classname)」フィールドにインプリメンテー
ション・クラス名ファイルの場所のフルネームを入力します。これは、ドット (.) で区切られたファイ
ル名です。このサンプルの場合は、com.ibm.websphere.security.FileRegistrySample になります。こ
のファイルは、以下の条件に合ったディレクトリーなら、統合ファイル・システム内のどのディレクト
リーに置いても構いません。
v ディレクトリーが、製品ディレクトリーの下に置かれていない。(推奨) つまり、ディレクトリーのパ
ス名は /QIBM/ProdData で始まるべきではありません。
v ディレクトリーが ws.ext.dir プロパティーで指定されている。
v ディレクトリーが server.policy ファイルで指定されている。
v QEJBSVR ユーザー・プロファイルがディレクトリーに対し Execute (*X) 権限を持ち、またクラ
ス・ファイルおよびそれをサポートするクラスに対して Read and Execute (*RX) 権限を持ってい
る。このサンプルでは、これは FileRegistrySample.class および RegExpSample.class ファイルを含み
ます。
カスタム・レジストリーのインプリメンテーション・クラス・ファイルが含まれるディレクトリーを
ws.ext.dir プロパティーで指定するには、管理コンソールで以下のステップを実行します。
a. ナビゲーション・メニューで「サーバー (Servers)」を展開し、「アプリケーション・サーバー
(Application Servers)」をクリックします。
b. 「アプリケーション・サーバー (Application Servers)」ページで、サーバーの名前をクリックしま
す。
c. 「追加プロパティー (Additional Properties)」で、「プロセス定義 (Process Definition)」をクリック
します。
d. 「追加プロパティー (Additional Properties)」で、「Java 仮想マシン (Java Virtual Machine)」をク
リックします。
e. 「追加プロパティー (Additional Properties)」で、「カスタム・プロパティー (Custom Properties)」
をクリックします。
f. ws.ext.dirs プロパティーがすでに定義されている場合には、それをクリックし、その値のうしろにコ
ロン (:) を付け、インプリメンテーション・クラスが含まれるディレクトリーの完全修飾パスを追加
します。
ws.ext.dirs プロパティーがリストされていない場合には、「新規 (New)」をクリックします。プロパ
ティーの名前として ws.ext.dirs を指定し、インプリメンテーション・クラスまたは JAR ファイ
ルが含まれるディレクトリーを指定します。
g. 「OK」をクリックします。
セキュリティー
93
h. 「保管」をクリックします。
このディレクトリーを server.policy ファイルに追加するには、WebSphere Application Server インスタ
ンスの properties サブディレクトリーにある server.policy ファイルを編集します。次の許可を指定しま
す。
grant codeBase “file:/CustomRegistry/-” {
permission java.security.AllPermission;
};
server.policy files の詳細については、 174 ページの『server.policy ファイルの構成』を参照してくださ
い。
5. 大文字小文字を区別しない認証を実行したい場合には、「大文字小文字を区別しない (Ignore Case)」
チェック・ボックス にチェックを入れます。このオプションを使用可能にする必要があるのは、ユーザ
ーのレジストリーが大文字小文字を区別したものでなく、ユーザーやグループの照会に対して戻される
文字のケース (大文字小文字の別) に一貫性がない場合のみです。
6. レジストリーを初期化するために入力しておきたい追加プロパティーが他にある場合には、「適用
(Apply)」をクリックします。そうでない場合には、「OK」をクリックして、セキュリティーの使用可
能化に必要なステップを完了します。
7. システムを初期化するために追加プロパティーを入力する必要がある場合には、パネルの下部にある
「カスタム・プロパティー (Custom Properties)」をクリックします。「新規」をクリックします。プロ
パティーの名前と値を入力します。「OK」をクリックします。まだ追加するプロパティーがある場合
には、このステップを繰り返します。
このサンプルの場合、次の 2 つのプロパティーを入力します (users.props と groups.props は、製品イ
ンストール・ディレクトリー配下の myDir ディレクトリーにあるものと仮定します)。
プロパティー名
プロパティー値
usersFile
${USER_INSTALL_ROOT}/myDir/users.props
groupsFile
${USER_INSTALL_ROOT}/myDir/groups.props
注: QEJBSVR ユーザー・プロファイルは、user.props および groups.props が格納されているディレクト
リーに対して Execute (*X) 権限を持っていなければなりません。それに加え、QEJBSVR は user.props
および groups.props の両ファイルに対して Read and Execute (*RX) 権限を持っていなければなりませ
ん。
「説明 (Description)」、「必須 (Required)」、および「検証式 (Validation Expression)」フィールド
は、使用されないフィールドであるため、ブランクのままにしておくことができます。
8. セキュリティーを初めて使用可能にする場合は、残りのステップを完了してから「グローバル・セキュ
リティー (Global Security)」パネルに進みます。「アクティブ・ユーザー・レジストリー (Active User
Registry)」に Custom を選択します。セキュリティーがすでに使用可能な状態になっているときにこの
パネルの情報を変更してしまった場合には、「グローバル・セキュリティー (Global Security)」パネル
に進み、「OK」または「適用」をクリックして変更内容を検証します。変更内容の妥当性が確認され
なかった場合には、サーバーを始動できなくなる可能性があります。
認証メカニズムの構成: WebSphere Application Server - Express は、以下の認証メカニズムを提供しま
す。
94
WebSphere Application Server - Express Version 5.1 セキュリティー
v
97 ページの『Simple WebSphere Authentication Mechanism』
デフォルトでは、WebSphere Application Server は、SWAM を認証メカニズムとして使用します。
SWAM は、単一サーバー・トポロジーを対象としたものです。SWAM を使用する場合、構成作業は不
要です。
v
97 ページの『Lightweight Third Party Authentication』
LTPA を使用すると、シングル・サインオン (SSO) と、他のアプリケーション・サーバー・プロセスへ
証明書を転送できる機能をサポートできます。 LTPA を構成するには、管理コンソールを使用します。
認証メカニズムの仕組みに関する詳細については、『認証メカニズム』を参照してください。
LTPA 認証メカニズムの構成
WebSphere セキュリティーの認証メカニズムとして LTPA を使用可能にするには、WebSphere 管理コンソ
ールで以下のステップを実行します。
1. 「セキュリティー (Security)」―>「認証メカニズム (Authentication Mechanisms)」と展開して、
「LTPA」をクリックします。
2. パスワード・フィールドにパスワードを入力して、入力したパスワードを確認します。このパスワード
は、LTPA キーのエクスポートやインポートが行われた場合にそうした LTPA キーの暗号化や暗号化解
除に使用されます。キーを別のセルにエクスポートするときには、このパスワードをもう 1 度入力する
必要があります。 LTPA キーの詳細については、 98 ページの『LTPA キーの構成』を参照してくださ
い。
3. 「タイムアウト (Timeout)」フィールドに正の整数を入力します。このタイムアウト値は、LTPA トー
クンの有効期間を分単位で示すものです。トークンにはこの有効期限が含まれるため、このトークンを
受け取ったサーバーは、処理を続ける前に、このトークンが有効であるかどうかを確認できます。トー
クンの有効期限が切れると、ユーザーはログインするように求められます。有効期限の最適値は、それ
ぞれの構成によって異なります。デフォルト値は、30 分です。
4. 「適用」をクリックします。これで、LTPA の構成が設定されました。LTPA キーは、あとで自動的に
生成されるため、ここでは生成しないでください。
5. アプリケーションにフォーム・ベースのログインが含まれる場合には、シングル・サインオン・サポー
トを使用可能にすることもできます。詳しくは、 99 ページの『シングル・サインオンの構成』を参照し
てください。
6. 「グローバル・セキュリティー (Global Security)」パネルで必要な情報を入力して「OK」をクリックし
ます。「グローバル・セキュリティー (Global Security)」パネルで「OK」または「適用 (Apply)」をク
リックすると、最初に LTPA キーが自動的に作成されるため、キーを手動で作成する必要はありませ
ん。
あとでキーを手動で生成しなければならなくなった場合には、 98 ページの『LTPA キーの構成』を参照
してください。
7. 変更内容を有効にするために、サーバーをいったん停止してから再始動します。
認証メカニズム: 認証は、特定の状況下でクライアントを有効にするかどうかを設定するプロセスです。
クライアントは、エンド・ユーザー、マシン、またはアプリケーションのいずれかになります。認証メカニ
ズムは、セキュリティー情報に関する規則 (例えば、別の Java プロセスへの証明書の転送が可能かどうか
というような情報) や、セキュリティー情報がどのような形式で証明書とトークンの両方に格納されるかを
定義します。
WebSphere Application Server - Express における認証メカニズムは、通常、ユーザー・レジストリーと密接
に連携します。ユーザー・レジストリーは、認証メカニズムが認証の実行時に参照するユーザーおよびグル
セキュリティー
95
ープ・アカウントのリポジトリーです。認証メカニズムによって証明書が作成されます。証明書は、製品内
において正常に許可されたクライアント・ユーザーであることを示す内部表現です。証明書の能力は、構成
される認証メカニズムによって決定されます。
WebSphere Application Server - Express は、Simple WebSphere Authentication Mechanism (SWAM) と
Lightweight Third Party Authentication (LTPA) という 2 つの認証メカニズムを提供します。この 2 つの認
証メカニズムの主な違いは、それぞれがサポートする分散型セキュリティー機能にあります。構成済みの認
証メカニズムは、同時に複数アクティブにすることはできません。アクティブな認証メカニズムは、ユーザ
ーが WebSphere グローバル・セキュリティーを構成する際に選択します。
認証プロセス
次の図は、認証プロセスを示したものです。
認証プロセス中にどのようなことが行われるかを以下に説明します。
1. Web クライアントが保護されたリソースにアクセスするときには、認証が必要とされます。 Web クラ
イアントは、HTTP または HTTPS プロトコルを使用して認証情報を送ります。認証情報は、基本認証
(ユーザー ID とパスワード)、証明書トークン (LTPA の場合)、またはクライアント証明書のいずれか
になります。 Web 認証は、Web 認証モジュールによって行われます。
2. 認証モジュールは、Java Authentication and Authorization Service (JAAS) ログイン・モジュールを用い
て実装されます。 Web オーセンティケーターが、ログイン・モジュールに認証データを渡します。
3. ログイン・モジュールは、Lightweight Third Party Authentication (LTPA) か Simple WebSphere
Authentication Mechanism (SWAM) のいずれかを使用して認証を行うことができます。
4. 認証モジュールは、システムで構成されているユーザー・レジストリーを使用して認証を行います。サ
ポートされるレジストリーは、ローカル・オペレーティング・システム (LocalOS) レジストリー、
Lightweight Directory Access Protocol (LDAP) レジストリー、カスタム・レジストリーの 3 種類です。
5. ログイン・モジュールは、認証の後に JAAS の対象を作成し、その認証データから抽出した CORBA
証明書をその対象の公開証明書リストに格納します。証明書は、Web オーセンティケーターに戻されま
す。
96
WebSphere Application Server - Express Version 5.1 セキュリティー
6. Web オーセンティケーターは、受け取った証明書を、現在許可サービスに使用されている ORB に格納
し、それを使用してさらに細かなアクセス制御チェックを行います。
Simple WebSphere Authentication Mechanism: SWAM 認証メカニズムは、単一の簡単な非分散アプリケー
ション・サーバー・ランタイム環境のためのものです。単一のアプリケーション・サーバーに制限されてい
るのは、 SWAM が転送可能な証明書をサポートしていないためです。これは、あるアプリケーション・
サーバー・プロセス内のオブジェクトが 2 番目のプロセスに常駐するオブジェクトでメソッドを起動した
場合に、最初のプロセス内の呼び出し元の ID が 2 番目のプロセスに送信されないことを意味します。送
信されるのは非認証の証明書であり、メソッドで構成されたセキュリティー許可によっては、これが許可の
失敗の原因になる場合もあります。
SWAM は単一のアプリケーション・サーバー・プロセスを対象としているので、シングル・サインオン
(SSO) はサポートされていません。
SWAM 認証メカニズムは、簡単な環境、ソフトウェア開発環境、または分散セキュリティー・ソリューシ
ョンを必要としないその他の環境に適しています。
Lightweight Third Party Authentication: Lightweight Third Party Authentication (LTPA) は、複数のアプリ
ケーション・サーバーとマシンの分散環境を対象とします。WebSphere Application Server - Express は、
LTPA プロトコルで暗号を使用して、分散環境におけるセキュリティーを提供することができます。複数の
ノードとセルに分散されたアプリケーション・サーバーは、LTPA プロトコルを使用して安全に通信するこ
とができます。
LTPA は、シングル・サインオン (SSO) 機能を提供します。SSO を使用すると、DNS ドメインでユーザ
ーは 1 回だけ認証を受ければ、リソースにアクセスするたびに認証情報を入力するように要求されないで
済みます。LTPA プロトコルは、暗号鍵 (LTPA 鍵) を使用して、サーバー間で引き渡されるデータの暗号
化と暗号化解除を行います。LTPA 鍵は、あるセル内のリソースが、他のセル内のリソースにアクセスする
ために、異なるセル間で共有する必要があります (そこでは、関係するセルがすべて、同じ LDAP または
カスタム・レジストリーを使用することが前提とされます)。
LTPA を使用すると、鍵によって署名されているトークンが作成されます。このトークンには、ユーザー情
報と有効期限時刻が格納されています。この理由により、LTPA トークンは、時間依存となります。保護ド
メインに属しているすべての製品サーバーは、日時および時間帯が同じでなければなりません。この条件が
満足されない場合は、LTPA トークンは、早めに有効期限が切れたことになり、認証または検証の失敗の原
因となります。
次に、この LTPA トークンが、Cookies (SSO が有効な場合の Web リソース用) または認証レイヤーを経
由して、(同じセルまたは別のセル内の) 他のサーバーに渡されます。1 つ以上の受信サーバーが発信サー
バーと同じ鍵を共有している場合は、トークンの暗号化を解除して、ユーザー情報を取得し、トークンの有
効期限が切れていないこと、およびトークン内のユーザー情報が、そのレジストリー内で有効なことを保証
するために検証されます。この検証が成功すると、受信サーバーのリソースのアクセスが可能になります。
セル内の WebSphere Application Server プロセスは、同一の鍵セットを共有します。異なるセル間で鍵を共
有する必要がある場合は、あるセルからエクスポートし、他のセルにインポートする必要があります。セキ
ュリティーを考慮して、エクスポートされる鍵は、ユーザー定義パスワードで暗号化されます。エクスポー
ト時と同じパスワードが、別のセルに鍵をインポートする時に必要になります。
LTPA では、構成するユーザー・レジストリーは、中央共有リポジトリーでなければなりません。
以下のテーブルは、LTPA が連係動作できる認証メカニズムの性能とユーザー・レジストリーを要約したも
のです。
セキュリティー
97
転送可能証明書
SSO
LocalOS ユーザー・
レジストリー
LDAP ユーザー・レ
ジストリー
Custom ユーザー・レ
ジストリー
SWAM
不可
不可
可
可
可
LTPA
可
可
可
可
可
注: LTPA の場合、LocalOS ユーザー・レジストリーは、ユーザーとグループがマシンに関係なく同じにな
るように中央管理しなければなりません。
LTPA キーの構成: キーの生成
LTPA のキーは、パスワードの変更が検出されると自動的に生成されます。LTPA パスワードを最初に設定
したときには、LTPA パネルで「OK」または「適用 (Apply)」をクリックすると同時に (セキュリティー
の使用可能化処理の一環として) LTPA のキーが自動的に生成されます。こうした状況では「キーの生成
(Generate Keys)」をクリックする必要はありません。
WebSphere 管理コンソールで、以下のステップを実行します。
1. ナビゲーション・メニューで、「セキュリティー (Security)」―>「認証メカニズム (Authentication
mechanisms)」―>「LTPA」をクリックします。
2. 既存のパスワードを使用する場合には、「キーの生成 (Generate Keys)」をクリックします。このアク
ションをとると、古いキー・セットと同じパスワードで暗号化される新しいキー・セットが生成されま
す。
注: パスワードの変更に関係なく、「キーの生成 (Generate Keys)」をクリックすれば、新しいキー・
セットが生成されます。この新しいキー・セットは、保管しない限りはランタイムに反映されないの
で、ただちにファイルを保管してください。
キーの生成に新しいパスワードを使用するには、その新しいパスワードを入力して、入力したパスワー
ドを確認します。「OK」または「適用 (Apply)」をクリックします。新しいキー・セットが生成されま
す。新しいキー・セットが生成されたことを示すメッセージがコンソールに現れます。「キーの生成
(Generate Keys)」をクリックしないでください。新規作成キーを保管すると、それらのキーがランタイ
ムに渡されます。
3. 「保管 (Save)」をクリックしてキーを保管します。
新しいキー・セットの生成と保管が行われると、キーの伝搬が動的に行われます。その時点で実行している
すべてのプロセス (セル、ノード・エージェント、およびアプリケーション・サーバー) に新規キー・セッ
トの変更が反映されます。以下の各トピックでは、キーのエクスポートとインポートについて説明します。
キーのエクスポート
複数の WebSphere Application Server - Express ドメイン (セル) で WebSphere Application Server Express 内での SSO (シングル・サインオン) をサポートするには、LTPA のキーおよびパスワードをドメ
イン間で共用しなければなりません。セル間でトークンの有効期限に食い違いが生じないように、各ドメイ
ンの時刻を合わせておく必要があります。「キーのエクスポート (Export Keys)」ボタンを使用すれば、
LTPA のキーを他のドメインまたはセルにエクスポートできます。 LTPA のキー・ファイルをエクスポー
トするには、管理コンソールで以下のステップを実行します。
WebSphere 管理コンソールで、以下のステップを実行します。
1. ナビゲーション・メニューで、「セキュリティー (Security)」―>「認証メカニズム (Authentication
mechanisms)」―>「LTPA」をクリックします。
98
WebSphere Application Server - Express Version 5.1 セキュリティー
2. 「キー・ファイル名 (Key File Name)」フィールドに、キーの保管先ファイルの絶対パスを入力しま
す。このファイルは、書き込み許可のあるファイルでなければなりません。
3. 「保管 (Save)」をクリックしてファイルを保管します。
4. 「キーのエクスポート (Export Keys)」をクリックします。LTPA キーを含んだファイルが作成されま
す。新しいキー・セットが、生成またはインポートされている場合、またはエクスポートの前に保管さ
れていなかった場合には、「キーのエクスポート (Export Keys)」は失敗します。失敗を避けるために、
新しいキー・セットをエクスポートする前にそれらが保管されているかどうか確認してください。
5. 「保管 (Save)」をクリックして、構成を保管します。
キーのインポート
複数の WebSphere Application Server - Express ドメイン (セル) で WebSphere Application Server Express 内での SSO (シングル・サインオン) をサポートするには、LTPA のキーおよびパスワードをドメ
イン間で共用しなければなりません。「キーのインポート (Import Keys)」ボタンを使用すれば、LTPA の
キーを他のドメインからインポートできます。 キー・ファイルは、関係するセルの 1 つからエクスポート
されて、1 つのファイルになっていなければなりません。
キーのインポートは、動的な操作です。この時点で実行中のすべてのサーバーは、新しいキー・セットで更
新されるため、バックレベル・キーの入ったバックレベル・トークンは検査に合格しなくなり、ユーザーに
対してはログインを求めるプロンプトが再度表示されます。
WebSphere 管理コンソールで、以下のステップを実行します。
1. ナビゲーション・メニューで、「セキュリティー (Security)」―>「認証メカニズム (Authentication
mechanisms)」―>「LTPA」をクリックします。
2. インポートするキーが存在するセル内におけるパスワードと一致するようにパスワード・フィールドの
パスワードを変更します。
3. 「保管」をクリックして、新しい鍵セットをリポジトリーに保管します。 これは、キーをインポートす
る前に実行しておくべき重要なステップです。パスワードとキーが一致しなかった場合、サーバーは始
動できなくなります。その場合、セキュリティーをオフにして、このプロセスをもう 1 度やり直す必要
があります。
4. 「キー・ファイル名 (Key File Name)」フィールドに、キーの保管先ファイルの絶対パスを入力しま
す。このファイルは、読み取り許可のあるファイルでなければなりません。
5. 「キーのインポート (Import Keys)」をクリックします。これで、キーがシステムにインポートされま
した。
6. 「保管」をクリックして、新しい鍵セットをリポジトリーに保管します。 サーバーが始動するように、
新しいキー・セットを保管して新しいパスワードと一致させる必要があります。
シングル・サインオンの構成: シングル・サインオンがサポートされていると、WebSphere リソース (JSP
ファイル、サーブレット、HTML ファイルなど) および Domino リソース (Domino データベースの文書
など) の両リソースにアクセスする場合、または複数の WebSphere ドメインのリソースにアクセスする場
合に、Web ユーザーの認証が一度だけで済んでしまいます。この認証は、認証メカニズムが LTPA の場合
にのみサポートされます。シングル・サインオンは、この機能を実行するために HTTP Cookies を使用し
ます。
シングル・サインオンが使用可能の場合、LTPA トークンを含む Cookie が作成されます。ユーザーが同じ
DNS ドメイン内の 任意の他の WebSphere または Domino プロセスの他の何らかの Web リソースまたは
セキュリティー
99
Domino リソースにアクセスすると、Cookie がその要求で送られます。その後、LTPA トークンが Cookie
から抽出され、検証されます。詳しくは、『シングル・サインオンの前提条件および条件』を参照してくだ
さい。
Web アプリケーションのいずれかが認証方法としてフォーム・ログインを使用している場合、LTPA 認証
メカニズムでは、シングル・サインオンが使用可能であることが必要です。
複数の WebSphere Application Server ドメインにおけるシングル・サインオンの構成
以下のステップを完了して、複数の WebSphere Application Server ドメインにシングル・サインオンを構成
します。
1. 『シングル・サインオンの前提条件および条件』。
2.
101 ページの『WebSphere Application Server - Express のシングル・サインオンおよび LTPA の構
成』。
WebSphere Application Server - Express と Lotus Domino 間のシングル・サインオンの構成
以下のステップを完了して、WebSphere Application Server と Domino にシングル・サインオンを構成しま
す。
1. 『シングル・サインオンの前提条件および条件』。
2.
101 ページの『WebSphere Application Server - Express のシングル・サインオンおよび LTPA の構
成』。
3.
106 ページの『Lotus Domino のシングル・サインオンの構成』。
4.
109 ページの『WebSphere Application Server - Express と Lotus Domino 間のシングル・サインオンの
検証』。
詳しくは、 110 ページの『シングル・サインオン構成のトラブルシューティング』 を参照してください。
シングル・サインオンの前提条件および条件: WebSphere Application Server - Express サーバー間、また
は WebSphere Application Server - Express と Domino 間でシングル・サインオンのサポートを使用するに
は、アプリケーションは以下の前提条件および条件を満たす必要があります。
v すべての要求の URL に同じ DNS ドメインが含まれている必要があります。例えば、DNS ドメインが
mycompany.com として指定されている場合、シングル・サインオンは
http://server1.mycompany.com/fred および http://server2.mycompany.com/bill に対して有効になり
ます。
v すべてのサーバーが同じユーザー・レジストリーを共用する必要があります。このレジストリーは、サ
ポート対象となる LDAP ディレクトリー・サーバー、またはカスタム・ユーザー・レジストリー (2 つ
の WebSphere Application Server 間でシングル・サインオンが構成される場合) のいずれかにすることが
できます。Lotus Domino ではカスタム・レジストリーの使用はサポートされませんが、Domino でサポ
ートされるレジストリーを WebSphere Application Server - Express 内のカスタム・レジストリーとして
使用することができます。詳しくは、 35 ページの『カスタム・ユーザー・レジストリー』を参照してく
ださい。
Domino ディレクトリー (LDAP アクセス用に構成)、またはその他の LDAP ディレクトリーをユーザ
ー・レジストリーとして使用することができます。 LDAP ディレクトリー製品は、WebSphere
Application Server - Express でサポートされるものである必要があります。サポートされる製品には、
Lotus Domino ディレクトリー・サーバーおよびすべての IBM SecureWay LDAP ディレクトリー・サー
バーが含まれます。 LDAP またはカスタム・レジストリーのいずれを使用した場合でも、シングル・サ
インオン構成は同じです。異なるのは、レジストリーの構成です。
100
WebSphere Application Server - Express Version 5.1 セキュリティー
v すべてのユーザーが単一の LDAP ディレクトリーに定義されている必要があります。LDAP 参照による
複数のディレクトリーへの同時接続はサポートされていません。複数の Domino ディレクトリー
assistance 文書の使用による複数ディレクトリーへのアクセスもサポートされていません。
v サーバーで生成される認証情報が、Cookie 形式でブラウザーに送られるため、ブラウザーで HTTP
Cookie を受け入れ可能にする必要があります。Cookie により、ユーザーの認証情報が他のサーバーへ伝
搬され、これによりユーザーは、異なるサーバーへの要求ごとに認証情報を入力する必要がなくなりま
す。
v Domino 製品は、次の要件を満たす必要があります。
– Domino for iSeries 5.0.6a 以降 (バージョン 6 を含む) がサポートされています。
– それ以外のプラットフォームで、Domino 5.0.5 以降 (バージョン 6 を含む) がサポートされていま
す。
– Lotus Domino Server でシングル・サインオンを使用するよう構成するには、Lotus Notes 5.0.5 以上
の管理クライアントが必要です。
– 複数の Domino ドメイン間で認証情報を共用することができます。
v WebSphere Application Server 製品は、次の要件を満たす必要があります。
– すべてのプラットフォームで WebSphere Application Server Version 3.5 以上がサポートされている。
– WebSphere Application Server によってサポートされている任意の HTTP Web サーバーを使用できま
す。
– 複数の製品管理可能ドメイン間で認証情報を共用することができます。
– 基本的なフォーム・ログインのメカニズムを使用した基本認証 (ユーザー ID およびパスワード) が
サポートされています。
– デフォルトでは、WebSphere Application Server - Express は認証の比較で大文字小文字を区別しま
す。これは、Domino によって認証されたユーザーが WebSphere Application Server 認証テーブルの
項目 (基本識別名も含む) と完全に一致している必要があることを意味します。認証で大文字小文字を
区別しない場合は、LDAP ユーザー・レジストリー設定で Ignore Case プロパティーを使用可能にす
る必要があります。
v WebSphere Application Server - Express バージョン 5 サーバー (5.0 または 5.1 のどちらか) と
WebSphere Application Server バージョン 4 アプリケーション・サーバーの間でシングル・サインオン
を使用している場合は、管理コンソールで LDAP サーバー・ポート番号を指定しなければなりません。
デフォルトで、WebSphere Application Server - Express バージョン 5 のデフォルト LDAP ポート番号
は 0 ですが、WebSphere Application Server バージョン 4 の場合は 0 ではありません。両方のサーバ
ーに対する LDAP ポート番号を同じ値に設定します。バージョン 5 の管理コンソールで、LDAP 設定
ページ上で LDAP ポート番号を設定します。「セキュリティー (Security)」 ―> 「ユーザー・レジスト
リー (User Registries)」 ―> 「LDAP」とクリックします。
WebSphere Application Server - Express のシングル・サインオンおよび LTPA の構成: WebSphere
Application Server - Express と Domino 間、または 2 つの WebSphere Application Server 間でシングル・
サインオンを使用するには、最初に WebSphere Application Server - Express のシングル・サインオンを構
成する必要があります。WebSphere Application Server のシングル・サインオンにより、複数の WebSphere
管理可能ドメイン、および Domino サーバー間で認証情報を共有することができます。
複数の WebSphere 管理可能ドメインで WebSphere Application Server にシングル・サインオンを提供する
には、以下のセクションに示すように、それぞれの管理可能ドメインで同じ DNS ドメイン、ユーザー・レ
ジストリー (LDAP またはカスタム・レジストリーを使用)、および共通セットの LTPA 鍵を使用するよう
構成する必要があります。
セキュリティー
101
このトピックでは、WebSphere Application Server - Express がインストールされており、1 つ以上の
WebSphere 管理可能ドメインで 1 つ以上のアプリケーション・サーバーが構成されていることを前提にし
ます。また、ユーザー・レジストリーに LDAP を使用します。LDAP レジストリーまたはカスタム・レジ
ストリーのどちらを使用する場合でも、シングル・サインオンのセットアップは同じです。違いとしては、
レジストリーの構成が異なります。カスタム・レジストリーについての詳細は、 35 ページの『カスタム・
ユーザー・レジストリー』を参照してください。
WebSphere Application Server - Express のシングル・サインオンを構成する前に、WebSphere Application
Server - Express がアクセス可能であることを確認してください。
1. アプリケーション・サーバーが正しく構成されていることを確認します。Web ブラウザーを使用して、
アプリケーション・リソースにアクセスします。
2. LDAP ディレクトリーが使用可能で、少なくとも 1 ユーザーにより構成されていることを確認しま
す。WebSphere Application Server - Express のシングル・サインオンの構成には、LDAP ディレクトリ
ーへのアクセスが必要です。Domino ディレクトリーまたは他の LDAP ディレクトリーを使用すること
ができます。
WebSphere Application Server - Express のシングル・サインオンを構成するには、次のステップを行いま
す。
1. WebSphere Application Server - Express セキュリティー設定の変更 (102ページ)。
2. WebSphere インスタンスの停止および再始動 (104ページ)。
3. LTPA 鍵のファイルへのエクスポート (105ページ)。
4. ユーザーの許可 (105ページ)。
5. LTPA 鍵ファイルの他の WebSphere 管理可能ドメインへのインポート (105ページ)。
WebSphere Application Server - Express セキュリティー設定の変更
シングル・サインオン構成は、WebSphere 管理可能ドメイン全般のセキュリティー構成の一部として組み
込まれています。
シングル・サインオンをサポートするよう WebSphere のセキュリティー構成を変更するには、WebSphere
管理コンソールで以下のステップを行います。
1. ナビゲーション・メニューで、「セキュリティー (Security)」―>「認証メカニズム (Authentication
mechanisms)」―>「LTPA」をクリックします。
2. 「追加プロパティー (Additional properties)」以下の「シングル・サインオン (SSO) (Single Signon
(SSO))」をクリックします。シングル・サインオンは、デフォルトで使用可能になっています。使用不
可になっている場合は、「使用可能にする (Enable)」をクリックします。
3. すべての要求が HTTPS トランスポートで行われると予想される場合は、「SSL 必須 (Requires
SSL)」フィールドを選択します。
4. 「ドメイン・ネーム (Domain Name)」フィールドに、シングル・サインオンを有効にする DNS ドメ
インの名前を入力します (シングル・サインオン Cookie は、このドメインだけのすべてのサーバーに
送られます)。例えば、ドメインが ibm.com の場合、シングル・サインオンはドメイン
rochester.ibm.com と austin.ibm.com 間では機能しますが、austin.otherCompany.com では機能しませ
ん。
注: ドメイン・フィールドはオプションで、左端がブランクの場合、Web ブラウザーのデフォルト
は、シングル・サインオン Cookie のドメイン名 (それを作成した WebSphere Application Server) に
設定されます。この場合、シングル・サインオンは、Cookie を作成したサーバーに対してのみ有効で
102
WebSphere Application Server - Express Version 5.1 セキュリティー
す。これは、複数の仮想ホストを定義しており、各仮想ホストが自らのドメインまたは別個のドメイン
をシングル・サインオン Cookie に指定する必要がある場合に好ましい動作です。
5. 「OK」をクリックします。
6. LTPA 設定ページを終了する前に、構成する管理可能ドメインにより使用される LTPA 鍵の構成も行
う必要があります。構成する管理可能ドメインの数に応じて、次のいずれかの ステップを行ってくだ
さい。
v 最初のまたは唯一の WebSphere 管理可能ドメインを構成する場合、LTPA 鍵を生成します。
a. 「パスワード (Password)」および「パスワードの確認 (Confirm Password)」フィールドに、こ
れらの LTPA 鍵に関連つける LTPA パスワードを入力します。このパスワードは、これらの鍵
を他の WebSphere Application Server 管理可能ドメイン構成 (存在する場合) にインポートする
場合、および Domino のシングル・サインオンを構成する場合に使用する必要があります。
b. 「鍵の生成 (Generate Keys)」をクリックして、LTPA 鍵を生成します。
c. 「保管 (Save)」をクリックして、LTPA 鍵を保管します。
v 追加の WebSphere 管理可能ドメインを構成する場合は、最初の管理可能ドメインの構成で使用した
LTPA 鍵をインポートする必要があります。詳しくは、『LTPA 鍵ファイルの他の WebSphere 管理
可能ドメインへのインポート』 (105ページ)を参照してください。
7. ナビゲーション・メニューで、「セキュリティー (Security)」―>「ユーザー・レジストリー (User
Registries)」―>「LDAP」とクリックします。(このトピックでは、LDAP ユーザー・レジストリーの
使用を前提にしています。カスタム・レジストリーを使用する場合は、代わりに「カスタム
(Custom)」をクリックしてください。)
8. 「LDAP ユーザー・レジストリー (LDAP User Registry)」ページに設定を入力します。
v サーバー・ユーザー ID (Server User ID)
WebSphere 管理可能ドメインの管理者のユーザー ID。LDAP ディレクトリーに定義済みのユーザー
には省略名またはユーザー ID を使用します。値の前に cn= や uid= を使用した識別名を指定しな
いでください。このフィールドには大文字小文字の区別はありません。
WebSphere 管理コンソールを開始すると、管理アカウントでログインするよう要求されます。この
フィールドに指定したものと正確に同じ値を入力する必要があります。
v サーバー・ユーザー・パスワード (Server User Password)
「サーバー・ユーザー ID (Server User ID)」フィールドに対応したパスワード。このフィールドに
は大文字小文字の区別があります。
v タイプ (Type)
使用する LDAP サーバーのタイプ。例えば、リストから SecureWay (IBM SecureWay LDAP ディ
レクトリー用) または Domino (Domino LDAP ディレクトリー用) を選択できます。
v ホスト (Host)
LDAP ディレクトリーを実行するマシンの完全修飾 DNS 名。例、myhost.mycompany.com
v ポート (Port)
LDAP ディレクトリー・サーバーが listen するポート。デフォルトでは、保護されない接続を使用
する LDAP ディレクトリー・サーバーは、ポート 389 を listen します。
v 基本識別名 (Base Distinguished Name)
LDAP ディレクトリー内で検索を開始するディレクトリーの識別名 (DN)。例えば、DN が cn=John
Doe, ou=Rochester, o=IBM, c=US で基本接尾部が c=US の場合、基本 DN は次のどの形でも指定
できます。
– ou=Rochester, o=IBM, c=us
– o=IBM, c=us
セキュリティー
103
– c=us
このフィールドには大文字小文字の区別はありません。このフィールドは、すべての LDAP ディレ
クトリーで必須です。
v バインド識別名 (Bind Distinguished Name)
ディレクトリーの検索を実行することのできるユーザーの DN。ほとんどの場合、このフィールド
は必須ではなく、すべてのユーザーが LDAP ディレクトリーの検索を許可されます。ただし、
LDAP ディレクトリーが特定のユーザーに制限されている場合、許可ユーザーの DN を指定する必
要があります。例、管理者 cn=administrator
v バインド・パスワード (Bind Password)
「バインド識別名 (Bind Distinguished Name)」フィールドに対応したパスワード。この値は、「バ
インド識別名 (Bind Distinguished Name)」フィールドに値を指定した場合のみ必要です。このフィ
ールドには大文字小文字の区別があります。
v 大文字小文字を区別しない (Ignore Case)
デフォルトでは、WebSphere Application Server - Express は認証の比較で大文字小文字を区別しま
す。これは、Domino によって認証されたユーザーが WebSphere Application Server 認証テーブルの
項目 (基本識別名も含む) と完全に一致している必要があることを意味します。認証で大文字小文字
を区別しない場合は、LDAP ユーザー・レジストリー設定で Ignore Case プロパティーを使用可能
にする必要があります。
9. 「OK」をクリックします。
10. ナビゲーション・メニューで、「セキュリティー (Security)」―>「グローバル・セキュリティー
(Global Security)」を選択します。「使用可能 (Enabled)」チェック・ボックスをチェックして、
WebSphere セキュリティーを使用可能にします。
11. 「キャッシュ・タイムアウト (Cache Timeout)」フィールドが、アプリケーションに適切な値に設定さ
れていることを確認します。タイムアウトになると、WebSphere Application Server - Express はセキュ
リティー・キャッシュをクリアして、セキュリティー・データを再作成します。値が低すぎると、処理
にかかる余分なオーバーヘッドが容認できなくなる場合があります。値が大きすぎると、セキュリティ
ー・データを長時間キャッシュすることによるセキュリティー上のリスクが生じます。デフォルト値は
600 秒です。
12. 「アクティブ認証メカニズム (Active Authentication Mechanism)」設定に「LTPA」を選択します。
13. 「アクティブ・ユーザー・レジストリー (Active User Registry)」設定に「LDAP」を選択します。
14. 「OK」をクリックして変更を保管します。
WebSphere インスタンスの停止および再始動
グローバル・セキュリティー設定を変更する場合、変更を反映させるにインスタンスを停止して再始動する
必要があります。
1. 管理コンソールからログアウトします。
2. サーバー・インスタンスを停止してから始動します。詳しくは、管理 セクションの『アプリケーショ
ン・サーバーの開始およびテスト』を参照してください。
3. 管理コンソールを始動します。シングル・サインオンの構成で指定したドメインを使用します。
注: ホスト名が完全修飾名でない場合、管理コンソールにはログインできません。ログインに失敗する
と、再度ログイン画面が表示されます。
104
WebSphere Application Server - Express Version 5.1 セキュリティー
4. グローバル・セキュリティー設定の「サーバー・ユーザー ID (Server User ID)」および「サーバー・
ユーザー・パスワード (Server User Password)」フィールドに指定したものと同じユーザー ID および
パスワードを指定します。
LTPA 鍵のファイルへのエクスポート
シングル・サインオンのセキュリティー構成を完了するには、LTPA 鍵をファイルにエクスポートする必要
があります。これは、複数の WebSphere 管理可能ドメインで使用するシングル・サインオンを構成する場
合、1 つの WebSphere 管理サーバーにのみ行います。このファイルは、後で追加の管理可能ドメインの構
成、および Domino のシングル・サインオンの構成を行う際に使用します。
LTPA 鍵をファイルにエクスポートするには、管理コンソールで以下のステップを行います。
1. ナビゲーション・メニューで、「セキュリティー (Security)」―>「認証メカニズム (Authentication
mechanisms)」―>「LTPA」をクリックします。
2. 「パスワード (Password)」および「パスワードの確認 (Confirm Password)」フィールドで、エクスポ
ートする鍵に関連したパスワードを指定します。
3. 「鍵ファイル名 (Key File Name)」フィールドに、LTPA 鍵を含めるファイルの名前と場所 (iSeries 統
合ファイル・システム) を指定します。任意のファイル名および拡張子を使用できます。指定した名前
および拡張子を控えておいてください。このファイルは、追加の WebSphere 管理可能ドメインおよび
Domino のシングル・サインオンを構成する際に使用します。
4. 「鍵のエクスポート (Export Keys)」をクリックして、指定したファイルに LTPA 鍵をエクスポートし
ます。
5. 「保管 (Save)」をクリックして、サーバー構成に変更を適用します。
ユーザーの許可
WebSphere Application Server のシングル・サインオン構成をテストする前に、ユーザーに権限を付与し
て、そのアクセスをテストできるようにする必要があります。詳しくは、 118 ページの『管理役割へのユー
ザーの割り当て』を参照してください。
LTPA 鍵ファイルの他の WebSphere 管理可能ドメインへのインポート
複数の WebSphere 管理可能ドメインで使用するシングル・サインオンを構成する場合、ファイルをエクス
ポートした管理可能ドメインだけを除いて、すべての管理可能ドメインに LTPA 鍵ファイルをインポート
します。最初に、これらの管理可能ドメインについて、先のステップをすべて完了したことを確認してくだ
さい (LTPA 鍵のファイルへのエクスポートを除く)。
LTPA 鍵ファイルをインポートするには、以下のステップを実行します。
1. ドメインの WebSphere サーバーを開始します。
2. 管理コンソールを始動します。
3. ナビゲーション・メニューで、「セキュリティー (Security)」―>「認証メカニズム (Authentication
mechanisms)」―>「LTPA」をクリックします。
4. 「パスワード (Password)」および「パスワードの確認 (Confirm Password)」フィールドで、インポー
トする鍵に関連したパスワードを指定します。
5. 「鍵ファイル名 (Key File Name)」フィールドに、LTPA 鍵ファイルの名前と場所を指定します。
6. 「鍵のインポート (Import Keys)」をクリックして、ファイルから LTPA 鍵をインポートします。
7. 「保管 (Save)」をクリックして、マスター構成に変更を適用します。
8. 「ログアウト (Logout)」をクリックして、管理コンソールを終了します。
セキュリティー
105
9. アプリケーション・サーバーを停止して再始動します。
Lotus Domino のシングル・サインオンの構成: Domino のシングル・サインオンを構成するには、セッシ
ョン・ベースの認証用にサーバー文書の新規のマルチサーバー・オプションを選択し、Domino ディレクト
リーに新規のドメイン全体の構成文書 (Web SSO 構成文書と呼ばれる) を作成します。Web SSO 構成文
書は、シングル・サインオン・ドメインに加わるすべての Domino サーバーに複製する必要があり、参加
する Domino サーバーに対して暗号化されて、ユーザー証明書の認証に Domino サーバーが使用する共有
秘密鍵を含みます。
この手順を完了するには、WebSphere Application Server - Express シングル・サインオン構成の次の情報が
必要です。
v 作成された LTPA 鍵を含むファイルの名前およびパス。
v WebSphere Application Server - Express から LTPA 鍵が生成された際に使用したパスワード。
v WebSphere Application Server - Express の構成を行う DNS ドメインの名前。
詳しくは、 101 ページの『WebSphere Application Server - Express のシングル・サインオンおよび LTPA
の構成』を参照してください。
Domino サーバーのシングル・サインオンを構成するには、次のステップを行います。
1. Web SSO 構成文書の作成。 (106ページ)
2. サーバー文書の構成。 (107ページ)
3. Domino 構成の完了。 (107ページ)
4. Domino 構成のシングル・サインオンの検証。 (108ページ)
5. (オプション) オリジナル・ドメインの追加 Domino サーバーの構成。 (108ページ)
6. (オプション) 異なるドメインの Domino サーバーの構成。 (108ページ)
Web SSO 構成文書の作成
Web SSO 構成文書を作成するには、Lotus Notes Client 5.0.5 以上を使用して、次のステップを行います。
1. Domino ディレクトリーでサーバー・ビューを選択します。
2. 「Web」プルダウン・メニューをクリックします。
3. 「Web SSO 構成の作成 (Create Web SSO Configuration)」を選択して、文書を作成します。
4. Web SSO 構成文書で、「鍵 (Keys)」プルダウン・メニューをクリックします。
5. 「WebSphere LTPA 鍵のインポート (Import WebSphere LTPA Keys)」を選択して、先に WebSphere
Application Server 用に作成してファイルに保管した LTPA 鍵をインポートします。
6. WebSphere Application Server サーバー用の鍵を含むファイルの完全修飾パス名を入力して、「OK」を
クリックします。
7. LTPA キーの生成時に使用したパスワードを入力します。SSO 構成文書が自動的に更新され、インポー
トしたファイルの情報が反映されます。
8. この文書のその他のフィールドを入力します。フィールドにはグループやワイルドカードは使用できま
せん。次のリストに、フィールドと期待される値を説明します。
v トークン有効期限 (Token Expiration)
トークンの有効期限が切れるまでの分数。トークンは、非活動状態に応じて有効期限が切れるのでは
なく、発行時からの指定された分数の間のみ有効となります。
v DNS ドメイン (DNS Domain)
システムの完全修飾インターネット名の DNS ドメイン部分です。これは必須フィールドです。
106
WebSphere Application Server - Express Version 5.1 セキュリティー
シングル・サインオンに加わるすべてのサーバーは、同じ DNS ドメイン内になければなりません。
この値は、WebSphere Application Server 構成において指定したドメイン値と同じである必要があり
ます。また、WebSphere Application Server では DNS ドメインの扱いに大文字小文字の区別がある
ため、DNS ドメインの値は、大文字小文字の区別を含め正確に同じように指定してください。
v Domino Server 名 (Domino Server Names)
シングル・サインオンに参加させる Domino サーバー。SSO 構成文書は、文書の作成者、「所有者
(Owners)」と「管理者 (Administrators)」フィールドのメンバー、およびこのフィールドに指定され
たサーバーについて暗号化されます。これらのサーバーは、異なる Domino ドメインに置くことがで
きますが、同じ DNS ドメイン内にある必要があります。
Domino サーバー名は、MyDominoServer/MyOu などの完全修飾名を指定する必要があります。ここに
指定した Domino サーバー名は、クライアントの Domino ディレクトリーにある対応するサーバー
の接続文書の名前にも一致する必要があります。
v LDAP 領域 (LDAP Realm)
LDAP サーバーの完全修飾 DNS ホスト名。このフィールドは、インポートされた LTPA 鍵ファイ
ルの提供する情報により初期化されます。この値は、WebSphere Application Server 管理可能ドメイ
ンに LDAP サーバーのポート値が指定された場合にのみ変更してください。ポートが指定された場
合、値にはコロン (:) の前にエスケープ文字 (¥) を挿入する必要があります。例えば、
myhost.mycompany.com:389 は myhost.mycompany.com¥:389 のようにします。
9. Web SSO 構成文書を保存します。文書は、Web 構成ビューに表示されます。
複数の Domino サーバーでシングル・サインオンを構成する場合は、『追加 Domino サーバーの構成』
(108ページ)を参照してください。
サーバー文書の構成
シングル・サインオンのサーバー文書を更新するには、次のステップを行います。
1. Domino ディレクトリーでサーバー・ビューを選択します。
2. サーバー文書を編集します。
3. 「ポート (Ports)」―>「インターネット・ポート (Internet Ports)」―>「Web」タブを選択します。
4. HTTP 認証オプション・セクションで Web ユーザーの基本認証を有効にするには、「名前とパスワー
ド (Name & password)」を「はい (yes)」に設定します。
5.
「インターネット・プロトコル (Internet Protocols)」―>「Domino Web エンジン (Domino Web
Engine)」を選択します。
6. 「セッション認証 (Session Authentication)」フィールドの「複数サーバー (SSO) (Multiple Servers
(SSO))」を選択して、Domino のシングル・サインオンを有効にします。
7. 「セキュリティー (Security)」タブを選択します。
8. 「インターネット・アクセス (Internet Access)」セクションで、「インターネット認証 (Internet
authentication)」フィールドの「名前バリエーションを増やしてセキュリティー保護を弱める (More
name variations with lower security)」を選択して、認証に省略名を使用できるようにします。
9. サーバー文書を保管します。
複数の Domino サーバーでシングル・サインオンを構成する場合は、『追加 Domino サーバーの構成』
(108ページ)を参照してください。
Domino 構成の完了
セキュリティー
107
手順を続ける前に、Web ユーザーが使用する Domino サーバーの構成を完了します。以降の構成ステップ
は、シングル・サインオンに固有のものではなく、ここでは詳しくは説明しません。以下のタスクについて
(http://www.lotus.com/ldd/doc/domino_notes/5.0.3/help5_admin.nsf) の
は、Domino 5 Administration Help
セキュリティーのトピックを参照してください。
v Domino ディレクトリーを使用しない場合の LDAP ディレクトリーへのアクセスの構成
v Domino リソースへの Web ユーザーの許可
Domino 構成のシングル・サインオンの検証
Domino のシングル・サインオン構成を検証するには、次のステップを行って、Domino サーバーが正しく
構成されており、Web ユーザーが Domino リソースへのアクセスを許可されていることを確認します。
1. Domino サーバーが正しく構成されていることを確認するには、Domino HTTP Web サーバーを停止し
て再始動します。
シングル・サインオンが正しく構成されていると、Domino サーバー・コンソールに次のメッセージが
表示されます。
HTTP: Web SSO 構成を正常にロードしました (HTTP: Successfully loaded Web SSO Configuration)
シングル・サインオンを有効にした Domino サーバーが Web SSO 構成文書を見つけられない、または
「Domino Server 名 (Domino Server Names)」フィールドに含まれておらず文書を暗号化解除できない
場合、サーバーのコンソールに次のメッセージが表示されます。
HTTP: Web SSO 構成のロードにエラーがありました。シングル・サーバー・セッションの認証に戻ってください
(HTTP: Error Loading Web SSO configuration. Reverting to single-server session authentication)
2. ユーザーが許可されていることを確認するには、Domino ディレクトリーなどの Domino リソースにア
クセスしてみてください。最初に Domino ディレクトリーに定義されたユーザーとしてローカル権限の
アクセスを試みます。次に、LDAP ディレクトリー・サービスに定義されたユーザーとして、
WebSphere Application Server ユーザー権限のアクセスを試みます。
単一ドメインの追加 Domino サーバーの構成
複数の Domino サーバーでシングル・サインオンを使用する場合、追加サーバーごとに次のステップを行
います。
1. 初期 Web SSO 構成文書をそれぞれの追加 Domino サーバーに対して複製します。
2. それぞれの追加 Domino サーバーについてサーバー文書を更新します。
3. 各 Domino HTTP Web サーバーを再始動します。
複数 Domino ドメインの Domino サーバーの構成
複数の Domino ドメインの Domino サーバーでシングル・サインオンを使用する場合、Domino サーバー
間にドメイン間認証も設定する必要があります。例えば、2 つの Domino ドメイン X と Y にある
Domino サーバーを想定します。
次の手順に従い、Domino サーバーでドメイン間のシングル・サインオンを実行できるようにします。
1. Domino 管理者は、ドメイン X の Domino ディレクトリーから Web SSO 構成文書をコピーして、ド
メイン Y の Domino ディレクトリーに貼り付けます。Domino 管理者には、ドメイン X の Web SSO
構成文書の暗号化解除、およびドメイン Y の Domino ディレクトリーへの文書の作成を行う権限が必
要です。
108
WebSphere Application Server - Express Version 5.1 セキュリティー
2. Lotus Notes クライアントのロケーション・ホーム・サーバーが、ドメイン Y の Domino サーバーに
設定されていることを確認してください。
3. ドメイン Y の Web SSO 構成文書を編集します。
4. 「参加 Domino Server (Participating Domino Servers)」フィールドには、シングル・サインオンに参
加するドメイン Y のサーバー文書を持つ Domino サーバーのみを含めます。
5. Web SSO 構成文書を保存します。これは、参加するドメイン Y の Domino サーバーに対して暗号化
されるため、これらのサーバーはドメイン X の Domino サーバーと同じ鍵情報をもちます。この共有
情報により、ドメイン Y の Domino サーバーが、ドメイン X の Domino サーバーとシングル・サイ
ンオンを実行できます。
WebSphere Application Server - Express と Lotus Domino 間のシングル・サインオンの検証: このトピッ
クでは、Domino と WebSphere Application Server - Express との間のシングル・サインオンの検証につい
て説明をします。最初に、次の条件が満たされていることを確認してください。
v LDAP ディレクトリーに、テスト用に定義されたユーザーがすくなくとも 1 人定義されている。
v シングル・サインオンに参加する WebSphere 管理可能ドメインごとに、WebSphere 管理コンソールを開
始できる。
v ユーザーは、各管理可能ドメインに対して、LDAP ディレクトリーに定義されたセキュリティー名によ
る認証を行える。
v 少なくとも LDAP ディレクトリーの 1 ユーザーが、少なくとも 1 つの Domino リソース (Domino デ
ィレクトリーなど) へのアクセスを許可されている。
v 少なくとも LDAP ディレクトリーの 1 ユーザーが、少なくとも 1 つの WebSphere リソース
(WebSphere 管理コンソールなど) へのアクセスを許可されている。
v HTTP Cookie を受け入れない 設定をしていない Web ブラウザーから、ユーザー ID とパスワードの入
力後に次のリソースにアクセスできる。
– WebSphere 保護リソース (サーブレットなど)。
– Domino 保護リソース (Lotus Notes データベースなど)。
事前テストがすべて成功したら、シングル・サインオンが正しく機能しているかを検証することができま
す。
WebSphere Application Server - Express と Domino 間のシングル・サインオンをテストするには、次のス
テップを行います。
1. Web ブラウザーを再始動します。
2. Web ブラウザーで HTTP Cookie を受け入れるよう設定します。(Internet Explorer を使用する場合は、
セッションごとの Cookie (保存でなく) を使用可能にします。
3. HTTP Cookie を受け入れる前に通知を行うようブラウザーを設定します。この警告により、サーバーの
認証後に、Domino と WebSphere Application Server が HTTP Cookie を生成してブラウザーに戻すの
を視覚的に確認できます。(Cookie が交換されていることを確認した後は、Cookie の通知を抑止して構
いません。)
4. ブラウザーから、Domino サーバーにより保護されたリソースの URL を指定します。例えば、次の例
のように、不特定ユーザーにアクセスを許可しないデータベースを開いてみます。
a. URL には、完全修飾 DNS ホスト名を使用してください。例えば、http://myhost/names.nsf では
なく http://myhost.mycompany.com/names.nsf を入力します。
b. ユーザー ID とパスワードを要求されたら、Domino と WebSphere Application Server 両方のリソー
スへのアクセスを許可されたユーザー ID を指定してください。
セキュリティー
109
名前の形式は、Domino による Web ユーザーの制限レベル、および Domino ディレクトリーや他の
LDAP ディレクトリーが使用されているかに応じて異なります。(基本認証のオプションについての
詳細は、Domino 5 Administration Help
(http://www.lotus.com/ldd/doc/domino_notes/5.0.3/help5_admin.nsf)、特に Web クライアントの認証レベ
ルの制御に関する情報を参照してください。)
Domino による Web ユーザーの制限レベルは、サーバー文書の「セキュリティー」ウィンドウの
Web サーバー認証フィールドで設定します。デフォルトの構成を使用した場合、ユーザーの省略名
またはユーザー ID を指定することができます。
c. 指示が出たら、HTTP Cookie を受け入れます。
このようなリソースに正常にアクセスできる場合、Domino サーバーにより生成されたトークンが
WebSphere Application Server - Express に受け入れられています。
5. 同じブラウザー・セッションから、WebSphere Application Server - Express に保護されているリソース
にアクセスを試みます。シングル・サインオンが正しく機能している場合、ログインのプロンプトが出
ずにアクセスが認可されます。
URL には、完全修飾された DNS ホスト名を使用します。例えば、http://myhost/snoop ではなく
http://myhost.mycompany.com/snoop を入力します。
注: セッションの有効期限が切れているか無効であることを伝えるメッセージが出た場合、いずれかの
システムで協定世界時オフセットが正しく設定されていない可能性があります。システム値
QUTCOFFSET が正しいことを確認してください。
6. 同じブラウザー・セッションから、シングル・サインオン構成に含まれる追加の Domino および
WebSphere ドメインにより管理されるリソースへのアクセスを試みます。
7. ブラウザー・セッションを再始動して、再度確認ステップを行います。今度は、WebSphere Application
Server - Express により保護されたリソースへのアクセスから開始します。これにより、WebSphere
Application Server が生成するトークンが Domino サーバーにより受け入れられたことが確認されま
す。ユーザー ID およびパスワードを要求されたら、WebSphere Application Server - Express のユーザ
ーのデフォルト命名規則であるユーザーの省略名またはユーザー ID を使用します。
シングル・サインオン構成のトラブルシューティング: この項目では、WebSphere Application Server Express と Domino サーバーの間でシングル・サインオンを構成するときに起こりやすい問題を説明し、考
えられるソリューションを提案します。
v Domino Web SSO 構成文書の保管ができません。
クライアントは、シングル・サインオンに関与している Domino サーバー用の Domino サーバー文書を
検出できなければなりません。 Web SSO 構成文書は指定されたサーバーに対して暗号化されているの
で、クライアント・ロケーション・レコードが示すホーム・サーバーは、関与しているサーバーのある
Domino ドメイン内のサーバーをポイントしなければなりません。このポインターにより、確実にルック
アップがサーバーの公開鍵を検出できるようになります。
「1 つ以上の関係する Domino Server を検出できません」というメッセージを受信した場合は、これら
のサーバーは Web SSO 構成文書を復号できないか、またはシングル・サインオンを実行できません。
Web SSO 構成文書が保管されたとき、ステータス・バーは、文書上でリストされたサーバー、作成者、
および管理者を検出することによって、この文書を暗号化するのに公開鍵がいくつ使用されたかを示し
ます。
110
WebSphere Application Server - Express Version 5.1 セキュリティー
v Domino サーバー・コンソールが、Domino HTTP サーバーの始動で Web SSO 構成文書のロードに失
敗します。
シングル・サインオンの構成中に、サーバー文書は「セッション認証 (Session Authentication)」フィー
ルド内で マルチサーバー 用に構成されます。 Domino HTTP サーバーは、始動中に Web SSO 構成文
書を検出し、ロードしようとします。 Domino サーバー・コンソールは、有効な文書が検出され、復号
された場合は、次のメッセージを報告します。
HTTP: Successfully loaded Web SSO Configuration.
サーバーが Web SSO 構成文書をロードできない場合は、シングル・サインオンが作動しません。この
場合、サーバーは次のメッセージを報告します。
HTTP: Error Loading Web SSO configuration.
Reverting to single-server session authentication.
Domino ディレクトリーの Web 構成ビュー内および $WebSSOConfigs 非表示ビュー内に Web SSO 構
成文書が 1 つしかないことを検証してください。複数の文書を作成することはできませんが、複製中に
追加の文書を挿入することはできます。
Web SSO 構成文書が 1 つしかない場合、同じエラー・メッセージの原因となるもう 1 つの条件は、サ
ーバー文書の公開鍵が ID ファイルの公開鍵と一致しないときです。 この場合、Web SSO 構成文書を
復号する試みは失敗し、エラー・メッセージが生成されます。
この状態は、ID ファイルが複数回作成されたが、サーバー文書が正しく更新されていないときに発生し
ます。通常、Domino サーバー・コンソール上に「公開鍵がサーバー ID と一致しません」というエラ
ー・メッセージが表示されます。このことが発生した場合、シングル・サインオンは、サーバーがそれ
に対応する秘密鍵を持っていない公開鍵で暗号化されているために、作動しません。
鍵の不一致問題を訂正するには、以下のステップを実行します。
1. サーバー ID ファイルから公開鍵をコピーして、それをサーバー文書に貼り付けます。
2. Web SSO 構成文書を再作成します。
v 保護リソースにアクセスするときに認証に失敗します。
Web ユーザーが、ユーザー ID およびパスワードのために繰り返しプロンプトが出される場合は、
Domino または WebSphere セキュリティー・サーバーのどちらかが Lightweight Directory Access
Protocol (LDAP) サーバーでユーザーを認証することができないために、シングル・サインオンが作動し
ません。以下の可能性を確認してください。
– LDAP サーバーが Domino サーバー・マシンからアクセス可能であることを検証します。 TCP/IP
ping ユーティリティーを使用して TCP/IP 接続を確認し、ホスト・マシンが実行されていることを検
証します。
– LDAP ディレクトリー内で LDAP ユーザーが定義されていることを検証します。 ldapsearch ユー
ティリティーを使用して、ユーザー ID が存在し、そのパスワードが正しいことを確認します。例え
ば、i5/OS Qshell、UNIX シェル、または Windows DOS プロンプトから、単一行として入力される
以下のコマンドを実行することができます。
ldapsearch -D “cn=John Doe, ou=Rochester, o=IBM, c=US”
-w mypassword -h myhost.mycompany.com -p 389
-b “ou=Rochester, o=IBM, c=US” (objectclass=*)
ディレクトリー項目のリストが表示されます。起こりうるエラー条件および原因がそれに続きます。
- オブジェクトなし: このエラーは、ユーザー識別名 (DN) 値 (-D オプションの後で指定される) ま
たは基本 DN 値 (-b オプションの後で指定される) のどちらかで参照されるディレクトリー項目が
存在しないことを示しています。
セキュリティー
111
- 無効な信任状: このエラーは、パスワードが無効であることを示しています。
- LDAP サーバーと接触不能: このエラーは、ホスト名またはサーバーに対して指定されたポートが
無効であるか、または LDAP サーバーが稼動していないことを示しています。
- 空のリストは、-b オプションによって指定された基本ディレクトリーにはディレクトリー項目が含
まれていないことを意味しています。
– 識別名の代わりにユーザーの短縮名 (またはユーザー ID) を使用している場合は、ディレクトリー項
目が短縮名で構成されていることを検証します。 Domino ディレクトリーの場合は、Person 文書の
「短縮名/UserID」フィールドです。 LDAP ディレクトリーの場合は、ディレクトリー項目の userid
プロパティーです。
– Domino ディレクトリーではなく、LDAP ディレクトリーを使用しているときに Domino 認証が失敗
した場合、Directory Assistance データベース内の Directory Assistance 文書の LDAP サーバーの構成
設定を検証します。また、サーバー文書が正しい Directory Assistance 文書を参照していることを検証
します。
Directory Assistance 文書内で指定された以下の LDAP 値は、WebSphere 管理可能ドメイン内のユー
ザー・レジストリーに対して指定された値と一致しなければなりません。
- ドメイン名
- LDAP ホスト名
- LDAP ポート
- 基本 DN
さらに、Directory Assistance 文書内で定義された規則は、ユーザーのディレクトリー項目を含むディ
レクトリーの基本 DN を参照しなければなりません。
以下の行をサーバー notes.ini ファイルに追加することによって、LDAP サーバーへの Domino サー
バーの要求をトレースすることができます。
webauth_verbose_trace=1
Domino サーバーを再始動した後で、Web ユーザーが Domino サーバーへの認証を試みると、
Domino サーバー・コンソール内にトレース・メッセージが表示されます。
v 保護リソースにアクセスすると、権限に失敗します。
正常に認証した後で、Web ユーザーに権限エラー・メッセージが表示された場合は、セキュリティーが
正しく構成されていません。
Domino データベースの場合、ユーザーがデータベースのアクセス制御設定内で定義されていることを検
証します。ユーザーの DN を正しく指定するために、Domino Administrative 文書を参照します。例え
ば、DN cn=John Doe, ou=Rochester, o=IBM, c=US の場合は、アクセス制御リスト上の値は John
Doe/Rochester/IBM/US のように設定されなければなりません。
WebSphere Application Server - Express によって保護されたリソースの場合、セキュリティー許可が正
しく設定されていることを検証します。選択されたグループに許可を付与する場合、リソースへのアク
セスを試みるユーザーがそのグループのメンバーであることを確認します。例えば、以下の URL を使
用してディレクトリーのコンテンツを表示することによって、グループのメンバーを検証することがで
きます。
Ldap://myhost.mycompany.com:389/ou=Rochester, o=IBM, c=US??sub
112
WebSphere Application Server - Express Version 5.1 セキュリティー
許可が設定された後で WebSphere Application Server - Express 管理可能ドメイン内で LDAP 構成情報
(ホスト、ポート、および基本 DN) を変更した場合、既存の許可は無効である可能性が高く、再作成が
必要です。
v 保護リソースにアクセスするとき SSO に失敗します。
Web ユーザーが各リソースの認証でプロンプトが出される場合は、SSO が正しく構成されていません。
以下の可能性を確認してください。
– WebSphere Application Server - Express および Domino サーバーの両方が、同じ LDAP ディレクト
リーを使用するように構成されなければなりません。シングル・サインオン用に使用される HTTP
Cookie は、ユーザーの完全 DN (例えば、cn=John Doe, ou=Rochester, o=IBM, c=US) およびドメイ
ン・ネーム・システム (DNS) ドメインを保管します。
– Domino ディレクトリーを使用している場合は、階層名によって Web ユーザーを定義します。例え
ば、Person 文書内の「ユーザー名 (User name)」フィールドを更新して、最初の値: John
Doe/Rochester/IBM/US のように、このフォーマットの名前を含むようにします。
– シングル・サインオンのために構成された Domino サーバーおよび WebSphere Application Server Express サーバーに発行された URL は、ホスト名または TCP/IP アドレスのみでなく、完全 DNS サ
ーバー名を指定しなければなりません。サーバーのグループに Cookies を送信するブラウザーの場合
は、DNS ドメインは Cookie に含まれていなければならず、また Cookie 内の DNS ドメインは
URL と一致しなければなりません。 (この要件は、TCP/IP ドメインのアクセスに Cookies を使用で
きないということを意味します。)
– Domino および WebSphere Application Server - Express は、同じ DNS ドメインを使用するように構
成されなければなりません。DNS ドメイン値が、大文字化も含めて、正確に同じであることを検証し
ます。 DNS ドメイン値は、WebSphere 管理コンソールの「グローバル・セキュリティー設定の構成
(Configure Global Security Settings)」パネル上、および Domino サーバーの Web SSO 構成文書内に
あります。 Domino Web SSO 構成文書に変更を加えた場合は、シングル・サインオンに関与してい
るすべての Domino サーバーに変更された文書を複製します。
– クラスター Domino サーバーは、シングル・サインオンを使用しているクラスター・メンバーへリダ
イレクトするために、Domino Internet Cluster Manager (ICM) のサーバー文書内の完全 DNS サーバ
ー名でデータを追加されたホスト名を持たなければなりません。このフィールドにデータを追加しな
い場合は、デフォルトで、ICM がホスト名のみを使用してクラスター Web サーバーへ URL をリダ
イレクトします。 URL 内に DNS ドメインが含まれていないので、シングル・サインオン Cookie
を送信することはできません。
問題を訂正するには、以下のステップを実行します。
1. サーバー文書を編集します。
2. 「インターネット・プロトコル (Internet Protocols)」タブをクリックします。
3. 「HTTP」タブをクリックします。
4. 「ホスト名 (Host names)」フィールドにサーバーの完全 DNS 名を入力します。
5. LDAP サーバーのポート値が WebSphere Application Server 管理可能ドメインに対して指定されて
いる場合は、Domino Web SSO 構成文書を編集して、「LDAP レルム」フィールドの値内へ、コ
ロン (:) の前に円記号 (¥) を挿入します。例えば、myhost.mycompany.com:389 は
myhost.mycompany.com¥:389 のようにします。
デフォルトの SSL 鍵ストア・ファイルとトラストストア・ファイルの変更: インターネットで送信され
るメッセージの完全性を保護するために、WebSphere Application Server - Express に同梱の デフォルトの
SSL 鍵ストア・ファイルとトラストストア・ファイルを変更することをお勧めします。LDAP ユーザー・
レジストリー、Web コンテナー、および認証プロトコル (CSIv2 と SAS) を含む SSL を使用する各種
セキュリティー
113
WebSphere Application Server - Express フィーチャーに使用できる SSL 構成は、一箇所で指定することが
できます。新規の鍵ストア・ファイルの作成方法については、 138 ページの『Java 鍵ストア・ファイルの
使用』 を参照してください。
異なる用途には異なる鍵ストア・ファイルとトラストストア・ファイルを作成することができます。また
は、1 つのファイルを作成して、サーバーが SSL を使用するすべての場合にそのファイルを適用すること
ができます。新規 KeyStore およびトラストストア・ファイルを作成したら、それを SSL 構成レパートリ
ーに指定します。 SSL 構成レパートリーを使用するには、管理コンソールで、「セキュリティー
(Security)」 を展開し、「SSL」 をクリックします。 DefaultSSLConfig を編集するか、新規の別名を持つ
新規の SSL 構成を作成することができます。
新規の鍵ストア・ファイルとトラストストア・ファイルに新規の別名を作成する場合は、その SSL 構成の
別名 DefaultSSLConfig を参照している場所をすべて変更する必要もあります。管理コンソールで、以下の
場所をそれぞれ変更してください。
v 「セキュリティー (Security)」―>「ユーザー・レジストリー (User Registries)」―>「LDAP」
v 「セキュリティー (Security)」―>「認証プロトコル (Authentication Protocol)」―>「CSIv2 インバウン
ド・トランスポート (CSIv2 Inbound Transport)」
v 「セキュリティー (Security)」―>「認証プロトコル (Authentication Protocol)」―>「CSIv2 アウトバウン
ド・トランスポート (CSIv2 Outbound Transport)」
v 「セキュリティー (Security)」―>「認証プロトコル (Authentication Protocol)」―>「SAS インバウン
ド・トランスポート (SAS Inbound Transport)」
v 「セキュリティー (Security)」―>「認証プロトコル (Authentication Protocol)」―>「SAS アウトバウン
ド・トランスポート (SAS Outbound Transport)」
v 「サーバー (Server)」―>「アプリケーション・サーバー (Application Servers)」―>「app_server」―
>「Web コンテナー (Web Container)」―>「HTTP トランスポート (HTTP transports)」―>「host」
v 「サーバー (Servers)」―>「アプリケーション・サーバー (Application Servers)」―>「app_server」―>
「サーバー・レベル・セキュリティー (Server Level Security)」―>「CSIv2 インバウンド・トランスポ
ート (CSIv2 Inbound Transport)」
v 「サーバー (Servers)」―>「アプリケーション・サーバー (Application Servers)」―>「app_server」―>
「サーバー・セキュリティー (Server Security)」―>「CSIv2 アウトバウンド・トランスポート (CSIv2
OutboundTransport)」
v 「サーバー (Servers)」―>「アプリケーション・サーバー (Application Servers)」―>「app_server」―>
「サーバー・セキュリティー (Server Security)」―>「SAS インバウンド・トランスポート (SAS
Inbound Transport)」
v 「サーバー (Servers)」―>「アプリケーション・サーバー (Application Servers)」―>「app_server」―>
「サーバー・セキュリティー (Server Security)」―>「SAS アウトバウンド・トランスポート (SAS
Outbound Transport)」
v 「サーバー (Server)」 ―> 「アプリケーション・サーバー (Application Servers)」 ―>「app_server」―>
「管理サービス (Administration Services)」 ―>「JMX コネクター (JMX Connectors)」 ―>
「SOAPConnector」 ―> 「カスタム・プロパティー (Custom Properties)」 ―> 「sslConfig」
このリストで、app_server はアプリケーション・サーバーの名前、host は、HTTP トランスポートの host
プロパティーの値です。
soap.client.props ファイルを更新します
114
WebSphere Application Server - Express Version 5.1 セキュリティー
soap.client.props ファイルは、管理ツールのセキュア SOAP 接続をサポートするために使用されます。管理
ツールのセキュア SOAP 接続についての詳細は、「管理 (Administration)」 トピックの 『保護環境におけ
る wsadmin の使用』を参照してください。
soap.client.props ファイルを編集して、新規クライアント鍵ストア・ファイルの以下のプロパティーを設定
してください。
v com.ibm.ssl.keyStore
v com.ibm.ssl.keyStorePassword
v com.ibm.ssl.trustStore
v com.ibm.ssl.trustStorePassword
注:soap.client.props ファイル内でパスワードをエンコードするには、『プロパティー・ファイルにおける手
動でのパスワードのエンコード』 (193ページ)を参照してください。
WebSphere の Web サーバー・プラグイン用の SSL 構成の更新
プラグイン用の SSL 構成の更新について詳しくは、『WebSphere プラグイン用の SSL の構成』 (126ペー
ジ)を参照してください。
注: SSL はデフォルトの構成で Web サーバー・プラグインに対して使用可能です。
グローバル・セキュリティーの使用可能化: WebSphere グローバル・セキュリティーを使用可能にするに
は、以下のステップを実行します。
1. 管理コンソールで、「セキュリティー (Security)」―>「グローバル・セキュリティー (Global
Security)」をクリックして、残りのセキュリティー設定を構成し、セキュリティーを使用可能にしま
す。セキュリティー構成をセットアップする場合、「グローバル・セキュリティー (Global Security)」
の構成は、最後に行う必要があります。これは、セキュリティー構成の最終的な検証がこのページで実
行されるためです。
2. グローバル・セキュリティーの設定値を構成します。
「グローバル・セキュリティーを使用可能にする (Enable global security)」を選択して、サーバーを再
始動したときにセキュリティーが有効になるようにします。
3. 「OK」または「適用 (Apply)」をクリックします。構成内容が検証されます。ページの上部に通知メッ
セージが現れます。このメッセージが赤いテキストで表示された場合、セキュリティーの検証で問題が
発生しています。構成を見直してユーザー・レジストリーの設定値に誤りがないかどうか確認してくだ
さい。 LTPA 構成の指定が不完全な場合もあります。
4. セキュリティーの検証で問題が発生しなければ、サーバーの再始動後にその構成が使用されるようにそ
の構成を保管します。構成を保管するには、管理コンソールで、ページの上部にある「保管 (Save)」を
クリックします。この操作を行うと、設定内容が構成リポジトリーに書き出されます。
5. 管理コンソールからログオフします。「ログアウト (Logout)」をクリックします。
6. 次の手順でサーバーを停止します。
a. iSeries コマンド行で、STRQSH コマンドを使用して Qshell を開始します。
b. /QIBM/ProdData/WebASE51/ASE/bin ディレクトリーに移動します。
c. stopServer コマンドを実行します。
/QIBM/ProdData/WebASE51/ASE/bin/stopServer -instance instanceName serverName
ここで、instanceName はインスタンスの名前で、server name はサーバーの名前です。
セキュリティー
115
注: セキュリティーを使用可能にしたあとは、ユーザー ID とパスワードを入力しなければ、stopServer
スクリプトを実行できません。
7. Qshell で startServer コマンド (例えば、startServer myServer) を使用してサーバーを始動します。
サーバーの再始動時に問題が発生した場合には、WebSphere Application Server インスタンスの logs サブ
ディレクトリーにある出力ログを調べてください。詳しくは、『トラブルシューティング』トピックの『ト
ラブルシューティング: セキュリティー』を参照してください。
役割ベースの権限
権限情報を使用して、呼び出し側がサービスを要求するのに必要な特権を持っているかどうかを判別しま
す。
次の図は、権限の間に使用されるプロセスを説明しています。 Web クライアントからの Web リソース・
アクセスは、Web コラボレーターによって処理されます。 Web コラボレーターは、オブジェクト・リク
エスト・ブローカー (ORB) の現行オブジェクトからクライアント信任状を抽出します。クライアント信任
状は、認証プロセス中に ORB 現行オブジェクト内で受信された信任状として設定されます。リソースお
よび受信された信任状は、アクセス・マネージャー・モジュールに提供されて、クライアントが要求された
リソースにアクセスするためにアクセスが許可されているかどうかを確認します。
アクセス・マネージャー・モジュールは、2 つの主なモジュールを含んでいます。
v リソース許可モジュール は、与えられたリソースに対する必要な役割を判別するのに役に立ちます。ア
プリケーション始動時にセキュリティー・ランタイムによって構築された、リソースから役割へのマッ
ピング・テーブルを使用します。リソースから役割へのマッピング・テーブルを構築するために、セキ
ュリティー・ランタイムは Web モジュール (web.xml ファイル) のデプロイメント記述子を読み取りま
す。
v 権限テーブル・モジュール は、役割をユーザーまたはグループへマップするテーブルを参照することに
よって、クライアントが必要な役割の 1 つを付与されているかどうかを判別します。マッピング・テー
ブルは、権限テーブル としても知られていますが、アプリケーション始動時にセキュリティー・ランタ
イムによって作成されます。権限テーブルを構築するために、セキュリティー・ランタイムはアプリケ
ーション・バインディング・ファイル (ibm-application-bnd.xmi ファイル) を読み取ります。
116
WebSphere Application Server - Express Version 5.1 セキュリティー
図 1: 認証
権限情報を使用して、呼び出し側がサービスを要求するのに必要な特権を持っているかどうかを判別しま
す。 権限情報を保管する方法はいくつかあります。例えば、各リソースを使用して、ユーザーおよびユー
ザー特権のリストを含む アクセス制御リスト を保管することができます。情報を保管するもう 1 つの方
法は、リソースのリストとそれと対応する各ユーザーの特権を関連付けることです。このリストは、可能性
リストと呼ばれます。
WebSphere Application Server - Express は、Java 2 Enterprise Edition (J2EE) 権限モデルを使用します。ア
プリケーションのアセンブリー中に、メソッドを呼び出すための許可が、1 つ以上の役割に付与されます。
役割は許可の集合です。例えば銀行用アプリケーションでは、役割は窓口係、管理者、事務員およびその他
の産業関連の地位を含むことができます。窓口係の役割は、引き出しおよび預金方法のような、口座内のお
金の管理に関連するメソッドを実行する許可に関連しています。窓口係の役割には、口座を閉じるための許
可は付与されていません。この許可は管理者の役割に与えられています。アプリケーション・アセンブラー
は、各役割のメソッド許可のリストを定義しています。このリストはそのアプリケーションのデプロイメン
ト記述子内に保管されます。
特定サブジェクトは、ユーザー・レジストリーから独立した製品定義のエンティティーです。レジストリー
内のユーザーまたはグループのクラスを一般的に表すために使用されます。 J2EE によって定義されたの
ではなく、WebSphere Application Server - Express によって提供された 2 つの特定サブジェクトがありま
す。
v AllAuthenticatedUsers は、すべての認証済みユーザーが保護メソッドにアクセスすることを許可する特
定サブジェクトです。ユーザーが正常に認証できている限りは、そのユーザーは保護リソースへのアク
セスが許可されます。
v Everyone は、保護リソースへの無制限のアクセスを許可する特定サブジェクトです。ユーザーはアクセ
スするために認証する必要はありません。この特定サブジェクトは、リソースが無保護であるかのよう
に保護メソッドへのアクセスを提供します。
セキュリティー
117
アプリケーションのデプロイメント中に、実ユーザーまたはユーザーのグループが役割へ割り当てられま
す。アプリケーション・デプロイヤーは、個々のメソッドを理解する必要がありません。役割をメソッドに
割り当てることによって、アプリケーション・アセンブラーはアプリケーション・デプロイヤーのジョブを
単純化します。メソッドのセットを使用して作業する代わりに、デプロイヤーは、メソッドのセマンティッ
ク・グループ化を提供する役割を使用して作業します。ユーザーが 1 つの役割に割り当てられると、その
ユーザーはその役割に付与されたすべてのメソッド許可を手に入れます。ユーザーは複数の役割に割り当て
ることができるので、そのユーザーに付与された許可は、それぞれの役割に付与された許可の結合となりま
す。さらに、認証メカニズムがユーザーのグループ化をサポートしている場合は、これらのグループを役割
に割り当てることができます。グループを役割に割り当てることは、個々のユーザーを役割に割り当てるの
と同じ効果があります。
デプロイメント中のベスト・プラクティスは、次の理由により、個々のユーザーではなく、グループを役割
に割り当てることです。
v 許可検査時にパフォーマンスを改善します。 通常、ユーザーよりもはるかに少ないグループしか存在し
ません。
v グループ・メンバーシップを使用してリソース・アクセスを制御することで、柔軟性がより高まりま
す。
v 製品環境の外部から、グループからのユーザーの追加および削除をサポートします。このアクション
は、WebSphere Application Server - Express 役割へのユーザーの追加および除去に優先します。これら
の変更が有効になるようにエンタープライズ・アプリケーションを停止し、再始動します。このアクシ
ョンは、実稼働環境内によっては、非常に破壊的である可能性があります。
実行時に、WebSphere Application Server - Express は、ユーザーの識別情報およびユーザーの役割へのマッ
ピングを基にして、着信要求を認可します。ユーザーが、メソッドを実行する許可を持ついずれかの役割に
属している場合は、要求は認可されます。ユーザー許可を持つどの役割にも属していない場合、要求は拒否
されます。
J2EE アプローチは、権限への宣言アプローチを提供していますが、すべての状態を宣言的に取り扱えない
ことも認識しています。これらの状態に対しては、ユーザーおよび役割情報をプログラマチックに判別する
ためのメソッドが提供されています。
サーブレットについては、次のメソッドが WebSphere Application Server - Express によってサポートされ
ています。
v getRemoteUser()
このメソッドは、認証済みユーザーのユーザー名を検索します。
v isUserInRole()
このメソッドは、特定役割に対するユーザー識別情報を確認します。
v getUserPrincipal()
このメソッドは、ユーザー識別情報を検索します。
これらのメソッドは、目的で、Enterprise Bean メソッドと対応しています。
J2EE セキュリティー権限モデルについて詳しくは、次の Web サイトを参照してください。
http://java.sun.com
管理役割へのユーザーの割り当て
WebSphere Application Server - Express は、WebSphere Application Server - Express 管理サブシステムを保
護するために、J2EE セキュリティー役割ベースのアクセス制御機能を拡張しました。 Web ベースの管理
118
WebSphere Application Server - Express Version 5.1 セキュリティー
コンソールまたはシステム管理スクリプト実行インターフェースから特定の WebSphere Application Server
- Express 管理機能を実行するために必要とされる各レベルの権限を提供するために、4 種類の管理役割が
定義されています。許可ポリシーは、グローバル・セキュリティーが使用可能になっているときにのみ適用
されます。次の表で、4 つの管理セキュリティー役割に関する定義を示します。
役割
説明
モニター権限
権限レベルの最も低い役割。この権限を与えられているユ
ーザーは、WebSphere Application Server - Express の構成
や現在の状態を見ることができます。
構成権限
この役割は、モニター権限に加えて、WebSphere
Application Server - Express の構成を変更できる権限を持
ちます。
オペレーター権限
この役割は、モニター権限に加えて、(例えば、サービス
の開始や停止など) ランタイム状態を変更する権限を持ち
ます。
管理者権限
この役割は、オペレーター権限と構成権限に加えて、機密
データ (サーバーのパスワード、LTPA のパスワードやキ
ーなど) へのアクセス権を持ちます。
WebSphere Application Server - Express のグローバル・セキュリティーが使用可能になっている場合、管理
サブシステムの役割ベース・アクセス制御が適用されます。管理サブシステムには、Security
Server、UserRegistry、およびすべての JMX MBean が含まれます。セキュリティーが使用可能になってい
る場合、Web ベースの管理コンソールや管理スクリプト実行ツールを使用するには、ユーザーは必要な認
証データを入力しなければなりません。さらに、管理コンソールは、ページに表示される制御機能がユーザ
ーの持つセキュリティー役割に応じて変更されるような設計になっています。例えば、モニター権限しか持
たないユーザーは、機密性の低い構成データしか見られません。オペレーター権限を持つユーザーは、シス
テムの状態を変更するボタンにアクセスできます。
グローバル・セキュリティーを使用可能にするときに指定されたサーバー ID は、管理役割へ自動的にマ
ップされます。管理役割のユーザーおよびグループは、WebSphere 管理コンソールから、いつでも追加ま
たは削除できます。ただし、変更を有効にするには、サーバーを再始動する必要があります。管理役割には
個々のユーザーではなくグループをマップするという方法が最も効率的なやり方です。これは、長期的に見
て管理の容易さと柔軟性を高めるものであるためです。管理役割にグループをマップすれば、そのグループ
のユーザーの追加または削除が WebSphere Application Server - Express の外部で行われるようになり、そ
の結果、変更を有効にするためにサーバーを再始動する必要がなくなります。
管理役割には、ユーザーやグループだけでなく、特殊な対象をマップすることもできます。特殊な対象は、
特定クラスのユーザーを一般化したものです。「AllAuthenticated (すべての認証ユーザー)」という特殊な
対象をマップした場合、管理役割のアクセス検査により、少なくとも認証されているユーザーでなければ、
その要求を実行できなくなります。「Everyone (すべてのユーザー)」という特殊な対象をマップした場合、
セキュリティーが無効になっている場合と同じように、認証の有無に関係なく、すべてのユーザーがそのア
クションを実行できるようになります。
グローバル・セキュリティーを使用可能にすると、WebSphere Application Server - Express のサーバーは、
アクティブなユーザー・レジストリー構成に定義されているサーバー ID で実行します。「サーバー
(Server)」という特殊な対象は、管理コンソールやその他のツールでは表示されませんが、管理者役割にマ
ップされます。これは、サーバー ID で実行する WebSphere Application Server - Express サーバー・ラン
タイム・コードには、ランタイム操作の実行に必要な権限が与えられるようになるためです。管理役割を持
つユーザーは、管理役割の割り当てられているユーザーが他に存在しない場合、サーバー ID を使用して
セキュリティー
119
管理コンソールまたは wsadmin スクリプト実行ツールにログインし、管理操作を実行することや、他のユ
ーザーまたはグループを管理役割に割り当てることができます。デフォルトは、サーバー ID が管理役割
に割り当てられるため、管理セキュリティー・ポリシーは、以下の操作の実行に管理役割を要求します。
v サーバー ID とサーバー・パスワードの変更
v WebSphere Application Server - Express グローバル・セキュリティーを使用可能または使用不可にする
操作
v Java 2 セキュリティーの実行または無効化
v LTPA パスワードの変更またはキーの生成
v 管理役割へのユーザーおよびグループの割り当て
初めてセキュリティーを使用可能にするときには、以下のステップを実行して、1 つ以上のユーザーおよび
グループを管理役割に割り当てることができます。グローバル・セキュリティーが使用可能になっている場
合、管理役割を持つユーザーは、以下のステップを実行できます。以下のステップで示すユーザーおよびグ
ループ検証はアクティブなユーザー・レジストリーに依存しているため、以下のステップを実行する前に、
アクティブなユーザー・レジストリーを構成する必要があります。
管理役割にユーザーを割り当てるには、WebSphere 管理コンソールで以下のステップを実行します。
1. 管理コンソールで「システム管理 (System Administration)」を展開し、「コンソール・ユーザー
(Console Users)」または「コンソール・グループ (Console Groups)」をクリックします。
必要なタスクを実行します。
v ユーザーまたはグループを追加するには、「追加 (Add)」をクリックします。
v 新規の管理ユーザーを追加するには、ユーザー・テキスト・ボックスにユーザー ID を入力し、管理
役割の 1 つを強調表示して「OK」をクリックします。検証エラーがなければ、指定したユーザー
が、割り当てられたセキュリティー役割と共に表示されます。新規の管理グループを追加するには、
グループ名を入力するかまたは特別サブジェクト「すべてのユーザー (EVERYONE)」か「すべての
認証ユーザー (AllAuthenticated)」を選択して、「OK」をクリックします。検証ボタンがなければ、
指定したグループまたは特殊な対象が、割り当てられたセキュリティー役割と共に表示されます。
v ユーザーまたはグループ割り当てを削除するには、「コンソール・ユーザー (Console Users)」または
「コンソール・グループ (Console Groups)」パネルにある削除ボタンをクリックします。ユーザーま
たはグループ・パネルで、削除するユーザーまたはグループのチェック・ボックスをクリックしてか
ら、「OK」をクリックします。
v 表示するユーザーまたはグループのセットを管理するには、右側のパネルにあるフィルター・フォル
ダーを展開し、フィルター・テキスト・ボックスを修正します。例えば、フィルターを user* に設
定すると、user という接頭部を持つユーザーのみが表示されます。
2. 修正を加えてから「保管 (Save)」をクリックします。
3. 変更内容を有効にするために、サーバーをいったん停止してから再始動します。サーバーの再始動後
は、すべての管理リソースが保護されます。管理セキュリティー構成はセル・レベルのものであるた
め、すべてのサーバーを再始動してください。
ネーミング役割へのユーザーの割り当て
WebSphere Application Server - Express は、J2EE セキュリティー役割ベースのアクセス制御を拡張して
WebSphere Application Server のネーミング・サブシステムを保護します。CosNaming セキュリティーで
は、CosNaming 機能の管理セキュリティーの細分度が向上しています。CosNaming 機能は、WebSphere
Application Server - Express のような CosNaming サーバーで使用できます。これらの機能は WebSphere
Application Server - Express ネーム・スペースの内容に影響を与えます。クライアント・プログラムが
120
WebSphere Application Server - Express Version 5.1 セキュリティー
CosNaming を呼び出すには、一般的に 2 つの方法があります。1 つ目は JNDI インターフェースを使用す
る方法です。2 つ目は CosNaming メソッドを直接呼び出す CORBA クライアントです。
次の 4 つのセキュリティー役割が導入されています:
CosNamingRead、CosNamingWrite、CosNamingCreate、および CosNamingDelete。4 つの役割の名前は
WebSphere Application Server Advanced Edition v4.0.2 と同じです。しかし、役割には、次のように低から
高の権限レベルがあります。
v CosNamingRead。CosNamingRead 役割が割り当てられたユーザーは、JNDI lookup() メソッドなどで、
WebSphere Application Server - Express のネーム・スペースの照会を実行できます。特別なサブジェク
ト、Everyone は、この役割のデフォルト・ポリシーです。
v CosNamingWrite。CosNamingWrite 役割が割り当てられたユーザーは、JNDI bind()、rebind()、または
unbind() などの書き込み操作、および CosNamingRead 操作を実行できます。特別なサブジェクト、
AllAuthenticated は、この役割のデフォルト・ポリシーです。
v CosNamingCreate。CosNamingCreate 役割が割り当てられたユーザーは、JNDI createSubcontext() などの
操作によるネーム・スペースへの新規オブジェクトの作成と、CosNamingWrite 操作を実行できます。特
別なサブジェクト、AllAuthenticated この役割のデフォルト・ポリシーです。
v CosNamingDelete。CosNamingDelete 役割が割り当てられたユーザーは、例えば JNDI destroySubcontext()
メソッドを使用して、ネーム・スペース内のオブジェクトを破棄でき、また CosNamingCreate 操作も実
行できます。特別なサブジェクト、AllAuthenticated は、この役割のデフォルト・ポリシーです。
さらに、サーバー特有のサブジェクトが、デフォルトで 4 つの CosNaming 役割すべてに割り当てられま
す。このサーバー特有のサブジェクトにより、サーバー ID の下で実行される、WebSphere Application
Server - Express サーバー・プロセスがすべての CosNaming 操作にアクセス可能になります。サーバー特
有のサブジェクトは表示されず、管理コンソールおよび管理ツールで変更することはできません。
ユーザー、グループ、または特別なサブジェクトの AllAuthenticated および Everyone は、いつでも
WebSphere Web ベースの管理コンソールでネーミング役割を追加または除去できます。ただし、変更を有
効にするには、サーバーを再始動する必要があります。最適な方法は、特定のユーザーでなくグループ、ま
たは特別サブジェクトの 1 つをネーミング役割にマップする方法です。最終的には、この方が管理が柔軟
で簡単であるからです。グループをネーミング役割にマップすると、グループに対するユーザーの追加や除
去は WebSphere Application Server - Express の外側で行われ、変更を有効にするためにサーバーを再始動
する必要はありません。
CosNaming 許可ポリシーは、グローバル・セキュリティーが使用可能な場合にのみ施行されます。グロー
バル・セキュリティーが使用可能な場合、適切な役割を割り当てないで CosNaming 操作を実行すると、
CosNaming サーバーから org.omg.CORBA.NO_PERMISSION 例外が発生します。
WebSphere Application Server バージョン 4.0.2 では、各 CosNaming 機能は 1 つの役割にのみ割り当てら
れます。したがって、CosNamingCreate 役割を割り当てられたユーザーは、CosNamingRead 役割も割り当
てられていないとネーム・スペースを照会できません。またほとんどの場合、作成者は、
CosNamingRead、CosNamingWrite、および CosNamingCreate の 3 つの役割が割り当てられる必要がありま
す。これは、このリリースで変更されました。上記の作成者に対する CosNamingRead および
CosNamingWrite 役割割り当て例は、CosNamingCreate 役割に組み込まれています。ほとんどの場合、
WebSphere Application Server 管理者は、以前のリリースから本リリースに移行する場合に、すべてのユー
ザーまたはグループに関する役割の割り当てを変更する必要はありません。
デフォルト・ポリシーを変更してネーム・スペースへのアクセスを大幅に制限する機能は存在しますが、そ
うすると実行時に予想しない org.omg.CORBA.NO_PERMISSION 例外が発生することがあります。通常
は、J2EE アプリケーションはネーム・スペースにアクセスし、使用する ID は J2EE アプリケーションに
セキュリティー
121
アクセスする際に WebSphere に認証されるユーザーの ID です。J2EE アプリケーション・プロバイダー
が予想されるネーミング役割と明確に通信しない場合、デフォルトのネーミング許可ポリシーを変更する場
合は注意する必要があります。
ユーザーをネーミング役割に割り当てするには、以下のステップを実行します。
1. 管理コンソールで、「環境 (Environment)」―>「ネーミング (Naming)」を展開します。「CORBA ネ
ーム・サービス・ユーザー (CORBA Naming Service Users)」または「CORBA ネーム・サービス・グ
ループ (CORBA Naming Service Groups)」をクリックします。
2. 必要なタスクを実行します。
v 「CORBA ネーム・サービス・ユーザー (CORBA Naming Service Users)」または「CORBA ネー
ム・サービス・グループ (CORBA Naming Service Groups)」パネルの「追加 (Add)」をクリックしま
す。
v 新規のネーム・サービス・ユーザーを追加するには、「ユーザー (User)」フィールドにユーザー ID
を入力し、1 つ以上のネーミング役割を強調表示し、「OK」をクリックします。検証エラーがなけ
れば、指定したユーザーが、割り当てられたセキュリティー役割とともに表示されます。
v 新規のネーム・サービス・グループを追加するには、「グループの指定 (Specify group)」を選択し
て、グループ名を入力するか、「特別なサブジェクトから選択 (Select from special subject)」を選択
し、「全員 (EVERYONE)」または「全員認証済み (ALL AUTHENTICATED)」を選択します。
「OK」をクリックします。検証エラーがなければ、指定したグループまたは特殊な対象が、割り当
てられたセキュリティー役割とともに表示されます。
v ユーザー割り当てまたはグループ割り当てを除去するには、「CORBA ネーム・サービス・ユーザー
(CORBA Naming Service Users)」または「CORBA ネーム・サービス・グループ (CORBA Naming
Service Groups)」パネルに進みます。除去するユーザーまたはグループの横のチェック・ボックスを
選択し、「除去 (Remove)」をクリックします。
v 表示するユーザーまたはグループのセットを管理するには、右側のパネルにあるフィルター・フォル
ダーを展開し、フィルター・テキスト・ボックスを修正します。例えば、フィルターを user* に設
定すると、「user」という接頭部を持つユーザーのみが表示されます。
3. 変更を行った後、「保管 (Save)」をクリックしてマッピングを保管します。変更を有効にするには、サ
ーバーを再始動する必要があります。
内部 HTTP トランスポートのトラステッド・モードの構成
WebSphere Application Server - Express は、管理者が専用 HTTP ヘッダーを信頼するかどうかを指定する
ことができる構成オプションを導入することによって、セキュリティーをより強固にすることができます。
実稼働環境におけるトラステッド・モードでの WebSphere Application Server - Express 内部 HTTP トラン
スポートの使用可能化を注意深く評価して、十分な信頼が確立されたかどうかを判別しなければなりませ
ん。
トラステッド・モードが使用可能のとき、WebSphere Application Server - Express 内部 HTTP トランスポ
ートは、HTTP ヘッダーへのクライアント証明書を追加することで、ユーザー ID アサーションを許可し
ます。 Web サーバー・プラグインはこの機能を使用して、クライアント証明書の認証をサポートすること
ができます。 HTTP ヘッダーには、クライアント証明書を行使するサーバー ID を判別するために
WebSphere Application Serve - Express が使用できる情報は含まれていません。 HTTP ヘッダーのスプー
フィングを回避するために、Web server プラグインと WebSphere Application Server - Express の間に、ト
ランスポート・レベルの認証でセキュア通信チャネルを確立しなければなりません。
各 HTTP ポートごとに独立してトラステッド・モードを構成し、インターネットおよびイントラネットの
両方から、クライアントのマシンが直接アクセスできるポート上で使用不可にすることができます。クライ
122
WebSphere Application Server - Express Version 5.1 セキュリティー
アント証明書の認証で Secure Sockets Layer (SSL) 接続を確立するために Web サーバー・プラグインを要
求することによって、トラステッド Web サーバー・プラグインのみがユーザー証明書を行使することを確
実にします。その上、自己署名証明書を使用して、自己署名証明書を持つサーバーのみがトラステッド内部
HTTP トランスポートへのセキュア接続を確立できるようにしなければなりません。自己署名証明書の認証
での SSL 接続のセットアップについて詳しくは、 125 ページの『WebSphere Application Server での SSL
の構成』を参照してください。
SSL 以外に、仮想プライベート・ネットワーク (VPN) および IPSec のようなメカニズムを使用して、無
許可ユーザーによってアクセスされることから内部 HTTP トランスポートを保護することができます。
トラステッド・モードは、デフォルトで true に設定されます。 WebSphere 管理コンソール内で以下のス
テップを実行して、トラステッド・モードを使用不可にするカスタム・トランスポート・プロパティーを追
加します。
1. 「サーバー」を展開して、「アプリケーション・サーバー (Application Servers)」をクリックします。
2. ご使用のアプリケーション・サーバー名をクリックします。
3. 「Web コンテナー (Web Container)」 ―> 「HTTP トランスポート (HTTP Transports)」 ―>
「host_name」 ―> 「カスタム・プロパティー (Custom Properties)」とクリックします。ここで
host_name はホスト名です。
4. 「新規 (New)」をクリックし、プロパティー名 Trusted を値 false で入力します。
5. サーバーを再始動します。
サーバーの再始動後は、トラステッドを false と設定されたトランスポートは、クライアント証明書のア
サーションを受け入れません。 HTTP Error 403 が、ご使用のログ・ファイル内の以下のものと同様のエ
ラー・メッセージで戻されます。
Requests through proxies such as the WebSphere webserver plug-in are not permitted
to this port. The HTTP transport on port 9080 is not configured to be trusted.
WebSphere Application Server - Express での SSL の構成
いくつかの WebSphere Application Server - Express コンポーネントは、Secure Socket Layer (SSL) を使用
してセキュア通信を提供します。特に、以下のものが SSL を使用します。
v HTTPS。アプリケーション・サーバーの組み込み HTTPS トランスポート。
v ORB。アプリケーション・サーバーのクライアントおよびサーバーのオブジェクト・リクエスト・ブロ
ーカー。
v LDAPS。認証に使用される、管理サーバーの LDAP レジストリーへのセキュア接続。これは、
WebSphere Application Server - Express でのみ使用可能です。
また、WebSphere アプリケーションは SSL を使用するように構成し実装することができます。このような
アプリケーションで使用されるディジタル証明書は、Java 鍵ストア・ファイル (.jks ファイル) または
i5/OS 証明書コンテナー (.kdb ファイル) のいずれかに保管することができます。
注: バージョン 5.0 では WebSphere アプリケーションで i5/OS 証明書コンテナーを使用することはお勧
めできません使用する場合は、いくつかの制限事項があります。詳しくは、『移行』トピックの 『Java 鍵
ストアを使用するためのアプリケーションの移行』を参照してください。
注: 連邦情報処理標準 (FIPS) が承認済みの Java Secure Socket Extension (JSSE) および Java Cryptography
Extension (JCE) プロバイダーは、iSeries ではサポートされていません。その他の WebSphere Application
Server - Express プラットフォームは、FIPS 承認の暗号アルゴリズムをサポートします。
セキュリティー
123
SSL の構成の詳細については、以下のトピックを参照してください。
v 『ブラウザー用の SSL を構成する』
v 『Web サーバーでの SSL の構成』
v 『SSL クライアント認証のための IBM HTTP Server for i5/OS の構成』
v
125 ページの『WebSphere Application Server での SSL の構成』
v
137 ページの『WebSphere アプリケーションでの SSL の構成』
v
153 ページの『WebSphere Application Server - Express および LDAP サーバー間の SSL 接続の構成』
ブラウザー用の SSL を構成する: ブラウザー用の SSL の構成は、ブラウザー固有のものとなっていま
す。手順については、使用しているブラウザーの資料を参照してください。
一般に、http://...ではなく https://...と入力する際、ブラウザーは、Web サーバーに対して、単なる
TCP 接続ではなく SSL 接続を作成します。次に、ブラウザーは、通常、ユーザーにプロンプトを出しま
すが、Web サーバーの妥当性検査が行なえない場合や、セキュリティー・オプションのレベル (使用する
暗号化アルゴリズムの強さ) が一致しない場合は接続に失敗します。
Web サーバーでの SSL の構成: Web サーバーでの SSL の構成は、Web サーバーのタイプによって異
なります。手順については、使用している Web サーバーの使用を参照してください。
一般に、SSL が使用可能になっている場合は、SSL のキー・ファイルが必要です。このキー・ファイルに
は、CA 証明書 (署名者証明書) とクライアントまたはサーバー証明書の両方が含まれていなければなりま
せん。クライアント認証も使用可能にすることができます。デフォルトでは、使用不可になっています。
Web サーバーで SSL クライアント認証が使用可能になっている場合は、WebSphere Web サーバー・プラ
グインによって、クライアント証明書 (ブラウザーからの証明書) が WebSphere Application Server Express に転送されます。アプリケーションのデプロイメント記述子で、クライアント証明書認証メソッド
を使用するよう指定されている場合は、証明書の識別名属性が、ユーザー・レジストリー内のプリンシパル
にマップ可能であれば、アプリケーション・サーバーは転送された証明書を認証証明書として受け取りま
す。クライアント証明書のマッピングの詳細については、 88 ページの『LDAP 検索フィルターの構成』を
参照してください。
注: クライアント証明書は、プラグイン・トランスポートで SSL が使用可能になっているかいないかには
関係なく、アプリケーション・サーバーに転送されます。ブラウザーのクライアント証明書の SSL 認証
は、実際には Web サーバーで行われるため、SSL をプラグイン・トランスポートに構成することを強く
お勧めします。これにより、アプリケーションのデプロイメント記述子によってクライアント証明書認証メ
ソッドを使用するよう指定されており、そのために信頼されていないソースからクライアント証明書を受け
取る可能性がない場合は、プラグインそれ自体のクライアント認証が必要になります。SSL クライアント
認証を要求するようプラグイン・トランスポートを構成する方法の詳細については、 125 ページの
『WebSphere Application Server での SSL の構成』の『アプリケーション・サーバーの HTTPS トランス
ポート用の SSL の構成』を参照してください。
SSL クライアント認証のための IBM HTTP Server for i5/OS の構成: SSL (Secure Sockets Layer) クラ
イアント認証のために IBM HTTP Server を構成するには、 IBM HTTP Server for i5/OS の「構成
(Configuration)」フォームと「管理 (Administration)」フォームを使用します。 SSL セキュリティーの前提
条件など、詳細については、 iSeries Information Center で次のトピックを参照してください。
v V5R2『Secure Sockets Layer (SSL)』
v V5R3 『Secure Sockets Layer (SSL)』
v V5R4 『Secure Sockets Layer (SSL)』
124
WebSphere Application Server - Express Version 5.1 セキュリティー
IBM HTTP Server for i5/OS の「構成 (Configuration)」フォームと「管理 (Administration)」フォームを使用
して、仮想ホストを作成し、SSL のポートを構成します。
1. 「サーバー (Server)」フィールドで、HTTP サーバー・インスタンスを選択します。
2. 左側のペインで、「一般サーバー構成 (General Server Configuration)」をクリックします。
3. 右側のペインの「一般設定 (General Settings)」タブをクリックします。
4. 「サーバー IP アドレスおよび listen するポート (Server IP addresses and ports to listen on)」以下
の「追加 (Add)」をクリックします。次のフィールドの値を指定します。
v IP アドレス: * と入力するか、メニューから「すべての IP アドレス (All IP addresses)」を選択
します。
v ポート: SSL による保護を行うポート番号を入力します。
v FRCA: このフィールドがある場合は、「使用不可 (Disabled)」に設定します。
5. 「OK」をクリックします。
6. 右側のペインで、「サーバー領域 (Server area)」の「グローバル構成 (Global Configuration)」を選択
します。
7. 左側のペインで、「コンテナー管理 (Container Management)」をクリックします。
8. 右側のペインで、「仮想ホスト (Virtual Hosts)」タブを選択します。
9. 「追加」をクリックします。
10. 「ホスト名の IP アドレス (IP address or host name)」フィールドで、「すべての IP アドレス (All
IP addresses)」を選択します。
11. 「ポート (Port)」フィールドで、SSL で保護するポート番号を入力します。
12. 「OK」をクリックします。
13. 「サーバー領域 (Server area)」で新規仮想ホストを選択します。
14. 左側のペインで、「セキュリティー (Security)」をクリックします。
15. 右側のペインで、「SSL を使用可能にする (Enable SSL)」を選択します。
16. 「サーバー証明書アプリケーション名 (Server certificate application name)」フィールドで、自動的に
生成されたアプリケーション ID (QIBM_HTTP_SERVER_LDH など) を選択します。
17. 「接続用にクライアント証明書を要求 (Require client certificate for connection)」を選択します。
18. 「OK」をクリックします。
このタスクを完了するには、Web サーバー用のサーバー証明書をインストールするために上記で選択した
アプリケーション ID が必要です。 IBM ディジタル証明書マネージャー (DCM) を使用して、 Web サー
バーと Web ブラウザーに証明書をインストールします。 iSeries Information Center で次のトピックを参
照してください。
v V5R2『ディジタル証明書マネージャー』
v V5R3『ディジタル証明書マネージャー』
v V5R4『ディジタル証明書マネージャー』
WebSphere Application Server での SSL の構成: WebSphere Application Server に SSL を構成する方法
については、以下のトピックを参照してください。
v WebSphere プラグインでの SSL の構成 (126ページ)
– 製品提供の証明書を使用した、WebSphere プラグイン用 SSL の構成 (126ページ)
– WebSphere の Web サーバー・プラグイン用の SSL キー・ファイルの作成 (126ページ)
v アプリケーション・サーバーの HTTPS トランスポート用の SSL の構成 (128ページ)
セキュリティー
125
1. デフォルトの署名者証明書なしでの SSL キー・ファイルの作成 (128ページ)
2. プラグインの SSL キー・ファイルへのアプリケーション・サーバーの署名者証明書の追加 (129ペー
ジ)
3. キー・ファイルへのアクセス権限の付与 (129ページ)
4. (オプション) SSL ポートのエイリアスの構成 (130ページ)
5. Web コンテナーに対する HTTPS トランスポートの構成 (130ページ)
注: 上記のステップでは、使用しているワークステーションから iSeries システムへマップされたネットワ
ークがあるものとしています。
WebSphere プラグインでの SSL の構成
WebSphere プラグインは、Web サーバーとのインターフェースを提供して、サーバー・サイドのリソース
を求めるクライアント要求を処理し、それらを処理するためにアプリケーション・サーバーに経路指定しま
す。 WebSphere Application Server - Express には、IBM HTTP Server for i5/OS および Domino Web
Server for iSeries 用のプラグインが組み込まれています。
ユーザーのブラウザーおよび Web サーバー間で SSL が作動した後、 Web サーバー・プラグインと
WebSphere Application Server - Express 製品との間の SSL の構成に進みます。プラグインおよびアプリケ
ーション・サーバー間のリンクが保護されていると分かっている場合、または、ユーザーのアプリケーショ
ンが重要でない場合は、この手順は必要ありません。ただし、アプリケーション・データのプライバシーが
重要な場合は、この接続は SSL 接続でなければなりません。
製品提供の証明書を使用した、WebSphere プラグイン用 SSL の構成
WebSphere Application Server - Express Version 5.1 (およびそれ以降) のアプリケーション・サーバー・イ
ンスタンスには SSL 鍵ファイルが含まれます。鍵ファイルのパス名は
/QIBM/UserData/WebASE51/ASE/instance/etc/plugin-key.kdb です。ここで、instance は、サーバー・インスタ
ンスの名前です。
plugin-key.kdb ファイルには、ディジタル証明書が含まれています。このディジタル証明書は、 HTTPS ト
ランスポートがデフォルトの SSL レパートリーで構成された場合に、 Web コンテナーの証明書の署名者
を信頼するために、 Web サーバー・プラグインで必要になります。デフォルトの Web コンテナーは、こ
のような HTTPS トランスポートと共に作成されます。
このデフォルトの HTTPS トランスポートは、サーバーを実動させる前に製品提供の証明書を置き換える
ために、除去または再構成される必要があります。製品提供の証明書を使用して WebSphere プラグイン用
の SSL を構成すると、構成の複雑さが大幅に低減されますが、これらの証明書は実動サーバーには使用し
ないでください。以下に示したタスクは、独自の証明書を作成する方法を示したものです。証明書は、商用
の認証局からも取得することができます。
WebSphere の Web サーバー・プラグイン用の SSL キー・ファイルの作成
以下は、WebSphere プラグインに対する SSL キー・ファイルを作成する方法の一例です。
1.
131 ページの『ディジタル証明書マネージャーの始動』。
手順は、実際の iSeries システムにインストールされているディジタル証明書マネージャー (DCM) の
リリースによって異なります。この記事で使用されている DCM のリリースは V5R1M0 です。
2.
132 ページの『ローカル認証局の作成』。
iSeries システムに認証局 (CA) を作成済みである場合は、このステップを省略します。
126
WebSphere Application Server - Express Version 5.1 セキュリティー
3. HTTP サーバー・プラグインの鍵ストアを作成します。
a. 左側のペインで、「新規証明書ストアの作成 (Create New Certificate Store)」をクリックします。
b. 「その他のシステム証明書ストア (Other System Certificate Store)」を選択し、「続行
(Continue)」をクリックします。
c. 「新規証明書ストアに証明書の作成 (Create a Certificate in New Certificate Store)」ページで、「は
い - 証明書ストアに証明書を作成します (Yes - Create a certificate in the certificate store)」を選
択してから、「続行 (Continue)」をクリックします。
d. 「認証局の選択 (Select a Certificate Authority (CA))」ページで、「ローカル認証局 (Local
Certificate Authority)」を選択してから、「続行 (Continue)」ボタンをクリックします。
e. フォームに入力して、証明書と証明書ストアを作成します。証明書ストアには次のパス名を使用しま
す。
/QIBM/UserData/WebASE51/ASE/instance/etc/plugin-key.kdb
ここで、instance はインスタンスの名前です。(ここの説明では、以降、etc 上位のディレクトリー
を USER_INSTALL_ROOT と呼ぶことにします。)
キー・ラベルとして、MyPluginCert を使用します。残りの必須フィールドに入力してから、「続行
(Continue)」をクリックします。
4. デフォルトのシステム証明書を設定します。
a. 左側のペインで、クリックして、「高速パス (Fast Path)」を展開します。
b. 「サーバーとクライアントの証明書の操作 (Work with server and client certificates)」を選択しま
す。
c. 証明書 MyPluginCert を選択します。
d. 「デフォルトの設定 (Set default)」をクリックします。
5. 「ローカル CA (Local CA)」以外のされたトラステッド署名者をすべて除去します。
a. 左のペインで、「証明書ストアの選択 (Select a Certificate Store)」をクリックします。
b. 「その他のシステム証明書ストア (Other System Certificate Store)」を選択し、「続行
(Continue)」をクリックします。
c. 「証明書ストアとパスワード (Certificate Store and Password)」ページで、証明書ストア・パスとフ
ァイル名 (USER_INSTALL_ROOT/etc/plugin-key.kdb) とパスワードを入力します。「次へ
(Continue)」をクリックします。
d. 左のペインで「高速パス (Fast Path)」をクリックします。
e. 「CA 証明書の操作 (Work with CA certificates)」を選択してから、「続行 (Continue)」をクリッ
クします。
f. 「CA 証明書の操作 (Work with CA Certificates)」ページで、LOCAL_CERTIFICATE_AUTHORITY
を除くすべての CA 証明書に対して、証明書を選択してから、「削除 (Delete)」をクリックしま
す。この証明書を削除することに間違いがないかの確認を求められたら、「Yes」で応答します。
6. ローカル CA 証明書を抽出し、後で、アプリケーション・サーバー・キー・ファイルにその証明書をイ
ンポートできるようにしておきます。
a. 左側のペインで、「PC への CA 証明書のインストール (Install CA certificate on your PC)」をク
リックします。
b. 右側のペインで、「証明書のコピーおよび貼り付け (Copy and paste certificate)」をクリックしま
す。
セキュリティー
127
c. 使用しているワークステーションの、iSeries にマップされているドライブに、テキスト・ファイル
USER_INSTALL_ROOT/etc/myLocalCA.txt を作成し、CA 証明書を myLocalCA.txt に貼り付けてか
ら、ファイルを保存します。
d. 「完了 (Done)」をクリックします。
管理可能ドメインに存在するリソースに対する SSL 設定値を管理するには、SSL 構成手段のすべてを使用
します。デフォルトの手段は、DefaultNode/DefaultSSLSettings です。試験の場合には、
DefaultNode/DefaultSSLSettings を使用し、実用上使用する場合には、新しい SSL 構成手段を作成し、個々
の資源に関連付けすることができます。詳しくは、 133 ページの『SSL 構成レパートリーの使用』を参照
してください。
アプリケーション・サーバーの HTTPS トランスポート用の SSL の構成
アプリケーション・サーバーの HTTPS トランスポート用の SSL を構成するには、まず、SSL の鍵ファ
イルを作成しなければなりません。このファイルの内容は、どの人物に HTTPS ポート経由でアプリケー
ション・サーバーとの直接通信を許可するかで異なります (すなわち、HTTPS サーバーのセキュリティ
ー・ポリシーを定義します)。
このトピックでは、制限付きセキュリティー・ポリシーについて説明します。この制限付きセキュリティ
ー・ポリシーでは、明確に定義された (その証明書が、ユーザーのローカル認証局で証明を受けた) クライ
アント・セットだけが、アプリケーション・サーバーの HTTPS ポートへの接続が許されます。アプリケ
ーションのデプロイメント記述子でクライアント証明書認証メソッドを使用することが指定されている場合
は、このセキュリティー・ポリシーに従うことをお勧めします。デフォルトの署名者証明書のない SSL キ
ー・ファイルを作成する手順は、このポリシーに従います。
アプリケーション・サーバーの HTTPS トランスポートに SSL を構成するには、以下のステップに従いま
す。
ステップ 1: デフォルトの署名者証明書なしでの SSL キー・ファイルの作成。
1. ワークステーション上で iKeyman を開始します。詳しくは、 134 ページの『iKeyman ユーティリティ
ー』を参照してください。
2. 新規の鍵データベース・ファイルを作成する。
a. 「鍵データベース・ファイル (Key Database File)」をクリックして、「新規 (New)」を選択する。
b. 以下の設定値を指定する。
v Key database type (鍵データベース・タイプ): JKS
v File Name (ファイル名): appServerKeys.jks
v 場所: USER_INSTALL_ROOT/etc など、使用している etc ディレクトリー
c. 「OK」をクリックする。
d. パスワードを入力して (確認のため 2 回)、「OK」をクリックする。
3. すべての署名者証明書を削除する。
4. 「署名者証明書 (Signer Certificates)」をクリックして、「個人証明書 (Personal Certificates)」を選択
する。
5. 新規の自己署名証明書を追加する。
a. 「新規の自己署名 (New Self-Signed)」をクリックして、自己署名証明書を追加する。
b. 以下の設定値を指定する。
v Key Label (鍵ラベル): appServerTest
128
WebSphere Application Server - Express Version 5.1 セキュリティー
v Common Name (共通名): iSeries サーバーの DNS 名を使用する。
v Organization (組織): IBM
c. 「OK」をクリックする。
6. この自己署名証明書から証明書を抽出する。これによって、証明書をプラグインの SSL キー・ファイ
ルにインポートできます。
a. 「証明書の抽出 (Extract Certificate)」をクリックする。
b. 以下の設定値を指定する。
v Data Type (データ型): Base64 エンコード ASCII データ
v Certificate file name (証明書ファイル名): appServer.arm
v Location (場所): ユーザーの etc ディレクトリーのパス
c. 「OK」をクリックする。
7. 以下のようにして、Local CA 公衆証明書をインポートする。
a. 「個人証明書 (Personal Certificates)」をクリックして、「署名者証明書 (Signer Certificates)」を
選択する。
b. 「追加」をクリックする。
c. 以下の設定値を指定する。
v Data Type (データ型): Base64 エンコード ASCII データ
v Certificate file name (証明書ファイル名): myLocalCA.txt
v Location (場所): ユーザーの etc ディレクトリーのパス
d. 「OK」をクリックする。
8. ラベルに「plug-in」と入力して、「OK」をクリックする。
9. 「鍵データベース・ファイル (Key Database File)」をクリックする。
10. 「終了 (Exit)」を選択する。
ステップ 2: プラグインの SSL キー・ファイルへのアプリケーション・サーバーの署名者証明書の追加。
1.
131 ページの『ディジタル証明書マネージャーの始動』
2. 左のペインで、「証明書ストアの選択 (Select a Certificate Store)」をクリックします。
3. 「その他のシステム証明書ストア (Other System Certificate Store)」を選択し、「続行 (Continue)」を
クリックします。
4. 「証明書ストアとパスワード (Certificate Store and Password)」ページで、証明書ストア・パスとファイ
ル名 (USER_INSTALL_ROOT/etc/plugin-key.kdb) とパスワードを入力してから、「続行」をクリックす
る。
5. 左のペインで「高速パス (Fast Path)」をクリックします。
6. 「CA 証明書の操作 (Work with CA certificates)」を選択してから、「続行 (Continue)」をクリックし
ます。
7. 「インポート」をクリックする。
8. Import file フィールド値に対して USER_INSTALL_ROOT/etc/appServer.arm を指定して、「続行」をク
リックする。
9. 「CA 証明書ラベル (CA certificate label)」フィールド値に対して、appServer と指定してから、「続行
(Continue)」をクリックする。
ステップ 3: キー・ファイルへのアクセス権限の付与。
セキュリティー
129
無許可アクセスから、キー・ファイルを保護することは非常に重要です。i5/OS Change Authority
(CHGAUT) コマンドを使用して、以下の保護内容を設定します。
v appServerKeys.jks
PROFILE
ACCESS
*PUBLIC
*EXCLUDE
QEJBSVR
*R
v plugin-key.kdb
PROFILE
ACCESS
*PUBLIC
*EXCLUDE
QTMHHTTP
*RX
v USER_INSTALL_ROOT/etc ディレクトリーに作成したその他のすべてのファイルには、 *PUBLIC に対し
て *EXCLUDE 権限を設定する必要があります。
注: QTMHHTTP は、i5/OS 用 IBM HTTP Server 向きのデフォルト・ユーザー・プロファイルです。Web
サーバーが別のプロファイルのもとで動作している場合は、QTMHHTTP の代りに、plug-inKeys.kdb 用の
*RX 権限をそのプロファイルに付与します。
例えば、QTMHHTTP ユーザー・プロファイルに plugin-key.kdb に対する読み取りおよび書き込み (*RX)
権限を付与するには、権限変更 (CHGAUT) コマンドを実行します。例えば、次のようにします。
CHGAUT OBJ(’/QIBM/UserData/WebASE51/ASE/myInstance/etc/plugin-key.kdb’)
USER(QTMHHTTP) DTAAUT(*RX)
ステップ 4: (オプション) SSL ポートのエイリアスの構成。
WebSphere 仮想ホストで、Web サーバーの SSL ポートのエイリアスをまだ構成していない場合は、ここ
で構成します。
ステップ 5: Web コンテナーに対する HTTPS トランスポートの構成
詳しくは、アプリケーション・サーバーの Web コンテナー用の 136 ページの『アプリケーション・サー
バーの Web コンテナーに関する HTTPS トランスポートの構成』を参照してください。
製品提供のキー・ファイル以外の鍵ファイルを使用して、 Web サーバー・プラグインに SSL を構成する
場合は、プラグインの構成ファイルを手動で更新する必要があります。更新が適用される前に、再生成され
たプラグインの構成ファイルには、以下のような項目が含まれているはずです。
<Transport Hostname=“MYISERIES” Port=“10175” Protocol=“https”>
<Property name=“keyring” value=“/QIBM/UserData/WebASE51/ASE/myinst/etc/plugin-key.kdb”/>
<Property name=“stashfile” value=“/QIBM/UserData/WebASE51/ASE/myinst/etc/plugin-key.sth”/>
</Transport>
独自の鍵ファイルを使用する場合、その鍵ファイルの名前が付いたプラグインの構成ファイルを手動で更新
して、 stashfile プロパティー定義を除去する必要があります。例えば、次のようにします。
<Transport Hostname=“MYISERIES” Port=“10175” Protocol=“https”>
<Property name=“keyring” value=“/QIBM/UserData/WebASE51/ASE/myinst/etc/myplugin-key.kdb”/>
</Transport>
注: SSL 用の WebSphere Web プラグインを構成するには、そのプラグインの構成ファイルを手動で更新
する必要があります。プラグインの構成ファイルが再生成されると、手動による変更は失われることがあり
130
WebSphere Application Server - Express Version 5.1 セキュリティー
ます。プラグインの構成ファイルを手動で変更した場合は、ファイルをチェックして、その変更が失われて
いるかどうかを確認し、必要であれば、その変更を再適用してください。
構成は完了しました。
別の方法として、アプリケーション・サーバーの Web コンテナーへの認証に、自己署名証明書を使用する
ようにプラグインを構成して、より厳しい制限付きセキュリティー・ポリシーを実装することもできます。
上記のタスクのすべてのステップを順調に完了したものと仮定して、以下のステップを実行して、このより
厳しい制限付きポリシーを実装します。
1. iKeyman を使用して鍵ストアを作成します。
2. 鍵ストアに自己署名証明書を作成します。
3. 鍵ストアから自己署名証明書を (秘密鍵とともに) エクスポートします。
4. 鍵ストアから自己署名証明書 (秘密鍵を含まないため、別名、署名者証明書ともいいます) を抽出しま
す。
5. 再度 iKeyman を使用して、HTTPS トランスポートのトラスト・ストア (上記の例では
appServerKeys.jks) に 抽出した署名者証明書を追加します。
6. HTTPS トランスポートのトラスト・ストアから、その他の署名者証明書をすべて除去します。
7. DCM を使用して、プラグインの鍵ストア (plugin-key.kdb) に自己署名証明書 (秘密鍵付き) をインポ
ートします。証明書のインポート時、使用したラベルを記録します。
注: DCM は、署名者証明書として自己署名証明書を取り扱い、自己署名証明書が秘密鍵を含んでいる
場合でも、署名者証明書のリストに追加します。
8. アプリケーション・サーバーを再始動します。
9. Web プラグイン構成ファイルを再生成します。
10. Web コンテナーへの認証にプラグインが使用すべき証明書は、Web プラグイン構成ファイルにある
HTTPS トランスポートに certLabel プロパティーを手動で追加することによって指定します
(USER_INSTALL_ROOT/config/cell/plugin-cfg.xml)。プラグインの鍵ストアに自己署名証明書をインポー
トしたときに使用したラベルを、certLabel プロパティー値に設定します。例えば、次のようにしま
す。
<Transport Hostname=“MYISERIES” Port=“10175” Protocol=“https”>
<Property name=“keyring”
value=“/QIBM/UserData/WebASE51/ASE/myinst/etc/plugin-key.kdb”/>
<Property name=“certLabel” value=“selfsigned”/>
</Transport>
11. Web サーバーを再始動します。
ディジタル証明書マネージャーの始動: ディジタル証明書マネージャー (DCM) は、iSeries ソフトウェ
ア・プロダクトです。これを使用すると、Web ベースの管理ツールを介してディジタル証明書を作成およ
び管理できます。 DCM の詳細については、iSeries Information Center にある以下のトピックを参照してく
ださい。
v V5R4『ディジタル証明書マネージャー』
v V5R3『ディジタル証明書マネージャー』
v V5R2『ディジタル証明書マネージャー』
DCM を始動するには、以下のステップを実行します。
1. IBM HTTP Server for i5/OS の *ADMIN インスタンスを開始します。
セキュリティー
131
*ADMIN サーバー・インスタンスは、以下の CL コマンド行、または iSeries Navigator を使用して開
始することができます。
v CL コマンド行を使用する場合
CL コマンド行から *ADMIN インスタンスを開始するには、次のように入力します。
STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN)
次に、Enter キーを押します。
v iSeries Navigator を使用する場合
iSeries Navigator は、iSeries サーバーへのグラフィカル・インターフェースです。iSeries Navigator
は、iSeries Access for Windows 製品のパーツです。
注: iSeries Access for Windows および iSeries ナビゲーターについては、 iSeries Access for
Windows Web サイト
を参照してください。
iSeries Navigator から *ADMIN インスタンスを開始するには、以下のステップを実行します。
a. iSeries Navigator を開始します。
b. 使用する iSeries サーバーをダブルクリックします。
c. 「ネットワーク」―>「サーバー (Server)」―>「TCP/IP」を選択します。
d. 右側のフレームの「HTTP 管理 (HTTP Administration)」を右クリックします。
e. 「開始 (Start)」を選択します。
注: このメニューで、「インスタンスの開始 (Start Instance)」オプションは選択しないでくださ
い。サーバーがすでに開始されている場合には、メニューの「開始 (Start)」オプションは使用不
可になっています。
2. JavaScript 対応のブラウザーを開始します。URL ロケーション、またはアドレス・ウィンドウに、この
URL を入力します。
http://your.server.name:2001
ここで、your.server.name は、iSeries システムのホスト名です。
3. i5/OS ユーザー・プロファイル名とパスワードの入力を求めるプロンプトが出されます。 i5/OS ユーザ
ー・プロファイルは、全オブジェクト (*ALLOBJ) の特殊権限を備えている必要があります。 iSeries
の「タスク (Tasks)」ページが表示されます。
4. 「ディジタル証明書マネージャー」をクリックする。「ディジタル証明書マネージャー」ページが表示
されます。
ローカル認証局の作成: この手順は、ご使用の iSeries システムにインストールしている DCM のリリー
スによって異なります。次に示すのは、OS/400 バージョン 5 リリース 1 モディフィケーション・レベル
0 (V5R1M0) の場合の手順です。新しいリリースの手順については、次のトピックを参照してください。
v V5R4『ローカル CA の作成および運用 (Create and operate a Local CA)』
v V5R3『ローカル CA の作成および運用 (Create and operate a Local CA)』
v V5R2『ローカル CA の作成および運用 (Create and operate a Local CA)』
ローカル認証局 (CA) を作成するには、次の手順を実行します。
1. 左側のペインで、「認証局 (CA) の作成 (Create a Certificate Authority (CA))」をクリックします。
132
WebSphere Application Server - Express Version 5.1 セキュリティー
2. 各フィールドに入力して、「次へ (Continue)」をクリックします。システムによって認証局証明書が
作成され、 Local Certificate Authority (CA) 証明書ストアに保管されます。
注: 後で参照するために、この手順で使用したパスワードを安全な場所に記録しておいてください。
3. 「ローカル CA 証明書のインストール (Install Local CA Certificate)」ページで、「次へ (Continue)」
をクリックします。
4. 「認証局 (CA) ポリシー・データ (Certificate Authority (CA) Policy Data)」ページで、必要なポリシ
ー・データを指定して「次へ (Continue)」をクリックします。
5. 「受け入れ済みポリシー・データ (Policy Data Accepted)」ページで、「次へ (Continue)」をクリック
します。
6. 各フィールドに入力して、「次へ (Continue)」をクリックします。
システムによって秘密鍵付きの証明書が作成され、デフォルトのサーバー証明書ストア (*SYSTEM)
に証明書が保管されます。
7. 「アプリケーションの選択 (Select Applications)」ページで、「次へ (Continue)」をクリックします。
8. 「アプリケーション状況の選択 (Select Applications Status)」ページで、「次へ (Continue)」をクリッ
クします。
9. 各フィールドに入力して、「次へ (Continue)」をクリックします。
システムによって秘密鍵付きの証明書が作成され、デフォルトのオブジェクト署名証明書ストア
(*OBJECTSIGNING) に証明書が保管されます。
10. 「アプリケーションの選択 (Select Applications)」ページで、「OK」ボタンをクリックします。
これで、システムを認証局 (CA) として設定するプロセスが完了しました。
SSL 構成レパートリーの使用: SSL レパートリーには、キー・ファイルのロケーション、そのタイプおよ
び使用可能暗号などの、SSL 接続を作成するのに必要な詳細事項が含まれます。WebSphere Application
Server - Express には、DefaultSSLSettings と呼ばれるデフォルトのレパートリーが用意されています。管
理コンソールでこのページを表示するには、「セキュリティー (Security)」―>「SSL」をクリックして、
SSL レパートリー設定値のリストを表示します。
注: 実稼働環境では、デフォルトのレパートリーを使用することはお勧めできません。詳しくは、 113 ペー
ジの『デフォルトの SSL 鍵ストア・ファイルとトラストストア・ファイルの変更』を参照してください。
Web コンテナーなど、SSL を使用して暗号化された要求を送受信するサービスの構成時に、適切なレパー
トリーが参照されます。このレパートリーから SSL 構成を削除する前に、SSL 構成別名がどこかで参照さ
れていれば、ここでそれを削除してしまうと、削除された別名にアクセスしたときに SSL 接続が失敗する
ことに注意してください。
管理者は、SSL 構成レパートリーにより、HTTPS、IIOPS、または LDAPS 接続を行うのに使用できる任意
の数の SSL 設定を定義できます。ここで定義した SSL 設定の 1 つを、SSL 接続が可能な管理コンソー
ル内の任意のロケーションから取り出すことができます。これにより、複数の場所で別名を指定するだけで
これらの SSL 構成を再使用できるので、SSL 構成を単純化できます。
SSL レパートリーを作成するには、WebSphere 管理コンソールで以下のステップを実行します。
1. ナビゲーション・メニューで、「セキュリティー (Security)」を展開して「SSL」をクリックします。
2. 「SSL 構成レパートリー (SSL Configuration Repertoire)」ウィンドウで、「新規 (New)」をクリックし
ます。構成を認識する別名を入力します。「OK」をクリックします。
セキュリティー
133
3. リンクをクリックして、新しい SSL 構成レパートリーを選択します。
4. 「追加プロパティー (Additional Properties)」の下の「Secure Sockets Layer (SSL)」をクリックしま
す。新規の構成詳細事項を表示されるウィンドウに入力できます。
5. 鍵ファイル名の完全修飾パス名を入力します。
6. キー・ファイルのパスワードを入力します。
7. トラスト・ファイルに関して上記 2 ステップを繰り返します。トラスト・ファイル・パス名が完全修
飾されていることを確認してください。
8. この構成でクライアント認証がサポートされる場合は、「クライアント認証 (Client Authentication)」
を選択します。これは HTTP と LDAP 要求にのみ影響します。
9. 該当するセキュリティー・レベルを設定する必要があります。有効な値は、以下のとおりです。
v 低
ディジタル署名暗号のみを指定します (暗号化は行いません)。
v 中
40 ビットの暗号のみを指定します (ディジタル署名を含む)。
v 高
128 ビットの暗号のみを指定します (ディジタル署名を含む)。
10. 事前設定のセキュリティー・レベルで必要な暗号が定義されていない場合、暗号スイート・オプション
に手動で追加できます。
11. ハードウェアまたはソフトウェア暗号サポートは、iSeries システムでは使用できないことに注意して
ください。「暗号トークン (Cryptographic Token)」の設定値は、iSeries には適用されません。
12. JSSE プロバイダーとして IBMJSSE を選択します。
注: 他の WebSphere Application Server プラットフォームでは、連邦情報処理標準 (FIPS) に準拠する
IBMJSSEFIPS JSSE プロバイダーがサポートされます。 FIPS は現行では iSeries でサポートされて
いないため、 IBMJSSE を選択するしかありません。
13. SSL プロトコル・バージョンを選択します。
14. 「OK」をクリックして変更を適用します。
15. エラーがなければ、変更をマスター構成に保管して WebSphere Application Server - Express を再始動
します。
iKeyman ユーティリティー: iKeyman ユーティリティーはディジタル証明書の管理に使用できるグラフィ
カル・ユーザー・インターフェース (GUI) ベースのツールです。 iKeyman を使用することにより、新規
の鍵データベースを作成したり、ディジタル証明書を検査したり、認証局 (CA) ルートをユーザーのデー
タベースに追加したり、証明書を 1 つのデータベースから他のデータベースにコピーしたり、 CA に対し
てディジタル証明書を要求および受信したり、デフォルト・キーを設定したり、パスワードの変更をしたり
できます。
iKeyman ユーティリティーは IBM Java Security Socket Extension パッケージの一部で、 WebSphere
Application Server - Express 製品に同梱されています。 iKeyman ユーティリティーはグラフィカル・イン
ターフェース対応のワークステーションにダウンロードすることが推奨されます。
iKeyman ユーティリティーのセットアップ
iKeyman ユーティリティーをセットアップし、ディジタル証明書を扱うには、次の手順に従ってくださ
い。
134
WebSphere Application Server - Express Version 5.1 セキュリティー
1. 以下の Java 環境のいずれかをご使用のワークステーションにインストールします (まだインストール
されていない場合)。
v IBM Developer Kit for Java、バージョン 1.3 以降
v IBM Runtime Environment、Java Edition、バージョン 1.3 以降
v Sun Microsystems、Inc. Java 2 Software Development Kit、バージョン 1.3 以降
v Sun Microsystems、Inc. Java 2 Runtime Environemnt、バージョン 1.3 以降
2. iKeyman プログラム・ファイルをご使用のワークステーションにダウンロードします。
ネットワーク・ドライブを iSeries システムに対してマップするか、ファイル転送プロトコル (FTP) を
使用して、ファイルをワークステーション・システムにコピーすることができます。
iKeyman のプログラム・ファイルを以下に示します。
v /QIBM/ProdData/WebASE51/ASE/lib/gskikm.jar
v /QIBM/ProdData/WebASE51/ASE/java/ext/ibmjceprovider.jar
v /QIBM/ProdData/WebASE51/ASE/java/ext/ibmpkcs11.jar
v /QIBM/ProdData/OS400/Java400/ext/ibmpkcs.jar
v /QIBM/ProdData/OS400/Java400/ext/ibmjcefw.jar
v /QIBM/ProdData/OS400/Java400/ext/US_export_policy.jar
v /QIBM/ProdData/CAP/local_policy.jar
上記のファイルを Java 環境の製品ディレクトリーの jre/lib/ext サブディレクトリーに置きます。例え
ば、Windows の 32 ビット・システムでは次のディレクトリーです。
v C:¥Program Files¥IBM¥Java14¥jre¥lib¥ext
v D:¥j2sdk1.4.0_01¥jre¥lib¥ext
3. ワークステーション上で、Java 環境の java.security ファイルを更新します。
java.security ファイルは Java 環境の jre/lib/security サブディレクトリーに存在します。ファイルをテキ
スト・エディターで開き、次の項目と似たものを探してください。
security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.rsajca.Provider
次の行を項目の末尾に追加します。
security.provider.3=com.ibm.crypto.provider.IBMJCE
PKCS11 ハードウェア暗号化サポートを使用している場合、次の項目も追加してください。
security.provider.4=com.ibm.crypto.pkcs11.provider.IBMPKCS11
java.security ファイルを保管します。
4. (Windows ワークステーションのみ) iKeyman を実行するためのバッチ (BAT) ファイルを作成します。
ご使用のワークステーションが Windows システムの場合は、iKeyman を開始するバッチ・ファイルを
作成することができます。次のようなバッチ・ファイルを作成します。
setlocal
set JAVA_HOME=java_root
set PATH=%JAVA_HOME%¥jre¥bin;%JAVA_HOME%¥bin;%PATH%
java com.ibm.gsk.ikeyman.Ikeyman
endlocal
セキュリティー
135
ここで、java_root は Java 環境のルート・ディレクトリーです (例えば、C:¥j2sdk1.4.0_01)。
iKeyman ユーティリティーを開始する
iKeyman を開始するバッチ・ファイルを作成した場合は、バッチ・ファイルを実行します。
バッチ・ファイルを作成しなかった場合は、プロンプトから次のコマンドを入力して iKeyman を開始でき
ます。
1. ワークステーションのコマンド・プロンプトを開きます。
2. iKeyman プログラム・ファイルを含むディレクトリーに移動します。移動先のディレクトリーは
java_root/jre/lib/ext です。ここで、java_root は Java 環境の製品ディレクトリーのルート・ディレクト
リーになります。
3. Java ユーティリティー (java コマンドなど) がシステム・パスに構成されていない場合は、以下のコマ
ンドを入力してください。ここで、java_root は Java 環境のルート・ディレクトリーです (例えば、
C:¥j2sdk1.4.0_01)。
set JAVA_HOME=java_root
set PATH=%JAVA_HOME%¥jre¥bin;%JAVA_HOME%¥bin;%PATH%
4. 次のコマンドを入力します。
java com.ibm.gsk.ikeyman.Ikeyman
iKeyman ユーティリティーの使用
iKeyman に関する追加情報は、IBM DeveloperWorks: iKeymanDocs.zip
からダウンロードできます。
注: UNIX ベースのプラットフォームで iKeyman を使用して、証明書署名要求を作成する場合、行末文字
(^M) をファイルから除去する必要があります。例えば、certreq.arm という名前の証明書署名要求から行末
文字を除去する場合、次のコマンドを実行します。
cat certreq.arm |tr -d “¥r” > new_certreq.arm
アプリケーション・サーバーの Web コンテナーに関する HTTPS トランスポートの構成:
理コンソールで、以下のステップを実行します。
WebSphere 管
1. 管理コンソールを始動します。
2. 製品に付随する鍵ファイルを使用している場合に Web サーバー・プラグインの SSL を構成するに
は、ステップ『HTTPS トランスポートの構成』 (137ページ)にスキップします。
SSL のレパートリーを作成するには、以下のステップを実行します。
a. 左側のペインで、「セキュリティー (Security)」を展開します。
b. 「SSL」をクリックします。
c. 右側のペインで、「新規 (New)」をクリックします。
d. 以下の構成設定値を指定します。
v 別名 (Alias): (SSL レパートリーの名前。例えば、mySSLSettings)
v 鍵ファイル名 (Key File Name): USER_INSTALL_ROOT/etc/appServerKeys.jks。例えば
/QIBM/UserData/WebASE51/ASE/myInstance/etc/appServerKeys.jks。
v キー・ファイル・パスワード (Key File Password): パスワードを入力します。
v キー・ファイル・フォーマット (Key File Format): JKS を選択します。
v トラスト・ファイル名 (Trust File Name): USER_INSTALL_ROOT/etc/appServerKeys.jks
136
WebSphere Application Server - Express Version 5.1 セキュリティー
注: 署名者証明書用に別のトラスト・ファイルを作成するのが普通です。ただし、以前のステッ
プで、プラグインの証明書を署名した CA の証明書を appServerKeys.jks に追加しましたが、こ
こでも、 appServerKeys.jks を使用します。
v トラスト・ファイル・パスワード (Trust File Password): パスワードを入力します。
v トラスト・ファイル・フォーマット (Trust File Format): JKS を選択します。
v クライアント認証 (Client Authentication): 選択済み
e. 「OK」をクリックします。
3. HTTPS トランスポートを構成します。
a. 左側のペインで、「サーバー (Servers)」を展開します。
b. 「アプリケーション・サーバー (Application Servers)」をクリックします。
c. 右側のペインで、アプリケーション・サーバー名をクリックします。
d. 「構成 (Configuration)」タブをクリックします。
e. 「Web コンテナー (Web Container)」をクリックします。
f. 「HTTP トランスポート (HTTP transports)」をクリックします。
g. 「新規 (New)」をクリックします。
h. 以下の構成設定値を指定します。
v ホスト (Host): *
v ポート (Port): Web コンテナーの SSL ポートに使用するポート番号を入力します。
v SSL の使用状態 (SSL Enabled):「SSL を使用可能にする (Enable SSL)」を選択します。
v SSL: 製品に付随する鍵ファイルを使用して Web サーバー・プラグインの SSL を構成している
場合は、DefaultSettings SSL レパートリーを選択します。そうでない場合は、mySSLSettings を
選択します。
4. 「OK」をクリックします。
5. 変更を保管します。
6. アプリケーション・サーバーを再始動します。
7. 管理コンソールを始動します。
8. 管理コンソールの左側のペインで、「環境 (Environment)」を展開し、「Web サーバー・プラグイン
の更新 (Update Web Server Plugin)」をクリックします。
9. 「OK」をクリックします。
10. これ以前に Web サーバー・プラグイン構成ファイル (USER_INSTALL_ROOT/config/cell/plugin-cfg.xml)
に手動で変更を加えている場合には、Web サーバーを再始動する前にそうした変更内容を手動で適用
し直す必要があります。
11. Web サーバーを再始動して、Web サーバー・プラグイン構成ファイルに対する変更をただちに反映さ
せてください。
WebSphere アプリケーションでの SSL の構成: SSL では、クライアント・アプリケーションは、ディジ
タル証明書を使用してサーバー・アプリケーションが信頼できるかどうかを判別します。同様に、サーバ
ー・アプリケーションは、クライアント・アプリケーションが信頼できるかどうかを判別するために、クラ
イアント・アプリケーションに対して証明書の提示を要求する場合があります。いずれのケースでも、アプ
リケーションはセキュアなネットワーク接続を開くためにディジタル証明書へのアクセス権を持つ必要があ
ります。また、これらの証明書は、クライアント・アプリケーションがアクセス可能な安全でセキュアなコ
ンテナーに保管する必要があります。さらに、アプリケーションがどの証明書を使用すべきかを判別できる
ようなメカニズムを用意する必要があります。
セキュリティー
137
WebSphere Application Server - Express for iSeries で稼働する Java アプリケーションの場合、証明書は以
下のタイプの証明書ストアに保管することができます。
v Java 鍵ストアファイル (.jks files)
Java 鍵ストア・ファイルを作成および管理するには、IBM Key Management ツール (iKeyman) または
Keytool ユーティリティーのいずれかを使用してください。WebSphere Application Server - Express 5.0
の証明書ストアには、Java 鍵ストア・ファイルをお勧めします。詳しくは、『Java 鍵ストア・ファイル
の使用』を参照してください。
v i5/OS 証明書ストア
バージョン 5.0 では WebSphere アプリケーションで i5/OS 証明書コンテナー (.kdb ファイル) を使用
することは推奨できません。使用する場合は、いくつかの制限事項があります。詳しくは、『移行』ト
ピックの 『Java 鍵ストアを使用するためのアプリケーションの移行』を参照してください。
Java 鍵ストア・ファイルの使用: JSSE アプリケーションを別のプラットフォームから移植する場合、ま
たは、Java 鍵ストア・ファイルを使用する証明書ストレージとの Java JSSE インターフェースを必要とす
る場合、または、com.ibm.net.ssl.SSLContext などの、その他の各種 SSL インプリメンテーション・クラス
へのアクセスを必要とする場合には、下記の Java JSSE を使用するための構成手順を実行してください。
また、HTTPS プロトコルを介して Web サーバーへの直接接続を提供するために java.net.URL クラスを使
用するアプリケーションでは、Java 鍵ストア・ファイルを使用することもできます。詳しくは、 141 ペー
ジの『java.net.URL HTTPS プロトコル用の SSL の構成』を参照してください。
クライアント Java 鍵ストアの構成
要求した個人および署名者の証明書が取り込まれているクライアント Java 鍵ストアがすでにある場合に
は、この手順を省略することができます。
クライアント Java 鍵ストアを構成するには、トラスト検証およびキー・ストレージのいずれにも使用され
る SSL キー・ファイルを作成します。以下の手順を実行します。
1. ワークステーションで iKeyman ユーティリティーを開始する。詳しくは、 134 ページの『iKeyman ユ
ーティリティー』を参照してください。
2. 新規の鍵データベース・ファイルを作成する。
a. 「鍵データベース・ファイル (Key Database File)」をクリックして、「新規 (New)」を選択する。
b. 以下の設定値を指定する。
v Key database type (鍵データベース・タイプ): JKS
v File Name (ファイル名): clientAppKeys.jks
v Location (場所): WAS_INSTANCE_ROOT/myKeys などのユーザーの myKeys ディレクトリー
c. 「OK」をクリックする。
d. パスワードを入力して (確認のため 2 回)、「OK」をクリックする。
3. 「署名者証明書 (Signer Certificates)」をクリックして、「個人証明書 (Personal Certificates)」を選択
する。
4. 新規の自己署名証明書を追加する。
a. 「新規の自己署名 (New Self-Signed)」をクリックして、自己署名証明書を追加する。
b. 以下の設定値を指定する。
v Key Label (鍵ラベル): clientAppTest
v Common Name (共通名): iSeries サーバーの DNS 名を使用する。
v Organization (組織): IBM
138
WebSphere Application Server - Express Version 5.1 セキュリティー
c. 「OK」をクリックする。
5. この自己署名証明書から証明書を抽出する。これによって、証明書をサーバー・アプリケーションの
SSL キー・ファイルにインポートできます。
a. 「証明書の抽出 (Extract Certificate)」をクリックする。
b. 以下の設定値を指定する。
v Data Type (データ型): Base64 エンコード ASCII データ
v Certificate file name (証明書ファイル名): clientAppsCA.arm
v Location (場所): ユーザーの myKeys ディレクトリーのパス
c. 「OK」をクリックする。
6. サーバー・アプリケーションの CA 証明書を serverAppKeys.jks ファイルからインポートする。
a. 「個人証明書 (Personal Certificates)」をクリックして、「署名者証明書 (Signer Certificates)」を選
択する。
b. 「追加」をクリックする。
c. 以下の設定値を指定する。
v Data Type (データ型): Base64 エンコード ASCII データ
v Certificate file name (証明書ファイル名): serverAppsCA.arm
v Location (場所): ユーザーの myKeys ディレクトリーのパス
d. 「OK」をクリックする。
7. ラベルに serverAppsCA と入力して、「OK」をクリックする。
8. 「鍵データベース・ファイル (Key Database File)」をクリックする。
9. 「終了 (Exit)」を選択する。
サーバー Java 鍵ストアの構成
要求した個人および署名者の証明書が取り込まれているサーバー Java 鍵ストアがすでにある場合には、こ
の手順を省略することができます。
サーバー Java 鍵ストアを構成するには、トラスト検証およびキー・ストレージのいずれにも使用する SSL
キー・ファイルを作成します。以下のステップを実行します。
1. ワークステーション上で iKeyman を開始する。詳しくは、 134 ページの『iKeyman ユーティリティ
ー』を参照してください。
2. 新規の鍵データベース・ファイルを作成する。
a. 「鍵データベース・ファイル (Key Database File)」をクリックして、「新規 (New)」を選択する。
b. 以下の設定値を指定する。
v Key database type (鍵データベース・タイプ): JKS
v File Name (ファイル名): serverAppKeys.jks
v Location (場所): WAS_INSTANCE_ROOT/myKeys などのユーザーの myKeys ディレクトリー
c. 「OK」をクリックする。
d. パスワードを入力して (確認のため 2 回)、「OK」をクリックする。
3. 「署名者証明書 (Signer Certificates)」をクリックして、「個人証明書 (Personal Certificates)」を選択
する。
4. 新規の自己署名証明書を追加する。
セキュリティー
139
a. 「新規の自己署名 (New Self-Signed)」をクリックして、自己署名証明書を追加する。
b. 以下の設定値を指定する。
v Key Label (鍵ラベル): serverAppTest
v Common Name (共通名): iSeries サーバーの DNS 名を使用する。
v Organization (組織): IBM
c. 「OK」をクリックする。
5. この自己署名証明書から証明書を抽出する。これによって、証明書をクライアント・アプリケーション
の SSL キー・ファイルにインポートできます。
a. 「証明書の抽出 (Extract Certificate)」をクリックする。
b. 以下の設定値を指定する。
v Data Type (データ型): Base64 エンコード ASCII データ
v Certificate file name (証明書ファイル名): serverAppsCA.arm
v Location (場所): ユーザーの myKeys ディレクトリーのパス
c. 「OK」をクリックする。
6. クライアント・アプリケーションの CA 証明書を clientAppKeys.jks ファイルからインポートする。
a. 「個人証明書 (Personal Certificates)」をクリックして、「署名者証明書 (Signer Certificates)」を選
択する。
b. 「追加」をクリックする。
c. 以下の設定値を指定する。
v Data Type (データ型): Base64 エンコード ASCII データ
v Certificate file name (証明書ファイル名): clientAppsCA.arm
v Location (場所): ユーザーの myKeys ディレクトリーのパス
d. 「OK」をクリックする。
7. ラベルに clientAppsCA と入力して、「OK」をクリックする。
8. 「鍵データベース・ファイル (Key Database File)」をクリックする。
9. 「終了 (Exit)」を選択する。
クライアント JSSE アプリケーション・コードの例
com.ibm.as400.ibmonly.net.ssl.Provider がコマンド行 Java 仮想マシン・システム・プロパティーまた
は java.security ファイル内のセキュリティー・プロパティーのいずれかでセキュリティー・プロバイダー
として指定されていない場合には、お使いのアプリケーション・コードは、SocketFactory を取得するのに
SocketFactory socketFactory = SSLSocketFactory.getDefault() を使用することはできませんので、注意
してください。
Java 鍵ストア・ファイルの完全対応使用では、java.security ファイルでのみ指定できる、ほかの 2 つのプ
ロパティーも以下のようにして設定する必要があります。
ssl.SocketFactory.provider=com.ibm.as400.ibmonly.net.ssl.SSLSocketFactoryImpl
ssl.ServerSocketFactory.provider=com.ibm.as400.ibmonly.net.ssl.SSLServerSocketFactoryImpl
各ユーザー・インスタンスに提供されているプロパティー・ディレクトリー内のデフォルト java.security
ファイルは、上記の 3 つのプロパティーを次のように設定します。
security.provider.6=com.ibm.as400.ibmonly.net.ssl.Provider
ssl.SocketFactory.provider=com.ibm.as400.ibmonly.net.ssl.SSLSocketFactoryImpl
ssl.ServerSocketFactory.provider=com.ibm.as400.ibmonly.net.ssl.SSLServerSocketFactoryImpl
140
WebSphere Application Server - Express Version 5.1 セキュリティー
145 ページの『例: JSSE クライアント・サーブレット』を参照してください。クライアント鍵ストアは、
WebSphere Application Server - Express の作業ディレクトリーに置く必要があります。
サーバー JSSE アプリケーション・コードの例
com.ibm.as400.ibmonly.net.ssl.Provider がコマンド行 Java 仮想マシン・システム・プロパティーまた
は java.security ファイル内のセキュリティー・プロパティーのいずれかでセキュリティー・プロバイダー
として指定されていない場合には、お使いのアプリケーション・コードは、ServerSocketFactory を取得する
のに ServerSocketFactory serverSocketFactory = SSLServerSocketFactory.getDefault() を使用するこ
とはできません。
Java 鍵ストア・ファイルの完全対応使用では、java.security ファイルでのみ指定できる、ほかの 2 つのプ
ロパティーも以下のようにして設定する必要があります。
ssl.SocketFactory.provider=com.ibm.as400.ibmonly.net.ssl.SSLSocketFactoryImpl
ssl.ServerSocketFactory.provider=com.ibm.as400.ibmonly.net.ssl.SSLServerSocketFactoryImpl
各ユーザー・インスタンスに提供されているプロパティー・ディレクトリー内のデフォルト java.security
ファイルは、上記の 3 つのプロパティーを次のように設定します。
security.provider.6=com.ibm.as400.ibmonly.net.ssl.Provider
ssl.SocketFactory.provider=com.ibm.as400.ibmonly.net.ssl.SSLSocketFactoryImpl
ssl.ServerSocketFactory.provider=com.ibm.as400.ibmonly.net.ssl.SSLServerSocketFactoryImpl
149 ページの『例: JSSE サーバー・サーブレット』を参照してください。サーバーの鍵ストアは、
WebSphere Application Server - Express の作業ディレクトリーに置く必要があります。
java.net.URL HTTPS プロトコル用の SSL の構成: java.net.URL クラスには、指定された URL を
HTTPS プロトコルを使用して検索するために Web サーバーへの直接接続が提供されています。
Web サーバーでの SSL の構成は、Web サーバーのタイプによって異なります。手順については、使用し
ている Web サーバーの使用を参照してください。
クライアント Java 鍵ストアの構成
要求した個人および署名者の証明書が取り込まれているクライアント Java 鍵ストアがすでにある場合に
は、この手順を省略することができます。
クライアント Java 鍵ストアを構成するには、Digital Certificate Manager (DCM) を使用して、Web サーバ
ーが使用する Local Certificate Authority (CA) 証明書を取り出します。続いて、その証明書をクライアント
Java 鍵ストア・ファイルにインポートすることができます。
以下のステップを実行します。
1.
131 ページの『ディジタル証明書マネージャーの始動』。
2. Local Certificate Authority (CA) を作成する。お使いの iSeries システムで認証局をすでに作成してある
場合には、この手順を省略してください。
3. 左のペインで「証明書ストアの選択 (Select a Certificate Store)」をクリックする。
4. 「*System」を選択して、「継続 (Continue)」をクリックする。
5. 「証明書ストア (Certificate Store)」および「パスワード (Password)」ページで、パスワードを入力し、
「継続 (Continue)」をクリックする。
6. 左側のペインで、「PC への CA 証明書のインストール (Install CA certificate on your PC)」をクリ
ックする。
セキュリティー
141
7. 右側のペインで、「証明書のコピーおよび貼り付け (Copy and paste certificate)」をクリックする。
8. PC 上でテキスト・ファイル USER_INSTALL_ROOT/etc/myLocalCA.txt を作成してから、CA 証明書を
myLocalCA.txt に貼り付け、そのファイルを保管する。CA 証明書のコピーは、必ず改行文字で終了す
るようにしてください。
9. 「完了 (Done)」ボタンをクリックする。
続いて、新規の鍵データベース・ファイルをクライアント Https アプリケーションに作成する。
1. ワークステーション上で iKeyman を開始する。詳しくは、 134 ページの『iKeyman ユーティリティ
ー』を参照してください。
2. 新規の鍵データベース・ファイルを作成する。
a. 「鍵データベース・ファイル (Key Database File)」をクリックして、「新規 (New)」を選択する。
b. 以下の設定値を指定する。
v Key database type (鍵データベース・タイプ): JKS
v File Name (ファイル名): httpsClientKeys.jks
v Location (場所):
USER_INSTALL_ROOT/etc/myKeys などのその他のディレクトリー
c. 「OK」をクリックします。
d. パスワードを入力して (確認のため 2 回)、「OK」をクリックする。
3. すべての署名者証明書を削除する。
4. 「署名者証明書 (Signer Certificates)」をクリックして、「個人証明書 (Personal Certificates)」を選択
する。
5. 新規の自己署名証明書を追加する。
a. 「新規の自己署名 (New Self-Signed)」をクリックして、自己署名証明書を追加する。
b. 以下の設定値を指定する。
v Key Label (鍵ラベル): httpsClientTest
v Common Name (共通名): iSeries サーバーの DNS 名を使用する。
v Organization (組織): IBM
c. 「OK」をクリックします。
6. この自己署名証明書から証明書を抽出する。これによって、証明書を Web サーバーの SSL キー・フ
ァイルにインポートできます。
a. 「証明書の抽出 (Extract Certificate)」をクリックする。
b. 以下の設定値を指定する。
v Data Type (データ型): Base64 エンコード ASCII データ
v Certificate file name (証明書ファイル名): httpsClient.arm
v Location (場所): ユーザーの etc ディレクトリーのパス
c. 「OK」をクリックします。
7. Web サーバーの証明書をインポートする。
a. 「個人証明書 (Personal Certificates)」をクリックして、「署名者証明書 (Signer Certificates)」を
選択する。
b. 「追加」をクリックする。
c. 以下の設定値を指定する。
142
WebSphere Application Server - Express Version 5.1 セキュリティー
v Data Type (データ型): Base64 エンコード ASCII データ
v Certificate file name (証明書ファイル名): myLocalCA.txt
v Location (場所): ユーザーの etc ディレクトリーのパス
d. 「OK」をクリックします。
8. ラベルに「web-server」と入力して、「OK」をクリックする。
9. 「鍵データベース・ファイル (Key Database File)」をクリックする。
10. 「終了 (Exit)」を選択する。
Web サーバーの証明書ストアの構成
クライアント HTTPS アプリケーションの署名者証明書を Web サーバーの SSL キー・ファイルおよび
Web サーバーのセキュア・アプリケーションのトラステッド CA 証明書リストに追加します。この手順
は、Web サーバー構成でクライアント認証が必要な場合に行います。
1.
131 ページの『ディジタル証明書マネージャーの始動』。
2. 左のペインで、「証明書ストアの選択 (Select a Certificate Store)」をクリックする。
3. 「*SYSTEM」を選択して、「継続 (Continue)」をクリックする。
4. 「証明書ストア (Certificate Store)」および「パスワード (Password)」ページで、パスワードを入力し、
「継続 (Continue)」をクリックする。
5. 左のペインで「高速パス (Fast Path)」をクリックする。
6. 「CA 証明書の処理 (Work with CA certificates)」を選択する。
7. 「インポート (Import)」ボタンをクリックする。
8. Import file: フィールド値に対して USER_INSTALL_ROOT/etc/httpsClient.arm を指定して、「継続
(Continue)」をクリックする。
9. CA certificate label フィールド値に対して httpsClient を指定して、「継続 (Continue)」をクリック
する。
10. 左のペインで、「サーバー・アプリケーションの処理 (Work with server applications)」を選択する。
このページで、Web サーバーの構成で使用するアプリケーションを選択して、「アプリケーションの
処理 (Work with Application)」をクリックする。
11. 「CA トラスト・リストの定義 (Define CA Trust List)」をクリックする。
12. httpsClient CA のチェック・ボックスをクリックし、「OK」をクリックする。
WebSphere Application Server - Express の構成
アプリケーション・サーバーでは、いくつかの Java 仮想マシン・プロパティーを指定する必要がありま
す。WebSphere 管理コンソールを使用して、次の手順を実行します。
1. ナビゲーション・メニューで、「サーバー」を展開し、「アプリケーション・サーバー (Application
Servers)」をクリックする。
2. 「アプリケーション・サーバー (Application Servers)」ページで、サーバーの名前をクリックする。
3. 「追加プロパティー (Additional Properties)」で、「プロセス定義 (Process Definition)」をクリックす
る。
4. 「追加プロパティー (Additional Properties)」で、「Java 仮想マシン (Java Virtual Machine)」をクリッ
クする。
5. 「追加プロパティー (Additional Properties)」で、「カスタム・プロパティー (Custom Properties)」をク
リックする。
セキュリティー
143
6. 新規プロパティーに対して、「新規 (New)」をクリックする。以下のプロパティーを追加してくださ
い。
名前
値
java.protocol.handler.pkgs
com.ibm.net.ssl.internal.www.protocol
javax.net.ssl.trustStore
USER_INSTALL_ROOT/etc/httpsClientKeys.jks。ここで、
USER_INSTALL_ROOT は、ユーザー・インスタンスのル
ート・ディレクトリーです。
javax.net.ssl.trustStorePassword
(パスワードを入力する。)
Web サーバーでクライアント認証が必要な場合には、次のプロパティーを追加指定する必要がありま
す。
名前
値
javax.net.ssl.keyStore
USER_INSTALL_ROOT/etc/httpsClientKeys.jks、ここで、
USER_INSTALL_ROOT はユーザー・インスタンスのルー
ト・ディレクトリーです。
javax.net.ssl.keyStorePassword
(パスワードを入力する。)
通常、javax.net.ssl.keyStore は別の鍵ストア・ファイルとなります。
「OK」をクリックします。
HTTPS を使用するサーブレットのコード例については、『例: HTTPS サーブレット』を参照してくださ
い。サーブレットは、クエリー・ストリングとして、またはサーブレット初期化パラメーターとして入力さ
れた URL を検索して表示します。
例: HTTPS サーブレット:
/*
* This material contains programming source code for your
* consideration. These examples have not been thoroughly
* tested under all conditions. IBM, therefore, cannot
* guarantee or imply reliability, serviceability, or function
* of these program. All programs contained herein are
* provided to you “AS IS”. THE IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* ARE EXPRESSLY DISCLAIMED. IBM provides no program services for
* these programs and files.
*/
import java.io.DataInputStream;
import java.security.*;
import java.net.URLConnection;
import java.net.URL;
import java.net.URLDecoder;
import java.io.PrintWriter;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class HttpsSampleServlet extends HttpServlet
{
public void doGet(HttpServletRequest req, HttpServletResponse res) {
res.setContentType(“text/html”);
144
WebSphere Application Server - Express Version 5.1 セキュリティー
// url passed in as browser query string
String url = req.getParameter(“httpsURL”);
if (null != url)
url = URLDecoder.decode(url);
else {
// url passed in as servlet init parameter
url = getInitParameter(“httpsURL”);
}
URLConnection conn = null;
URL connectURL = null;
// send result to the caller
try {
PrintWriter out = res.getWriter();
if (null == url || url.length() == 0) {
out.println(“No Https URL provided to retrieve”);
}
else {
connectURL = new URL(url);
conn = connectURL.openConnection();
DataInputStream theHTML = new DataInputStream(conn.getInputStream());
String thisLine;
while ((thisLine = theHTML.readLine()) != null) {
out.println(thisLine);
}
}
out.flush();
out.close();
}
catch (Exception e) {
System.out.println(“Exception in HttpsSampleServlet: ” + e.getMessage());
e.printStackTrace();
}
}//end goGet(...)
}//end class
例: JSSE クライアント・サーブレット:
/*
*
* This material contains programming source code for your
* consideration. These examples have not been thoroughly
* tested under all conditions. IBM, therefore, cannot
* guarantee or imply reliability, serviceability, or function
* of these program. All programs contained herein are
* provided to you “AS IS”. THE IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* ARE EXPRESSLY DISCLAIMED. IBM provides no program services for
* these programs and files.
*
*/
import java.io.*;
import java.net.ServerSocket;
import java.net.Socket;
import java.security.Security;
import java.security.KeyStore;
import javax.net.ssl.SSLServerSocketFactory;
import javax.net.ssl.SSLSocketFactory;
import javax.net.ssl.SSLServerSocket;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.SSLSession;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
セキュリティー
145
import
import
import
import
com.ibm.net.ssl.SSLContext;
com.ibm.net.ssl.TrustManagerFactory;
com.ibm.net.ssl.TrustManager;
com.ibm.net.ssl.KeyManagerFactory;
/*
* ServerJsse and ClientJsse
*
* Sample applications to demonstrate a simple client/server interaction using JSSE.
* They communicate using all enabled cipher suites.
*
* The ServerJsse and ClientJsse use different KeyStore files called
* “clientAppKeys.jks” and “serverAppKeys.jks” protected by a password and assumed
* to be in the current working directory. In a real application, the client and
* server should also have their own KeyStore files.
*
* You can build these sample program classes by issuing the following command but
* first make sure that the ibmjsse.jar file shipped in the
* “WAS_PRODUCT_ROOT/java/ext” is in your CLASSPATH or extensions directory.
* This is a servlet, so you also need “WAS_PRODUCT_ROOT/lib/j2ee.jar to compile.
*
*
javac ServerJsse.java
*
javac ClientJsse.java
*
*
* Running the client/server application requires that the Server is started first
* and then the Client application.
*
* To start the ServerJsse, run the following command:
*
*
java ServerJsse
*
* The ServerJsse uses port 8050 by default. Once ServerJsse has started it waits
* for the ClientJsse connection.
*
* To start the client, issue the following command:
*
*
java ClientJsse hostname:port
*
* where hostname:port is the optional host:port running SeverJsse.
* The default is localhost:8050.
*
*/
public class ClientJsse extends HttpServlet {
static int N = 50, L = 100, R = 2;
static PrintWriter out = new PrintWriter(System.out);
static SSLContext sslContext;
// Open the KeyStore to obtain the Trusted Certificates.
// KeyStore is of type ”JKS“. Filename is ”clientAppKeys.jks“
// and password is ”myKeys“.
public static void initContext() {
try {
Security.addProvider(new com.ibm.jsse.JSSEProvider());
KeyStore ks = KeyStore.getInstance(”JKS“);
ks.load(new FileInputStream(”clientAppKeys.jks“), ”myKeys“.toCharArray());
KeyManagerFactory kmf = KeyManagerFactory.getInstance(”IbmX509“);
kmf.init(ks, ”myKeys“.toCharArray());
TrustManager[] tm;
TrustManagerFactory tmf = TrustManagerFactory.getInstance(”IbmX509“);
tmf.init(ks);
tm = tmf.getTrustManagers();
146
WebSphere Application Server - Express Version 5.1 セキュリティー
sslContext = SSLContext.getInstance(”SSL“);
sslContext.init(kmf.getKeyManagers(), tm, null);
}
catch (Throwable t) {
out.println(”Failed to read clientAppKeys.jks file.“);
t.printStackTrace();
}
}
public void doGet(HttpServletRequest q, HttpServletResponse r) {
r.setContentType(”text/html“);
String[] args = new String[1];
args[0] = getInitParameter(”hostname“);
// send result to the caller
try {
out = r.getWriter();
out.println(”<html>“);
out.println(”<head>title>Client JSSE Session</title></head>“);
out.println(”<body>“);
out.println(”<h1>Client JSSE Session (starting)</h1>“);
out.flush();
out.println(”<pre>“);
main(args);
out.println(”</pre>“);
out.println(”</body></html>“);
out.flush();
out.close();
}
catch (Exception e) {
out.println(”Exception in ClientJsse Servlet: “ + e.getMessage());
e.printStackTrace();
}
}//end public void doGet(...)
/** Starts the ClientJsse application as stand alone application.
* @param args the name of the host the ClientJsse should connect to
*/
public static void main(String args[]) throws Exception {
int i, j, len, ci_nonanon;
String host = ”127.0.0.1“;
int port = 8050;
if ((args != null) && (args.length > 0)) {
host = args[0];
i = host.indexOf(’:’);
if (i != -1) {
try {
port = Integer.parseInt(host.substring(i+1));
host = host.substring(0,i);
}
catch (Exception e) {
System.err.println(”ClientJsse: wrong address format“);
e.printStackTrace();
throw e;
}
}
}
if (args.length > 1)
セキュリティー
147
N = Integer.parseInt(args[1]);
if (args.length > 2)
L = Integer.parseInt(args[2]);
byte buffer[] = new byte[L];
out.println(”ClientJsse: started.“);
initContext();
try {
if (sslContext == null) {
out.println (”ClientJsse:
return;
}
SSL client context NOT created.“);
out.println(”ClientJsse: SSL client context created.“);
SSLSocketFactory factory = sslContext.getSocketFactory();
String[] cipher_suites =
sslContext.getSocketFactory().getSupportedCipherSuites();
out.println(”ClientJsse: enabled cipher suites“);
for (i=0, ci_nonanon=0; i < cipher_suites.length; i++) {
if (cipher_suites[i].indexOf(”_anon_“) < 0) {
ci_nonanon++;
}
out.println(”
“ + cipher_suites[i]);
}
out.flush();
SSLSocket ssl_sock;
OutputStream ostr;
InputStream istr;
long t;
String[] ecs = new String[1];
out.println(”¥n “);
for (int csi = 0; csi < ci_nonanon; csi++) {
// Remove anonymous cipher suites.
// TrustManager requires a personal certificate.
ecs[0] = cipher_suites[csi];
if (ecs[0].indexOf(”_anon_“) >= 0) {
continue;
}
for (int n = 0; n < R; n++) {
t = System.currentTimeMillis();
try {
ssl_sock = (SSLSocket) factory.createSocket(host, port);
ssl_sock.setEnabledCipherSuites(ecs);
ssl_sock.startHandshake();
SSLSession session = ssl_sock.getSession();
out.println(” “);
out.println(”¥nClientJsse: SSL connection established“);
out.println(”
cipher suite:
“ + session.getCipherSuite());
}
catch (Exception se) {
out.println(” “);
out.println(”¥nClientJsse: can’t connect using: “ +
cipher_suites[csi] + ”¥n“ + se);
break;
}
if (L > 0) {
istr = ssl_sock.getInputStream();
ostr = ssl_sock.getOutputStream();
for (j=0; j < N; j++) {
if ((j==N-1) && (n == R-1) && (csi == ci_nonanon - 1))
148
WebSphere Application Server - Express Version 5.1 セキュリティー
buffer[0] = (byte)-1;
ostr.write(buffer, 0, L);
for (len = 0;;) {
try {
if ((i = istr.read(buffer, len, L-len)) == -1) {
out.println(”ClientJsse: SSL connection dropped by partner.“);
istr.close();
return;
}
// out.println(”ClientJsse: “ + i + ” bytes received.“);
if ((len+=i) == L) break;
}
catch (InterruptedIOException e) {
// out.println(”ClientJsse: timeout.¥n“);
}
}
}
}
out.println(”Messages = “ + N*2 + ”; Time = “ +
(System.currentTimeMillis() - t));
ssl_sock.close();
out.println(”ClientJsse: SSL connection closed.“);
out.flush();
}
}
Thread.sleep(1500);
// Example using plain sockets
if (L > 0) {
Socket sock = new Socket(host, port);
out.println(” “);
out.println(”¥nClientJsse: Plain Socket connection established.“);
istr = sock.getInputStream();
ostr = sock.getOutputStream();
t = System.currentTimeMillis();
for (j=0; j < N; j++) {
ostr.write(buffer, 0, L);
for (len = 0;;) {
if ((i = istr.read(buffer, len, L-len)) == -1) {
out.println(”ClientJsse: connection dropped by partner.“);
return;
}
if ((len+=i) == L) break;
}
}
out.println(”Messages = “ + N*2 + ”; Time = “ +
(System.currentTimeMillis() - t));
sock.close();
out.println(”ClientJsse: Plain Socket connection closed.“);
Thread.sleep(1500);
}
}
catch (Exception e) {
out.println(e);
}
out.println(” “);
out.println(”ClientJsse: terminated.“);
out.flush();
}//end main(...)
}//end class
例: JSSE サーバー・サーブレット:
/*
*
*
This material contains programming source code for your
セキュリティー
149
* consideration. These examples have not been thoroughly
* tested under all conditions. IBM, therefore, cannot
* guarantee or imply reliability, serviceability, or function
* of these program. All programs contained herein are
* provided to you “AS IS”. THE IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* ARE EXPRESSLY DISCLAIMED. IBM provides no program services for
* these programs and files.
*
*/
import java.io.*;
import java.net.ServerSocket;
import java.net.Socket;
import java.security.Security;
import java.security.KeyStore;
import javax.net.ssl.SSLServerSocketFactory;
import javax.net.ssl.SSLServerSocket;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.SSLSession;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import com.ibm.net.ssl.SSLContext;
import com.ibm.net.ssl.TrustManagerFactory;
import com.ibm.net.ssl.KeyManagerFactory;
/*
* ServerJsse and ClientJsse
*
* Sample applications to demonstrate a simple client/server interaction using JSSE.
* They will communicate using all enabled cipher suites.
*
* The ServerJsse and ClientJsse use different KeyStore files called
* “clientAppKeys.jks” and “serverAppKeys.jks” protected by a password and assumed
* to be in the current directory. In a real application, the client and server
* should also have their own KeyStore files.
*
* You can build these sample program classes by issuing the following command but
* first make sure that the ibmjsse.jar file shipped in the
* “WAS_PRODUCT_ROOT/java/ext” is in your CLASSPATH or extensions directory.
* This is a servlet, so you also need “WAS_PRODUCT_ROOT/lib/j2ee.jar to compile.
*
*
javac ServerJsse.java
*
javac ClientJsse.java
*
*
* Running the client/server application requires that the Server is started first
* and then the Client application.
*
* To start the ServerJsse, run the following command:
*
*
java ServerJsse port
*
* The ServerJsse uses port 8050 by default. Once ServerJsse has started it waits
* for the ClientJsse connection.
*
* To start the client, issue the following command:
*
*
java ClientJsse hostname:port
*
* where hostname:port is the name of the host:port running SeverJsse.
* The default is localhost:8050.
*
*/
public class ServerJsse extends HttpServlet {
static int N = 50, L = 100, R = 2;
150
WebSphere Application Server - Express Version 5.1 セキュリティー
static PrintWriter out = new PrintWriter(System.out);
static SSLContext sslContext;
// Open up the KeyStore to obtain the Trusted Certificates.
// KeyStore is of type ”JKS“. Filename is ”serverAppKeys.jks“
// and password is ”myKeys“.
private static void initContext() throws Exception {
try {
Security.addProvider(new com.ibm.jsse.JSSEProvider());
KeyStore ks = KeyStore.getInstance(”JKS“);
ks.load(new FileInputStream(”serverAppKeys.jks“), ”myKeys“.toCharArray());
KeyManagerFactory kmf = KeyManagerFactory.getInstance(”IbmX509“);
kmf.init(ks, ”myKeys“.toCharArray());
TrustManagerFactory tmf = TrustManagerFactory.getInstance(”IbmX509“);
tmf.init(ks);
sslContext = SSLContext.getInstance(”SSL“);
sslContext.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);
}
catch (Exception e) {
out.println(”Failed to read serverAppKeys.jks file.“);
e.printStackTrace();
throw e;
}
}
public void doGet(HttpServletRequest q, HttpServletResponse r) {
r.setContentType(”text/html“);
String[] args = new String[1];
args[0] = getInitParameter(”port“);
// send result to the caller
try {
out = r.getWriter();
out.println(”<html>“);
out.println(”<head><title>Server JSSE Session</title></head>“);
out.println(”<body>“);
out.println(”<h1>Server JSSE Session (starting) </h1>“);
out.flush();
out.println(”<pre>“);
main(args);
out.println(”</pre>“);
out.println(”</body></html>“);
out.flush();
out.close();
}
catch (Exception e) {
out.println(”Exception in ServerJsse Servlet: “ + e.getMessage());
e.printStackTrace();
}
}//end public void doGet(...)
/* Entry point for ServerJsse as stand alone application.
* @param args no parameters required
*/
public static void main(String args[]) throws Exception {
int i, j, len, portint;
String port = ”8050“;
if ((args != null) && (args.length > 0)) {
port = args[0];
セキュリティー
151
}
portint = (new Integer(port)).intValue();
if (args.length > 1)
N = Integer.parseInt(args[0]);
if (args.length > 2)
L = Integer.parseInt(args[1]);
byte buffer[] = new byte[L];
out.println(”SERVER: started.“);
initContext();
try {
out.println(”ServerJsse: SSL server context created.“);
SSLServerSocketFactory factory = sslContext.getServerSocketFactory();
// Get and print the list of supported enabled cipher suites
String enabled[] = factory.getSupportedCipherSuites();
out.println(”ServerJsse: enabled cipher suites“);
for (i=0; i < enabled.length; i++)
out.println(enabled[i]);
out.flush();
// Create an SSL session over port 8050
SSLServerSocket ssl_server_sock =
(SSLServerSocket)factory.createServerSocket(portint);
SSLSocket ssl_sock;
InputStream istr;
OutputStream ostr;
long t;
while (buffer[0] != -1) {
for (int n=0; n<R; n++) {
try {
ssl_sock = (SSLSocket)(ssl_server_sock.accept());
ssl_sock.setEnabledCipherSuites(enabled);
ssl_sock.startHandshake();
SSLSession session = ssl_sock.getSession();
out.println(” “);
out.println(”¥nServerJsse: SSL connection established“);
out.println(”
cipher suite:
“ + session.getCipherSuite());
}
catch (IOException se) {
out.println(”ServerJsse: client connection refused¥n“ + se);
break;
}
if (L > 0) {
istr = ssl_sock.getInputStream();
ostr = ssl_sock.getOutputStream();
t = System.currentTimeMillis();
for (j=0;j<N;j++) {
for (len = 0;;) {
try {
if ((i = istr.read(buffer, len, L-len)) == -1) {
out.println(”ServerJsse: connection dropped by partner.“);
ssl_sock.close();
return;
}
}
catch (InterruptedIOException e) {
152
WebSphere Application Server - Express Version 5.1 セキュリティー
out.println(”waiting“);
continue;
}
if ((len+=i) == L) break;
}
ostr.write(buffer, 0, L);
}
out.println(”Messages = “ + N*2 + ”; Time = “ +
(System.currentTimeMillis() - t));
}
ssl_sock.close();
}
}
ssl_server_sock.close();
out.println(”ServerJsse: SSL connection closed.“);
out.flush();
Thread.sleep(1000);
// Example using plain sockets
if (L > 0) {
ServerSocket server_sock = new ServerSocket(portint);
Socket sock = server_sock.accept();
out.println(” “);
out.println(”¥nServerJsse: Plain Socket connection accepted.“);
istr = sock.getInputStream();
ostr = sock.getOutputStream();
t = System.currentTimeMillis();
for (j=0;j<N;j++) {
for (len = 0;;) {
if ((i = istr.read(buffer, len, L-len)) == -1) {
out.println(”ServerJsse: connection dropped by partner.“);
return;
}
if ((len+=i) == L) break;
}
ostr.write(buffer, 0, L);
}
out.println(”Messages = “ + N*2 + ”; Time = “ +
(System.currentTimeMillis() - t));
sock.close();
server_sock.close();
out.println(”ServerJsse: Plain Socket connection closed.“);
Thread.sleep(1000);
}
}
catch (IOException e) {
e.printStackTrace();
}
catch (InterruptedException f) {
f.printStackTrace();
}
out.println(” “);
out.println(”ServerJsse: terminated.“);
out.flush();
}//end main(...)
}//end class
WebSphere Application Server - Express および LDAP サーバー間の SSL 接続の構成:
1. LDAP サーバーで SSL を構成する。使用する LDAP サーバーによって、手順は異なります。詳しく
は、ご使用のサーバーに関する資料を参照してください。 i5/OS ディレクトリー・サービスを使用して
いる場合は、 iSeries Information Center でディレクトリー・サービスの資料を参照してください。
v V5R2の場合
セキュリティー
153
v V5R3 の場合
v V5R4 の場合
2. WebSphere Application Server - Express トラスト・ストア・ファイルを更新する。トラスト・ストア・
ファイルは、WebSphere サーバーのトラスト・ベースのリポジトリーです。これは、SSL 初期化中に
LDAP サーバーを認証する必要があるので、トラスト・ストア・ファイルは、LDAP サーバーに関する
情報を提供しなければなりません。
LDAP サーバーの証明書を妥当性検査するためには、サーバーに、LDAP サーバーの証明書を発行した
CA の公開鍵が必要です。この鍵は、その CA の証明書で見つかるので、CA 証明書をサーバー上のト
ラスト・ストア・ファイルに追加する必要があります。
トラスト・ストア・ファイルに証明書をさらに追加するには、以下のようにします。
a. LDAP サーバーの証明書を発行した CA の証明書を取得する。例えば、LDAP サーバーの証明書
が、iSeries システム上のローカル CA によって発行された場合は、以下のディジタル証明書マネー
ジャー (DCM) を使用して、ローカル CA の証明書を抽出します。
1)
131 ページの『ディジタル証明書マネージャーの始動』。
注: ご使用の iSeries システムにインストールしている DCM のリリースにより手順は異なりま
す。このトピックで使用している DCM のリリースは V5R1M0 です。
2) 左側のペインで、「PC への CA 証明書のインストール (Install CA certificate on your PC)」
をクリックする。
3) 右側のペインで、「証明書のコピーおよび貼り付け (Copy and paste certificate)」をクリックす
る。
4) PC 上でテキスト・ファイルを作成してから、CA 証明書を myLocalCA.txt に貼り付け、そのフ
ァイルを保管する。 CA 証明書のコピーは、必ず改行文字で終了するようにしてください。
5) 「完了 (Done)」ボタンをクリックする。
b. CA 証明書をサーバーのトラスト・ストア・ファイルに追加する。
1) ワークステーション上で iKeyman を開始する。詳しくは、 134 ページの『iKeyman ユーティリ
ティー』を参照してください。
2) 「鍵データベース・ファイル (Key Database File)」をクリックして、「開く (Open)」を選択
する。
3) ブラウザーを使用して、WebSphere サーバー・インスタンスのトラスト・ストア・ファイルが
入ったディレクトリーに移動し、そのファイルをオープンする。例えば、
USER_INSTALL_ROOT/etc/DummyServerTrustFile.jks のようになります。
4) 「個人証明書 (Personal Certificates)」をクリックして、「署名者証明書 (Signer Certificates)」
を選択する。
5) 「追加」をクリックする。
6) 以下の設定値を指定する。
v Data Type (データ型): Base64 エンコード ASCII データ
v Certificate file name (証明書ファイル名): myLocalCA.txt
v Location (位置): myLocalCA.txt が入ったディレクトリーへのパス
7) 「OK」をクリックする。
8) ラベルに LocalCA と入力して、「OK」をクリックする。
9) 「鍵データベース・ファイル (Key Database File)」をクリックする。
154
WebSphere Application Server - Express Version 5.1 セキュリティー
10) 「終了 (Exit)」を選択する。
3. WebSphere で SSL 接続を使用可能にする。 WebSphere 管理コンソールを使用して、 LDAP 構成
(「セキュリティー (Security)」―>「ユーザー・レジストリー (User Registries)」―>「LDAP」の下に
あります) を変更します。
v ポートを 636 に設定する。 (異なるポート番号を使用した場合は、ポートをその番号に設定する。)
v 「使用可能な SSL (SSL Enabled)」を選択する。
v 「DefaultSSLSettings」を選択する。
4. 「OK」をクリックする。
5. 変更を保管する。
6. アプリケーション・サーバーを停止して再始動してから、管理コンソールを始動する。 LDAP レジス
トリーにログインするように指示するプロンプトが出されます。
ヒント
SSL 接続が機能しない場合は、以下のことを行ってみてください。
v LDAP サーバーがポート 636 (または、設定で指定されているその他のポート) に対して listen してい
るかどうか検査する。
v LDAP サーバーの証明書がまだ有効であるかどうか検査する。
v LDAP サーバーの CA の証明書を鍵リングまたはファイルのその他のタイプのファイルからエクスポー
トする必要がある場合、 DER バイナリー形式または Base64 エンコード ASCII で証明書をエクスポー
トするオプションを探す。ツールは、LDAP サーバーによって異なる可能性があります。
v FTP (ファイル転送プロトコル) を使用して証明書ファイルをリモート・ホストから転送する場合は、転
送モードを必ずバイナリーに設定する。
Java 2 セキュリティーの構成
Java 2 セキュリティーは、きわめて高い普及性を備え、アプリケーション開発に多大な影響を与える新し
いプログラミング・モデルです。詳しくは、 157 ページの『Java 2 セキュリティー』を参照してくださ
い。
Java 2 セキュリティーは、デフォルトでは使用不可になっていますが、グローバル・セキュリティーが使
用されると自動的に使用可能な状態になります。ただし、J2EE 役割ベース・セキュリティーとは独立して
いるため、グローバル・セキュリティーと J2EE 役割ベース・セキュリティーはそれぞれ別個に使用可能
または使用不能にすることができます。 Java 2 セキュリティーには、J2EE 役割ベース認証機能だけでな
く、アクセス制御保護機能もあります。特に、システム・リソースや API を保護する機能です。 Java 2
のリリース以後、Java 開発キットは、機密性の高い API (Java 仮想マシンを終了させるための API など)
やリソースを利用する API (例えば、ファイルを開いて読み取りや書き込みを行う API など) を保護する
ために Java 2 セキュリティーを使用しています。
注: Java 2 セキュリティーは、Java 2 セキュリティーが使用可能な Java 仮想マシン内で実行される Java
プログラムを制限するだけです。 Java 2 セキュリティーが使用不能になっている場合や、システム・リソ
ースが他のプログラムやコマンドからアクセスされる場合には、システム・リソースを保護しません。した
がって、iSeries システム・リソースを保護したい場合には、iSeries セキュリティーを使用する必要があり
ます。
どのようなときに Java 2 セキュリティーを使用すべきかについて、以下にガイドラインをいくつか示しま
す。
セキュリティー
155
v システム・リソースの保護を使用可能にするとき。例えば、ソケット接続のオープンや受信監視を行う
ときや、オペレーティング・システムのファイル・システムを読み書きするとき、Java 仮想マシンのシ
ステム・プロパティーを読み書きするときなど。
v アプリケーション・コードによる破壊的な API の呼び出しを防ぎたいとき。例えば、System.exit() を呼
び出すと、アプリケーション・サーバーがダウンします。
v アプリケーション・コードが権限情報 (パスワード) や追加権限 (サーバー証明書) を取得することを防
ぎたいとき。
テスト環境もしくは実稼働環境において Java 2 セキュリティーを容易に使用可能にできるよう、Java 2
セキュリティー・プログラミング・モデルに基づいてアプリケーションを開発してください。開発者は、ア
プリケーション内で使用される API が Java 2 セキュリティーによって保護されるかどうかを知っていな
ければなりません。きわめて重要なことは、使用される API に必要な許可をポリシー・ファイル
(was.policy) で宣言しておくということです。さもなければ、Java 2 セキュリティーが使用可能な状態にな
っても、アプリケーションは実行できません。was.policy および他の Java 2 セキュリティー・ポリシー・
ファイルに関する詳細については、 161 ページの『Java 2 ポリシー・ファイルの構成』を参照してくださ
い。
アプリケーションに設定されているデフォルト許可セットは、J2EE 1.3 の仕様で定義されている推奨許可
セットです。すべてのユーザーに許可を与える Java 開発キット java.policy ファイル内に定義されている
許可に加えて、デフォルト値が、app.policy ポリシー・ファイル内で宣言されています。ただし、
filter.policy ファイル内で宣言されている許可は、アプリケーションに与えられません。filter.policy ファイ
ル内で宣言されている許可は、許可検査の際に除外されてアプリケーションには渡されません。
アプリケーションに必要な許可を was.policy ファイル内で定義して、META-INF サブディレクトリーにあ
るアプリケーション EAR ファイルにその was.policy ファイルを組み込んでください。
ポリシー・ファイルの詳細については、 161 ページの『Java 2 ポリシー・ファイルの構成』を参照してく
ださい。
Java 2 セキュリティーを使用可能にするには、管理コンソールで以下のステップを実行します。
v ナビゲーション・メニューで、「セキュリティー (Security)」を開きます。「グローバル・セキュリティ
ー (Global Security)」をクリックします。「グローバル・セキュリティー (Global Security)」ページが現
れます。
v 「Java 2 セキュリティーの実行 (Enforce Java 2 Security)」を選択することによって、Java 2 セキュリ
ティーを使用可能にします。
v 「グローバル・セキュリティー (Global Security)」ページで「OK」または「適用 (Apply)」をクリック
します。
v 「保管 (Save)」をクリックして変更を保管します。
v サーバーを再始動して、変更を有効にします。
これで、Java 2 セキュリティーが使用可能になり、各サーバーに対して実行されます。 Java 2 セキュリ
ティーで保護された API が呼び出されると、Java 2 セキュリティー許可がチェックされます。
Java 2 セキュリティーのトレース
WebSphere Java 2 Security Manager には、アプリケーションがリソースへのアクセスを拒否された場合
(つまり、 java.security.AccessControlException 例外がスローされたとき) に、セル・スタック上の全クラス
に与えられている Java 2 セキュリティー許可をダンプするという機能が追加されています。ただし、デフ
ォルトでは、このトレース機能は使用不可になっています。この機能は、
156
WebSphere Application Server - Express Version 5.1 セキュリティー
com.ibm.ws.security.core.SecurityManager=all=enabled というトレースの指定にサーバー・トレース・
サービスの指定を付け加えることによって使用可能な状態にできます。上記の例外がスローされた場合、ト
レース・ダンプを調べれば、Java 2 で保護されたリソースにアクセスできなかった原因が、アプリケーシ
ョンの許可不足にあるのか、プロダクト・ランタイム・コードにあるのか、あるいは使用したサード・パー
ティー・ライブラリーが特権のあるライブラリーとして正しくマークされていなかったことにあるのかを判
断できます。
Java 2 セキュリティー: Java 2 セキュリティーは、WebSphere Application Server - Express でサポート
される機能です。Java 2 セキュリティーは、特定の保護システム・リソースへのアクセスを許可する前に
アクセス権をチェックすることによりシステム全体の保全性を高める、ポリシー・ベースのきめ細かいアク
セス制御機構を提供します。Java 2 セキュリティーは J2EE 役割ベースの権限から独立しています。Java
2 セキュリティーが、ファイルの入出力、ソケット、プロパティーなどのシステム・リソースへのアクセス
を保護するのに対して、J2EE セキュリティーは、サーブレット、JSP ファイルなどの Web リソースへの
アクセスを保護します。WebSphere のグローバル・セキュリティーには、J2EE 役割ベースの認証、CSIv2
認証プロトコル、SSL 構成が含まれます。 Java 2 セキュリティーは、WebSphere グローバル・セキュリ
ティーとは無関係に使用可能または使用不可にすることができます (「Global Security (グローバル・セキ
ュリティー)」パネルまたは「Server Level Security (サーバー・レベル・セキュリティー)」パネルの
「Enforce Java 2 Security (Java 2 セキュリティーの実行)」チェック・ボックス)。ただし、WebSphere
グローバル・セキュリティーが使用可能な場合、デフォルトで Java 2 セキュリティーも使用可能になりま
す。WebSphere グローバル・セキュリティーが使用可能でも、Java 2 セキュリティーを使用不可にできる
ことに留意してください。
Java 2 セキュリティーは業界および WebSphere において比較的新しい機能なので、多くの既存アプリケー
ションや新規のアプリケーションでさえも、Java 2 セキュリティーが実行できる非常にきめ細かいアクセ
ス制御プログラミング・モデルに対応しない場合があります。アプリケーションが Java 2 セキュリティー
に対応していない場合、管理者は Java 2 セキュリティーの使用可能化がもたらす考えられる結果を理解す
る必要があります。Java 2 セキュリティーにより、アプリケーション開発者や管理者に新たな要件が課せ
られます。
配置者と管理者のための Java 2 セキュリティー
Java 2 セキュリティーを使用可能にする前に、すべてのアプリケーションに必要な権限が付与されている
ことを確認する必要があります。付与されていないと、アプリケーションの実行に失敗する場合がありま
す。デフォルトで、アプリケーションには J2EE 1.3 仕様で推奨される権限が付与されます。WebSphere
で付与されるデフォルトの権限の詳細については、以下のポリシー・ファイルを参照してください。
v /QIBM/ProdData/Java400/jdk14/lib/security/java.policy
v /QIBM/UserData/WebASE51/ASE/instance/properties/server.policy
v /QIBM/UserData/WebASE51/ASE/instance/config/cells/cell/nodes/node/app.policy
ここで、instance はインスタンスの名前、cell はセルの名前、node はノードの名前です。
WebSphere Application Server - Express では、これらのポリシー・ファイルに含まれるデフォルトのポリシ
ーよりも制限的なポリシーをサポートしません。これは、WebSphere には必要な Java 2 セキュリティー
doPrivileged API が適所にないためです。デフォルトのポリシーをより制限的にしようとすると、
WebSphere は Java 2 セキュリティー・アクセス制御例外をスローし、アプリケーションまたは
WebSphere Application Server - Express 自体に予期しない障害が発生します。
セキュリティー
157
Java プロセスのセキュリティー・ポリシーを定義するために、いくつかのポリシー・ファイルが使用され
ます。一部のポリシー・ファイルは静的です (コード・ベースがポリシー・ファイル内で静的に定義されま
す)。静的ポリシー・ファイルの例としては、Java 開発キットに用意されている java.policy ファイルが挙
げられます。
それ以外のポリシー・ファイルは動的です。WebSphere では、静的および動的ポリシー・ファイルの両方
をサポートします。動的ポリシー・ファイルは、エンタープライズ・アプリケーション、リソース、および
ユーティリティー・ライブラリーとともに使用します。動的ポリシー・ファイルでは、コードベースが (配
置情報に基づいて) 動的に計算され、アクセス権が (テンプレート・ポリシー・ファイルに基づいて) 実行
時に付与されます。
ポリシー・ファイルの詳細については、 161 ページの『Java 2 ポリシー・ファイルの構成』を参照してく
ださい。
アプリケーションが Java 2 セキュリティーに対応しない場合、アプリケーション・プロバイダーがアプリ
ケーションの一部として was.policy ファイルを提供しない場合、あるいはアプリケーション・プロバイダ
ーが WebSphere ポリシー・ファイルの 1 つに付与するべきアクセス権を伝達しない場合、アプリケーシ
ョンは実行時に Java 2 セキュリティー・アクセス制御例外を引き起こしやすくなり (WebSphere で Java
2 セキュリティーが使用可能になっている場合)、多くの場合は正しく実行しません。
アプリケーションが Java 2 セキュリティーに対応するかどうか、明らかではないことがあります。
WebSphere では、Java 2 セキュリティー関連のアクセス制御例外が発生する可能性があるアプリケーショ
ンのトラブルシューティングを判断するのに役立つ、実行時のデバッグ援助機能をいくつか用意していま
す。
アプリケーション開発者のための Java 2 セキュリティー
アプリケーション開発者は、デフォルトの WebSphere ポリシーに付与されているアクセス権と、Java SDK
API のアクセス権要件を把握する必要があります。また、アプリケーションが呼び出す API に追加アクセ
ス権が必要かどうかを知る必要があります。Java API にアクセス権が必要かどうかの詳細については、
『Java 2 SDK 上のアクセス権 (Permissions in the Java 2 SDK)』
(http://java.sun.com/j2se/1.3/docs/guide/security/permissions.html) を参照してください。
アプリケーション・プロバイダーは、アプリケーションにデフォルトのポリシーで必要なアクセス権が付与
されていると想定する場合があります。デフォルトの WebSphere ポリシーでカバーされないリソースを使
用するアプリケーションには、追加の Java 2 セキュリティー・アクセス権を付与する必要があります。
was.policy 以外の動的 WebSphere ポリシー・ファイルの 1 つ、または java.policy などの従来の静的ポリ
シー・ファイルの 1 つでは、アプリケーションに追加アクセス権を付与することができる一方で、
was.policy ファイル (EAR ファイル内にあります) は、追加アクセス権が確実にそれらを必要とするアプリ
ケーションに向けられているか確認します。アクセス権を必要とするアプリケーション・コードにアクセス
権が向けられている場合、通常は保護リソースを使用するためのアクセス権を持たないアプリケーション・
コードには、そのアクセス権は付与されません。
アプリケーションのコンポーネント (ライブラリーなど) が複数の EAR ファイル内に組み込まれている場
合、ライブラリー開発者は、アプリケーション・アセンブラーに必要な Java 2 アクセス権を文書化する必
要があります。ライブラリー・タイプのコンポーネントには was.policy タイプのファイルがないので、開
発者は外部文書によって必須アクセス権を伝達しなければなりません。コンポーネント・ライブラリーが複
数のエンタープライズ・アプリケーションで共有されている場合、app.policy によってノード上のすべての
エンタープライズ・アプリケーションにアクセス権を付与することができます。
158
WebSphere Application Server - Express Version 5.1 セキュリティー
アクセス権がコンポーネント・ライブラリーによって内部でのみ使用され、アプリケーションがアクセス権
で保護されるリソースへのアクセスを決して許可されない場合、コードに特権があるとマークする必要があ
ります (doPrivileged ブロックを挿入します)。(詳しくは、 174 ページの『AccessControlException』を参照
してください。) ただし、doPrivileged ブロックを正しく挿入しないとセキュリティー・ホールができる場
合があるので、doPrivileged ブロックを使用するかどうかを判断する際には十分な注意と理解が必要です。
実行時に was.policy ファイルのアクセス権が付与される方法の詳細については、 169 ページの『was.policy
ファイルの構成』を参照してください。
Java 2 セキュリティーを考慮してアプリケーションを開発することは新しいスキルであり、以前はアプリ
ケーション開発者に必要なかったセキュリティー認識を要します。Java 2 セキュリティー・モデルおよび
アプリケーション開発の含意については、このセクションでは説明しません。詳しくは、『J2SDK 1.3 セ
キュリティー文書 (The J2SDK 1.3 Security documentation)』
(http://java.sun.com/j2se/1.3/docs/guide/security/index.html) を参照してください。
デバッグ援助機能
Java 2 セキュリティーのデバッグには、2 つの主要な援助機能があります。
v WebSphere SystemOut.log ファイル
AccessControl 例外は SystemOut.log に記録されます。このファイルには、例外を引き起こすアクセス権
違反、例外呼び出しスタック、各スタック・フレームに付与されるアクセス権が含まれます。この情報
は、通常、欠如しているアクセス権やアクセス権が必要なコードを判断するのに役立ちます。
v com.ibm.websphere.java2secman.norethrow プロパティー
Java 2 セキュリティーが WebSphere で使用可能になっている場合、アクセス権違反が発生すると、デ
フォルトでセキュリティー・マネージャー・コンポーネントが java.security.AccessControl 例外をスロー
します。この例外が処理されないと、ランタイム障害が発生する場合があります。(この例外は
SystemOut.log にも記録されます。) ただし、com.ibm.websphere.java2secman.norethrow プロパティーが
true に設定されている場合、セキュリティー・マネージャーは AccessControl 例外をスローせずにそれ
を記録します。
注: このプロパティーは、セキュリティー・マネージャーが例外をスローしないよう指示するので、セキ
ュリティー・マネージャーは技術的には Java 2 セキュリティーを実行していません。非スロー・プロパ
ティーは、実稼働環境では使用しないでください。
このプロパティーは、アプリケーションが完全にテストされ、SystemOut.log で AccessControl 例外が検
査される、サンドボックスまたはテスト環境において有用です。このプロパティーはスローされない
AccessControl 例外を発生させるので、例外は呼び出しスタックに伝搬されず、障害を引き起こしませ
ん。このプロパティーを使用しない場合、AccessControl 例外を一度に 1 つずつ検索および修正する必要
があります。
サーバーの com.ibm.websphere.java2secman.norethrow プロパティーを設定するには、管理コンソールで以
下のステップを行います。
1. 「サーバー 」―>「アプリケーション・サーバー (Application Servers)」をクリックします。ご使用
のアプリケーション・サーバーの名前をクリックします。
2. 「追加プロパティー (Additional Properties)」の下で、「プロセス定義 (Process Definition)」―
>「Java 仮想マシン (Java Virtual Machine)」―>「カスタム・プロパティー (Custom Properties)」
―>「新規」をクリックします。
3. 「名前」フィールドに、 com.ibm.websphere.java2secman.norethrow と入力します。
セキュリティー
159
4. 「値」フィールドに、true と入力します。
5. 構成を保管します。
Java 2 セキュリティーを作動不能なアプリケーションの処理
サード・パーティー・アプリケーションを使用していて、Java 2 セキュリティーが提供する増強されたシ
ステム保全性が必要な場合、アプリケーション・プロバイダーに連絡して Java 2 セキュリティーのサポー
トを要求するか、少なくとも、デフォルトの WebSphere ポリシーを上回る必要な追加アクセス権を理解し
てください。
Java 2 セキュリティーをサポートしないアプリケーションを扱う最も容易な方法は、WebSphere で Java 2
セキュリティーを使用不可にすることです。この解決策の難点はシステム全体に適用されてしまうことで、
システム保全性は本来よりも弱まります。このことは、安易に考えてはいけません。場合によっては、Java
2 セキュリティーを使用不可にするとリスクを許容することになります。
もう一つの方法は、Java 2 セキュリティーを使用可能なままにしながら、十分なだけの追加アクセス権を
付与するか、問題のあるアプリケーションのみにすべてのアクセス権を付与することです。十分なアクセス
権の数を判断するのは容易ではありません。アプリケーション・プロバイダーから必要なアクセス権を何ら
かの方法で知らされていない場合、必要なアクセス権を判断する容易な方法はありません。したがって、す
べてのアクセス権を付与するのが唯一の選択肢となります。このリスクを最小限にするには、問題のあるア
プリケーションを別のノードに配置します。こうすると、特定のリソースからアプリケーションを切り離す
ことができます。次に、アプリケーションの EAR ファイルに組み込まれている was.policy ファイルに
java.security.AllPermission を付与します。例えば、以下のようになります。
grant codeBase “file:${application}” {
permission java.security.AllPermission;
};
server.policy ファイル
このポリシーは、WebSphere クラスのポリシーを定義します。
server.policy ファイルは、サーバー・リソースの Java 2 セキュリティー・ポリシーを定義するために使用
してください。エンタープライズ・アプリケーション・リソースの場合は、ノード向けアクセス権に
app.policy ファイルを、アプリケーション向けアクセス権に was.policy ファイルを使用します。
java.policy ファイル
このファイルは、すべてのクラスに付与されるデフォルトのアクセス権を表します。このファイルのポリシ
ーは、WebSphere Application Server - Express が稼働している Java 仮想マシンによって起動されるすべて
のプロセスに適用されます。詳しくは、 173 ページの『java.policy ファイルの構成』を参照してください。
トラブルシューティング
v 症状
エラー・メッセージ SECJ0314E: 現行の Java 2 セキュリティー・ポリシーが Java 2 セキュリティ
ー・アクセス権の違反の可能性を報告しました。詳しくは、「問題判別ガイド」を参照してください。
{0}Permission¥:{1}Code¥:{2}{3}Stack Trace¥:{4}Code Base Location¥:{5}
v 問題
Java セキュリティー・マネージャー checkPermission() が、サブジェクト・アクセス権における
SecurityException をデバッグ情報とともに報告しました。報告された情報は、システム構成によって異な
160
WebSphere Application Server - Express Version 5.1 セキュリティー
ります。この報告は、RAS トレースをデバッグ・モードに構成することによって使用できます。詳しく
は、『トラブルシューティング』トピックの『トレース・サービスを使用可能または使用不可にする』
を参照してください。
v 推奨される応答
報告された例外は、保護システムにとって重大である場合があります。セキュリティー・トレースをオ
ンにして、セキュリティー・ポリシーに違反している可能性のあるコードを判別します。違反コードを
判別したら、該当するすべての Java 2 セキュリティー・ポリシー・ファイルおよびアプリケーション・
コード自体を調べて、試行された操作が (Java 2 セキュリティーに関して) 許可されるかどうか検証す
る必要があります。
注: アプリケーションが Java Mail を使用している場合、このメッセージは問題ない可能性がありま
す。was.policy ファイルを更新して、アプリケーションに以下のアクセス権を付与することができます。
permission
permission
permission
permission
java.io.FilePermission
java.io.FilePermission
java.io.FilePermission
java.io.FilePermission
“${user.home}${/}.mailcap”, “read”;
“${user.home}${/}.mime.types”, “read”;
“${java.home}${/}lib${/}mailcap”, “read”;
“${java.home}${/}lib${/}mime.types”, “read”;
注: アプリケーションが ClassLoader クラスの getResourceAsStream(foo) メソッドを使用している場合
(ここで、foo はファイル名)、このメッセージは問題ない可能性があります。was.policy ファイルを更新
して、アプリケーションに以下のアクセス権を付与することができます (または、app.policy ファイルを
更新して、ノード上のすべてのアプリケーションにアクセス権を付与することができます)。
permission java.io.FilePermission “/QIBM/ProdData/Java400/foo”, “read”;
メッセージ
v メッセージ: SECJ0313E: Java 2 セキュリティー・マネージャーのデバッグ・メッセージ・フラグが初期
化されます。TrDebug: {0}、Access: {1}、Stack: {2}、Failure: {3}
問題: セキュリティー・マネージャーに有効なデバッグ・メッセージ・フラグの値が構成されました。
推奨される応答: なし
v メッセージ: SECJ0307E: コード・ベース・ロケーションの判別を試行時に、予期しない例外をキャッチ
しました。例外: {0}
問題: コード・ベース・ロケーションを判別しようとして、予期しない例外をキャッチしました。
推奨される応答: IBM 担当員に連絡してください。
Java 2 ポリシー・ファイルの構成: J2EE 1.3 仕様は、コンテナー・プロバイダーとアプリケーション・
コード間の責任について明確に定義されたプログラミング・モデルです。Java 2 Security Manager を使用
して、このプログラミング・モデルの実行を支援することをお勧めします。特定の操作はコンテナーの動作
や操作と干渉するために、アプリケーション・コードで使用できない操作があります。Java 2 Security
Manager は、コンテナーとアプリケーション・コードの責任分担を施行するために製品で使用されます。
WebSphere Application Server - Express は、ポリシー・ファイルの管理をサポートします。製品には、静的
または動的のいくつかのポリシー・ファイルが存在します。静的ポリシー・ファイルには、デフォルトのア
クセス権が用意されています。動的ポリシー・ファイルは、特定リソース・タイプのアクセス権のテンプレ
ートです。一部の動的ポリシー・ファイルでは相対ファイル・パスを使用できます。アプリケーションが配
置されるときに、絶対パスが解決されます。詳しくは、 163 ページの『ポリシー・ファイルの構文』を参照
してください。
動的ポリシー・ファイル
次のファイルには、アプリケーションに関するアクセス権が用意されています。
セキュリティー
161
v app.policy
このファイルには、セル内のすべてのエンタープライズ・アプリケーションに関するデフォルトのアク
セス権が設定されています。詳しくは、 168 ページの『app.policy ファイルの構成』を参照してくださ
い。
v was.policy
このファイルには、WebSphere Application Server - Express エンタープライズ・アプリケーションに関
するアプリケーション固有のアクセス権が設定されています。このファイルは、EAR ファイル内にパッ
ケージされています。詳しくは、 169 ページの『was.policy ファイルの構成』を参照してください。
v ra.xml
このファイルには、特定の WebSphere Application Server - Express エンタープライズ・アプリケーショ
ンに関するコネクター固有のアクセス権が設定されています。このファイルは、RAR ファイル内にパッ
ケージされています。
v spi.policy
このファイルには、WebSphere Application Server - Express に組み込まれているサービス・プロバイダ
ー・インターフェース (SPI) またはサード・パーティー・リソースに関するアクセス権が設定されてい
ます。詳しくは、 170 ページの『spi.policy ファイルの構成』を参照してください。
v library.policy
このファイルには、エンタープライズ・アプリケーションで共用される Java ライブラリー・クラスに関
するアクセス権が設定されています。デフォルトでは、このファイルは空です。詳しくは、 171 ページ
の『library.policy ファイルの構成』を参照してください。
v filter.policy
このファイルには、セル内の was.policy および app.policy ファイルからフィルターに掛けられたアクセ
ス権のリストが含まれています。このフィルター・メカニズムは、was.policy と app.policy にのみ適用
されます。詳しくは、 171 ページの『filter.policy ファイルの構成』を参照してください。
静的ポリシー・ファイル
次のファイルには、デフォルトのアクセス権が用意されています。アプリケーション・レベルを超えたアク
セス権が必要な場合、静的ポリシー・ファイルを更新する必要があることがあります。静的ポリシー・ファ
イルは、WebSphere リポジトリーおよびファイル複製サービスで管理される構成ファイルでないことに注
意してください。これらのファイルの変更はローカルで、他のマシンに複製されません。
v java.policy
このファイルには、ノードの Java 仮想マシンで実行されるすべての Java プログラムに関するデフォル
トのアクセス権が設定されています。 (iSeries では、このファイルは IBM Development Kit for Java に
付属しています。)デフォルトでは、アクセス権はすべての Java クラスに付与されています。このファ
イルはすべての JVM プロセスに関するアクセス権を表すので、絶対に必要でない限り、この内容を変
更しないでください。詳しくは、 173 ページの『java.policy ファイルの構成』を参照してください。
v server.policy
このファイルには、ノード上のすべての WebSphere Application Server - Express プログラムに関するデ
フォルトのアクセス権が設定されています。デフォルトでは、アクセス権はすべての製品サーバーに付
与されています。このファイルはすべてのサーバー・プロセスに関するアクセス権を表すので、絶対に
必要でない限り、この内容を変更しないでください。詳しくは、 174 ページの『server.policy ファイルの
構成』を参照してください。
Java 2 セキュリティー・ポリシー・ファイルを編集する場合、次のようないくつかの考慮事項がありま
す。
162
WebSphere Application Server - Express Version 5.1 セキュリティー
v Signed By キーワードは、ポリシー・ファイル app.policy、spi.policy、library.policy、was.policy、および
filter.policy ではサポートされていません。しかし、Signed By キーワードは、java.policy および
server.policy ポリシー・ファイルでサポートされています。
v Java 認証および許可サービス (JAAS) principal キーワードは、
app.policy、spi.policy、library.policy、was.policy、および filter.policy ファイルではサポートされていませ
ん。ただし、JAAS principal キーワードは、Java 仮想マシン (JVM) システム・プロパティー
java.security.auth.policy によって指定されている場合、JAAS ポリシー・ファイルでサポートされて
います。auth.policy.url.n=URL で、java.security.auth.policy の権限ポリシー・ファイルを静的に
設定することができます。ここで、n は整数、URL は権限ポリシーのロケーションです。
v 静的ポリシー・ファイルはアプリケーション・レベルを超えてアクセス権を付与するので、静的ポリシ
ー・ファイルではなく動的ポリシー・ファイルを更新することをお勧めします。
v ポリシー・ファイルを編集して必要なアクセス権を追加する場合、有効範囲が最小のポリシーを使用す
ることをお勧めします。こうすると、アプリケーションに不要なアクセス権を付与することを避けるこ
とができ、リソースを適切に保護できます。例えば、app.policy ファイル (セル内のすべてのアプリケー
ションに関するアクセス権を定義) でなく ra.xml かまたは was.policy ファイル (これらのファイルは単
一アプリケーションのアクセス権を定義) を更新します。
v ${application} シンボルではなく、${webComponent}、${connectorComponent}、および ${jars} など
の特定のコンポーネント・シンボルを使用します。
v セル内の WebSphere Application Server - Express エンタープライズ・アプリケーションにいかなる場合
でも付与すべきでないアクセス権がある場合は、このアクセス権を filter.policy ファイルに追加します。
v 動的ポリシー・ファイルを変更したら、エンタープライズ・アプリケーションを再始動します。
v 静的ポリシー・ファイルを変更したら、アプリケーション・サーバーを再始動します。
トラブルシューティング
セル内の WebSphere Application Server エンタープライズ・アプリケーションがアクセス権を必要とする場
合、動的ポリシー・ファイルの一部を更新する必要がある可能性があります。アクセス権が不足すると、
java.security.AccessControlException が発生します。詳しくは、 174 ページの『AccessControlException』を参
照してください。
欠如しているアクセス権は、例外データにリストされます。例えば、以下のようになります。
java.security.AccessControlException: access denied
(java.io.FilePermission /QIBM/ProdData/WebASE51/ASE/java/ext/mail.jar read)
Java プログラムがこの例外を受け取り、このアクセス権の追加が正当である場合は、アクセス権を適切な
動的ポリシー・ファイルに追加します。例えば、以下のようにします。
grant codeBase “file:${application}” {
permission java.io.FilePermission
“/QIBM/ProdData/WebASE51/ASE/java/ext/mail.jar”, “read”;
};
ポリシー・ファイルの構文: このトピックでは、WebSphere Application Server - Express でサポートされ
る Java 2 セキュリティー・ポリシー・ファイルの構文について説明します。
ポリシー・ファイルの構文
ポリシー・ファイルには複数のポリシー・エントリーが含まれています。各ポリシー・エントリーの形式に
は、次のような特定の様式があります。
セキュリティー
163
grant [codebase Codebase] {
permission Permission;
permission Permission;
permission Permission;
};
ここでは、下記の変数が使用されます。
v Codebase
これは URL です。例: “file:${java.home}/../lib/tools.jar”
使用法:
– [codebase Codebase] が指定されていない場合には、リストされた許可がすべてに適用されます。
– URL が JAR ファイル名で終了する場合には、JAR ファイル内のクラスのみが codebase に属しま
す。
– URL が “/” で終了する場合には、指定のディレクトリー内のクラス・ファイルのみが codebase に属
します。
– URL が “*” で終了する場合には、指定のディレクトリー内のすべての JAR およびクラス・ファイル
が codebase に属します。
– URL が “-” で終了する場合には、指定のディレクトリーおよびそのサブディレクトリー内のすべて
の JAR およびクラス・ファイルが codebase に属します。
注: app.policy および was.policy ファイルで指定されている grant 項目には、定義済みのコード・ベー
スがなければなりません。コード・ベースのない grant 項目を指定すると、ポリシー・ファイルのロー
ドが適切に行われず、アプリケーションが失敗することがあります。すべてのアプリケーションに許可
を付与するのであれば、grant 項目のコード・ベースとして file:${application} を使用してくださ
い。
v Permission
permission は、以下の情報部分で定義されます。
– permission タイプ。permission のクラス名です。
– ターゲット名。ターゲットを指定します。
– アクション。ターゲット上での実行が許可されたアクションを指定します。
以下に、permission エントリーの例を示します。java.io.FilePermission “/tmp/xxx”, “read,write”。
permission について詳しくは、「Java 2 SDK における許可 (Permissions in the Java 2 SDK)」
(http://java.sun.com/j2se/1.3/docs/guide/security/permissions.html) を参照してください。
ダイナミック・ポリシー・ファイルの構文
エンタープライズ・アプリケーションでは、指定のタイプのリソースに対する許可をダイナミック・ポリシ
ー・ファイルに定義することができます。この定義は、ポリシー・ファイルで製品予約のシンボルを使用し
て行います。
予約シンボルのスコープは、それが定義されるところによって異なります。許可を app.policy ファイルに
定義する場合、シンボルは、ノードで稼働するエンタープライズ・アプリケーションのすべての上にあるリ
ソースすべてに適用されます。許可をお使いのアセンブル済みアプリケーション内の META-INF/was.policy
ファイルで許可を定義する場合には、指定のエンタープライズ・アプリケーションにのみ適用されます。
以下のリストには、codebase エントリーで有効なシンボルが含まれています。
164
WebSphere Application Server - Express Version 5.1 セキュリティー
v file:${application}
許可はアプリケーション内のすべてのリソースに適用されます。
v file:${jars}
許可はアプリケーション内のすべてのユーティリティー JAR ファイルに適用されます。
v file:${webComponent}
許可はアプリケーション内の Web リソースに適用されます。
v file:${connectorComponent}
許可はアプリケーション内およびスタンドアロン・コネクター・リソース内両方のコネクター・リソー
スに適用されます。
より一般の設定では、特定のモジュール名を指定できます。例えば、次のようにします。
grant codebase “file:DefaultWebApplication.war” {
permission java.security.SecurityPermission “printIdentity”;
};
grant codebase “file:IncCMP11.jar” {
permission java.io.FilePermission
“${user.install.root}${/}bin${/}DefaultDB${/}-”, “read,write,delete”;
};
相対コードベースは、was.policy ファイル内でのみ使用することができます。
java.io.FilePermission のパスおよび名前を指定する、組み込みシンボルが提供されています。これらのシン
ボルで、よりフレキシブルな許可を指定することができます。絶対ファイル・パスは、アプリケーションの
インストール後でないと、修正されません。
以下は、サポートされている組み込みシンボルです。
v ${app.installed.path}
アプリケーションがインストールされているパス。
v ${was.module.path}
モジュールがインストールされているパス。
v ${current.cell.name}
現行のセル名。
v ${current.node.name}
現行のノード名。
v ${current.server.name}
現行のサーバー名。
注: ${was.module.path} シンボルは ${application} エントリーでは使用できません。
新規の許可を追加する場所は慎重に判別してください。許可の指定を不適切に行うと、
AccessControlException 例外が生じる原因になります。DynamicPolicy はランタイムにコードベースを解決
するため、どのポリシー・ファイルに問題があるのかを判別することは困難です。許可の追加は、必要なリ
ソースのみに行ってください。例えば、${webComponent} (${application} ではなく) を使用します。ま
た、可能であれば、(app.policy ファイルではなく) was.policy ファイルを更新します。
静的ポリシーのフィルター操作
ポリシー・モデルは、一部の制限された静的ポリシー・フィルター操作をサポートします。app.policy ファ
イルおよび was.policy ファイルに、filter.policy ファイルで定義された許可がある場合、ランタイムにはア
セキュリティー
165
プリケーションから許可が除去され、監査メッセージがログに記録されます。ただし、app.policy および
was.policy で定義された許可が複合型の許可 (例: java.security.AllPermission) である場合、許可は除去され
ず、ログ・ファイルに警告メッセージが書き込まれます。ポリシーのフィルター操作は、名前が java また
は javax で始まるパッケージのみをサポートします。
より厳格なフィルター処理を行うために、ランタイム・ポリシーのフィルター・サポートが提供されていま
す。app.policy ファイルと was.policy ファイルが、キーワード runtimeFilterMask で filter.policy ファイ
ルに定義されている許可を持っている場合は、アプリケーションに認可されている許可に関係なく、このラ
ンタイムにより、その許可がアプリケーションから除去されます。例えば、was.policy ファイルが
java.security.AllPermission permission をあるモジュールに認可していたとしても、指定した許可
(runtimeFilterMask など) は、実行中に、認可されている許可から除去されます。
管理コンソールの「グローバル・セキュリティー (Global Security)」パネルで「許可警告の発行 (Issue
Permission Warning)」が使用可能になっている場合に、app.policy ファイルおよび was.policy ファイルに
カスタム許可が含まれているときには (java または javax で始まらないパッケージの場合)、警告メッセ
ージはログインに記録され、許可は除去されません。AllPermission 許可が app.policy ファイルおよび
was.policy ファイルの両方にリストされている場合には、警告メッセージがログに記録されます。
ポリシー・ファイルの編集
ポリシー・ファイルの編集には、IBM Developer Kit for Java または Sun Microsystems Java 2 Software
Development Kit (bin サブディレクトリー内) で提供されているポリシー・ツール (policytool) を使用する
ことをお勧めします。
ポリシー・ファイルに構文エラーがある場合、エンタープライズ・アプリケーションまたはサーバー・プロ
セスが始動できない可能性があります。 これらのポリシー・ファイルの編集は慎重に行ってください。例
えば、ポリシー許可ターゲット名の中で末尾にスペースあると、ポリシーは WebSphere Application Server
内で許可を適切に構文解析することができません。次の例では、3 番目と 4 番目の引用符の間のスペース
に注意してください。
grant {
permission javax.security.auth.PrivateCredentialPermission
“javax.resource.spi.security.PasswordCredential * ¥”*¥“ ”,“read”; };
許可が、IBM Developer Kit、Java Technology Edition バージョン 1.4.x ポリシー・ツールによってロード
されたポリシー・ファイル内にある場合、次のメッセージが表示される場合があります。
Errors have occurred while opening the policy configuration.
View the warning log for more information.
または、警告ログ内に次のメッセージが表示される場合があります。
Warning: Invalid argument(s) for constructor:
javax.security.auth.PrivateCredentialPermission.
この問題を修正するには、許可を編集して末尾のスペースを除去します。末尾のスペースが除去されると、
許可は適切にロードします。次のコード・サンプルは、訂正された許可を表示しています。
grant { permission javax.security.auth.PrivateCredentialPermission
“javax.resource.spi.security.PasswordCredential * ¥”*¥“”,“read”; }
ポリシー・ツールについて詳しくは、 167 ページの『ポリシー・ツールによるポリシー・ファイルの作成お
よび編集』 を参照してください。
トラブルシューティング
166
WebSphere Application Server - Express Version 5.1 セキュリティー
ダイナミック・ポリシーをデバッグするには、以下の方法を使用して AccessControlException 例外の明細報
告書を作成することができます。
v トレース仕様でのトレースを使用可能にする:
com.ibm.ws.security.policy.*=all=enabled:com.ibm.ws.security.core.SecurityManager=all=enabled
v First Failure Data Capture (FFDC) を使用可能にする。ffdcRun.properties ファイルを変更して、Level=4
および LAE=true を指定します。ログ・ファイルでキーワード Access Violation (アクセス違反) を検索
してください。
ポリシー・ツールによるポリシー・ファイルの作成および編集: Java 2 セキュリティーは、複数のポリシ
ー・ファイルを使用して各 Java プログラムに付与されたアクセス権を判別します。Java Development Kit
および Java ランタイム環境に、これらのポリシー・ファイルを編集するポリシー・ツールのグラフィカ
ル・アプリケーションが用意されています。ポリシー・ツールは iSeries IBM Developer Kit for Java の一
部として使用できますが、ワークステーション上でポリシー・ツールを実行することをお勧めします。ポリ
シー・ツールは、Java Development Kit インストール・ルートまたは Java ランタイム環境インストール・
ルートの bin サブディレクトリーに存在します。
常にこのツールを使用してポリシー・ファイルを編集し、その内容の構文を保証することをお勧めします。
ポリシー・ファイルに構文エラーがあると、サーバーの始動時およびアプリケーションの実行時に
AccessControlException が発生します。AccessControlException の原因を特定するのは、簡単な作業ではあり
ません。これらのポリシー・ファイルの編集は慎重に行ってください。
1. コマンド・プロンプトからポリシー・ツールを開始します。例えば、java という名前のディレクトリー
に JRE がインストールされている Windows 32 ビット・システムでは、次のコマンドをコマンド行か
ら入力します。
C:¥java¥jre¥bin¥policytool
2. 「ポリシー・ツール (PolicyTool)」ウィンドウが開きます。ポリシー・ツールは、ユーザーのホーム・
ディレクトリーから java.policy ファイルを探します。このファイルが存在しないと、エラー・メッセー
ジが表示されます。「OK」をクリックします。
3. 既存のポリシー・ファイルを編集するには、「ファイル (File)」―>「開く (Open)」をクリックしてポ
リシー・ファイルに移動します。それを選択して、「開く (Open)」をクリックします。コード・ベー
ス・エントリーがウィンドウにリストされます。
新規のポリシー・ファイルを作成する場合は、「ファイル (File)」―>「新規 (New)」をクリックしま
す。
4. コード・ベース・エントリーを作成または変更します。
v 既存のコード・ベース・エントリーを変更するには、エントリーを選択し、「ポリシー・エントリー
の編集 (Edit Policy Entry)」をクリックします。「ポリシー・エントリー (Policy Entry)」ウィンド
ウが開き、選択したコード・ベースに関して定義されているアクセス権リストが表示されます。
v 新規のコード・ベース・エントリーを作成するには、「ポリシー・エントリーの追加 (Add Policy
Entry)」をクリックします。「ポリシー・エントリー (Policy Entry)」ウィンドウが開きます。
「CodeBase」フィールドにコード・ベース情報を、例えば、
/QIBM/UserData/WebASE51/ASE/instance/InstalledApps/testcase.ear のように URL フォーマット
で入力します。
5. アクセス権指定を変更または追加します。
v 既存のアクセス権指定を変更するには、変更するエントリーをクリックして、「アクセス権の編集
(Edit Permission)」をクリックします。「アクセス権 (Permissions)」ウィンドウが開き、選択するア
クセス権情報が表示されます。
セキュリティー
167
v 新規アクセス権を追加するには、「アクセス権の追加 (Add Permission)」をクリックします。「アク
セス権の追加 (Add Permission)」ウィンドウが開きます。
「アクセス権 (Permissions)」ウィンドウで、以下のステップを実行します。
a. 「アクセス権 (Permission)」リストからアクセス権を選択します。選択したアクセス権が表示されま
す。アクセス権を選択した後、「ターゲット名 (Target Name)」、「アクション (Actions)」、およ
び「署名者 (Signed By)」フィールドに可能な選択が自動的に表示されるか、または右側のテキスト
入力域にテキスト入力が可能になります。
b. リストからターゲット名を選択するか、またはテキスト・フィールドにターゲット名を入力します。
c. リストからアクションを選択します。
d. 必要に応じ、「署名者 (Signed By)」 フィールドに値を入力します。
注: Signed By キーワードは、次のポリシー・ファイルではサポートされていません。
app.policy、spi.policy、library.policy、was.policy、および filter.policy。しかし、Signed By キーワー
ドは、java.policy および server.policy ポリシー・ファイルでサポートされています。Java 認証およ
び許可サービス (JAAS) principal キーワードは、app.policy、spi.policy、library.policy、was.policy、
および filter.policy ファイルではサポートされていません。ただし、JAAS principal キーワード
は、Java 仮想マシン (JVM) システム・プロパティーである java.security.auth.policy で指定さ
れている場合、JAAS ポリシー・ファイル内でサポートされています。
e. 「OK」をクリックして、「アクセス権 (Permissions)」ウィンドウを閉じます。
指定したコード・ベースの変更されたアクセス権エントリーが表示されます。
6. 「完了 (Done)」をクリックして、ウィンドウを閉じます。変更されたコード・ベース・エントリーがリ
ストされます。
7. 編集を終了するまで、ステップ 4 から 6 を繰り返します。
8. ファイルの編集を完了した後、「ファイル (File)」―>「保管 (Save)」をクリックします。
ポリシー・ツールの詳細については、「ポリシー・ツール (Policy Tool)」
(http://java.sun.com/j2se/1.3/docs/tooldocs/win32/policytool.html) を参照してください。
app.policy ファイルの構成: Java 2 セキュリティーは、複数のポリシー・ファイルを使用して各 Java プ
ログラムに付与されたアクセス権を判別します。app.policy ファイルは、すべての WebSphere Application
Server - Express エンタープライズ・アプリケーションによって共用されるデフォルトのポリシー・ファイ
ルです。 app.policy ファイル、server.policy ファイル、アプリケーションの was.policy ファイル、および
ra.xml ファイルに定義されている許可の共用体が、エンタープライズ・アプリケーションに適用されま
す。
注: Signed By キーワードおよび Java 認証および許可サービス (JAAS) principal キーワードは、
app.policy ファイルではサポートされていません。しかし、Signed By キーワードは、java.policy および
server.policy ファイルでサポートされています。JAAS principal キーワードは、Java 仮想マシン (JVM)
システム・プロパティー java.security.auth.policy によって指定されている場合、JAAS ポリシー・フ
ァイルでサポートされています。auth.policy.url.n=URL で、java.security.auth.policy の権限ポリシー・フ
ァイルを静的に設定することができます。ここで、n は整数、URL は権限ポリシーのロケーションです。
エンタープライズ・アプリケーションに対するデフォルト許可が十分である場合には、変更を加える必要は
ありません。特定の変更をセル内のすべてのエンタープライズ・アプリケーションに対して加える必要があ
168
WebSphere Application Server - Express Version 5.1 セキュリティー
る場合には、app.policy ファイル を更新しなければなりません。ポリシー・ファイルに構文エラーがある
と、アプリケーション・サーバーを始動できなくなります。これらのポリシー・ファイルの編集は慎重に行
ってください。
ポリシー・ツールを使用して app.policy ファイルを編集します。詳しくは、 167 ページの『ポリシー・ツ
ールによるポリシー・ファイルの作成および編集』を参照してください。変更は、ノードにローカルなもの
です。
WebSphere Application Server - Express によって提供される app.policy ファイルは、
/QIBM/UserData/WebASE51/ASE/instance/config/cells/cell/nodes/node/app.policy にあります。ここで、instance
はインスタンス名、cell はセル名、 node はノード名です。
app.policy ファイルには、以下のデフォルト許可が含まれています。
grant codeBase “file:${application}” {
// The following are required by Java mail
permission java.io.FilePermission
“${was.install.root}${/}java${/}extlib${/}mail.jar”, “read”;
permission java.io.FilePermission
“${was.install.root}${/}java${/}extlib${/}activation.jar”, “read”;
};
grant codeBase “file:${jars}” {
permission java.net.SocketPermission “*”, “connect”;
permission java.util.PropertyPermission “*”, “read”;
};
grant codeBase “file:${connectorComponent}” {
permission java.net.SocketPermission “*”, “connect”;
permission java.util.PropertyPermission “*”, “read”;
};
grant codeBase “file:${webComponent}” {
permission java.io.FilePermission “${was.module.path}${/}-”, “read, write”;
permission java.lang.RuntimePermission “loadLibrary.*”;
permission java.lang.RuntimePermission “queuePrintJob”;
permission java.net.SocketPermission “*”, “connect”;
permission java.util.PropertyPermission “*”, “read”;
};
あるセル内のすべての WebSphere Application Server - Express エンタープライズ・アプリケーションが、
app.policy ファイルでデフォルトとして定義されていない許可を必要とする場合には、app.policy ファイル
と、おそらく server.policy ファイルも更新する必要があります。
app.policy ファイルを変更した場合、app.policy ファイルの変更を有効にするためにすべてのエンタープラ
イズ・アプリケーションを再始動する必要があります。
was.policy ファイルの構成: Java 2 セキュリティーは、複数のポリシー・ファイルを使用して各 Java プ
ログラムに付与されたアクセス権を判別します。was.policy ファイルは、エンタープライズ・アプリケーシ
ョンに関するアプリケーション固有のポリシー・ファイルです。これは EAR ファイル
(META-INF/was.policy) に組み込まれています。
注: Signed By キーワードおよび Java 認証および許可サービス (JAAS) principal キーワードは、
was.policy ファイルではサポートされていません。しかし、Signed By キーワードは、java.policy および
server.policy ポリシー・ファイルでサポートされています。JAAS principal キーワードは、Java 仮想マシ
ン (JVM) システム・プロパティー java.security.auth.policy によって指定されている場合、JAAS ポ
リシー・ファイルでサポートされています。auth.policy.url.n=URL で、java.security.auth.policy の権
限ポリシー・ファイルを静的に設定することができます。ここで、n は整数、URL は権限ポリシーのロケ
ーションです。
セキュリティー
169
java.policy ファイル、server.policy ファイル、app.policy ファイル、アプリケーションの was.policy ファイ
ル、および ra.xml ファイルのアクセス権指定で設定されているアクセス権の和集合が、エンタープライ
ズ・アプリケーションに適用されます。
エンタープライズ・アプリケーションに対するデフォルト許可が十分である場合には、変更を加える必要は
ありません。アプリケーションが特定のリソースにアクセスする必要がある場合、was.policy ファイルを更
新する必要があることがあります。ポリシー・ファイルに構文エラーがあると、アプリケーション・サーバ
ーが始動に失敗することがあります。
ユーザー・アプリケーションの was.policy ファイルの作成および更新については、 167 ページの『ポリシ
ー・ツールによるポリシー・ファイルの作成および編集』を参照してください。 was.policy ファイルを作
成した後、それをアプリケーションに追加する必要があります。詳しくは、 70 ページの『アプリケーショ
ンへの was.policy ファイルの追加』を参照してください。
変更を有効にするために、エンタープライズ・アプリケーションを再始動します。
spi.policy ファイルの構成: このファイルには、WebSphere Application Server - Express に組み込まれてい
るサービス・プロバイダー・インターフェース (SPI) またはサード・パーティー・リソースに関するアク
セス権が設定されています。SPI の例としては、JDBC ドライバーなどが挙げられます。 デフォルトで
は、このファイルの内容はすべてにアクセス権が付与されています。SPI リソースに関してさらにアクセス
権が必要な場合、このファイルを更新する必要があることがあります。しかし、ファイル内のアクセス権は
resources.xml に定義されているすべての SPI に適用されるので、ファイルの更新は慎重に行ってくださ
い。
注: filterMask および runtimeFilterMask キーワードの後に、codebase キーワードまたは他のキーワー
ドを置かないでください。Signed By キーワードおよび Java 認証および許可サービス (JAAS) principal
キーワードは、spi.policy ファイルではサポートされていません。しかし、Signed By キーワードは、
java.policy および server.policy ポリシー・ファイルでサポートされています。JAAS principal キーワード
は、Java 仮想マシン (JVM) システム・プロパティー java.security.auth.policy によって指定されてい
る場合、JAAS ポリシー・ファイルでサポートされています。auth.policy.url.n=URL で、
java.security.auth.policy の権限ポリシー・ファイルを静的に設定することができます。ここで、n は整
数、URL は権限ポリシーのロケーションです。
java.policy ファイルおよび spi.policy ファイルに設定されているアクセス権の和集合が SPI ライブラリー
に適用されます。
WebSphere Application Server - Express の spi.policy ファイルは、ディレクトリー
/QIBM/UserData/WebASE51/ASE/instance/config/cells/cell/nodes/node にあります。ここで、instance はインス
タンス名、cell はセル名、node はノード名です。
デフォルトの spi.policy ファイルには、次のデフォルトのアクセス権が設定されています。
grant {
permission java.security.AllPermission;
};
更新された spi.policy ファイルを有効にするには、すべての関連 Java プロセスを再始動する必要がありま
す。
170
WebSphere Application Server - Express Version 5.1 セキュリティー
library.policy ファイルの構成: library.policy ファイルは、Java ライブラリー・クラスのテンプレートで
す。共用ライブラリーは、複数のエンタープライズ・アプリケーションで定義され、使用できます。共用ラ
イブラリーの定義および管理の詳細については、『管理』トピックの『共用ライブラリーの管理』を参照し
てください。
共用ライブラリーのデフォルトのアクセス権 (java.policy ファイル、app.policy ファイル、および
library.policy ファイルで定義されるアクセス権の和集合) が適切である場合、アクションは必要ありませ
ん。セル内の共用ライブラリーにアクセスするために特定の変更が必要な場合は、library.policy ファイルを
更新します。
注: grant キーワードの後に、codebase キーワードまたは他のキーワードを置かないでください。Signed
By キーワードおよび Java 認証および許可サービス (JAAS) principal キーワードは、library.policy ファ
イルではサポートされていません。しかし、Signed By キーワードは、java.policy および server.policy ポ
リシー・ファイルでサポートされています。JAAS principal キーワードは、Java 仮想マシン (JVM) シス
テム・プロパティー java.security.auth.policy によって指定されている場合、JAAS ポリシー・ファイ
ルでサポートされています。auth.policy.url.n=URL で、java.security.auth.policy の権限ポリシー・フ
ァイルを静的に設定することができます。ここで、n は整数、URL は権限ポリシーのロケーションです。
java.policy ファイル、app.policy ファイル、および library.policy ファイルに設定されているアクセス権の
和集合が、共用ライブラリーに適用されます。
WebSphere Application Server - Express の library.policy ファイルは、ディレクトリー
/QIBM/UserData/WebASE51/ASE/instance/config/cells/cell/nodes/node にあります。ここで、instance はインス
タンス名、cell はセル名、node はノード名です。
デフォルトでは、ファイルには以下のようなデフォルトのアクセス権エントリーが設定されています。
grant {
};
ユーザー・インスタンス用の library.policy ファイルを更新するには、ポリシー・ツールを使用します。詳
しくは、 167 ページの『ポリシー・ツールによるポリシー・ファイルの作成および編集』を参照してくださ
い。
filter.policy ファイルの構成: Java 2 セキュリティーは、複数のポリシー・ファイルを使用して、それぞれ
の Java プログラムに与える許可を決定します。 Java 2 セキュリティー・ポリシー・フィルターは、Java
2 セキュリティーが使用可能になっているときにのみ有効です。Java 2 セキュリティーの使用可能化に関
する詳細については、 155 ページの『Java 2 セキュリティーの構成』を参照してください。
filter.policy ファイルで定義されるフィルター・ポリシーは、セルにローカルなポリシーです。filter.policy
ファイルは、許可の提供ではなく許可 の制限に使用される唯一のポリシー・ファイルです。フィルター・
ポリシー・ファイルにリストされている許可は、app.policy および was.policy ファイルから除外されます。
その他のポリシー・ファイルに定義されている許可は、filter.policy ファイルの影響を受けません。
許可がフィルターで除外されると、監査メッセージがログに記録されます。ただし、app.policy および
was.policy ファイルに定義されている許可が複合型の許可 (例えば、java.security.AllPermission というよう
な許可) である場合、その許可は除去されず、警告メッセージがログに記録されます。「許可警告の発行
(Issue Permission Warning)」が使用可能になっていて (デフォルトでは使用不可)、 app.policy および
was.policy ファイルにカスタム許可 (java や javax 以外の文字から始まるパッケージの許可 ) が含まれて
いる場合、警告メッセージがログに記録され、許可は除去されません。「許可警告の発行 (Issue
Permission Warning)」の設定は、管理コンソールの「グローバル・セキュリティー (Global Security)」ペ
ージで変更できます。 app.policy ファイルまたは was.policy ファイルに java.security.AllPermission が指定
セキュリティー
171
されている場合、警告メッセージがログに記録されます。ただし、許可は除去されません。エンタープライ
ズ・アプリケーションには AllPermission を使用しないことが推奨されます。
filter.policy ファイルには、デフォルトの許可がいくつか定義されています。これらは、推奨される最小限
の許可です。filter.policy ファイルにこれ以上許可を追加すると、エンタープライズ・アプリケーションで
特定の操作が失敗する可能性があります。
WebSphere Application Server - Express の filter.policy ファイルは、ディレクトリー
/QIBM/UserData/WebASE51/ASE/instance/config/cells/cell にあります。ここで、instance はインスタンス名
で、cell はセル名です。
デフォルトでは、filter.policy ファイルには、以下の許可が含まれます。
filterMask {
permission java.lang.RuntimePermission “exitVM”;
permission java.lang.RuntimePermission “setSecurityManager”;
permission java.security.SecurityPermission “setPolicy”;
permission javax.security.auth.AuthPermission “setLoginConfiguration”;
};
runtimeFilterMask {
permission java.lang.RuntimePermission “exitVM”;
permission java.lang.RuntimePermission “setSecurityManager”;
permission java.security.SecurityPermission “setPolicy”;
permission javax.security.auth.AuthPermission “setLoginConfiguration”;
};
filterMask ブロックに定義されている許可は、静的ポリシー・フィルターを行うためのものです。セキュリ
ティー・ランタイムは、アプリケーションの始動時に、こうした許可をアプリケーションから削除しようと
します。複合型の許可は除去されず、警告が発行されます。filterMask に定義されている許可がアプリケー
ションに含まれる場合、またはスクリプト (wsadmin ツール) が使用された場合、アプリケーションの配置
は中止されます。
runtimeFilterMask ブロックは、セキュリティー・ランタイムがアプリケーション・スレッドからのアクセス
要求を拒否するリソースへのアクセス許可を定義します。アプリケーションが始動しなくなる恐れや正常に
機能しなくなる可能性があるため、runtimeFilterMask には、これ以上許可を追加しないでください。通常、
許可を追加する必要があるのは、filterMask ブロックだけです。
WebSphere Application Server - Express 自体は、filter.policy ファイルに基づいて、システム自体の完全性
を損なうような許可を制限または拒否します。例えば、WebSphere Application Server - Express は、
exitVM および setSecurityManager 許可を、ほとんどのアプリケーションに与えてはならない許可と見なし
ます。こうした許可をアプリケーションに与えた場合、以下のようなシナリオが考えられます。
v exitVM
サーブレット、JSP ファイル、または他のライブラリーが、System.exit() API を呼び出して、WebSphere
Application Server - Express プロセス全体が終了する可能性があります。
v setSecurityManager
アプリケーションが、より多くの許可を与えてしまうような、あるいは WebSphere Application Server Express SecurityManager によって施行されるデフォルト・ポリシーをバイパスしてしまうような独自の
SecurityManager をインストールする可能性があります。
filter.policy ファイルに構文エラーが場合、その filter.policy ファイルは、WebSphere セキュリティー・ラ
ンタイムによってロードされません。これは、所定の位置にフィルターがないことを意味します。フィルタ
ーが存在しない場合、エンタープライズ・アプリケーションは、通常は許可されないリソースにもアクセス
できるようになります。 filter.policy ファイルを編集するときには、最大限の注意を払ってください。
172
WebSphere Application Server - Express Version 5.1 セキュリティー
注: filterMask および runtimeFilterMask キーワードの後に、codebase キーワードまたは他のキーワー
ドを置かないでください。Signed By キーワードおよび Java 認証および許可サービス (JAAS) principal
キーワードは、filter.policy ファイルではサポートされていません。しかし、Signed By キーワードは、
java.policy および server.policy ポリシー・ファイルでサポートされています。JAAS principal キーワード
は、Java 仮想マシン (JVM) システム・プロパティー java.security.auth.policy によって指定されてい
る場合、JAAS ポリシー・ファイルでサポートされています。auth.policy.url.n=URL で、
java.security.auth.policy の権限ポリシー・ファイルを静的に設定することができます。ここで、n は整
数、URL は権限ポリシーのロケーションです。
バージョン 5 では、filter.policy ファイルの編集ツールは用意されていません。このファイルを編集するに
は、テキスト・エディターを使用する必要があります。
filter.policy ファイルの変更を有効にするには、関連する Java プロセスをすべて再始動します。
java.policy ファイルの構成: java.policy ファイルは、iSeries システムで実行されるすべての Java プログ
ラムで共用される全体的なデフォルト・ポリシー・ファイルです。このファイルは変更しないでください。
ノード上の Java プログラムの中に、java.policy ファイルにデフォルトとして定義されていないアクセス権
を必要とするものがある場合は、server.policy ファイルを構成してアクセス権を追加します。詳しくは、
174 ページの『server.policy ファイルの構成』を参照してください。
java.policy ファイルは Java Development Kit (JDK) の一部として組み込まれており、WebSphere 構成およ
びファイル複製サービスでは管理されません。
WebSphere Application Server - Express で使用される java.policy ファイルは、
/QIBM/ProdData/Java400/jdk14/lib/security ディレクトリーにあります。これには次のデフォルトのアクセス
権が設定されています。
grant codeBase “file:${java.home}/lib/ext/*” {
permission java.security.AllPermission;
};
grant codeBase “file:/QIBM/ProdData/OS400/Java400/*” {
permission java.security.AllPermission;
};
grant codeBase “file:/QIBM/ProdData/OS400/Java400/ext/*” {
permission java.security.AllPermission;
};
grant codeBase “file:/QIBM/ProdData/Java400/*” {
permission java.security.AllPermission;
};
grant {
permission
permission
permission
permission
permission
permission
permission
permission
permission
permission
permission
permission
permission
permission
permission
permission
java.lang.RuntimePermission “stopThread”;
java.net.SocketPermission “localhost:1024-”, “listen”;
java.util.PropertyPermission “java.version”, “read”;
java.util.PropertyPermission “java.vendor”, “read”;
java.util.PropertyPermission “java.vendor.url”, “read”;
java.util.PropertyPermission “java.class.version”, “read”;
java.util.PropertyPermission “os.name”, “read”;
java.util.PropertyPermission “os.version”, “read”;
java.util.PropertyPermission “os.arch”, “read”;
java.util.PropertyPermission “file.separator”, “read”;
java.util.PropertyPermission “path.separator”, “read”;
java.util.PropertyPermission “line.separator”, “read”;
java.util.PropertyPermission “java.specification.version”, “read”;
java.util.PropertyPermission “java.specification.vendor”, “read”;
java.util.PropertyPermission “java.specification.name”, “read”;
java.util.PropertyPermission “java.vm.specification.version”, “read”;
セキュリティー
173
permission
permission
permission
permission
permission
java.util.PropertyPermission
java.util.PropertyPermission
java.util.PropertyPermission
java.util.PropertyPermission
java.util.PropertyPermission
“java.vm.specification.vendor”, “read”;
“java.vm.specification.name”, “read”;
“java.vm.version”, “read”;
“java.vm.vendor”, “read”;
“java.vm.name”, “read”;
};
server.policy ファイルの構成: server.policy ファイルは、サーバーのデフォルトのポリシー・ファイルで
す。サーバーのデフォルトのアクセス権が適切である場合、アクションは必要ありません。ノードの一部の
サーバー・プログラムに特定の変更が必要な場合は、server.policy ファイルを更新します。アプリケーショ
ンにアクセス権を追加する場合は、app.policy と was.policy ファイルを使用します。
ノード上の一部のサーバー・プログラムに、java.policy ファイルと server.policy ファイルにデフォルトと
して定義されていないアクセス権が必要な場合は、ポリシー・ツールを使用して server.policy ファイルを
更新します。アクセス権を追加するかどうかを決定するには、『AccessControlException』を参照してくださ
い。
server.policy ファイルは、ディレクトリー /QIBM/UserData/WebASE51/ASE/instanceName/properties にあり
ます。ここで、instanceName はインスタンス名です。これには次のデフォルトのアクセス権が設定されて
います。
grant codeBase “file:${was.install.root}/java/extlib/-” {
permission java.security.AllPermission;
};
grant codeBase “file:${was.install.root}/java/tools/ibmtools.jar” {
permission java.security.AllPermission;
};
grant codeBase “file:/QIBM/ProdData/Java400/jdk14/lib/tools.jar” {
permission java.security.AllPermission;
};
grant codeBase “file:${was.install.root}/lib/-” {
permission java.security.AllPermission;
};
grant codeBase “file:${was.install.root}/classes/-” {
permission java.security.AllPermission;
};
grant codeBase “file:${was.install.root}/deploytool/-” {
permission java.security.AllPermission;
};
ポリシー・ツールを使用して、server.policy ファイルを変更します。詳しくは、 167 ページの『ポリシー・
ツールによるポリシー・ファイルの作成および編集』を参照してください。
server.policy ファイルを更新後、すべての Java プロセスを再始動して更新された server.policy ファイルを
有効にします。
AccessControlException: Java 2 セキュリティーの振る舞いは、そのセキュリティー・ポリシーで指定され
ます。セキュリティー・ポリシーは、特定のコード・ベースがアクセス可能なシステム・リソースおよびそ
れらへの署名者を指定するアクセス制御マトリックスです。Java 2 セキュリティー・ポリシーは宣言書で
あり、java.security.AccessController.checkPermission() メソッドによって施行されます。
174
WebSphere Application Server - Express Version 5.1 セキュリティー
次のコード例は java.security.AccessController.checkPermission() メソッドのアルゴリズムです。ここで、呼び
出し側 m は java.security.AccessController.checkPermission() メソッドを起動しました。完全アルゴリズムに
ついては、「Class AccessController」
の API 文書を参照してください。
i = m;
while (i > 0) {
if (caller i’s domain does not have the permission)
throw AccessControlException;
else if (caller i is marked as privileged)
return;
i = i - 1;
};
アルゴリズムでは、java.security.AccessController.checkPermission() の実行時に上記の許可が呼び出しスタッ
ク上のクラス (呼び出し側) のすべてに付与されることが要求されます。付与されない場合、要求は拒否さ
れます (java.security.AccessControlException はスローされます)。ただし、呼び出し側に特権がマークされ、
クラス (呼び出し側) に上記の許可が付与されている場合、アルゴリズムはその時点で戻り、呼び出しスタ
ック全体には作用しません。以降のクラス (呼び出し側) には要求された許可が付与される必要はありませ
ん。
java.security.AccessControlException 例外は、要求された許可が
java.security.AccessController.checkPermission() メソッド時に欠落している呼び出しスタック上で特定のクラ
スの結果としてスローされます。次に、java.security.AccessControlException 例外に対して考えうる 2 つの
解決策を示します。
v Java 2 セキュリティーで保護されている API がアプリケーションで呼び出されている場合には、要求さ
れた許可をアプリケーション Java 2 セキュリティー・ポリシーに付与します。
v Java 2 セキュリティーで保護されている API がアプリケーションで直接呼び出されてはいないが、その
アプリケーションが保護リソースにアクセスするサード・パーティー・コードである場合には、アプリ
ケーションに追加の特権を付与するオプションが用意されています。ただし、追加の特権を付与するこ
とでアプリケーションに必要以上のアクセス権限を付与する場合には、アプリケーションに特権が適切
にマークされない可能性があります。
呼び出しスタックの例
以下は、パスワードを更新するためにサード・パーティーの API ユーティリティーをアプリケーション・
コードで使用している呼び出しスタックの例です。次の例は、ポイントを例示するための一例にすぎませ
ん。これは、コードを特権としてマークするときの絶対的なガイドではありません。コードを特権としてマ
ークするときの正しい場所に関する説明はこのアプリケーションに特定のものであり、個々の状態で固有の
ものです。したがって、正しい判断を行うためにはドメインに関する深い知識とセキュリティーの専門知識
が要求されます。このトピックに関しては数多くの優れた出版物や書籍があります。詳細については、そう
した資料を参照することを強くお勧めします。
セキュリティー
175
ユーザーのパスワードを変更するには PasswordUtil ユーティリティーを使用できます。旧パスワードを入
力してから、新規パスワードを 2 回入力します。これは正しいパスワードの入力を確認するためです。旧
パスワードがパスワード・ファイルに保管されているものと一致する場合には、新規パスワードが保管さ
れ、パスワード・ファイルが更新されます。スタック・フレームのいずれも特権としてマークされていない
と想定してみましょう。java.security.AccessController.checkPermission() アルゴリズムに従って、呼び出しス
タック上のすべてのクラスにパスワード・ファイルへの書き込み許可が付与されていない場合、アプリケー
ションは失敗します。クライアント・アプリケーションについては、パスワード・ファイルに直接書き込み
を行ってパスワード・ファイルを自由に更新する許可を付与しないでください。
ただし、PasswordUtil.updatePasswordFile() メソッドで、特権としてパスワード・ファイルにアクセスするコ
ードがマークされている場合には、許可検査アルゴリズムは、PasswordUtil クラスに許可が付与されている
限りは、要求された許可について PasswordUtil.updatePasswordFile() メソッドを呼び出すクラスから要求さ
れた許可を検査しません。したがって、クライアント・アプリケーションは、パスワード・ファイルへの書
き込み許可を付与せずに、パスワードを正常に更新することができます。
コードを特権としてマークできることは、非常にフレキシブルで強力な機能ですが、この機能はいわば両刃
の剣であり、危険性も伴います。この機能を適切に使用しない場合には、システムのセキュリティー全体に
暗号漏えいやセキュリティー・ホール発生の可能性が生じます。コードを特権としてマークする機能は慎重
に使用してください。
注: コードを特権としてマークする箇所を判別するには、ドメインに関する知識とセキュリティーに関する
専門知識が必要です。セキュリティー・エクスポージャーは、不適切にマークされたコードから発生しま
す。
java.security.AccessControlException の解決
上記で説明したように、java.security.AccessControlException 例外の解決には、次の 2 つの解決策がありま
す。問題の解決に当たり、次の解決策のいずれが最善であるのかの判別は、ケースごとに判断してくださ
い。
v 欠落している許可をアプリケーションに付与する。
v コードを特権としてマークする (この機能のデメリットとリスクに留意すること)。
176
WebSphere Application Server - Express Version 5.1 セキュリティー
Java 認証および許可サービス・ログインの構成
Java 認証および許可サービス (JAAS) は、プログラマチック・ログイン用の認証 API のコレクションで
す。WebSphere Application Server - Express には、JAAS に対して次のような拡張機能が用意されていま
す。
v com.ibm.websphere.security.auth.WSSubject
JAAS バージョン 1.0 仕様での設計上のミスのため、javax.security.auth.Subject.getSubject() は、
java.security.AccessController.doPrivileged() コード・ブロック内での実行のスレッドに関連付けられている
サブジェクトを戻しません。これは不整合な振る舞いで、問題があり望ましくない結果を発生させま
す。com.ibm.websphere.security.auth.WSSubject API では、サブジェクトを実行スレッドに関連付けする回
避策を用意しています。com.ibm.websphere.security.auth.WSSubject API は、J2EE リソースに対する
JAAS 許可モデルを拡張します。
Subject.doAs() ブロック中のサブジェクトは、Subject.getSubject() 呼び出しで検索することができます。
ただし、Subject.doAs() ブロック中に AccessController.doPrivileged() 呼び出しが存在すると、この方法は
成功しません。次の例では、s1 は s と等しいですが、s2 は null です。
Subject.doAs(s, new PrivilegedAction() {
public Object run() {
System.out.println(“Within Subject.doAsPrivileged()”);
Subject s1 = Subject.getSubject(AccessController.getContext());
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
Subject s2 = Subject.getSubject(AccessController.getContext());
return null;
}
}
return null;
}
}
AccessController.doPrivileged() メソッドは、Subject 伝搬を切り捨てて許可を削減するだけでなく、
Subject オブジェクト内のプリンシパル用に定義されている JAAS セキュリティー・ポリシーを組み込み
ません。
v コンソールを使用した構成
管理コンソールで JAAS ログインを構成することができます。ただし、WebSphere Application Server Express は JAAS デフォルト実装で提供されるデフォルトの JAAS ログイン構成フォーマット (プレー
ン・テキスト・ファイル) もサポートします。管理構成とプレーン・テキスト・ファイル・フォーマット
の両方に重複したログイン構成が定義されている場合は、管理構成に設定されたログイン構成が優先さ
れます。
v プロキシー LoginModule
デフォルトの JAAS 実装は、クラスをロードするのにスレッド・コンテキスト・クラス・ローダーを使
用しません。LoginModule クラス・ファイルがアプリケーション・クラス・ローダーまたは Java 拡張ク
ラス・ローダー・クラス・パスに存在しない場合は、LoginModule はロードできません。このクラス・
ローダーの可視性問題のために、WebSphere Application Server - Express はプロキシー LoginModule を
用意して、コンテキスト・クラス・ローダーのスレッドを使用して JAAS LoginModule をロードしま
す。LoginModule 実装を、このプロキシー LoginModule を使用してアプリケーション・クラス・ローダ
ーや Java 拡張クラス・ローダー・クラスパスに配置する必要はありません。
定義済み JAAS ログイン構成は、アプリケーションで使用するように提供されています。WebSphere 管理
コンソールで構成を表示できます。「セキュリティー (Security)」―>「JAAS 構成 (JAAS
Configuration)」を展開し、「アプリケーション・ログイン (Application Login)」をクリックします。次の
JAAS ログイン構成は使用可能です。
セキュリティー
177
v WSLogin
一般に、アプリケーションが使用できるログイン構成および LoginModule 実装を定義します。
v DefaultPrincipalMapping
Java 2 Connector が、認証済み WebSphere ユーザー ID を、特定のバックエンド・エンタープライズ情
報システムのユーザー認証データのセット (ユーザー ID およびパスワード) にマップするために通常使
用する、特別な LoginModule モジュールを定義します。Java 2 Connector および DefaultMappingModule
モジュールに関する詳細については、 155 ページの『Java 2 セキュリティーの構成』を参照してくださ
い。
注: 定義済みの JAAS ログイン構成を除去または削除しないでください。これらを削除または除去する
と、他のエンタープライズ・アプリケーションが失敗することがあります。
管理コンソールを使用して、新規 JAAS ログイン構成を追加および変更できます。変更を実行時に有効に
するには、アプリケーション・サーバーを再始動する必要があります。
JAAS ログイン・モジュールを配置できるロケーションは、WebSphere Application - Express Server ディレ
クトリー構造内にいくつかあります。次のリストに、JAAS ログイン・モジュールのロケーションを、推奨
順に示します。
v 特定の Java 2 Enterprise Edition (J2EE) アプリケーションの Enterprise Archive (EAR) ファイル
内。
EAR ファイル内にログイン・モジュールを配置する場合、特定のアプリケーションにのみアクセス可能
です。
v WebSphere Application Server - Express 共用ライブラリー内。
ログイン・モジュールを共用ライブラリーに配置する場合、モジュールにアクセスできるアプリケーシ
ョンを指定する必要があります。共用ライブラリーの詳細については、『管理』トピックの『共用ライ
ブラリーの管理』を参照してください。
新規 JAAS ログインを構成するには、管理コンソールで以下のステップを実行します。
1. ナビゲーション・ツリーで「セキュリティー (Security)」をクリックします。
2. 「JAAS 構成 (JAAS Configuration)」―>「アプリケーション・ログイン (Application Logins)」をク
リックします。
3. 「新規」をクリックします。「アプリケーション・ログイン構成 (Application Login Configuration)」パ
ネルが表示されます。
4. 新規 JAAS ログイン構成の別名を指定して、「適用 (Apply)」をクリックします。これが
javax.security.auth.login.LoginContext に渡して新規 LoginContext を作成するログイン構成の名前です。
5. 「JAAS ログイン・モジュール (JAAS Login Modules)」をクリックします。
6. 「新規」をクリックします。
7. モジュールのクラス名を指定します。クラス・ローダーの可視性問題の制約のために、WebSphere プ
ロキシー LoginModule を指定することをお勧めします。
8. LoginModule 実装をプロキシー LoginModule の代行プロパティーとして指定します。WebSphere プロ
キシー LoginModule のクラス名は、com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy
です。
9. ドロップダウン・リストから「認証方式 (Authentication Strategy)」を選択して、「適用 (Apply)」を
クリックします。
10. 「カスタム・プロパティー (Custom Properties)」をクリックします。これにより、選択した
LoginModule に関する「カスタム・プロパティー (Custom Properties)」パネルにナビゲートします。
178
WebSphere Application Server - Express Version 5.1 セキュリティー
11. 実際の LoginModule 実装の値で代行される名前で新規プロパティーを作成します。値 true を持つデ
バッグのような他のプロパティーを指定できます。これらのプロパティーは、LoginModule の
initialize() メソッドに対するオプションとして LoginModule に渡されます。
12. 「保管」をクリックします。
プレーン・テキスト・ファイルの変更
WebSphere Application Server - Express は JAAS デフォルト実装で提供されるデフォルトの JAAS ログイ
ン構成フォーマット (プレーン・テキスト・ファイル) をサポートします。しかし、プレーン・テキスト・
ファイルをこのフォーマットで編集するツールは用意されていません。JAAS ログイン構成をプレーン・テ
キスト・ファイル、wsjaas.conf に定義できます (インスタンスのルートの properties サブディレクトリ
ーに存在します。例えば、/QIBM/UserData/WebASE51/ASE/instance/properties)。構文エラーがあると、JAAS
ログイン構成プレーン・テキスト・ファイルが正しく構文解析できなくなることがあります。これにより、
他のアプリケーションが失敗することがあります。
認証に JAAS を使用する Java クライアント・プログラムは、指定された JAAS 構成ファイルで起動する
必要があります。この構成ファイルは、launchClient スクリプトで設定されます。Java クライアント・プロ
グラムを起動する際に launchClient スクリプトが使用されない場合、適切な JAAS 構成ファイル
が、-Djava.security.auth.login.config フラグで Java 仮想マシンに渡されることを確認します。
プレーン・テキスト JAAS 構成ファイルの編集の詳細については、『JAAS 1.0 開発者ガイド (JAAS 1.0
Developer’s Guide)』
を参照してください。
アプリケーション・サーバーを再始動して、プレーン・テキスト・ファイルへの変更を確認します。
J2C 認証データ項目の構成
Java 2 Connector (J2C) 認証データ項目は、リソース・アダプターおよび JDBC データ・ソースによって
使用されます。 Java 2 Connector 認証データ項目は、以下の情報を含む認証データを含みます。
v 別名
認証データ項目を識別するための識別子。リソース・アダプターまたは Java Database Connectivity
(JDBC) データ・ソースを構成するときに、管理者は、対応する別名に対してどの認証データを使用する
かを指定することができます。
v User ID (ユーザー ID)
対象とするセキュリティー・ドメインのリソース・アダプターに接続するためのユーザー ID。
v Password (パスワード)
構成リポジトリー内でエンコードされているユーザー ID のパスワード。
v 説明 (Description)
短いテキスト記述。
新規 J2C 認証データ項目の作成
新規の J2C 認証データ項目を作成するには、WebSphere 管理コンソールで以下のステップを実行してくだ
さい。
1. ナビゲーション・メニューで、「セキュリティー (Security)」を展開し、「JAAS 構成 (JAAS
Configuration)」―>「J2C 認証データ (J2C Authentication Data)」をクリックします。
2. 「J2C 認証データ項目 (J2C Authentication Data Entries)」パネルで、「新規 (New)」をクリックしま
す。
3. 固有の別名、有効なユーザー ID、有効なパスワード、および短い説明 (オプション) を入力します。
セキュリティー
179
4. 「OK」または「適用 (Apply)」をクリックします。ユーザー ID およびパスワードの妥当性検査が行わ
れないことに注意してください。
5. 「保管」をクリックします。
アプリケーション・サーバー・プロセスを再始動せずに新規作成したデータ項目を使用することができま
す。具体的には、認証データはアプリケーションの開始時にアプリケーション・サーバーによってロードさ
れ、同じアプリケーション・サーバー上のアプリケーション間で共有されます。
J2C 認証データ項目の削除
J2C 認証データ項目を削除するには、WebSphere 管理コンソールで以下のステップを実行してください。
1. 認証データ項目を削除もしくは除去する前に、そのデータ項目がリソース・アダプターもしくは JDBC
データ・ソースによって使用または参照されていないことを確認してください。削除した認証データ項
目がリソースによって使用または参照されていた場合は、リソース・アダプターまたは JDBC データ・
ソースを使用するアプリケーションは、リソースへの接続に失敗します。
2. ナビゲーション・メニューで、「セキュリティー (Security)」を展開し、「JAAS 構成 (JAAS
Configuration)」―>「J2C 認証データ (J2C Authentication Data)」をクリックします。
3. 「J2C 認証データ (J2C Authentication Data)」パネルで、削除する項目のチェック・ボックスを選択
し、「削除 (Delete)」をクリックします。
セキュリティー構成の調整
一般的にパフォーマンスの問題は、機能と速度との間のトレードオフに関わる問題です。通常、機能と処理
が増すほど、パフォーマンスは低下します。必要とするセキュリティーのタイプ、および環境内でどれを使
用不可にすることができるかを考慮してください。例えば、Virtual Private Network (VPN) で稼働するアプ
リケーション・サーバーの場合、Single Sockets Layer (SSL) を無効にする必要があるかどうかを検討しま
す。ユーザーが多数の場合、グループにマップして、グループを J2EE 役割に関連付けられるでしょうか?
これらは、セキュリティー・インフラストラクチャーを設計する場合に考慮すべき質問です。
パフォーマンス、機能、およびセキュリティーの間には、常にトレードオフが存在します。一般的にセキュ
リティーにより、要求の処理時間が増しますが、これは妥当な理由によるものです。ただし、環境内ではす
べてのセキュリティー機能を必要とするとは限りません。セキュリティーの調整を行う場合は、変更を行う
前にベンチマークを作成して、変更によりパフォーマンスが向上するか確認できるようにしてください。
大規模な配置では、パフォーマンスは非常に重要です。各種機能の組み合わせによりベンチマーク測定を実
行することにより、環境における最適なパフォーマンスと利点が得られる構成を決めることができます。
WebSphere セキュリティー構成の調整方法については、以下のトピックを参照してください。
181 ページの『セキュリティー全般の調整のヒント』
WebSphere セキュリティー全般のパフォーマンス向上のためのヒントについては、このトピックを参
照してください。
182 ページの『CSIv2 の調整』
Common Security Interoperability Version 2 (CSIv2) 認証プロトコルを使用する場合の構成の調整にお
ける考慮事項については、このトピックを参照してください。
182 ページの『LDAP 認証の調整』
LDAP ユーザー・レジストリーを使用する場合の認証プロセスの最適化については、このトピックを
参照してください。
180
WebSphere Application Server - Express Version 5.1 セキュリティー
183 ページの『Web 認証の調整』
ブラウザー・ベースの認証を使用する場合の調整のヒントは、このトピックを参照してください。
183 ページの『権限の調整』
権限プロセスの高速化については、このトピックを参照してください。
183 ページの『SSL パフォーマンスのヒント』
WebSphere Application Server で SSL 接続を使用する場合のパフォーマンス向上のヒントについて
は、このトピックを参照してください。
セキュリティー全般の調整のヒント
WebSphere セキュリティー構成の一般的な調整のヒントを以下に示します。
1. サーバーに配置するコードを正確に把握しており、処理リソースを保護する必要のない場合は、Java 2
セキュリティー・マネージャーを無効にすることを考慮してください。これによりローカル・リソース
に多少のリスクが残ることは留意してください。
2. 環境の保護が十分になされていると判断した場合、キャッシュおよびトークンのタイムアウト設定の値
を増やしてみてください。(これらの設定は、WebSphere 管理コンソールの「グローバル・セキュリティ
ー」パネルの一般プロパティーで設定できます。) これにより、再認証の要求される回数が少なくなり
ます。この操作により、以降の要求での作成済みの証明書の再利用回数が増えます。トークンのタイム
アウト値を増すことの短所として、トークンがハイジャックされる危険にさらされる点があります。タ
イムアウト設定の値を大きくするほど、トークンの有効期限が切れるまでの間にシステムがハッキング
される時間が増すことになります。セキュリティー・キャッシュ・プロパティーを使用することによ
り、1 次および 2 次ハッシュ・テーブル・キャッシュの初期サイズ (再ハッシュの頻度とハッシュ・ア
ルゴリズムの配布に影響する) を決定することができます。これらのプロパティーのリストについて
は、『セキュリティー・キャッシュ・プロパティー』を参照してください。
3. 管理コネクターを Simple Object Access Protocol (SOAP) から Remote Method Invocation (RMI) に変更
するよう考慮してください。RMI はステートフル接続を使用しますが、SOAP は完全にステートレスで
す。ベンチマーク・テストを実行して、環境でのパフォーマンスが向上したかを確認してください。こ
の制御では、管理アプリケーションのパフォーマンスにのみ影響します。
4. wsadmin スクリプトを使用してすべてのユーザー/グループのアクセス ID を完了することにより、アプ
リケーションの始動を高速化します。この操作は、アプリケーションに多数のユーザー/グループが含ま
れる場合、またはアプリケーションが頻繁に停止して開始する場合に行ってください。詳しくは、『管
理』トピックの『wsadmin 管理ツール』を参照してください。
5. Web サーバー・プラグインで使用する接続で SSL を有効にする必要があるかどうかを考慮してくださ
い。これらの接続は長期間の接続ですが、Web サーバーへのブラウザーの接続は一般的に短期間です。
このため、Web サーバー・プラグインで使用される接続に SSL を有効にした場合、ブラウザーと Web
サーバー間の接続に SSL を有効にした場合よりも、一般的にパフォーマンスへの影響は小さくなりま
す。ただし、十分なセキュリティーが提供されている場合は、プラグイン接続の SSL 保護が必要でな
い場合があります。例えば、Web サーバーとアプリケーション・サーバーがファイアウォールにより保
護されている場合は、プラグイン接続は十分に保護されていると考えられます。
セキュリティー・キャッシュ・プロパティー: 1 次ハッシュ・テーブル・キャッシュおよび 2 次ハッシ
ュ・テーブル・キャッシュの初期サイズは、以下のシステム・プロパティーによって決定されます。初期サ
イズは、再ハッシュの頻度とハッシュ・アルゴリズムの分布に影響します。使用可能なハッシュ値の数が大
きいほど、ハッシュの衝突が起こる可能性が少なく、検索時間は長くなる可能性が高くなります。ハッシ
ュ・テーブル・キャッシュが複数のエントリーによって構成される場合は、自動再ハッシュによりテーブル
のサイズを拡大させるよりも、大きな容量でテーブルを作成するほうがハッシュ・エントリーの効率がよく
なります。再ハッシュをすると、そのたびにすべてのエントリーを移動します。
セキュリティー
181
v com.ibm.websphere.security.util.authCacheEnabled
このプロパティーは、Subject キャッシュがプロセスに対して使用可能であるかどうかを決定します。
Subject キャッシュが使用不可の場合、新規 Java 認証および許可サービス (JAAS) ログインがすべての
要求に対して発生し、その結果として性能低下が起こります。Subject キャッシュを使用不可にする場合
は、注意してください。
v com.ibm.websphere.security.util.tokenCacheSize
このキャッシュは LTPA 証明書を保管します。その際、LTPA トークンを索引値として使用します。
LTPA トークンを使用して最初にログインするときは、セキュリティー・サーバーで LTPA 証明書が作
成されます。このキャッシュにより、以降に LTPA トークンを使用してログインするときは、セキュリ
ティー・サーバーにアクセスする必要はありません。
v com.ibm.websphere.security.util.LTPAValidationCacheSize
このキャッシュは、ログイン用の証明書トークンを受け取り、再度セキュリティー・サーバーで検証を
行う必要なく、具体的な LTPA 証明書オブジェクトを返します。トークンが期限切れの場合は、再度検
証が必要です。
CSIv2 の調整
Common Security Interoperability Version 2 (CSIv2) 認証プロトコルを調整する場合は、次の作業を行うよ
うにしてください。
1. あまり重要でないデータを大量に送信する場合は、暗号の強度を下げてください。強力な暗号を使用す
ると、大量のデータの暗号化に時間がかかります。データの重要性が低い場合、128 ビット暗号による
処理を行っても意味はありません。
2. ダウンストリームへの委任に ID アサーションを使用する場合、トラステッド・サーバー ID リストに
はアスタリスク (*) のみを入れるようにしてください (つまり、すべてのサーバーが信頼される)。サー
バー間で SSL 相互認証を使用することにより、この信頼関係が提供されます。この追加ステップを
SSL ハンドシェークに加えることにより、アップストリーム・サーバーの完全な認証を行い、トラステ
ッド・リストをチェックするよりは良好なパフォーマンスが得られます。アスタリスクを使用する場
合、識別トークンが信頼されます。SSL 接続は、クライアント証明書の認証によりサーバーを信頼しま
す。
3. CSIv2 でステートフル・セッションが有効であることを確認してください。これはデフォルトで有効で
すが、認証が必要となるのは最初の要求と以降にトークンの有効期限が切れた場合のみとなります。
4. WebSphere Application Server バージョン 5 サーバーとのみ通信を行う場合、アクティブ認証プロトコ
ル設定には CSI および SAS でなく CSI のみを指定してください。この操作により、クライアントと
サーバー・サイドの両方で、すべての要求のインターセプター呼び出しが除去されます。
LDAP 認証の調整
LDAP 認証プロセスを調整するには、次のステップを行うようにしてください。
1. 大文字小文字の区別が重要でない場合は、WebSphere 管理コンソールの LDAP ユーザー・レジストリ
ー・パネルの「大文字小文字を区別しない (Ignore Case)」チェック・ボックスを選択してください。
2. LDAP ユーザー・レジストリー構成の「接続の再使用 (Reuse Connections)」を選択します。
3. 使用する LDAP サーバーが提供するキャッシュ機能を確認して、その機能を利用します。この操作
は、頻繁に変更することのない LDAP サーバーに適しています。
4. WebSphere Application Server - Express for iSeries バージョン 5.1 では、 V5R2 で OS/400 Directory
Services 製品を使用しており LDAP 4.1 にアップグレード済みの場合、ディレクトリー・タイプに
SecureWay ではなく IBM_Directory_Server を使用できます。LDAP 4.1 の場合、i5/OS ディレクトリ
ー・サービスは、グループ・メンバーシップの検索に新規のグループ・メンバーシップ属性を使用する
ようプログラムされているため、パフォーマンスが向上します。ただし、認証には大文字小文字を区別
182
WebSphere Application Server - Express Version 5.1 セキュリティー
しない必要があるため、「ディレクトリー・タイプに IBM_Directory_Server を選択した場合は、「大
文字小文字を区別しない (Ignore Case)」も選択してください。LDAP 4.1 で必要とされる PTF につい
ては、『iSeries LDAP: 新機能 (What’s New)』
(http://www.ibm.com/servers/eserver/iseries/ldap/whatsnew.htm) を参照してください。
Web 認証の調整
Web 認証プロセスを調整するには、次のステップを行うようにしてください。
1. 環境の保護が十分になされていると判断した場合、キャッシュおよびトークンのタイムアウト設定の値
を増やしてみてください。(これらの設定は、WebSphere 管理コンソールの「グローバル・セキュリティ
ー」パネルの一般プロパティーで設定できます。) これにより、再認証の要求される回数が少なくなり
ます。この操作により、以降の要求での作成済みの証明書の再利用回数が増えます。トークンのタイム
アウト値を増すことの短所として、トークンがハイジャックされる危険にさらされる点があります。タ
イムアウト設定の値を大きくするほど、トークンの有効期限が切れるまでの間にシステムがハッキング
される時間が増すことになります。セキュリティー・キャッシュ・プロパティーを使用することによ
り、1 次および 2 次ハッシュ・テーブル・キャッシュの初期サイズ (再ハッシュの頻度とハッシュ・ア
ルゴリズムの配布に影響する) を決定することができます。これらのプロパティーのリストについて
は、 181 ページの『セキュリティー・キャッシュ・プロパティー』を参照してください。
2. シングル・サインオン (SSO) を使用可能にするよう考慮してください。SSO は、WebSphere 管理コン
ソールのグローバル・セキュリティー・パネルで認証メカニズムに LTPA を選択した場合にのみ使用可
能になります。SSO を選択すると、1 つのアプリケーション・サーバーに対する単一の認証により、同
じ SSO ドメイン内の複数のアプリケーション・サーバーへの要求を行えるようになります。SSO が望
ましくない状況もあるため、このような場合は SSO を使用しないでください。SSO についての詳細
は、 99 ページの『シングル・サインオンの構成』を参照してください。
権限の調整
権限プロセスを調整する場合は、次のステップを行うようにしてください。
1. ユーザーをユーザー・レジストリーのグループにマップするよう考慮してください。その上で、グルー
プを J2EE 役割に関連付けます。この関連付けにより、ユーザー数が増えた場合のパフォーマンスが大
きく向上します。
2. サーブレットのセキュリティー制約は慎重に割り当てるようにしてください。例えば、URL パターン
*.jsp を使用して同じ認証データ制約を適用し、すべての JSP ファイルを指示することができます。指
定した URL については、最長のパスの一致に対して、デプロイメント記述子の完全一致突き合わせが
優先されます。セキュリティー制約に指定した URL の完全一致突き合わせおよび最長のパスの一致が
ない場合は、拡張子の一致 (*.jsp、*.do、*.html) を使用してください。
SSL パフォーマンスのヒント
Secure Sockets Layer (SSL) のパフォーマンスには、次の 2 つのタイプがあります。
v ハンドシェーク
v バルク暗号化および暗号化解除
SSL 接続を確立すると、SSL ハンドシェークが発生します。接続が行われた後は、SSL は読み取り/書き込
みごとにバルク暗号化と暗号化解除を実行します。SSL ハンドシェークによるパフォーマンス・コスト
は、バルク暗号化および暗号化解除よりも非常に大きくなります。
単一の SSL 接続を使用して複数の要求を送信することにより (要求ごとに接続を開くのではなく)、SSL
のパフォーマンスが向上します。また、新規接続を開く回数を減らすことも重要です。接続の回数全体を減
らすことにより、SSL 接続によるセキュア通信のパフォーマンス、および単純な TCP/IP 接続による非セ
セキュリティー
183
キュア通信のパフォーマンスが向上します。単一の SSL 接続で複数の要求を送信する方法の 1 つに、
HTTP 1.1 をサポートするブラウザーを使用する方法があります。
2 つの WebSphere Application Server コンポーネント間の接続 (TCP/IP および SSL) の数を減らすもう 1
つの一般的な方法として、以下のガイドラインによりアプリケーション・サーバーの HTTP トランスポー
ト構成を検証して、Web サーバー・プラグインがアプリケーション・サーバーへの新規接続を反復して開
くことのないようにする方法があります。
v キープアライブ接続の最大数が、少なくとも Web サーバーによりサポートされる最大数となるようにし
ます。Web サーバー・プラグインが、アプリケーション・サーバーに対して可能な同時接続すべてに対
してキープアライブ接続を取得できるようにしてください。これを行えない場合、アプリケーション・
サーバーは、1 つの要求の処理後に接続をクローズします。また、Web コンテナー・スレッド・プール
のスレッド最大数が、キープアライブ接続の最大数よりも多くなるようにして、キープアライブ接続が
Web コンテナー・スレッドを浪費することのないようにする必要があります。この設定についての詳細
は、 186 ページの『例: HTTP トランスポートに対するカスタム・プロパティーの設定』を参照してくだ
さい。
v キープアライブ接続ごとの最大要求数を増やすことを考慮してください。デフォルト値は 100 で、アプ
リケーション・サーバーは、要求が 100 に達した後のプラグインの接続をクローズします。するとプラ
グインは、新しい接続を開く必要があります。このパラメーターは、アプリケーション・サーバーに接
続する際のサービス妨害攻撃を防ぎ、アプリケーション・サーバーのスレッドを結合する連続した送信
要求を防ぐことを目的としています。この設定についての詳細は、 『例: HTTP トランスポートのカス
タム・プロパティーの設定』を参照してください。
v システムで複数の SSL ハンドシェークを実行する場合は、ハードウェア・アクセラレーターを使用して
ください。
注: IBM Cryptopgraphic Coprocessor for iSeries は、WebSphere Application Server での使用はサポートさ
れません。ただし、IBM Cryptographic Coprocessor を使用して、IBM HTTP Server for i5/OS (powered
by Apache) など他の iSeries 製品の SSL パフォーマンスを向上させることができます。
Web サーバー接続は短期間であることから、一般的にアクセラレーターは Web サーバーにおいて利点
があります。一般的に WebSphere Application Server 接続はより長い間存続することから、ハードウェ
ア・アクセラレーターを使用しても WebSphere Application Server の SSL パフォーマンスが大きく向上
することはありません。
パフォーマンス向上のためのもう 1 つの方法として、データの暗号化および暗号化解除をより拘束に行う
代替の暗号スイートを使用する方法があります。
暗号スイートのパフォーマンスは、ソフトウェアとハードウェアでは異なります。暗号スイートのパフォー
マンスがソフトウェアで良好であっても、ハードウェアでのパフォーマンスが良いとは限りません。一般的
にハードウェアでは不十分なアルゴリズムがありますが (例、DES および 3DES)、専用のハードウェアを
使用することにより、これらアルゴリズムを効率よく実装することができます。
バルク暗号化および暗号化解除のパフォーマンスは、個々の SSL 接続で使用される暗号スイートにより影
響を受けます。次の図は、それぞれの暗号スイートのパフォーマンスを示しています。
184
WebSphere Application Server - Express Version 5.1 セキュリティー
データを計算するテスト・ソフトウェアは、クライアントおよびサーバー・ソフトウェアともに Java
Secure Socket Extension (JSSE) を使用し、これは暗号ハードウェア・サポートを使用しません。テストに
は、接続を確立するための時間は含まれず、確立した接続でのデータの送信時間のみ含まれます。このため
データは、長期間実行される接続における各種暗号スイートの相対的な SSL パフォーマンスを示していま
す。
接続を確立する前に、クライアントは各テスト・ケースごとに単一の暗号スイートを使用可能にしていま
す。接続が確立された後は、クライアントがサーバーへの整数の書き込みに要した時間、およびサーバーが
指定数のバイトをクライアントに書き戻すのに要した時間を測定しています。データ量の変動による、暗号
スイートの相対的なパフォーマンスへの影響は無視できます。
上記の分析から、次の点が明らかになります。
v バルク暗号化のパフォーマンスは、暗号スイート名の WITH に続く内容によってのみ影響を受けます。
WITH の前の部分は、SSL ハンドシェークにおいてのみ使用されるアルゴリズムを識別していることか
ら、これは予想通りです。
v MD5 および SHA は、データ保全性を提供するための 2 つのハッシュ・アルゴリズムです。MD5 は
SHA よりも 25% 高速ですが、SHA は MD5 よりも安全です。
v DES および RC2 は RC4 よりも低速です。Triple DES が最も安全ですが、ソフトウェアのみの使用で
はパフォーマンス・コストは高くなります。
v 最適なパフォーマンスとプライバシーを提供する暗号スイートは SSL_RSA_WITH_RC4_128_MD5 で
す。SSL_RSA_EXPORT_WITH_RC4_40_MD5 は RSA_WITH_RC4_128_MD5 よりも暗号化が弱いもの
の、バルク暗号化のパフォーマンスは同じです。このため、SSL 接続が長期間実行される接続であれ
ば、セキュリティー・レベルの高と中のパフォーマンスの違いは無視できます。WebSphere Application
Server 製品間のみにおける通信に参加するすべてのコンポーネントについては、セキュリティー・レベ
ルは中でなく高を使用することをお勧めします。接続が長期間実行される接続であることを確認してく
ださい。
セキュリティー
185
例: HTTP トランスポートに対するカスタム・プロパティーの設定: WebSphere Application Server Express には、WebSphere 管理コンソールの HTTP トランスポート設定ページには表示されないトランス
ポート・プロパティーがいくつかあります。次のようなものがあります。
v ConnectionIOTimeout
要求時にデータの読み取りまたは処理を試行する際の最大待機時間 (秒数) を指定します。データ型: 整
数。
v ConnectionKeepAliveTimeout
キープアライブ接続において次の要求を待つ最大秒数を指定します。データ型: 整数。
v MaxKeepAliveConnections
すべての HTTP トランスポートの中で同時に存在できるキープアライブ (持続的) 接続の最大数を指定
します。要求後、特定のトランスポートの接続を閉じるには、そのトランスポートで
MaxKeepAliveConnections を「0」(ゼロ) に設定するか、KeepAliveEnabled を「false」に設定します。
Web サーバー・プラグインは、アプリケーション・サーバーに対してできる限り長く接続を開き続けま
す。ただし、このプロパティーの値が小さすぎる場合は、プラグインは 1 つの接続を通して複数の要求
を送ることができず、それぞれの要求ごとに新規の接続をオープンしなくてはならないため、パフォー
マンスは低下します。アプリケーション・サーバーは、TIME_WAIT 状態のソケットが多すぎる場合、
負荷が重いため新規接続を受け入れない可能性があります。すべてのクライアント要求が Web サーバ
ー・プラグイン経由で、ポート 9080 用の TIME_WAIT 状態のソケットが多くある場合、アプリケーシ
ョン・サーバーは途中で接続を閉じるため、パフォーマンスが低下します。アプリケーション・サーバ
ーは、以下のいずれかの理由からプラグインまたはクライアントからの接続をクローズします。
– Web サーバー・プラグインが常に HTTP 1.1 で要求を送信する場合に、クライアント要求が HTTP
1.0 の要求であるとき。
– 同時に保持できる最大のキープアライブ接続数に達したとき。キープアライブ状態は、接続の存続期
間中、一度のみ獲得することができます。それは、最初の要求が完了したのち、かつ 2 番目の要求が
読み取られる前です。
– ある接続に対する最大要求数に達した場合。これは、クライアントがキープアライブ接続を永遠に保
持し続けようとするという、サービス妨害攻撃を防ぐためです。
– 次の要求、または現在の要求の残りの部分の読み取りを待機中にタイムアウトになった場合。
データ型: 整数。 デフォルト: Web コンテナーのスレッド・プール内の最大スレッド数の 90%。これ
は、すべてのスレッドがキープアライブ接続に保持され、新しく受信した要求を処理するスレッドがな
くなってしまうことを防ぎます。
v MaxKeepAliveRequests
単一のキープアライブ接続で処理されることが可能な要求の最大数を指定します。このパラメーターに
より、クライアントがキープアライブ接続を保持しようとする場合に、サービス妨害の攻撃を防ぐこと
ができます。 Web サーバー・プラグインは、アプリケーション・サーバーに対してできる限り長く接続
を開き続け、最適なパフォーマンスを提供します。データ型: 整数。デフォルト: 100。
v KeepAliveEnabled
接続をキープアライブにするかどうかを指定します。データ型: ブール。デフォルト: true。
これらのプロパティーは、Web コンテナー上、または HTTP トランスポート・カスタム・プロパティ
ー・ページ上で設定できます。「Web コンテナー・カスタム・プロパティー (Web container Custom
Properties)」ページで設定する場合、すべてのトランスポートはプロパティーを継承します。トランスポ
ートに対して同じプロパティーを設定すると、Web コンテナーで定義したのと同様の設定値がオーバー
ライドされます。
186
WebSphere Application Server - Express Version 5.1 セキュリティー
HTTP トランスポート・カスタム・プロパティー・ページ上で特定のトランスポートに対してこれらのカス
タム・プロパティーの値を設定するには、次のようにします。
1. WebSphere 管理コンソール内でトランスポート・プロパティーの設定ページにアクセスします。
a. ナビゲーション・メニューで、「サーバー (Servers)」―>「Application Servers」―>「server」―
>「Web コンテナー (Web Container)」―>「HTTP トランスポート (HTTP Transport)」をクリッ
クします。ただし、ここで server はアプリケーション・サーバーの名前です。
b. プロパティーを設定するホストをクリックします。
c. 「追加プロパティー (Additional Properties)」で、「カスタム・プロパティー (Custom
Properties)」をクリックします。
d. 「カスタム・プロパティー (Custom Properties)」ページで、「新規 (New)」をクリックします。
2. 新規プロパティーの設定ページで、トランスポート・プロパティーの名前と設定する値を入力します。
例えば、要求中のデータの読み取りまたは書き込みのためにトランスポートが待機する時間を最大 60
秒とする場合、名前に「ConnectionIOTimeout」および値に「60」を入力してください。次に「OK」を
クリックします。
3. コンソール・タスクバーで、「保管 (Save)」をクリックし、構成の変更を保管します。
4. サーバーを再始動します。
5. Web サーバー・プラグインを再生成します。
特定のユーザー・プロファイルでのアプリケーション・サーバーの実行
デフォルトの QEJBSVR ユーザー・プロファイル以外のユーザー・プロファイル下でアプリケーション・
サーバーを実行することができます。
アプリケーション・サーバーのデフォルトのユーザー・プロファイルを変更するには、以下のステップを実
行してください。
1. 既存のユーザー・プロファイルを選択するか、またはユーザー・プロファイルの作成 (CRTUSRPRF) コ
マンドで新規のユーザー・プロファイルを作成します。
新規のユーザー・プロファイルは、QEJBSVR の権限と同じオブジェクトを対象とした権限を持ってい
なければなりません。新規のプロファイルのグループ・プロファイルに QEJBSVR を指定します。
iSeries コマンド行から、次のコマンドを実行します。
CHGUSRPRF USRPRF(profile) GRPPRF(QEJBSVR)
ここで、profile は、新規のユーザー・プロファイルの名前です。
注: ユーザー・プロファイルを使用可能にするために enbprfwas スクリプトを使用する場合は、このコ
マンドを実行する必要はありません。代わりに、enbprfwas スクリプトに -chggrpprf パラメーターを指
定してください。
2. (オプション) アプリケーション・サーバーが現在、QEJBSVR 以外のユーザー・プロファイルの下で稼
働している場合、Qshell で以下のコマンドを実行します (ここで、instance はインスタンスの名前で
す)。
a.
chown -R QEJBSVR /QIBM/UserData/WebASE51/ASE/instance
b.
cd /QIBM/ProdData/WebASE51/ASE/bin
c.
セキュリティー
187
grtwasaut -user QEJBSVR -dtaaut RWX -objaut ALL -recursive
d. (オプション) 旧ユーザー・プロファイルがインスタンス内でサーバーを実行するために使用されな
くなった場合、以下のコマンドを実行して、それが持つ権限を取り消すことができます。
rvkwasaut -instance instance -user profile -recursive
ここで、profile は旧ユーザー・プロファイルの名前です。
3. 以下のアクションのいずれかを実行して、このユーザー・プロファイルによるアプリケーション・サー
バーの実行を可能にします。
v 『ユーザー・プロファイルを使用可能にして iSeries ナビゲーターでアプリケーション・サーバーを
実行する』。
v enbprfwas スクリプトを使用します。例えば、以下のコマンドを実行します。
/QIBM/ProdData/WebASE51/ASE/bin/enbprfwas -profile myProfile
ここで、myProfile はユーザー・プロファイルの名前です。
詳しくは、『管理』トピックの 『enbprfwas スクリプト』を参照してください。
4. 以下のように、アプリケーション・サーバーの「Run As User (ユーザーとして実行)」プロパティーで
新規のユーザー・プロファイル名を指定します。
a. WebSphere 管理コンソールを始動します。
b. ナビゲーション・メニューで、「サーバー」を展開し、「アプリケーション・サーバー (Application
Servers)」をクリックします。
c. 「アプリケーション・サーバー (Application Servers)」ページで、アプリケーション・サーバー名を
クリックします。
d. 「追加プロパティー (Additional Properties)」で、「プロセス定義 (Process Definition)」をクリック
します。
e. 「追加プロパティー (Additional Properties)」の下の「プロセス実行 (Process Execution)」をクリッ
クします。
f. 「ユーザーとして実行 (Run As User)」フィールドにユーザー・プロファイル名を入力します。
g. 「OK」をクリックします。
h. 構成を保管します。
i. アプリケーション・サーバーを再始動します。
ユーザー・プロファイルを使用可能にして iSeries ナビゲーターでアプリケ
ーション・サーバーを実行する
デフォルトのユーザー・プロファイル (QEJBSVR) を除き、アプリケーション・サーバーを稼働するために
使用するすべてのユーザー・プロファイルは、WebSphere アプリケーションの iSeries ナビゲーターにより
使用可能になければなりません。
オペレーション・ナビゲーターを実行するために使用するユーザー・プロファイルには、このタスクを実行
するための *SECADM 特殊権限がなければなりません。
1. iSeries ナビゲーターを開く。
2. アプリケーション・サーバー を含む iSeries アイコンを右クリックする。
3. ポップアップ・メニューの「Application Administration (アプリケーション管理)」を選択する。
4. 「ホスト・アプリケーション (Host Applications)」タブをクリックします。
188
WebSphere Application Server - Express Version 5.1 セキュリティー
5. QIBM_EJB_PRODUCT を展開する。
6. QIBM_EJB_GROUP_OF_FUNCS を展開する。
7. QIBM_EJB_SERVER_FUNC を選択して、「Customize (カスタマイズ)」をクリックする。
8. 「Users and groups (ユーザーおよびグループ)」リスト・ボックスで、アプリケーション・サーバー
を実行する際に使用するユーザー・プロファイルを選択する。
9. 一番上の「Add (追加)」 ボタンをクリックして、「Usage allowed (許される使用法)」リストにユーザ
ー・プロファイルを追加してから、「OK」をクリックする。
10. 「Application Administration (アプリケーション管理)」パネルで、「OK」をクリックする。
iSeries オブジェクトおよびファイルの保護
このトピックでは、機密情報を含み、保護する必要のあるさまざまな iSeries オブジェクトおよびファイル
について説明します。
統合ファイル・システムのファイルの保護
サーブレットと JSP ファイルの他に、WebSphere 管理アプリケーションおよびアプリケーション・サーバ
ーは、統合ファイル・システムのストリーム・ファイルにもアクセスします。以下のファイルには機密情報
を含めることができるので、無許可アクセスが許可されないよう十分に注意を払う必要があります。
v インスタンスの properties サブディレクトリー (例え
ば、/QIBM/UserData/WebASE51/ASE/instance/properties) にあるいくつかのファイルには、ユーザー ID
とパスワードを含めることができます。
デフォルトでは、これらのファイルは *PUBLIC 権限が *EXCLUDE に設定されて出荷されています。
QEJBSVR ユーザー・プロファイルには、これらファイルに対する *RX 権限 が許可されています。パ
スワードをエンコードすることにより、さらに保護を強化することができます。詳しくは、 190 ページ
の『パスワードのエンコード』 を参照してください。
v etc サブディレクトリーで、WebSphere Application Server - Express のインスタンス用に作成したイン
スタンス、すべてのキー (KDB) ファイルおよびトラスト (JKS) ファイルを保護する場合は、次のよう
にします。
– JKS ファイルの場合は、QEJBSVR ユーザー・プロファイルに *R 権限が必要であり、*PUBLIC に
は *EXCLUDE 権限が必要です。
– KDB ファイルの場合は、Web サーバーを実行する際のユーザー・プロファイルには *RX 権限が、
*PUBLIC には *EXCLUDE 権限が必要です。
WebSphere サーバーの保護
WebSphere セキュリティーを使用可能にする場合は、WebSphere サーバーのユーザー・プロファイルとパ
スワードを、i5/OS システム・セキュリティーを使用して、セキュアな方法で保守する必要のあるサーバー
構成ファイルに配置する必要があります。さらに、一部の WebSphere リソースをパスワードで保護するこ
とができます。これらのパスワードもサーバー構成ファイルに配置されます。WebSphere サーバーは、自
動的にパスワードをエンコードして、不用意に見られたりすることのないようにします。しかし、パスワー
ドのエンコードだけでは十分な保護とはいえません。
以下のファイルは、ユーザーのインスタンスの config サブディレクトリー内にあり、ユーザー ID とパ
スワードを含めることができます。
v config/cells/cell_name/security.xml
セキュリティー
189
v config/cells/cell_name/nodes/node_name/resources.xml
v config/cells/cell_name/nodes/node_name/servers/server_name/server.xml
ここで、cell_name はセルの名前、node_name はノードの名前、そして server_name はアプリケーション・
サーバーの名前です。
サーバーのユーザー・プロファイルとパスワードは、そのサーバーの初期設定時にそのサーバーを認証する
のに使用されます。この認証は、以下の理由で必ず行う必要があります。
v ユーザー ID とパスワードは、メソッドの委任に SYSTEM_IDENTITY を使用するよう Bean のセキュ
リティーが配置されている場合に、サーバーのシステム ID として使用されます。この場合、ユーザー
ID とパスワードは、ある Enterprise Bean から別の Enterprise Bean にメソッド呼び出しが行われたとき
に使用されます。
v ユーザー ID とパスワードは、サーバー間通信を行うためにサーバーを認証する際に使用されます。こ
れらのファイルに対するセキュリティーは危うくなる可能性があるので、サーバー ID とパスワードに
は、デフォルト以外のユーザー・プロファイルを使用してください。デフォルトのユーザー・プロファ
イルは QEJBSVR です。ローカル・オペレーティング・システム (LocalOS) のユーザー・レジストリー
(i5/OS) を使用する場合は、特殊な権限を持たない iSeries ユーザー・プロファイルを作成し、それを使
用することができます。詳しくは、 187 ページの『特定のユーザー・プロファイルでのアプリケーショ
ン・サーバーの実行』を参照してください。
WebSphere のユーザー・プロファイル
初めてのインストール時に、WebSphere Application Server - Express はデフォルトで、以下の iSeries ユー
ザー・プロファイルを使用します。
v QEJB
このプロファイルを使用すると、パスワードを含むいくつかの管理データにアクセスできます。
v QEJBSVR
このプロファイルは、WebSphere アプリケーション・サーバーが実行するコンテキストを提供します。
セキュリティー目的または管理目的の場合は、他のユーザー・プロファイルを作成し、その下で
WebSphere Application Server - Express の各種パーツを実行することもできます。詳しくは、 187 ペー
ジの『特定のユーザー・プロファイルでのアプリケーション・サーバーの実行』を参照してください。
パスワードのエンコード
v パスワードのエンコードで行うこと (190ページ)
v パスワードのエンコードで行わないこと (191ページ)
v OS400 パスワード・エンコード・アルゴリズムの使用時に考慮すべき問題点 (191ページ)
v WebSphere インスタンスの OS400 パスワード・エンコード・アルゴリズムの使用可能化 (192ページ)
v プロパティー・ファイル内のパスワードの手動エンコード (193ページ)
v 平文パスワードの保護 (194ページ)
v 妥当性検査リスト・オブジェクトの管理 (195ページ)
v アルゴリズムの切り替え (196ページ)
v 問題の解決 (196ページ)
パスワードのエンコードで行うこと
190
WebSphere Application Server - Express Version 5.1 セキュリティー
パスワードのエンコードの目的は、サーバー構成ファイルおよびプロパティー・ファイルでパスワードが偶
然に見られることがないようにすることです。デフォルトでは、各種 ASCII WebSphere サーバー構成ファ
イルにおいて、パスワードが単純なマスキング・アルゴリズムで自動的にエンコードされます。また、パス
ワードは、Java クライアントおよび WebSphere 管理コマンドで使用されるプロパティー・ファイルにおい
て、手動でエンコードすることができます。
デフォルトのエンコード・アルゴリズムは XOR です。これに代わる OS400 エンコード・アルゴリズム
は、 WebSphere Application Server for iSeries - Express でのみ使用可能で、 i5/OS の妥当性検査リスト
(*VLDL) オブジェクトを活用します。 OS400 アルゴリズムの場合には、パスワードは、妥当性検査リス
トに暗号化された形式で保管され、構成ファイルには、XOR アルゴリズムの場合のようなマスク処理され
たパスワードそのものではなく、保管されたパスワードに対するインデックスが含まれます。
WebSphere Application Server - Express インスタンスのプロパティーは、パスワードのエンコードにどのア
ルゴリズムを使用するかを制御します。
エンコードされたパスワードは、以下の形式をとります。
{algorithm}encoded_password
ここで、{algorithm} は、パスワードのエンコードに使用するアルゴリズムを指定するタグ (XOR または
OS400) であり、encoded_password は、エンコードされたパスワードの値です。パスワードをデコードする
必要がある場合、サーバーまたはクライアントはこのタグを使用して使用するアルゴリズムを判別し、その
アルゴリズムを使用してエンコードされたパスワードをデコードします。
Java クライアントは sas.client.props ファイルからパスワードを使用します (このファイルは、
/QIBM/UserData/WebASE51/ASE/myInstance/properties などの、ユーザー・インスタンス・ルートのプロパテ
ィー・サブディレクトリー内にあります)。 Java クライアントでパスワードのエンコードを行うには、
PropFilePasswordEncoder ツールを使用して、パスワードを sas.client.props ファイルに手動でエンコードし
なければなりません。
WebSphere 管理コマンドは、SOAP 接続に soap.client.props ファイル (これもプロパティー・サブディレク
トリーにあります) のパスワードを使用します。一部の管理コマンドは、オプションで、RMI 接続に (プ
ロパティー・サブディレクトリー内の) sas.client.props ファイルのパスワードを使用します。WebSphere 管
理コマンドでパスワードのエンコードを行うには、PropFilePasswordEncoder ツールを使用して、パスワー
ドを sas.client.props および sas.client.props ファイルに手動でエンコードしなければなりません。
パスワードのエンコードで行わないこと
OS400 エンコード・アルゴリズムまたはデフォルト・エンコード・アルゴリズムのどちらを使用するとし
ても、エンコードにより、完全にパスワードを保護できるわけではありません。固有のセキュリティーは、
WebSphere の構成ファイルおよびプロパティー・ファイルで使用されるパスワードを保護するための基本
メカニズムです。
OS400 パスワード・エンコード・アルゴリズムの使用時に考慮すべき問題点
OS400 パスワード・エンコード・アルゴリズムを使用するかどうかを決める前に、考慮すべき問題点があ
ります。
v OS400 パスワード・アルゴリズムを使用する場合は、 Java クライアント・アプリケーションまたは
WebSphere サーバーのホストとなるシステム上で、 i5/OS システム値 QRETSVRSEC を 1 に設定し
て、妥当性検査リストから暗号化されたパスワードを取り出せるようにしておく必要があります。
QRETSVRSEC システム値は、ご使用の iSeries システム上のすべての妥当性検査リスト内の暗号化され
たデータへのアクセスに影響します。
セキュリティー
191
注: OS400 パスワード・エンコード・アルゴリズムの設定がご使用の iSeries システム・セキュリティ
ー・ポリシーと合わない場合は、これを使用しないでください。
v WebSphere 管理ドメイン内のすべてのサーバー・インスタンスが同一の iSeries システム上にある場合、
サーバー・インスタンスには OS400 アルゴリズムのみを使用します。
– WebSphere 管理ドメインは、複数の iSeries システム上に拡張することができます。OS400 パスワー
ド・アルゴリズムのみを使用できるのは、管理可能ドメイン内のすべてのサーバーが同じ iSeries シ
ステムにある場合です。
– サーバー構成 (XML) ファイルには、エンコードされたパスワードが含まれています。 XML ファイ
ルに含まれるパスワードが OS400 エンコード・アルゴリズムを使用してエンコードされている場
合、パスワードのエンコード元である同一 iSeries システム上の WebSphere サーバー・インスタンス
にのみ、これらのエンコードが有効となります。したがって、OS400 エンコード・アルゴリズムを使
用してエンコードされたパスワードに含まれる構成ファイルのコピーは、他の iSeries システムでの
サーバーの構成には使用できません。
– さらに、管理ドメイン内の WebSphere サーバー・インスタンスはすべて、同じ i5/OS の妥当性検査
リスト (*VLDL) オブジェクトを使用するように構成されていなければなりません。
v OS400 エンコード・アルゴリズムを使用してパスワードをエンコード中にエラーが発生した場合、XOR
エンコード・アルゴリズムを使用して、パスワードをエンコードします。こうしたエラーが発生するの
は、例えば、管理者が手動で妥当性検査リスト・オブジェクトを作成して、i5/OS ユーザー・プロファイ
ル QEJB の妥当性検査リスト・オブジェクトに十分な権限を付与しない場合です。
WebSphere インスタンスの OS400 パスワード・エンコード・アルゴリズムの使用可能化
WebSphere インスタンスの OS400 パスワード・エンコード・アルゴリズムを使用可能にするには、以下の
ステップを実行してください。
1. OS400 パスワード・エンコード・アルゴリズムを使用し、使用する妥当性検査リスト・オブジェクトを
指定するように os400.security.password プロパティーを設定します。
iSeries システム上のすべての WebSphere インスタンスで、同じ妥当性検査リスト・オブジェクトを使
用することをお勧めします。すべてのインスタンスのオブジェクトおよびデータのバックアップを同時
に取らないと、例外が発生することになります。各 WebSphere インスタンスで使用する妥当性検査リ
スト・オブジェクトを決定する際、バックアップおよび復元についての方針について考慮してくださ
い。
プロパティーを設定するには、以下のステップのいずれかを実行してください。
v crtwasinst ユーティリティー (/QIBM/ProdData/WebASE51/ASE/bin など、製品インストールの bin サ
ブディレクトリーにあります) の -os400passwords および -validationlist オプションを使用して、イン
スタンス作成時にプロパティーを設定します。例えば、prod という名前の WebSphere インスタンス
を生成し、妥当性検査リスト・オブジェクト /QSYS.LIB/QUSRSYS.LIB/WAS.VLDL を使用して、
OS400 エンコード・アルゴリズムでそのインスタンスを使用可能にするには、以下のようにします。
a. CL コマンド行で STRQSH (Qshell の始動) コマンドを実行します。
b. Qshell で、次のコマンドを実行します。
/QIBM/ProdData/WebASE51/ASE/bin/crtwasinst -instance prod -portblock 10150
-os400passwords -validationlist /QSYS.LIB/QUSRSYS.LIB/WAS.VLDL
v WebSphere インスタンスの setupCmdLine Qshell スクリプト (ユーザー・インスタンスの bin インス
タンスにあります) で、Java システム・プロパティーを設定します。例えば、myInst という名前の
インスタンスの OS400 パスワード・エンコード・アルゴリズムを使用可能にするには、以下のよう
に /QIBM/UserData/WebASE51/ASE/myInst/bin/setupCmdLine ファイルを編集します。
192
WebSphere Application Server - Express Version 5.1 セキュリティー
a. プロパティー os400.security.password.encoding.algorithm を OS400 に設定します。デフォルト設
定は、XOR です。
b. os400.security.password.validation.list.object プロパティーを、使用する妥当性検査リストの絶対名
に設定します。デフォルト設定は、/QSYS.LIB/QUSRSYS.LIB/EJSADMIN.VLDL です。
c. ファイルを保管します。
2. 妥当性検査リストを含むライブラリーに、QEJB ユーザー・プロファイルの実行権限 (*X) を付与しま
す。QEJB に、すでにライブラリーに対する最低限必要な権限 (*X) が付与されている場合、次のステ
ップに進みます。
例えば、妥当性検査リストが /QSYS.LIB/WSADMIN.LIB 内に作成された場合、権限の表示 (DSPAUT)
コマンドを使用して、最低限必要な権限をチェックします。
DSPAUT OBJ(’/QSYS.LIB/WSADMIN.LIB’)
次に、権限の変更 (CHGAUT) コマンドを使用して、QEJB に実行権限を付与します (QEJB に実行権限
がない場合のみ)。例えば、次のようにします。
CHGAUT OBJ(’/QSYS.LIB/WSADMIN.LIB’) USER(QEJB) DTAAUT(*X)
3. i5/OS の妥当性検査リスト・オブジェクト (*VLDL) を作成します。このステップは、サーバー・イン
スタンス用のオプションです。妥当性検査リスト・オブジェクトは、サーバーの始動時に作成されま
す。リモート・インスタンスの場合、リモート・インスタンスをホストするシステム上に妥当性検査リ
ストがない場合に、妥当性検査リストを作成します。各リモート・インスタンスで使用する妥当性検査
リスト・オブジェクトを決定する際、バックアップおよび復元についての方針も考慮に入れてくださ
い。
注: OS400 パスワード・エンコード・アルゴリズムを使用する場合、Java クライアントは、アクセスす
る WebSphere サーバー・インスタンスと同じ iSeries システム上にある必要はありません。
妥当性検査リスト・オブジェクトを作成するには、*ALLOBJ 特殊権限を持つ i5/OS ユーザー・プロフ
ァイルを使用して、以下のステップを実行します。
a. *ALLOBJ 特殊権限を持つユーザー・プロファイルを使用して、iSeries サーバーにサインオンしま
す。
b. 妥当性検査リストの作成 (CRTVLDL) コマンドを使用して、妥当性検査リスト・オブジェクトを作
成します。例えば、ライブラリー WSADMIN.LIB に妥当性検査リスト・オブジェクトを作成する場
合、次のコマンドを使用します。
CRTVLDL VLDL(WSADMIN/WSVLIST)
c. 妥当性検査リスト・オブジェクトに QEJB ユーザー・プロファイルの *RWX 権限を与えます。例
えば、ライブラリー WSADMIN 内の妥当性検査リスト・オブジェクト WSVLIST に *RWX 権限を
付与するには、次のコマンドを使用します。
CHGAUT OBJ(’/QSYS.LIB/WSADMIN.LIB/WSVLIST.VLDL’) USER(QEJB) DTAAUT(*RWX)
4. システム値の変更 (CHGSYSVAL) コマンドを使用して、QRETSVRSEC システム値を 1 に設定しま
す。例えば、次のようになります。
CHGSYSVAL SYSVAL(QRETSVRSEC) VALUE(’1’)
5. サーバー・インスタンスの場合、サーバーを始動 (または再始動) して、サーバーが作動可能になるま
で待ってから、インスタンスに関連するプロパティー・ファイルのパスワードを手動でエンコードしま
す。
プロパティー・ファイル内のパスワードの手動エンコード
セキュリティー
193
PropFilePasswordEncoder ユーティリティーを使用して、プロパティー・ファイル内のパスワードをエンコ
ードします。この Qshell スクリプトは、WebSphere Application Server - Express で使用可能です。このス
クリプトを実行するには、使用するユーザー・プロファイルに *ALLOBJ 権限が付与されている必要があ
ります。
例えば、ご使用のインスタンスの sas.client.props ファイル内にあるプロパティーのパスワードをエンコー
ドするには、以下のようにします。
1. 全オブジェクト (*ALLOBJ) 特殊権限を持つユーザー・プロファイルを使用して、iSeries サーバーにサ
インオンします。
2. CL コマンド行で Qshell の始動 (STRQSH) コマンドを実行して、Qshell 環境を始動します。
3. Qshell で、次のコマンドを単一行で入力します。
/QIBM/ProdData/WebASE51/ASE/bin/PropFilePasswordEncoder -instance instance
/QIBM/UserData/WebASE51/ASE/instance/properties/sas.client.props -SAS
ここで、instance はサーバー・インスタンスの名前です。
myInst という名前のインスタンスの soap.client.props ファイル内にあるプロパティーのパスワードをエン
コードするには、以下のようにします。
1. CL コマンド行で Qshell の始動 (STRQSH) コマンドを実行して、Qshell 環境を始動します。
2. Qshell で、次のコマンドを単一行で入力します。
/QIBM/ProdData/WebASE51/ASE/bin/PropFilePasswordEncoder -instance myInst
/QIBM/UserData/WebASE51/ASE/myInst/properties/soap.client.props
com.ibm.SOAP.loginPassword,com.ibm.ssl.keyStorePassword,com.ibm.ssl.trustStorePassword
詳しくは、『管理』トピックの 『PropFilePasswordEncoder スクリプト』を参照してください。
WebSphere Application Server - Express のプロセスの外部 (別のサーバーなど) で実行されているアプリケ
ーションのユーザー ID やパスワードをテキスト・ファイルに保管している場合は、 EncAuthDataFile ス
クリプトを使用してパスワードをエンコードします。詳しくは、『管理 』トピックの『EncAuthDataFile ス
クリプト』を参照してください。
平文パスワードの保護
WebSphere Application Server - Express は、複数の平文パスワードを持っています。これらのパスワードは
暗号化されていませんが、エンコードはされています。以下はエンコードされたパスワードを持つファイル
のリストです。
194
WebSphere Application Server - Express Version 5.1 セキュリティー
ファイル名
追加情報
security.xml
以下のフィールドは、エンコードされたパスワードを含み
ます。
v LTPA パスワード (LTPA password)
v JAAS 認証データ (JAAS Auth Data)
v ユーザー・レジストリー・サーバー・パスワード (User
Registry server password)
v LDAP ユーザー・レジストリー・バインド・パスワー
ド (LDAP User Registry bind password)
v キー・ファイル・パスワード (Key file password)
v トラスト・ファイル・パスワード (Trust file password)
v 暗号トークン・デバイス・パスワード (Crypto token
device password)
sas.client.props
war/WEB-INF/ibm_web_bnd.xml
Java 暗号化アーキテクチャー内の記述子を除くすべての
記述子内の resource-ref バインディングに対するデフォ
ルト基本認証に対し、パスワードを指定します。
ear/META-INF/ibm_application_bnd.xml
すべての記述子内の ″run as″ バインディングに対するデ
フォルト基本認証にパスワードを指定します。
server.xml
以下のフィールドは、エンコードされたパスワードを含み
ます。
v キー・ファイル・パスワード (key file password)
v トラスト・ファイル・パスワード (trust file password)
v 暗号トークン・デバイス・パスワード (Crypto token
device password)
v 認証ターゲット・パスワード (auth target password)
ws-security.xml
ibm-webservices-bnd.xmi
ibm-webservicesclient-bnd.xmi
/properties/soap.client.props
/properties/sas.tools.properties
/properties/sas.stdclient.properties
wsserver.key
これらのファイルを再オープンする場合、パスワードはプレーン・テキストでは表示されません。その代わ
りに、パスワードはエンコードされて表示されます。WebSphere Application Server - Express では、パスワ
ードをデコードするためのユーティリティーは用意されていません。
PropFilePasswordEncoder ユーティリティーは、WebSphere Application Server - Express パスワード・ファ
イルをエンコードする場合にのみ使用できます。ユーティリティーは、オープンおよびクローズ・タグが含
まれる XML ファイルまたは他のファイルに含まれるパスワードをエンコードすることはできません。
妥当性検査リスト・オブジェクトの管理
セキュリティー
195
妥当性検査リストは、複数の WebSphere インスタンス間で共用できます。例えば、WebSphere Application
Server - Express の 2 つのインスタンス、prod1 と prod2 がある場合は、どちらのインスタンスでも妥当
性検査リスト /QSYS.LIB/QUSRSYS.LIB/EJSADMIN.VLDL を使用できます。
WebSphere Application Server - Express で使用するその他の構成データ・オブジェクトと併せて、定期的に
妥当性検査リスト・オブジェクトを保管するようにしてください。追加情報については、『管理』の『保管
と復元: セキュリティー』を参照してください。
損傷のある妥当性検査リスト・オブジェクトについては、復元するか取り替えるかしてください。妥当性検
査リスト・オブジェクトを取り替えるには、以下のようにします。
1. 妥当性検査リスト・オブジェクトを使用するすべての WebSphere インスタンスについて、以下のよう
にします。
a. サーバーを停止します。
b. すべてのサーバーの os400.security.password.validation.list.object プロパティーを、使用する新規の妥
当性検査リストの絶対名に設定します。既存の妥当性検査リスト・オブジェクトを使用しても、新規
の妥当性検査リスト・オブジェクトを指定しても構いません。新規の妥当性検査リスト・オブジェク
トの場合、前述のように手動で作成するか、あるいはサーバーが再始動されると自動的に作成されま
す。
c. 構成ファイルを編集して、エンコードされた各パスワードに適切な「クリア・テキスト」値を設定し
ます。
2. sas.client.props および soap.client.props ファイルを編集します。エンコードされた各パスワードに適切な
クリア・テキスト値を設定してから、パスワードを手動でエンコードします。
3. 妥当性検査リスト・オブジェクトが取り替えられたすべての WebSphere インスタンスについて、サー
バーを再始動します。
アルゴリズムの切り替え
WebSphere インスタンス用のエンコード・アルゴリズムを切り替えるには、以下のようにします。
1. 妥当性検査リスト・オブジェクトを使用するすべての WebSphere インスタンスで、プロパティー
os400.security.password.encoding.algorithm を OS400 または XOR に設定します。OS400 を使用する場
合は、前述の『WebSphere インスタンス の OS400 パスワード・エンコード・アルゴリズムの使用可能
化 (192ページ)』の説明に従って、使用可能な状態にしてください。このステップから先を実行しない
場合、パスワードはすべて古いアルゴリズムでエンコードされますが、サーバーの再始動後、管理コン
ソールを使用してパスワードの変更が行われた場合、それらのパスワードは新しいエンコード・アルゴ
リズムでエンコードされます。
2. すべてのサーバーを停止します。
3. 構成ファイルを編集して、エンコードされたパスワードをすべてクリア・テキストに変更してくださ
い。
4. プロパティー・ファイルを編集して、エンコードされたパスワードをすべてクリア・テキストに変更し
ます。
5. サーバーを再始動します。
6. 『プロパティー・ファイル内のパスワードの手動エンコード (193ページ)』の説明に従って、プロパテ
ィー・ファイル内のパスワードをエンコードします。
問題の解決
196
WebSphere Application Server - Express Version 5.1 セキュリティー
例えば、パスワード・エンコードが破壊されているなどの理由によりパスワードをデコードできない場合
は、以下のことを行います。
v このパスワードがサーバー構成ファイル内にある場合は、そのファイルを編集し、パスワードを適切な
クリア・テキスト値に設定します。それから、サーバーを再始動します。
v このパスワードが sas.client.props または soap.client.props ファイル内にある場合は、ファイルを編集
し、パスワードを適切なクリア・テキスト値に設定します。最後に、PropFilePasswordEncoder ユーティ
リティーを使用して、パスワードをエンコードします。
インスタンス固有の setupCmdLine QShell スクリプトにはプロパティーが含まれており、これを使用する
と、 Java クライアントや WebSphere 管理コマンドで OS400 アルゴリズムを使用するときにトレース情
報を取得できます。トレースを得るために、os400.security.password.debug=true を設定します。トレー
スは、標準出力に書き込まれます。
セキュリティー
197
198
WebSphere Application Server - Express Version 5.1 セキュリティー
付録. 特記事項
本書は米国 IBM が提供する製品およびサービスについて作成したものです。
本書に記載の製品、サービス、または機能が日本においては提供されていない場合があります。日本で利用
可能な製品、サービス、および機能については、日本 IBM の営業担当員にお尋ねください。本書で IBM
製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、またはサービスのみ
が使用可能であることを意味するものではありません。これらに代えて、IBM の知的所有権を侵害するこ
とのない、機能的に同等の製品、プログラム、またはサービスを使用することができます。ただし、IBM
以外の製品とプログラムの操作またはサービスの評価および検証は、お客様の責任で行っていただきます。
IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む) を保有している場合があ
ります。本書の提供は、お客様にこれらの特許権について実施権を許諾することを意味するものではありま
せん。実施権についてのお問い合わせは、書面にて下記宛先にお送りください。
〒106-0032
東京都港区六本木 3-2-31
IBM World Trade Asia Corporation
Licensing
以下の保証は、国または地域の法律に沿わない場合は、適用されません。 IBM およびその直接または間接
の子会社は、本書を特定物として現存するままの状態で提供し、商品性の保証、特定目的適合性の保証およ
び法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任を負わないものとします。国または地
域によっては、法律の強行規定により、保証責任の制限が禁じられる場合、強行規定の制限を受けるものと
します。
この情報には、技術的に不適切な記述や誤植を含む場合があります。本書は定期的に見直され、必要な変更
は本書の次版に組み込まれます。 IBM は予告なしに、随時、この文書に記載されている製品またはプログ
ラムに対して、改良または変更を行うことがあります。
本書において IBM 以外の Web サイトに言及している場合がありますが、便宜のため記載しただけであ
り、決してそれらの Web サイトを推奨するものではありません。それらの Web サイトにある資料は、こ
の IBM 製品の資料の一部ではありません。それらの Web サイトは、お客様の責任でご使用ください。
IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、自ら適切と信
ずる方法で、使用もしくは配布することができるものとします。
本プログラムのライセンス保持者で、(i) 独自に作成したプログラムとその他のプログラム (本プログラム
を含む) との間での情報交換、および (ii) 交換された情報の相互利用を可能にすることを目的として、本
プログラムに関する情報を必要とする方は、下記に連絡してください。
IBM Corporation
Software Interoperability Coordinator, Department YBWA
3605 Highway 52 N
Rochester, MN 55901
U.S.A.
本プログラムに関する上記の情報は、適切な使用条件の下で使用することができますが、有償の場合もあり
ます。
© Copyright IBM Corp. 2004, 2006
199
本書で説明されているライセンス・プログラムまたはその他のライセンス資料は、IBM 所定のプログラム
契約の契約条項、IBM プログラムのご使用条件、IBM 機械コードのご使用条件、またはそれと同等の条項
に基づいて、 IBM より提供されます。
この文書に含まれるいかなるパフォーマンス・データも、管理環境下で決定されたものです。そのため、他
の操作環境で得られた結果は、異なる可能性があります。一部の測定が、開発レベルのシステムで行われた
可能性がありますが、その測定値が、一般に利用可能なシステムのものと同じである保証はありません。さ
らに、一部の測定値が、推定値である可能性があります。実際の結果は、異なる可能性があります。お客様
は、お客様の特定の環境に適したデータを確かめる必要があります。
IBM 以外の製品に関する情報は、その製品の供給者、出版物、もしくはその他の公に利用可能なソースか
ら入手したものです。IBM は、それらの製品のテストは行っておりません。したがって、他社製品に関す
る実行性、互換性、またはその他の要求については確証できません。 IBM 以外の製品の性能に関する質問
は、それらの製品の供給者にお願いします。
IBM の将来の方向または意向に関する記述については、予告なしに変更または撤回される場合があり、単
に目標を示しているものです。
表示されている IBM の価格は IBM が小売り価格として提示しているもので、現行価格であり、通知なし
に変更されるものです。卸価格は、異なる場合があります。
本書はプランニング目的としてのみ記述されています。記述内容は製品が使用可能になる前に変更になる場
合があります。
本書には、日常の業務処理で用いられるデータや報告書の例が含まれています。より具体性を与えるため
に、それらの例には、個人、企業、ブランド、あるいは製品などの名前が含まれている場合があります。こ
れらの名称はすべて架空のものであり、名称や住所が類似する企業が実在しているとしても、それは偶然に
すぎません。
著作権使用許諾:
本書には、様々なオペレーティング・プラットフォームでのプログラミング手法を例示するサンプル・アプ
リケーション・プログラムがソース言語で掲載されています。お客様は、サンプル・プログラムが書かれて
いるオペレーティング・プラットフォームのアプリケーション・プログラミング・インターフェースに準拠
したアプリケーション・プログラムの開発、使用、販売、配布を目的として、いかなる形式においても、
IBM に対価を支払うことなくこれを複製し、改変し、配布することができます。このサンプル・プログラ
ムは、あらゆる条件下における完全なテストを経ていません。従って IBM は、これらのサンプル・プログ
ラムについて信頼性、利便性もしくは機能性があることをほのめかしたり、保証することはできません。
それぞれの複製物、サンプル・プログラムのいかなる部分、またはすべての派生的創作物にも、次のよう
に、著作権表示を入れていただく必要があります。
© (お客様の会社名) (西暦年). このコードの一部は、IBM Corp. のサンプル・プログラムから取られていま
す。 © Copyright IBM Corp. _年を入れる_. All rights reserved.
この情報をソフトコピーでご覧になっている場合は、写真やカラーの図表は表示されない場合があります。
プログラミング・インターフェース情報
この「WebSphere Application Server - Express」資料には、プログラムを作成するユーザーが IBM i5/OS
のサービスを使用するためのプログラミング・インターフェースが記述されています。
200
WebSphere Application Server - Express Version 5.1 セキュリティー
商標
以下は、IBM Corporation の商標です。
AIX
AIX 5L
e (ロゴ) server
eServer
i5/OS
IBM
IBM (ロゴ)
iSeries
pSeries
WebSphere
xSeries
zSeries
Intel、Intel Inside (ロゴ)、および Pentium は、Intel Corporation の米国およびその他の国における商標で
す。
Microsoft、Windows、Windows NT および Windows ロゴは、Microsoft Corporation の米国およびその他の
国における商標です。
Java およびすべての Java 関連の商標およびロゴは、Sun Microsystems, Inc. の米国およびその他の国にお
ける商標または登録商標です。
Linux は、Linus Torvalds の米国およびその他の国における商標です。
UNIX は、The Open Group の米国およびその他の国における登録商標です。
他の会社名、製品名およびサービス名等はそれぞれ各社の商標です。
資料に関するご使用条件
これらの資料は、以下の条件に同意していただける場合に限りご使用いただけます。
個人使用: これらの資料は、すべての著作権表示その他の所有権表示をしていただくことを条件に、非商業
的な個人による使用目的に限り複製することができます。ただし、IBM の明示的な承諾をえずに、これら
の資料またはその一部について、二次的著作物を作成したり、配布 (頒布、送信を含む) または表示 (上映
を含む) することはできません。
商業的使用: これらの資料は、すべての著作権表示その他の所有権表示をしていただくことを条件に、お客
様の企業内に限り、複製、配布、および表示することができます。 ただし、IBM の明示的な承諾をえずに
これらの資料の二次的著作物を作成したり、お客様の企業外で資料またはその一部を複製、配布、または表
示することはできません。
ここで明示的に許可されているもの以外に、資料や資料内に含まれる情報、データ、ソフトウェア、または
その他の知的所有権に対するいかなる許可、ライセンス、または権利を明示的にも黙示的にも付与するもの
ではありません。
資料の使用が IBM の利益を損なうと判断された場合や、上記の条件が適切に守られていないと判断された
場合、IBM はいつでも自らの判断により、ここで与えた許可を撤回できるものとさせていただきます。
お客様がこの情報をダウンロード、輸出、または再輸出する際には、米国のすべての輸出入関連法規を含
む、すべての関連法規を遵守するものとします。
付録. 特記事項
201
IBM は、これらの資料の内容についていかなる保証もしません。これらの資料は、特定物として現存する
ままの状態で提供され、商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての
明示もしくは黙示の保証責任なしで提供されます。
コードに関するライセンス情報および特記事項
IBM は、お客様に、すべてのプログラム・コードのサンプルを使用することができる非独占的な著作使用
権を許諾します。お客様は、このサンプル・コードから、お客様独自の特別のニーズに合わせた類似のプロ
グラムを作成することができます。
強行法規で除外を禁止されている場合を除き、IBM、そのプログラム開発者、および供給者は「プログラ
ム」および「プログラム」に対する技術的サポートがある場合にはその技術的サポートについて、商品性の
保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任を負
わないものとします。
IBM、そのプログラム開発者、または供給者は、いかなる場合においてもその予見の有無を問わず、以下に
対する責任を負いません。
1. データの喪失、または損傷。
2. 直接損害、特別損害、付随的損害、間接損害、または経済上の結果的損害
3. 逸失した利益、ビジネス上の収益、あるいは節約すべかりし費用
国または地域によっては、法律の強行規定により、上記の責任の制限が適用されない場合があります。
202
WebSphere Application Server - Express Version 5.1 セキュリティー
򔻐򗗠򙳰
Printed in Japan