5. 5-1

by user

on 15 сентября 2016

Category: Documents

>> Downloads: 8

views

Report

Comments

Description

Download 5. 5-1

Transcript

5. 5-1

5.セキュリティー構成
この章では、WAS V6.1 におけるセキュリティーの概念や仕組み、構成について説明します。また、
各項目について、管理コンソールを使用した設定方法についても紹介します。
5-1 セキュリティー・アーキテクチャー
この節では、WAS セキュリティー全体像を理解するために、基盤となっている技術やアーキテクチャ
ーについて説明します。
5-1-1 セキュリティー機能を支える技術
WAS セキュリティーは、図 5-1 に示すような階層化セキュリティー・アーキテクチャー上に構築されま
す。
図 5-1 階層化セキュリティー・アーキテクチャー
-1-
WAS リソースには、ネーミングやユーザー・レジストリー、JMX メッセージ Bean、HTML、サーブレット、
JSP、EJB、Web サービスなどといったサービスやコンテンツが挙げられます。階層構造の最も高い位置
にある WAS セキュリティーは、このようなさまざまなリソースへアクセスする方法として、統一されたセキュ
リティー・ポリシーおよびサービスを提供しています。
WAS セキュリティーの下の層が J2EE セキュリティーです。WAS セキュリティーは、 J2EE ベースのセ
キュリティー・ポリシーを実行し、J2EE セキュリティーの API をサポートします。
J2EE セキュリティーの下の層が CORBA セキュリティーです。セキュアな Object Request Broker(以
下、ORB)間で行われる呼び出しは、全て Common Security Interoperability Version 2(以下、CSIv2)セ
キュリティー・プロトコル上で行われます。このプロトコルはセキュリティー・コンテキストを生成し、セッショ
ンが確立された後、呼び出しは EJB 層に渡されます。後方互換性のために、WAS は、以前のリリースや
他の IBM 製品で使用されていた Secure Authentication Service(以下、SAS)セキュリティー・プロトコルも
サポートします。
CORBA セキュリティーの下の層が Java 2 セキュリティーです。Java 2 セキュリティー・モデルは、ファ
イル・システム、システム・プロパティー、ソケット接続、スレッド化、クラス・ロードなどのシステム・リソース
に対して、きめの細かいアクセス制御を提供します。アプリケーション・コードで保護されたリソースにアク
セスするためには、必要な許可を明示的に与えなければなりません。
Java 2 セキュリティーの下の層が JVM セキュリティーです。JVM セキュリティー・モデルは、オペレー
ティング・システム層の上にセキュリティーの層を提供します。例えば、JVM セキュリティーは無制限のア
クセスからメモリーを保護し、スレッド内でエラーが起こった場合には例外をスローして配列型を定義しま
す。
更にこれらの下の層がオペレーティング・システム・セキュリティーです。基礎となるオペレーティング・
システムのセキュリティー基盤は、特定のセキュリティー・サービスを WAS に提供します。このセキュリテ
ィー・サービスには、WAS の製品インストールにおいて機密ファイルを保護するファイル・システム・セキ
ュリティーのサポートが含まれます。システム管理者は、製品を構成したら、オペレーティング・システム
のユーザー・レジストリーから認証情報を直接取得することができます。
図 5-1 にあるようにオペレーティング・システム・セキュリティーの下にある層がネットワーク・セキュリテ
ィーです。ネットワーク・セキュリティー層は、トランスポート・レベルの認証およびメッセージの保全性と機
密性を提供します。別個のアプリケーション・サーバー間の通信は、Secure Sockets Layer(以下、SSL)を
使用するように構成することができます。また、更にメッセージ保護を強化するためには、IP セキュリティ
ーや Virtual Private Network(以下、VPN)を使用することもできます。
5-1-2 セキュリティー概観
アプリケーション・サーバーは、複数層のエンタープライズ・コンピューティング・フレームワークの中核
をなすコンポーネントです。WAS は、図 5-2 に示すようにオープン・アーキテクチャーを採用し、エンタ
ープライズ・ソフトウェア・コンポーネントと統合するために多数のプラグイン・ポイントを提供します。プラ
グイン・ポイントは、J2EE の標準仕様が適用できるところでは必ずこの仕様を基にしています。図 5-2 で
影が付いた部分は、WAS と他のエンタープライズ・ソフトウェア・コンポーネントとの境界を示します。
-2-
図 5-2
WAS セキュリティー概観
トラスト・アソシエーションにより、WAS セキュリティーとサード・パーティー製セキュリティー・サーバーと
を統合することができます。具体的には、リバース・プロキシー・サーバーがフロントエンド認証サーバー
として機能できるようになる一方で、プロキシー・サーバーによって渡される信任状を WAS 製品自体の
認証ポリシーに適用することができます。トラスト・アソシエーション・インターセプターを実装する製品に
は、IBM Tivoli Access Manager for e-business、WebSEAL、Caching Proxy などがあります。
WAS は、ユーザーの認証情報やドメインなどの情報が含まれたセキュリティー属性を、構成内のサー
バー間で受け渡しすることができます。セキュリティー属性は、ユーザーのアカウント情報が格納された
ユーザー・レジストリーあるいは Java Authentication and Authorization Service(以下、JAAS)ログイン・モ
ジュールから取得することができます。
また、WAS では、Web サービス・セキュリティー仕様に基づいて Web サービスを保護することができま
す。この仕様は、Web サービス環境で交換されるメッセージの保護方法を規定しており、メッセージの保
全性と機密性を保護するための中核機構を定義し、セキュリティー関連の要求とメッセージを関連付け
るためのメカニズムを提供します。
その他にも、J2EE コネクター・アーキテクチャーによるコンテナー管理認証のサポート、Java
Authorization Contract for Containers(以下、JACC)インターフェースによる外部 JACC プロバイダーのサ
ポート、CSIv2 セキュリティー・プロトコルのサポートなど、WAS はさまざまなプラグイン・ポイントを提供し
ています。
-3-
5-1-3 管理セキュリティー
WAS V6.0 までのセキュリティーは、グローバル・セキュリティーが使用されていました。グローバル・セ
キュリティー構成は、通常セキュリティー・ドメイン内のすべてのサーバーに適用され、その環境で実行さ
れているすべてのアプリケーションに適用されます。グローバル・セキュリティーを使用して管理コンソー
ルにログインしたいときも事前にユーザー・レジストリーを構築することや、複雑なセキュリティー設定を
行う必要がありました。
WAS V6.1 からは、このグローバル・セキュリティーが管理セキュリティーとアプリケーション・セキュリテ
ィーに分離しました。これにより、管理者は簡単にアクセス制限をかけることができるようになりました。た
だし、管理セキュリティーは単独で有効にすることが可能ですが、アプリケーション・セキュリティーは独
立して有効にすることはできません。必ずアプリケーション・セキュリティーを有効にする場合は管理セキ
ュリティーを有効にする必要があります。
管理セキュリティーとは、WAS の管理をセキュアにするための機能です。管理セキュリティーを有効に
し、ユーザー・レジストリーとして統合リポジトリーに関連づいたデフォルトのファイル・ベース・組み込み
レジストリーを使用することによって LDAP サーバーを構築せずに、管理コンソールログイン時の認証を
簡単に設定することができます。管理セキュリティーを設定することにより、WAS V6.0 では事前に作成
が必要であった内部プロセス通信に必要なサーバー・ユーザーID や LTPA が自動的に生成され、デフ
ォルトの認証メカニズムは LTPA となります。
グローバル・セキュリティーは WAS 導入後に設定が可能でしたが、WAS V6.1 では WAS 導入ウィザード
またはプロファイル作成ウィザードを使用して WAS 導入中に設定が可能になりました。ウィザード内にあ
る管理セキュリティーの選択パネルでは、[管理セキュリティーを有効にする]がデフォルト ON になってい
ます。WAS V6.1 では管理セキュリティーの常時使用を推奨しています。セキュリティー構成ウィザードを
使用して WAS 導入後に設定することも可能です。
5-1-4 設定方法
ここでは、管理コンソールを使用した管理セキュリティーの設定方法を紹介します。管理セキュリティ
ーは WAS 導入中、プロファイル作成中、または WAS 導入後に設定することが可能です。
まず初めに、WAS 導入中、プロファイル作成中の設定方法を紹介します。WAS 導入ウィザードまたは
プロファイル管理ツールには、管理セキュリティー・パネルが追加されています。WAS 導入ウィザード、
プロファイル作成ウィザードともに同様のパネルが表示されます。
図 5-3
プロファイル管理ツールの管理セキュリティー設定画面
-4-
管理セキュリティーを設定する場合は、このパネルの[管理セキュリティーを有効にする]のチェックボッ
クスを ON にします。続いて、任意のユーザー名とパスワードを入力します。このユーザー名はのちに１
次管理ユーザーとなり管理セキュリティーが有効となった管理ツールからログインする際に入力するユ
ーザー名とパスワードになります。このユーザーはファイル・ベースのリポジトリーに格納されます。ここで
設定したユーザー情報は<DM_Profile_Root>/config/<cellname> パスに保管されているファイル・レジ
ストリー（fileRegistry.xml）に保管されます。管理セキュリティーは WAS 導入後、またはプロファイル作成
後に有効となります。ただし、有効であるのは管理セキュリティーだけで、このときアプリケーション・セキ
ュリティーはデフォルトで使用不可となっています。アプリケーション・セキュリティーを使用可能にする場
合は、あらためて設定する必要があります。
5-1-4-1 セキュリティー構成ウィザード
次に、あとから管理セキュリティーを有効にする方法を説明します。
管理セキュリティーを WAS 導入後またはプロファイル作成後に設定するには、セキュリティー構成ウィ
ザードを使用します。セキュリティー構成ウィザードは、基本的な管理とアプリケーションのセキュリティー
を構成するために必要なステップを提供しています。具体的には 1 次管理ユーザーの作成や、使用す
るユーザー・レジストリーの選択、管理セキュリティーON などになります。管理コンソールから、[セキュリ
ティー]→[管理、アプリケーション、およびインフラストラクチャーの保護]を開きます。[セキュリティー構
成ウィザード]ボタンをクリックします。
【Step1】保護の範囲の指定
アプリケーション・セキュリティーとリソース・セキュリティーの選択ができますが、これらの選択について
は任意です。必要があれば選択し、[次へ]をクリックします。管理セキュリティーはこのウィザードを使用
して変更した場合、デフォルトで有効になりますので選択するチェックボックスはありませんのでご注意く
ださい。
【Step2】ユーザー・リポジトリー
-5-
ユーザー・リポジトリーの選択を行います。ユーザー・リポジトリーは、認証やアクセス制御のために使
用するユーザーとグループの情報を持ちます。いずれか１つだけ選択し、[次へ]をクリックします。
【Step3】ユーザー・リポジトリーの構成
管理セキュリティーが有効になった管理コンソールにログインする際に必要なユーザー名とパスワー
ドを設定します。このユーザーはファイル・ベースのリポジトリーに保管されます。ファイル・ベースのリポ
ジトリーに保管されたユーザーは、管理コンソールから、[ユーザーおよびグループ]→[ユーザーの管
理]または[グループの管理]を開くとその管理画面を確認することができます。
また、WAS 導入またはプロファイル作成ウィザードの管理セキュリティー･パネルでは、[管理セキュリ
ティーを有効にする]のチェックボックスを ON にしたとき入力するユーザー名とパスワードが同様です。
【Step4】要約
このページでは設定した内容の確認ができます。
[管理セキュリティーを使用可能にする]が ON になっていることを確認します。設定に間違いがなけれ
ば[OK]ボタンをクリックし、保管します。
管理コンソールからログアウトし、管理セキュリティーが有効になった管理ツールを使用するためサー
バーを再起動します。サーバーの再起動が完了したら、管理セキュリティーが有効になった管理ツール
をたちあげます。ログイン・ユーザーを要求されますので、セキュリティー構成ウィザードの Step3 で設定
した 1 次管理ユーザーを入力します。無事、ログインができたら、[セキュリティー]→[管理、アプリケーシ
ョン、およびインフラストラクチャーの保護]画面を開き、[管理セキュリティーを使用可能にする]のチェッ
クボックスが ON になっていることを確認します。
-6-
5-1-4-2 セキュリティー構成報告書
導入またはプロファイル作成後に、管理セキュリティーは管理コンソールから確認することができま
す。
管理コンソールから、[セキュリティー]→[管理、アプリケーション、およびインフラストラクチャーの保
護]を開き、[セキュリティー構成報告書]を開きます。
[セキュリティー構成報告書]は、現在のセキュリティーに関する設定の全てを見ることができます。ただ
し、報告書への現在の制限により、アプリケーション・レベルのセキュリティー情報は表示されません。ま
た、Java Message Service (JMS) セキュリティー、バス・セキュリティー、 Web Services セキュリティーに
関する情報も同じく表示されません。
5-2 認証
この節では、WAS V6.1 における基本的なセキュリティー技術の一つである認証について説明しま
す。
5-2-1 認証とは
認証とは、リソースを要求するユーザーが「誰であるか」、そして「本人であるか」を証明するプロセスで
す。最も一般的に使われる認証手法は、ユーザーID とパスワードの照合による審査です。
5-2-2 認証モデル
WAS セキュリティーにおける認証は、J2EE のセキュリティー・モデルに基づいて行われます。J2EE に
ついては、下記サイトから詳細が得られます。
Sun Developer Network (SDN) Java EE : Do more with less work.
http://java.sun.com/j2ee/index.jsp
WAS の認証モデルは、以下の要素から構成されています。それぞれの詳細は後述します。（「5-2-3
チャレンジ・タイプ」、「5-2-4 認証メカニズム」参照）
•
チャレンジ・タイプ
ユーザーが自分自身に関する情報（ユーザーID やパスワードなど）を提示する方法
•
認証メカニズム
ユーザーの提示した情報を登録済みのユーザー情報と照会・確認するための方法
5-2-3 チャレンジ・タイプ
WAS V6.1 は、チャレンジ・タイプとして以下の 4 種類の方式を提供しています。
•
なし（None）
ユーザーは、ユーザーID やパスワード等の入力を求められることはありません。リソースが
セキュリティー機能によって保護されている場合、ユーザーはリソースにアクセスすること
はできません。
-7-
•
基本認証（Basic）
HTTP1.0/1.1 の仕様で定められた認証方法です。ユーザーが図 5-4 のようなブラウザのポ
ップアップ画面から入力したユーザーID とパスワードで認証が行われます。いったん入
力したユーザーID とパスワードはブラウザにキャッシュされ、リクエストごとに HTTP ヘッダ
ーに含められ、自動的に Web サーバーに送信されます。ユーザーID とパスワードは
Base64 でエンコーディングされます。しかし、Base64 は暗号化を行うわけではなく、主に
通信の間で文字化けを防ぐ目的でバイナリー化するものであるため、比較的簡単にデコ
ードできてしまいます。したがって、セキュリティーを確保するためには SSL（通信の暗号
化）の併用が必須となります。
図 5-4 基本認証の認証画面
•
フォーム認証（Form）
ログイン・ページに HTML フォームを使用する認証です。ログイン・ページは図 5-5 のよう
に HTML なので自由にカスタマイズ可能です。ユーザーの入力したユーザーID および
パスワードはアプリケーション・データとして、ブラウザから WAS 上に送信されます。フォ
ームで入力したユーザーID やパスワードはネットワーク上で暗号化されないので、セキュ
リティーを確保するためには SSL の併用が必須です。
図 5-5 フォーム認証の認証画面
-8-
•
証明書（Certificate）
クライアント・マシンに組み込まれた X.509 形式の証明書に基づいて、ユーザーの認証が
行われます。そのため、クライアント側に各自の X.509 証明書と秘密鍵を所有している必
要があります。SSL によって行われる高度な認証で、ネットワーク上に流れるデータを盗
聴されても成りすましの危険が小さく、非常に安全な認証方式です。クライアント証明書
を使用するにあたっては Web サーバーで設定を行う必要があります。（「5-4-3-1 Web ブラ
ウザと WAS の SSL 構成」参照）
5-2-4 認証メカニズム
WAS は、認証メカニズムとして LTPA をサポートしています。
LTPA はプロファイル作成時にセキュリティーが有効であればデフォルトで構成されます。なお、使用
可能なユーザー・レジストリーは、統合リポジトリー、ローカル OS ユーザー・レジストリー、LDAP ユーザ
ー・レジストリー、カスタム・ユーザー・レジストリーの４種類になります。
•
LTPA
LTPA は、分散環境と複数アプリケーション・サーバーおよび複数マシン環境を対象として
います。LTPA は、転送可能な信任状および SSO（※１）をサポートしています。LTPA は、
分散環境のセキュリティーを暗号化によりサポートしているので、認証関連のデータを暗
号化し、デジタル署名して安全に伝送し、後で署名を暗号解除して検査することができま
す。複数のノードおよびセルに分散されているアプリケーション・サーバーは、LTPA を使
用することによって安全に通信を行うことができます。また、SSO・フィーチャーも提供され
ます。SSO（※1）では、ユーザーは Domain Name System(以下、DNS)ドメインで一度だ
け認証を受けるだけで、プロンプトが出されることもなく、WAS の他のセルにあるリソース
にアクセスすることができます。
WAS V6.0 までサポートされていた SWAM は WAS V6.1 では推奨されていません。将来のリリースで
除去される予定です。
(※1)
SSO とは、複数台の WAS セキュリティー・サーバーが存在する場合に、一度ユーザーが DNS ドメイ
ンで認証されると、他のセキュリティー・サーバーにアクセスする場合に再度認証を行うことなく、同一の
ユーザーとしてリソースへのアクセスを継続できる機能です。WAS は、SSO をサポートしていますが、
SSO を使用するには LTPA の使用が前提となります。
5-2-5 ユーザー・レジストリー
WAS のユーザー・レジストリーは、基本認証、またはクライアント証明書を使用したユーザー認証に
使用されます。ユーザーおよびグループについての情報を検索し、ユーザーおよびグループのセキュリ
ティー・ロールへのマッピングなど、セキュリティーに関連する管理機能を実行します。WAS はさまざまな
タイプのユーザー・レジストリーをサポートしています。
WAS は、ユーザー・レジストリーとして以下の４種類の方式を提供しています。
•
ローカル OS レジストリー
ローカル・マシン上の OS のユーザー情報がレジストリーとして使用され、ユーザーID とパ
スワード情報が認証時に使用されます。アプリケーション・サーバーが複数のマシンに分
-9-
散しているセル環境では、各マシンが独自のユーザー・レジストリーを持つため、ローカ
ル OS ユーザー・レジストリーを使用しないでください。ユーザー・レジストリーから取り出し
た ID は、通常、固有の ID であるため、まったく同じユーザーとパスワードが各マシン上に
存在しても、マシンごとに異なります。また、UNIX システムでローカル OS ユーザー・レジ
ストリーを使用する場合、WAS プロセスを実行するプロセス ID は、ユーザーやグループ
情報取得用のローカル OS の API を呼び出すために、root 権限を持っている必要があり
ます。
•
LDAP レジストリー
LDAP は、LDAP バインディングを使用する認証が行われるユーザー・レジストリーです。
WAS セキュリティーは、ユーザーおよびグループの情報用リポジトリーとして機能する主
要な LDAP ディレクトリー・サーバーのインプリメンテーションを提供し、サポートします。こ
れらの LDAP サーバーは、ユーザー認証やその他のセキュリティー関連タスクの際に呼
び出されます。カスタム LDAP フィーチャーにより、適切なフィルターを使用すれば、製品
がサポートする LDAP サーバーのリストにはない、他の任意の LDAP サーバーをユーザ
ー・レジストリーとして使用できます。
•
カスタム・ユーザー・レジストリー
開発者は、com.ibm.websphere.security.UserRegistry インターフェースを実装することによ
り、セキュリティーに使用するユーザー・レジストリーを自由に作りこむことができます。カス
タム・ユーザー・レジストリーは、リレーショナル・データベース、フラット・ファイルなど、事
実上あらゆるタイプのアカウント・レポジトリーをサポートすることができます。既存のアプ
ケーションでユーザーID、パスワードを管理するためにデータベースを使用している場合
などは、このインターフェースを実装すればそのデータベースを WAS セキュリティーのユ
ーザー・リポジトリーとすることが可能です。
•
統合リポジトリー
統合リポジトリーは、複数のレジストリーを同時に使用しながら論理的な単一リポジトリー
のビューを提供します。1 つのレルム下には、次の 3 種類のユーザー・リポジトリーの組み
合わせが可能です。
・
・
・
ビルドインされたファイル・ベース・リポジトリー
1 つ以上の外部リポジトリー
ファイル・ベース・リポジトリーと 1 つ以上の外部リポジトリー
統合リポジトリーは read/write 両方をサポートします。統合リポジトリーがサポートするリポ
ジトリーのタイプはさまざまで、以下の 4 種類のリポジトリーをサポートします。ファイル・ベ
ースのリポジトリーはデフォルトで提供されます。
¾ ファイル・ベース
¾ LDAP（または LDAP のサブツリー）
¾ データベース
¾ カスタム
このうちデータベースとカスタムは管理コンソールから操作することはできません。コマン
ドラインからのみサポートされていますのでご注意ください。なお、統合リポジトリーを使用
する場合、ユーザーは統合リポジトリーに追加されている複数リポジトリー内でユニークで
ある必要があります。
- 10 -
5-2-6 仮想メンバー・マネージャー（VMM:virtual
member manager）
VMM = Virtual Member Manager
アプリケーション
管理コンソール
wsadmin
Administrative Command Framework
認証
(JAAS)
VMM ユーザー管理
VMM構成管理
VMM
VMM
構成
APIs
ランタイム
APIs
Property Ext
リポジトリー
CUR
LDAP
VMM
WASセキュリティ
Adaptor
Adaptor
Adaptor
Adaptor
File
LDAP
DB
Custom
Adaptor
Local OS
ユーザー・レジストリー
DB
図 5-6 VMM アーキテクチャー概要
統合リポジトリーが提供するユーザーやグループの管理、同時に複数のレジストリーをサポートする機
能は仮想メンバー・マネージャー（VMM）によって提供されています。VMM の目的は、ユーザーおよび
組織情報に対して、単一のモデルを提供することです。つまり VMM は、リポジトリーに特化しない、ユ
ーザーとグループを管理するための API とスキーマを提供します。この管理機能は、管理コンソール、コ
マンドライン・ユーティリティ、公開された API から利用できます。
5-2-7 認証プロセス
前述の認証メカニズム機構とユーザー・レジストリーによって行われる WAS V6.1 の認証プロセスは、
図 5-7 のような流れとなります。
基本的に、認証が必要なのは EJB クライアントと Web クライアントが保護リソースにアクセスする場合
です。サーブレット、EJB、または純粋な EJB クライアントは、CSIv2 や SAS といったプロトコルを使用し
て、WAS に認証情報を送信します。Web クライアントは、HTTP や HTTPS といったプロトコルを使用し
て認証情報を送信します。
認証情報は、基本認証、信任状トークン（LTPA の場合）、またはクライアント証明書のいずれかです。
Web 認証は Web オーセンティケーター・モジュールにより実行され、EJB 認証は CSIv2 および SAS 層
にある EJB オーセンティケーター・モジュールにより実行されます。認証モジュールは、JAAS ログイン・
モジュールを使用して実装されます。Web オーセンティケーターおよび EJB オーセンティケーターは、ロ
グイン・モジュールに認証データを渡し、データを認証するために LTPA の認証モジュールを呼び出しま
す。認証モジュールは、認証にローカル OS、LDAP、カスタム・ユーザー・レジストリーのいずれかをユー
ザー・レジストリーとして使用します。
認証後にログイン・モジュールによって作成される信任状は、Web オーセンティケーター・モジュール
または EJB オーセンティケーター・モジュールに返されます。そして、Web オーセンティケーター・モジュ
- 11 -
ールまたは EJB オーセンティケーター・モジュールは、アクセス許可の仕組みが後に参照できるよう、こ
の信任状を保管しておきます。
図 5-7 認証プロセス
5-2-8 設定方法
ここでは、管理コンソールを使用した統合リポジトリー、SSO、トラスト・アソシエーション、ユーザー・レ
ジストリーなどの設定方法を紹介します。
5-2-8-1 統合リポジトリー
統合リポジトリーの設定は、管理コンソールの[セキュリティー]→[管理、アプリケーション、およびイン
フラストラクチャーの保護]→ユーザー・アカウント・リポジトリー・フィールドの[使用可能なレルム定義]で
[統合リポジトリー]を選択し、右隣の[構成]ボタンをクリックします。デフォルトではレルム内のリポジトリー
はファイル・ベースのリポジトリーのみです。
- 12 -
統合リポジトリー画面では、[ベース・エントリーをレルムに追加]ボタンをクリックします。
リポジトリー参照画面で、[リポジトリーの追加]ボタンをクリックし、追加リポジトリーへのセキュア・アクセ
スに関する構成を次画面で行います。必要な項目を入力したら[OK]ボタンを押します。
管理コンソールから、[セキュリティー]→[管理、アプリケーション、およびインフラストラクチャーの保
護]を開き、ユーザー・アカウント・リポジトリー・フィールドの[使用可能なレルム定義]で[統合リポジトリー]
を選択し、右隣の[構成]ボタンをクリックします。関連項目の[リポジトリーの管理]をクリックすると、追加さ
れたリポジトリーを確認することができます。
5-2-8-2 SSO
SSO（シングル・サインオン）とは、複数のシステムの認証処理を 1 回のログオンで実行する認証方法
です。例えばそれぞれ認証が必要なシステム A とシステム B があります。これらのシステムが SSO を実
現していると、システム A で認証を行ったクライアントは、システム B にアクセスする際に再度認証を必要
とすることなくアクセスが可能になります。
- 13 -
WAS では LTPA 認証方式で SSO をサポートしています。これは、WAS が LTPA 鍵の交換をサポート
しているため実現することができます。LTPA 認証方式では、クライアントは最初に認証を受けたサーバ
ーから LTPA トークンを受け取ります。この LTPA トークンはユーザー情報と有効期限が含まれています。
2 回目以降のアクセスでは、LTPA トークンを持ってサーバーにアクセスし、サーバーはトークンの内容に
従って認証を行います。従って、異なるシステム間で認証に使用する LTPA トークンを共通化することで
SSO を実現することが可能になります。ただし、SSO もフォーム認証と同様に、j_username ヘッダーに含
まれるユーザーID やパスワードは暗号化されていないのでご注意ください。従って HTTP で使用するこ
とはユーザーID/パスワードが盗聴される危険にさらされます。この危険を回避するために、フォーム認
証では必ず SSL を使用する必要があります。
SSO におけるログインの処理の流れを表したのが、図 5-8 になります。
/FormAuth/login.html がシステムのログオン画面です。この画面でユーザーID/パスワードを入力して
ログオンボタンをクリックすると、サーバーに対する認証要求が実行されます。ユーザーID とパスワード
が正しい場合には LTPA トークンが発行され、保護されたリソースに対してアクセス可能になります。この
後システム B の保護されたリソースに対してアクセスをします。この際 HTTP リクエストにはシステム A で
発行された LTPA トークンが付加されています。システム B はシステム A の LTPA トークンの情報を元に、
クライアントからにリクエストを許可して、画面を返します。
図 5-8 SSO におけるログイン処理の流れ
SSO の設定は、管理コンソールから LTPA トークンを共有する範囲を指定するドメイン・ネームの設定
と、LTPA 鍵の交換を行う必要があります。LTPA を共有する範囲をの設定は、[セキュリティー]→[管理、
アプリケーション、およびインフラストラクチャーの保護]→[SSO]を開いて行います。ドメイン・ネームを入
力します。デフォルトはサーバー名です。クライアントはここで設定されたドメイン名に対して、同じ LTPA
トークンを付加します。したがって、ドメイン名が異なるシステム間では SSO を実現することは出来ませ
ん。
- 14 -
図 5-9 SSO の設定
LTPA の交換のため、鍵のエクスポートとインポートを行います。
特定のサーバーから LTPA 鍵をエクスポートします。インポート時に必要となるパスワードを入力しま
す。パスワードは任意の値を入力することが可能です。完全修飾鍵ファイル名は、LTPA 鍵をエクスポー
トするファイル名を完全修飾名で指定して、エクスポートボタンをクリックします。エクスポートを行う画面
は[セキュリティー]-[管理、アプリケーション、およびインフラストラクチャーの保護]-[認証メカニズムおよ
び有効期限]です。エクスポートした LTPA 鍵はテキスト形式ですので、テキスト・エディタで内容を確認
することができます。
エクスポートした LTPA 鍵を別のサーバーでインポートします。
まずエクスポートで作成したファイルのインポートを行うサーバーまで移動させます。そしてエクスポー
ト時に指定したパスワードを入力し、完全修飾鍵ファイル名を指定してインポートボタンをクリックします。
インポートを行う画面は、エクスポートを行う画面と同じで[セキュリティー]-[管理、アプリケーション、およ
びインフラストラクチャーの保護]-[認証メカニズムおよび有効期限]です。
図 5-10 LTPA 鍵のインポート・エクスポート画面
構成を保管し、アプリケーション・サーバーあるいはデプロイメント・マネージャーを再起動します。
- 15 -
5-2-8-3 トラスト・アソシエーション
トラスト・アソシエーションにより、WAS セキュリティーとサード・パーティー製セキュリティー・サーバーと
を統合することができます（「5-1-2 セキュリティー概観」参照）。トラスト・アソシエーションの設定は、管理
コンソールの[セキュリティー]→[管理、アプリケーション、およびインフラストラクチャーの保護]→[認証]
→[Web セキュリティー]→[トラスト・アソシエーション]を開いて行います。各項目に適切な値を設定して
から構成を保管し、アプリケーション・サーバーあるいはデプロイメント・マネージャーを再起動します。
図 5-11 トラスト・アソシエーションの設定画面
•
トラスト・アソシエーションを使用可能にする
トラスト・アソシエーション機能を有効にするかどうかを指定します。トラスト・アソシエーショ
ン機能により、WAS セキュリティーとサード・パーティー製セキュリティー・サーバーを統合
することができます。つまり、リバース・プロキシー・サーバーがフロントエンド認証サーバ
ーとして機能できるようになる一方で、プロキシー・サーバーから渡された信任状をこの製
品自体の認証ポリシーに適用することができるようになります。
5-3 認可
この節では、WAS V6.1 における基本的なセキュリティー技術の一つである認可について説明しま
す。
5-3-1 認可とは
認可とは、認証されたユーザーが、要求するリソースにアクセスする権限をもっているかを判定するプ
ロセスであり、アクセス制御とも言われます。
5-3-2 認可モデル
WAS セキュリティーにおける認可は、J2EE のセキュリティー・モデルに基づいて行われます。J2EE の
認可の情報については、下記サイトから詳細が得られます。
Sun Developer Network (SDN) Java EE: Do more with less work
http://java.sun.com/j2ee/index.jsp
- 16 -
個々のユーザーに対してアクセス制御を行うのではなく、セキュリティー・ロールという概念の元にアク
セス制御を行います。セキュリティー・ロールを使用することによって、ユーザー管理を WAS 環境から分
離することができます。HTML、サーブレット、JSP、EJB などといったリソースに対して、図 5-12 のように
セキュリティー・ロールを設定してアクセス制御を行うことができます。例えば、Teller ロールを設定しま
す。表から Teller ロールは AccountBean method の getBalance を実行することが可能です。このロール
を持つユーザーは、Teller Group と Bob になります。よって、Bob は getBalance を実行することができ
るユーザーになります。
図 5-12 セキュリティー・ロールの設定例
WAS の認可モデルには、以下の二形態があります。それぞれの詳細は後述します。（「5-3-3 宣言セ
キュリティー」、「5-3-4 プログラマティック・セキュリティー」参照）
•
宣言セキュリティー（デクララティブ・セキュリティー）
デプロイメント・ディスクリプターにセキュリティー・ポリシーを記述する方法
•
プログラマティック・セキュリティー
API を使用してコード内でセキュリティー・タスクを実装する方法
5-3-3 宣言セキュリティー
宣言セキュリティーは、アプリケーションのアセンブリー段階で構成されるもので、セキュリティー・ポリ
シーなどの情報はデプロイメント記述子で宣言または定義されています。宣言セキュリティーは、セキュ
リティー・ラインタイムによって施行されます。ここに、デプロイメント記述子の一例を示します。
<servlet-mapping id="ServletMapping_8">
<security-constraint id="SecurityConstraint_5">
<web-resource-collection id="WebResourceCollection_5">
<web-resource-name>HitCount Protected Area</web-resource-name>
<url-pattern>/HitCount/*</url-pattern>
<http-method>DELETE</http-method>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
</web-resource-collection>
<auth-constraint id="AuthConstraint_5">
<description>All Role - HitCount:+:</description>
<role-name>All Role</role-name>
</auth-constraint>
</user-data-constraint>
- 17 -
5-3-4 プログラマティック・セキュリティー
プログラマティック・セキュリティーは、宣言セキュリティー単独ではアプリケーションのセキュリティー・
モデルを表現するのに十分でない場合に、セキュリティーを重視するアプリケーションによって使用され
ます。Servlet と EJB に対して API を提供しており、コードの中でそれらを使用してセキュリティー・タスク
を実装することができます。
プログラマティック・セキュリティーは、HttpServletRequest インターフェースの以下のメソッドから構成さ
れています。
•
HttpServletRequest.getRemoteUser
クライアント認証に使用したユーザー名を戻します。ユーザーが認証されていない場合
は、null を戻します。
•
HttpServletRequest.isUserRole
リモート・ユーザーに指定されたセキュリティー・ロールが与えられている場合は、true を戻
します。リモート・ユーザーが、指定されたロールを与えられていない場合、またはユーザ
ーが認証されていない場合は、false を戻します。
•
HttpServletRequest.getUserPrincipal
リモート・ユーザー名を含む java.security.Principal オブジェクトを戻します。ユーザーが認
証されていない場合は、null を戻します。
また、javax.ejb.EJBContext インターフェースで提供される次の２つのメソッドを使用すると、EJB の呼
び出し元についてのセキュリティー情報にアクセスすることができます。
•
IsCallerInRole
Bean の呼び出し元に、ロール名で指定されているセキュリティー・ロールが認可されてい
る場合は、true を戻します。呼び出し元に指定のロールが認可されていない場合、または
呼び出し元が認証されていない場合は、false を戻します。指定のロールに、全員のアク
セスが認可されている場合は、常に true を戻します。
•
getCallerPrincipal
Bean 呼び出し元の名前を含むプリンシパル・オブジェクトを戻します。呼び出し元が認証
されていない場合は、認証されていない名前を含むプリンシパルを戻します。
5-3-5 代行モデル
代行とは、セキュリティーID を呼び出し元から呼び出されるオブジェクトに伝搬するプロセスです。
J2EE 仕様により、サーブレットと EJB は、EJB を呼び出す際にクライアント ID を伝搬することも、あるいは
デプロイメント記述子で明示指定された別の ID を使用することもできます。WAS では、図 5-13 のように
クライアント ID、指定済み ID、システム ID といった３つのタイプの代行が可能です。
- 18 -
図 5-13 代行モデル
5-3-6 認可プロセス
前述のような認可機構によって行われる WAS V6.1 の認可プロセスは、図 5-14 のような流れとなりま
す。
図 5-14 認可プロセス
- 19 -
Web クライアントからの Web リソース・アクセスは、Web コラボレーターによって処理されます。Java クラ
イアントからの EJB リソース・アクセスは、EJB コラボレーターによって処理されます。Web コラボレーター
と EJB コラボレーターは、ORBcurrent オブジェクトからクライアント信任状を抽出します。クライアント信任
状は、認証プロセスの際に ORB current オブジェクトで受け取った信任状として設定されます。リソースと
信任状はアクセス・マネージャーに提示され、クライアントに対して、そのクライアントが要求しているリソ
ースへのアクセスが許可されているかどうかがチェックされます。
アクセス・マネージャー・モジュールには、リソース許可モジュールと許可表モジュールといった２つの
メイン・モジュールがあります。リソース許可モジュールは、指定のリソースに必要なロールを決定するの
に役立ちます。このモジュールは、セキュリティー・ランタイムがアプリケーションの始動時に作成する、リ
ソースからロールへのマッピング表を使用します。リソースからロールへのマッピング表を作成するため
に、セキュリティー・ラインタイムは EJB または Web モジュールのデプロイメント記述子を読み取ります。
許可表モジュールは、ユーザーまたはグループに対するロール表を調べ、クライアントに必要なロール
のいずれかが付与されているかどうかを判断します。ロールからユーザーまたはグループへのマッピン
グ表は許可表とも呼ばれ、アプリケーション始動時にセキュリティー・ランタイムによって作成されます。
許可表を作成するために、セキュリティー・ランタイムはアプリケーション・バインディング・ファイル
ibm-application-bnd.xml を読み取ります。
呼び出し元がサービスの要求に必要な特権を持っているかどうかを判別するためには、許可情報を
使用します。許可情報は、いろいろな方法で保管できます。例えば、リソースごとにアクセス制御リストを
保管することができ、ここには、ユーザーおよびユーザー特権のリストが含まれています。もう１つの保管
方法は、リソースのリストとそれに対応する特権を各ユーザーに関連付けることです。
5-3-7 設定方法
ここでは、AST を使用したセキュリティー・ロールの設定方法や、そのロールを実際のユーザーにマッ
ピングさせる設定方法を紹介します。
5-3-7-1 セキュリティー・ロールの設定
アプリケーションへのアクセスに対して認可処理を行うためには、アプリケーションにセキュリティー・ロ
ールの設定を行う必要があります。ここでは、AST を使用した設定方法を紹介します。手順としては、Ear
ファイルへのセキュリティー・ロール設定、Web モジュールへのセキュリティー設定、EJB モジュールへの
セキュリティー設定を行い、必要に応じて代行の設定を行います。
1). Ear ファイルへのセキュリティー・ロール設定
アプリケーション・デプロイメント記述子エディターを使用して、エンタープライズ・アプリケーションのセ
キュリティー・ロールを定義します。セキュリティー・ロールは、プリンシパルを論理的にグループ化したも
のです。EJB メソッドのようなオペレーションへのアクセスは、ロールにアクセス許可を与えることで制御さ
れます。
(i)
J2EE パースペクティブの[プロジェクト・エクスプローラー]ビューで、エンタープライズ・
アプリケーション・プロジェクトのデプロイメント記述子（application.xml）を右クリックし
て、[アプリケーションから開く]→[デプロイメント記述子エディター]を選択します。アプリ
ケーション・デプロイメント記述子エディターが開くので、[セキュリティー]タブをクリックし
ます。
- 20 -
(ii) [セキュリティー]ページで[追加]をクリックし、[セキュリティー役割の追加]ウィザードでロ
ール名と説明（任意）を入力してから[終了]をクリックします。
てから[終了]をクリックします。
- 21 -
(iii) 追加したセキュリティー・ロールを選択した状態で、[全員]、[すべての認証ユーザー]、
[ユーザー/グループ]のいずれかを選択してバインディングを行います。
−
−
−
全員
認証されていないユーザーも含む全てのユーザーを割り当てます。
すべての認証ユーザー
認証に成功したすべてのユーザーを割り当てます。
ユーザー/グループ
特定のユーザーあるいはグループを割り当てます。
(iv) 構成を保管します。
2). Web モジュールへのセキュリティー設定
Web デプロイメント記述子エディターを使用して、アプリケーション記述子に定義したロールにアクセ
ス許可を与えます。
(i)
J2EE パースペクティブの[プロジェクト・エクスプローラー]ビューで、動的 Web プロジェ
クトのデプロイメント記述子（web.xml）を右クリックして、[アプリケーションから開く]→[デ
プロイメント記述子エディター]を選択します。Web デプロイメント記述子エディターが
開くので、[セキュリティー]タブをクリックします。
- 22 -
(ii) [セキュリティー]ページの[セキュリティー役割]で[追加]をクリックし、[セキュリティー役割
の追加]ウィザードでロール名（ここでは wasadm）と説明（任意）を入力してから[終了]
をクリックします。
- 23 -
(iii) [セキュリティー]ページの[セキュリティー制約]で[追加]をクリックし、[セキュリティー制約
の追加]ウィザードでロール名（ここでは wasadm）を入力し、[次へ]をクリックします。
(iv) [リソース名]を入力し、HTTP 方式（ここでは GET と POST）を選択し、パターン（ここで
は「/*」）を追加し、[終了]をクリックします。
- 24 -
(v) [セキュリティー制約]→[許可役割]で[追加]をクリックし、適切なロール（ここでは
wasadm）を選択して[終了]をクリックします。
(vi) 構成を保管します。
3). EJB モジュールへのセキュリティーの設定
EJB デプロイメント記述子エディターを使用して、アプリケーション記述子に定義したロールにアクセス
許可を与えます。
(i)
J2EE パースペクティブの[プロジェクト・エクスプローラー]ビューで、EJB プロジェクトの
デプロイメント記述子（ejb.jar.xml）を右クリックして、[アプリケーションから開く]→[デプ
ロイメント記述子エディター]を選択します。EJB デプロイメント記述子エディターが開く
ので、[アセンブリー]タブをクリックします。
(ii) [アセンブリー記述子]ページの[セキュリティー役割]で[追加]をクリックし、[セキュリティ
ー役割の追加]ウィザードでロール名（ここでは wasadm）と説明（任意）を入力してから
[終了]をクリックします。
- 25 -
(iii) [アセンブリー記述子]ページの[メソッド・アクセス権]で[追加]をクリックし、[メソッド・アク
セス権の追加]ウィザードで[セキュリティー役割]か[未検査]のいずれかを選択します。
[セキュリティー役割]の場合は、リストされる既存のセキュリティー・ロールを選択して[次
へ]をクリックします。（EJB1.x プロジェクトの場合は[セキュリティー役割]を選択）
−
セキュリティー役割
選択されたセキュリティー・ロールを使用すると、メソッドは呼び出される前に
許可について検査されます。
−
未検査
メソッドが、呼び出される前に許可について検査されません。
- 26 -
(iv) [メソッド・アクセス権の追加]ウィザードで、リストされるエンタープライズ Bean のうち１つ
以上を選択して[次へ]をクリックします。
- 27 -
(v) [メソッド・アクセス権の追加]ウィザードで、選択したエンタープライズ Bean のメソッドが
リストされるので、アクセス制御を行いたいメソッド１つ以上を選択して[終了]をクリックし
ます。
(vi) 構成を保管します。
4). 代行の設定
セキュリティーID を呼び出し元から呼び出されるオブジェクトに伝搬させたい場合の設定方法を紹介
します。EJB デプロイメント記述子には、前述の方法により、セキュリティーID にするセキュリティー・ロー
ル（ここでは wasadm）が追加されていることを前提条件とします。
(i)
J2EE パースペクティブの[プロジェクト・エクスプローラー]ビューで、EJB プロジェクトの
デプロイメント記述子を右クリックして、[アプリケーションから開く]→[デプロイメント記述
子エディター]を選択します。EJB デプロイメント記述子エディターが開くので、[アクセ
ス]タブをクリックします。
(ii) [アクセス]ページの[セキュリティーID（Bean レベル）]で[追加]をクリックし、[セキュリティ
ーID]ウィザードで[呼び出し元の ID を使用]あるいは[特定の役割に割り当てられた ID
を使用]のいずれかの Run-as モードを選択して[次へ]をクリックします。ここで後者を選
択した場合、[役割名]には[アセンブリー記述子]ページで追加したセキュリティー・ロー
ルがリストされるのでそれを選択します。
- 28 -
(iii) リストされるエンタープライズ Bean のうち１つ以上を選択して[終了]をクリックします。
(iv) J2EE パースペクティブの[プロジェクト・エクスプローラー]ビューで、エンタープライズ・
アプリケーション・プロジェクトのデプロイメント記述子を右クリックして、[アプリケーショ
ンから開く]→[デプロイメント記述子エディター]を選択します。アプリケーション・デプロ
イメント記述子エディターが開くので、[セキュリティー]タブをクリックします。セキュリティ
- 29 -
ー・ロールを選択して[バインディングでのセキュリティー・ロールの実行]で[追加]をクリ
ックし、適切なユーザーID とパスワードを入力して[終了]をクリックします。
(v) 構成を保管します。
5-3-7-2 実ユーザーとのマッピング
セキュリティー・ロールの設定がされているアプリケーション（Ear ファイル）を WAS 上にインストールす
る際、定義されているセキュリティー・ロールと実際にレジストリー内に登録されているユーザーのマッピ
ングを行う必要があります。ここでは、管理コンソールを使用した設定方法を紹介します。
1). 新規アプリケーションのインストール
WAS の管理コンソールから[アプリケーション]→[新規アプリケーションのインストール]を開き、セキュ
リティー・ロールの設定がされている Ear ファイルを指定して[OK]をクリックします。その後も、各項目に
適切な値を入力して進めていきます。
- 30 -
2). RunAs ロールのマップ
[RunAs 役割をユーザーにマップ]で、適切なユーザーID とパスワードを入力して[次へ]をクリックしま
す。
3). セキュリ
ー・ロールのマップ
ティ
[セキュリティー役割をユーザー/グループにマップ]で、ロール（ここでは wasadm）を選択して[ユー
ザーの検索]をクリックします。
- 31 -
4). ユーザー/グループの検索
[ユーザーまたはグループの検索]で、アプリケーションに設定されているロールがリストされます。[スト
リングの検索]に検索条件となる文字列を入力して[検索]をクリックします。
5). ユーザー/グループの選択
[使用可能]フィールドに、レジストリー内で有効なユーザーがリストされます。セキュリティー・ロールと
マップさせたユーザーを選択して[>>]をクリックします。選択されたものは、[選択済み]フィールドにリスト
されます。その後も、各項目に適切な値を入力して進めていきます。
- 32 -
6). 構成の保管
インストールが完了したら構成を保管します。これで、アプリケーションに設定されているセキュリティ
ー・ロールと実際のレジストリー内のユーザーのマップ作業は完了です。
5-4 SSL
この節では、WAS V6.1 における基本的なセキュリティー技術の一つである SSL について説明しま
す。
5-4-1 SSLとは
SSL とは、クライアントとサーバー間のセキュア接続のための認証性、保全性、および機密性のあるト
ランスポート層セキュリティーを提供するプロトコルです。このプロトコルは、TCP/IP の上位、かつ HTTP、
LDAP、ORB/IIOP などのアプリケーション・プロトコルの下位で実行され、トランスポート・データに信頼
性とプライバシーを提供します。
- 33 -
クライアントとサーバー双方の SSL 構成に応じて、さまざまなレベルの信頼性、データ保全性、および
プライバシーを確立することができます。適切な構成を行い、クライアントとアプリケーション両方のデー
タに必要な保護レベルを実現するためには、SSL の基本動作について理解していることが非常に重要
です。
SSL によって提供されるセキュリティー・フィーチャーの中には、データの伝送中に機密情報が漏れな
いようにするためのデータの暗号化があります。また、データの署名により、データの転送中にデータが
許可なく変更されることを防止できます。更に、クライアント認証およびサーバー認証により、適切なユー
ザーまたはマシンと通信していることが保証されます。SSL は、エンタープライズ環境の通信の保護に効
果的です。
図 5-15 SSL の仕組み
5-4-2 SSL構成
WAS では、内部にある複数のコンポーネントが SSL を使用することで、データを信頼できるものにし、
プライバシーを保護します。これらのコンポーネントとは、標準装備された HTTP トランスポート、ORB、
およびセキュア LDAP クライアントです。
各コンポーネント間において使用される SSL は、以下の通りです。
•
HTTP トランスポート
WAS に組み込まれた HTTP トランスポートは、ブラウザなどの Web クライアントから SSL を
介した HTTP 要求を受け入れます。
•
ORB
WAS で使用される ORB は、SSL を介して IIOP を実行し、メッセージを保護します。
•
セキュア LDAP クライアント
- 34 -
セキュア LDAP クライアントは、SSL を介して LDAP を使用し、LDAP ユーザー・レジストリ
ーへのセキュア接続を実現します。このクライアントは、LDAP をユーザー・レジストリーと
して構成する場合にのみ存在します。
5-4-3 設定方法
ここでは、Web ブラウザと Web サーバー間および Web サーバーと WAS 間を SSL 通信させるための
設定方法をそれぞれ紹介します。
5-4-3-1 WebブラウザとWebサーバー間のSSL構成
WAS は Web ブラウザと Web サーバー間での SSL 通信をサポートしています。SSL 通信には Web サ
ーバーの機能が使用され、Web サーバー側で SSL 通信を可能にするための設定を行う必要がありま
す。具体的な手順は、Web サーバーの製品ごとに異なりますので、各製品のマニュアル等を参照してく
ださい。ここでは、Web サーバーとして IHS を使用している場合の設定方法を紹介します。
•
Web サーバーの設定
IHS で SSL 通信の設定を行うには、IHS の構成ファイル<IHS_root>/conf/httpd.conf を編
集します。IHS の構成ファイルは、WAS の管理コンソールを介して編集することもできま
す。httpd.conf を開き、次の行をファイルの下部に追加します。
LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
Listen 443
<VirtualHost droplet.austin.ibm.com:443>
ServerName droplet.austin.ibm.com
DocumentRoot <IHS_root>/htdocs
SSLEnable
#SSLClientAuth required
</VirtualHost>SSLDisable
Keyfile <IHS_root>/serverkey.kdb
鍵ファイルのホスト名とパスは適宜変更してください。また、SSLClientAuth ディレクティブ
のコメントアウトをはずすことにより、クライアント認証をサポートすることができます。
•
WAS の設定
WAS では、SSL 通信用のポートを使用して IHS と通信できるようにするには、仮想ホスト
default_host にホスト・エイリアスを追加する必要があります。管理コンソールの[環境]→
[仮想ホスト]→[default_host]→[ホスト別名]を選択します。[新規作成]ボタンをクリックし
て、該当するフィールドに SSL 通信に使用するポート番号（通常は 443）を指定して、エイ
リアスを追加します。
- 35 -
5-4-3-2 WebサーバーとWASのSSL構成
Web サーバーと WAS 間で SSL 通信を行うためには、Web サーバーに組み込まれて実際にアプリケ
ーション・サーバーと通信を行っている Web サーバー・プラグインに SSL 通信用の設定を行う必要があり
ます。また、通信相手となる Web コンテナーにも設定を行う必要があります。ここでは、Web サーバーとし
て IHS を使用している場合の設定方法を紹介します。
注）
デフォルト構成では、Web ブラウザと Web サーバー間が SSL 通信を行っている場合、Web サーバー
と WAS は自動的に SSL 通信用ポートを使用して SSL 通信を行います。パフォーマンスの観点から、明
示的に Web サーバーと WAS 間で SSL 通信をさせないためには、WAS で定義されている SSL 通信用
のトランスポートを削除する必要があります。この方法に関しては、本書では割愛させていただきますこと
をご了承ください。
1). Web サーバー・プラグイン用の自己署名証明書の作成
Web サーバー・プラグインはそれ自身の秘密鍵と公開鍵を保管し、Web コンテナーの鍵ファイルの公
開証明書を保管するために、鍵リング（鍵データベース）を必要とします。Web サーバー・プラグイン用の
自己署名証明書を作成するには、以下のステップを実行します。
(i) CMS タイプの鍵リングを作成
管理コンソールから[セキュリティー]→[SSL 証明書および鍵管理]→[エンドポイント・セキュ
リティ構成の管理 ] を選択します。 [ インバウンド ] → <Node_name> → [servers] →
<webserver_name>を開きます。関連項目の[鍵ストアおよび証明書]を選択し、[新規作
成]の順に選択し、以下のように設定し、[OK]をクリックします。
名前：WAS61PluginCertificates（任意）
パス： <IHS_Install_root>¥conf¥keys¥WAS6PluginCertificates.kdb（任意）
パスワード：passw0rd（任意）
タイプ：CMSKS
- 36 -
(ii) 個人証明書を作成します。
管理コンソールから[セキュリティー]→[SSL 証明書および鍵管理]→[エンドポイント・セキュ
リティ構成の管理 ] を選択します。 [ インバウンド ] → <Node_name> → [servers] →
<webserver_name>を選択します。WAS6PluginCertificates を選択し、[個人証明書]→
[自己署名証明書の作成]を順に選択し、以下のように設定し、[OK]をクリックします。
別名：WAS6PluginCert
共通名：マシン名
有効期間：365 日（デフォルト）
組織：組織名
次に、Web コンテナー用の自己署名証明書の作成を行います。
(iii) JKS タイプの鍵ストアを作成
管理コンソールから[セキュリティー]→[SSL 証明書および鍵管理]→[エンドポイント・セキュリ
ティ構成の管理 ] を選択します。 [ インバウンド ] → <Node_name> → [servers] →
<server_name>を選択します。[鍵ストアおよび証明書]を選択し、[新規作成]をクリックしま
す。以下の値が入力できたら[OK]ボタンをクリックします。
名前： WAS6WebContainerCertificates
パス：<WAS_root>/profiles/Profile_name>/cells/SSLCell
/WAS6WebContainerCertificates.jks
パスワード：任意のパスワードを指定
タイプ：JKS
(iv) 個人証明書を作成します。
管理コンソールから[セキュリティー]→[SSL 証明書および鍵管理]→[エンドポイント・セキ
ュリティ構成の管理 ] を選択します。 [ インバウンド ] → <Node_name> → [servers] →
<webserver_name>を選択します。WAS6PluginCertificates を選択し、[個人証明書]→
[自己署名証明書の作成]をクリックします。以下の値を入力して[OK]をクリックします。
別名：WAS6CustNode01Cert
共通名：マシン名
有効期間：365 日（デフォルト）
組織：組織名
(v) 作成した公開鍵を交換します。
[SSL 証明書および鍵管理]→[エンドポイント・セキュリティ構成の管理]→server1→[鍵ス
トアおよび証明書]を選択します。作成した２つの鍵ストアにチェックを入れ、[署名者の交換]
をクリックします。 WAS6WebContainerCertificates の個人証明書を
WAS6PluginCertificates の署名者に追加します。WAS6PluginCertificates の個人証明書
を WAS6WebContainerCertificates の署名者に追加します。最後に[適用]をクリックし、
[OK]を選択します。
(vi) 鍵ストア構成を作成します。
- 37 -
[セキュリティー]→[SSL 証明書と鍵管理]→[エンドポイント・セキュリティ構成の管理]→イ
ンバウンド→（セル名）を選択します。[鍵ストアと証明書]→[新規作成]ボタンをクリックし、作
成する鍵ストア構成の値を入力します。
名前：WebContainerKeyStore
パス：${CONFIG_ROOT}¥cells¥<セル名>¥WAS6WebContainerCertificates.jks
パスワード：任意のパスワード
タイプ：JKS
(vii) SSL 構成を作成します。
[SSL 証明書と鍵管理]→[SSL 構成]→[新規作成]を選択し、作成する SSL 構成の値を
入力します。
名前：WebContainerSSL
トラスト・ストア名：WebContainerKeyStore（リストから選択）
鍵ストア名：WebContainerKeyStore（リストから選択）
証明書エイリアスを取得します。[証明書エイリアスの取得]をクリックします。サーバーとク
ライアント証明書エイリアスを選択し、適用をクリックします。（※クライアント認証、
CipherSuite、プロバイダーやプロトコルの設定をするにはこの手順の後に、追加プロパティ
ー＞QoP を選択します。）
構成を保存します。
(viii) Web コンテナーが、前手順で作成した個人証明書を使用するように構成を修正しま
す。
[サーバー]→[アプリケーション・サーバー]を選択しサーバー名を選択します。[Web コン
テナー設定]→[Web コンテナー・トランスポート・チェーン]を選択します。
WCInboundSecure をクリックし、使用可能にチェックが入っているのを確認します。
SSL インバウンド・チャネル（SSL2）をクリックし、このエンドポイント特定を選択して、リス
トから WebContainerSSL を選択します。[OK]を選択して構成を保存し、Web サーバー・プ
ラグインの再生成と伝播を行います。
(ix) Web サーバー・プラグインファイルの修正をします。
プラグイン用に作成した鍵ストア・ファイルとスタッシュ・ファイルを Web サーバーのレポジ
トリ・ディレクトリにコピーします。
＜WAS_Root＞/profiles/AppSrv01/config/cells/cellname/nodes/nodename/
server/webserver1/
管理コンソールでプラグイン・プロパティを変更します。[サーバー]→[Web サーバー]→
[webserver1]を選択します。追加プロパティーのプラグイン・プロパティを選択し、以下の
値を修正します。
プラグインの鍵ストア・ファイル名
・WAS6PluginCertificates.kdb
プラグインの鍵ストアディレクトリとファイル名
・<Plugin_Install_Root>/config/webserver1/ WAS6PluginCertificates.kdb
- 38 -
ログレベル
・Trace
Web サーバー鍵ストアディレクトリにコピーするをクリックし[OK]をクリックし、構成を保存し
ます。
(x) プラグイン構成ファイルを編集します。
プラグイン構成ファイルが下記のような内容になっているかを確認します。
<Transport Hostname=“<Host_Name>” Port=“9443” Protocol="https">
<Property name="keyring"
value=“<Plugin_Install_Root>¥config¥webserver1¥WAS6PluginCertificates.kdb"/>
<Property name="stashfile"
value="<Plugin_Install_Root>¥config¥webserver1¥WAS6PluginCertificates.sth"/>
ポート番号に 9080 を使用しないよう 9080 のトランスポートの定義をコメントアウトします。
<!-- <Transport Hostname=“[HostName]" Port="9080“
プラグイン構成ファイルを保存し、Web サーバーを再始動します。
(xi) 動作確認を行います。
サンプル・アプリケーションの snoopServlet を稼動させ、SSL 通信が行えていることを確認
します。
http://[ホスト名]/snoop
図 5-16 snoop 画面
5-5 鍵と証明書
この節では、WAS V6.1 における鍵と証明書の管理について説明します
- 39 -
5-5-1 Ikeymanと同等の機能を管理コンソールから使用
WAS V6.0 まで ikeyman で提供されていたのと同等の機能が WAS V6.1 から管理コンソールで行うこ
とができるようになりました。従来の ikeyman も WAS V6.1 でも引き続きご使用できます。ただし、個人証
明書と署名者証明書の管理は ikeyman、管理コンソールのどちらで行なっても可能ですが、証明書要
求は生成したツールを使用して受信する必要があります。これは、証明書要求を ikeyman で作成された
場合は ikeyman で受信する、管理コンソールで作成された場合は管理コンソールで受信する、という意
味になります。
また、鍵や証明書の管理は ikeyman、管理コンソールのほかに wsadmin からも AdminTask オブジェク
トを使用することで可能です。
5-5-2 証明書の有効期限
WAS V6.1 から証明書の有効期限を管理コンソールから管理することができるようになりました。対象
は鍵ストアに格納されている証明書と署名のみです。管理コンソールから、[セキュリティー]→[SSL 証明
書および鍵管理]→[証明書有効期限の管理]を選択します。この証明書の有効期限の管理のページで
は、スケジュールやしきい値に基づいてすべての証明書を検査します。また、関連項目にある[通知]で
は、有効期限切れの警告をログや e-mail で知らせることができます。
有効期限のしきい値に達した場合、同じ証明書情報を使用して自動的に自己署名証明書を更新す
ること（注）や、鍵ストア内にある古い証明書を新しい証明書に置き換えることも可能です。
図 5-17 証明書有効期限の管理と通知画面
（注）証明書自動更新による問題
- 40 -
現在（2006.12）、プロファイル作成時に「セル（デプロイメント・マネージャーおよびフェデレーテッド・
アプリケーション・サーバー）」を使用すると DM とノードが通信できなくなる障害が発生しています（PMR
56630 6X6 760）。管理セキュリティーを有効にした時点で、「セル全体の証明書（DM の証明書）」と「各
ノードの証明書」が作成され使用されます。このときの証明書の Subject は、CN=ホスト名、O=IBM（固
定）、C=US（固定）となっていて、同一の Subject をもった複数の証明書が存在することになります。DM
とノードの通信には、「セル全体の証明書」が DM からノードに渡され、「ノードの証明書」がノードから
DM に渡されます。それぞれの証明書はトラスト・ストアの公開鍵で信頼性を検証されます。このとき同一
の Subject をもった証明書を使用しているので同一の証明書が使用された構成になっています。よっ
て、自動更新がはしると別の証明書を WAS は新規作成し、このときに CellDefaultTrustStore と
NodeDefaultTrustStore に新しい「ノードの証明書」の公開鍵が追加されません。結果として、DM と
Node 間の通信ができなくなってしまいます。
5-6 管理ロール
この節では、WAS V6.1 から新しく追加された管理ロールとその設定方法について説明します。
5-6-1 管理ロール
管理ロールとは、ユーザーおよびグループに対して割り当てられた役割のことで、管理セキュリティー
が有効なときに使用できます。この管理ロールは 1 ユーザーに対して複数割り当てることが可能です。
WAS 管理機能へのアクセス制御に使用される管理ロールには、既存の管理者、コンフィギュレータ
ー、オペレーター、モニターの 4 種類に加えてデプロイヤー、AdminSecurityManager、iscadmins の 3 種
類が追加され 7 種類になりました。
管理ロール
管理者
内容
オペレーター、コンフィギュレーターに与えられる権限をもち、管理者ロー
ルにだけ許可されている追加権限をもっている
・サーバーID とパスワードの変更
・管理者ロールにユーザーとグループをマップ
・認証、認可のメカニズムの構成
・LTPA パスワードの変更や鍵生成 Change the Lightweight Third Party
Authentication (LTPA) password and generate keys.
コンフィギュレーター
モニターに与えられる権限をもち、WAS の構成を変更することができる
・リソース作成
・アプリケーションに、ユーザーおよびグループからロールへのマッピング
の割り当て
・アプリケーション・サーバーをマップ
・アプリケーションのインストール、アンインストール
・アプリケーションのデプロイ
モニターに与えられる権限をもち、ランタイム状態を変更することができる
・サーバーの起動／停止
・管理コンソールでサーバーの状態を監視
・WAS の構成をみる
・アプリケーション・サーバーのランタイム状態をみる
オペレーター
モニター
- 41 -
デプロイヤー
wsadmin からのみ使用可能（管理コンソールでの作業不可、管理コンソー
ルへのログインは可能）
・アプリケーションの構成とランタイムオペレーションが可能
AdminSecurityManager
wsadmin からのみ使用可能（管理コンソールでの作業不可）
・ユーザーやグループを管理ロールにマップすることができる。
・Fine-grained 管理セキュリティーを使用する場合、この管理ロールをもつ
ユーザーだけが許可グループを管理できる
管理コンソール・ユーザーのみ使用可能
統合リポジトリー構成のユーザーおよびグループを管理することができる
・ユーザーやグループを作成、更新、または削除することができる
iscadmins
管理者と AdminSecurityManager は区別されます。管理ロールをユーザーやグループに割り当てるに
は AdminSecurityManager の権限が必要です。具体的には、管理コンソールから[ユーザーおよびグル
ープ]→[管理ユーザー・ロール]または[管理グループ・ロール]が、AdminSecurityManager が操作できる
特定の項目になります。1 次管理ユーザーは管理者と AdminSecurityManager の２つのロールをあわせ
もったユーザーです。
5-6-1-1 デプロイヤー
デプロイヤーはコンフィギュレーターとオペレーター両方の一部の権限をもった管理ロールで、
wsadmin からのみ使用可能です。デプロイヤーロールはアプリケーションに対する構成とランタイム操作
が可能です。しかし、アプリケーション以外の他のリソース、たとえばノードやサーバーなどを操作する権
限はデプロイヤーにはありません。具体的には、アプリケーションのインストール、アンインストール、編
集、更新、再デプロイ、そして起動・停止など行います。
5-6-1-2 AdminSecurityManager
AdminSecurityManager・ロールは fine-grained 管理セキュリティーが使用されている場合に許可グル
ープを管理することができる管理ロールで、wsadmin からのみ使用可能です。この管理ロールを持つユ
ーザーだけが、管理ロールにユーザーまたはグループをマッピングしたり、許可グループを管理したり
することが可能です。
5-6-1-3 Iscadmins
iscadmins は統合リポジトリー構成のユーザーまたはグループを管理する権限を持つ管理ロールで、
管理コンソールからのみ使用可能です。（wsadmin 不可）管理コンソールから、[ユーザーおよびグルー
プ]を開き、[ユーザーの管理]または[グループの管理]の範囲を操作することができます。
5-6-2 稼動ユーザー
デフォルトでは、Linux、UNIX、または z/OS プラットフォーム上の WAS ノードは、それぞれ root ユー
ザーID を使用して、デプロイメント・マネージャー、ノード・エージェント、およびアプリケーション・サーバ
ーの全てのプロセスを実行します。
事前に設定を行っておくことで、これらの各プロセスを root 以外の同じユーザーおよびグループのもと
で稼動させることができます。ただし、ノード・エージェント・プロセスを root 以外のユーザーID で稼動さ
- 42 -
せる場合は、同じユーザーID で、ノード・エージェントが制御する全てのアプリケーション・サーバー・プ
ロセスを実行しなければなりません。
WAS V6.1 では非 root ユーザーでもインストール、プロファイル作成が行えるようになっています。非
root ユーザーでプロファイルを作成した場合、そのプロセスについてはインストールした非 root ユーザー
であれば、Run-AS ユーザーの設定を特に行わなくても修正プログラムのインストールや起動停止を行う
事が出来ます。
また、WAS の稼動ユーザーを root 以外のユーザーID に設定した場合、ユーザー・レジストリーとして
ローカル OS を選択することはできません。
5-6-3 設定方法
ここでは、WAS の管理ロールおよび稼動ユーザーをデフォルトから変更するための設定方法を紹介し
ます。管理ロールの割り当ては、ユーザーID、グループともに可能です。グループに管理ロールを割り
当てた場合は、そのグループに所属するユーザーすべてにその管理ロールが割り当てられます。運用
面では、ユーザーよりグループにマッピングするほうがより効率的です。
5-6-3-1 管理ロールの設定
管理ロールをユーザーに割り当てる方法を紹介します。管理ロールを操作できるのは、
AdminSecurityManager・ロールの権限をもつユーザーまたは 1 次管理ユーザーです。
管理コンソールの[ユーザーおよびグループ]→[管理ユーザー・ロール]を選択して[追加]ボタンをクリ
ックし、アクティブなユーザー・レジストリーに登録されているユーザーID を入力し、割り当てるロールを
選択して[OK]をクリックします。マスター構成へ変更を保存します。ユーザー・レジストリーに存在しない
ユーザー名を入力した場合はエラー・メッセージがもどります。
•
ユーザー
ユーザーID を指定します。入力されるユーザーID は、構成されたアクティブ・ユーザー・
レジストリーに存在している ID でなければなりません。
•
ロール
- 43 -
ユーザーに割り当てるロールを選択します。各ロールに与えられる権限に関しては、前述
の通りです。
管理コンソールの[ユーザーおよびグループ]→[管理ユーザー・ロール]を選択し、新規マッピング・ユ
ーザーが管理者ロールで表示されることを確認します。
グループに管理ロールをマッピングする場合は同様に、管理コンソールの[ユーザーおよびグループ]
→[管理グループ・ロール]を選択して[追加]ボタンをクリックし、アクティブなユーザー・レジストリーに登
録されているグループ名を入力し、割り当てるロールを選択して[OK]をクリックします。マスター構成へ
変更を保存します。このとき、ユーザー・レジストリーに存在しないグループ名を入力した場合はエラー・
メッセージがもどります。
5-6-3-2 稼動ユーザーの設定
WAS の稼動ユーザーの設定方法を紹介します。各プロセスを稼動させる root 以外のユーザーID は、
事前に作成しているものとします。
初めに、アプリケーション・サーバー・プロセスを root 以外のユーザーで稼動させるための設定を説明
します。
管理コンソールの[サーバー]→[アプリケーション・サーバー]→[アプリケーション・サーバー名]→[サー
バー・インフラストラクチャー]→[Java およびプロセス管理]→[プロセスの実行]を選択し、以下のようにプ
ロセスを稼動させるユーザーやグループ、Umask を設定して[OK]をクリックします。
- 44 -
•
プロセスの優先順位
プロセスのオペレーティング・システムの優先順位を指定します。サーバーを起動する管
理プロセスが、この設定を受諾するには、root 権限が必要です。
•
Umask
プロセスが実行されるユーザー・マスク（ファイル・モード許可マスク）を指定します。
•
Run-As ユーザー
プロセスが実行されるユーザーID を指定します。
•
Run-As グループ
プロセスがメンバーとして所属し、そのプロセスが実行されるグループを指定します。
OS/400 の場合、この設定は無視されます。
•
プロセス・グループでの実行
プロセスに特定のプロセス・グループを指定します。このプロセス・グループは、プロセッサ
ーの区分化などを行う場合に役立ちます。例えば、システム管理者は、12 個のプロセッ
サーのうちの 6 個で実行されるようにプロセス・グループを割り当てることができます。デ
フォルト(0)では、どの特定グループにもプロセスは割り当てられていません。OS/400 の場
合、この設定は無視されます。
設定が完了したら保管します。そして、Linux および UNIX プラットフォームでは、root として、オペレ
ーティング・システムのツールを使用してファイルのパーミッションを変更します。
chgrp wasgroup /opt/WebSphere
chgrp wasgroup /opt/WebSphere/AppServer
chgrp -R wasgroup /opt/WebSphere/AppServer/cloudscape
chgrp -R wasgroup /opt/WebSphere/AppServer/profiles/nodeProfile1
chmod g+wr /opt/WebSphere
chmod g+wr /opt/WebSphere/AppServer
chmod -R g+wr /opt/WebSphere/AppServer/cloudscape
chmod -R g+wr /opt/WebSphere/AppServer/profiles/nodeProfile1
以上の設定で、Run-As ユーザーに指定したユーザーID でアプリケーション・サーバーを稼動させる
ことができます。
また、ノード・エージェント・プロセスやデプロイメント・マネージャー・プロセスについても同様の設定を
行うことで、root 以外のユーザーで稼動させることができます。ノード・エージェント・プロセスの場合は、
管理コンソールの[システム管理]→[ノード・エージェント]→[nodeagent]→[サーバー・インフラストラクチ
ャー]→[Java およびプロセス管理]→[プロセス定義]→[プロセスの実行]から同様の設定を行います。デ
プロイメント・マネージャー・プロセスの場合は、管理コンソールの[システム管理]→[Deployment
Manager]→[dmgr]→[サーバー・インフラストラクチャー]→[Java およびプロセス管理]→[プロセス定義]
→[プロセスの実行]から同様の設定を行います。
- 45 -
5-7 Fine-grained 管理セキュリティー
この節では、WAS V6.1 から新機能として実装されるようになった Fine-grained 管理セキュリティーの
機能およびその設定方法について説明します。
5-7-1 Fine-grained 管理セキュリティーとは
Fine-grained 管理セキュリティーを使用することによって、より細かいリソース単位でユーザーに管理ロ
ールを割り当てることができます。リソース単位での管理ロールは許可されたリソース以外にアクセスす
ることができません。割り当てることが可能なリソース・インスタンスは次の 6 つです。
・セル
・ノードグループ
・ノード
・クラスター
・サーバー
・アプリケーション
・
Fine-grained 管理セキュリティーは、管理コンソールから使用することはできません。必ず wsadmin か
ら使用するようにしてください。これは、管理コンソールから設定された管理ロールを与えられたユーザ
ーが管理できるリソースはセル全体となり、Fine-grained はセル・レベルよりもより細かい単位でロールを
わりあてる管理セキュリティーであるため、管理コンソールからの使用ができません。
5-7-2 許可グループ
許可グループとは、同じ権限をもつリソースを１つにまとめたものをいいます。この許可グループには
特定の管理ロールをもつユーザーやリソースを追加することが可能です。従来の WAS との相互互換性
のため、セル・レベルの管理権限をもつ許可グループがデフォルトで用意されています。この許可グル
ープに割り当てられたユーザーはセル内のリソースすべてにアクセス可能です。
シングル・サーバー構成では、サーバーが特定の許可グループにおかれることはありません。許可グ
ループにおけるのは、アプリケーションのみです。アプリケーションによって許可グループが異なることは
可能です。
リソースには親子関係が存在します。親リソースにアクセス可能な場合は、子リソースすべてにアクセ
スすることが可能です。つまり、親リソースを許可グループに追加した場合は、その子リソースは自動的
に同じ許可グループに配置されます。
また、リソースは複数の許可グループにまたがって登録されることはありません。したがって、親と子が
異なる許可グループに所属するということはできません。必ず１リソースは１許可グループに属します。
図 5-18 はリソースの親子関係を表します。
- 46 -
リソース・タイプの関係
セル
ノードグループ
クラスター
ノード
アプリケーション
許可グループ
サーバー
図 5-18 リソース・タイプの包括関係
図 5-19 のように許可グループが定義されている場合、Adminuser1 がアクセス可能なリソースは、
node1、App-Server1-N1、application1、application2、App-Server2-N1 になります。Adminuser1 は許可グ
ループ 1 に属します。許可グループ 1 にはリソースである node1 が同じく属します。よって、Adminuser1
は node1 にアクセス可能です。アプリケーション・サーバーは Adminuser1 が属する許可グループ 1 配下
には明確に定義されていません。しかし、ノードとサーバーの関係には親子関係があり、親リソースであ
るノードの子リソースがサーバーですので、User1 は App-Server1-N1 と App-Server2-N1、そして、
Server1-N1 にデプロイされている application1、application2 にアクセスすることができます。
図 5-19 許可グループ
Fine-grained 管理セキュリティーを設定するには、wsadmin コマンド・ツールを使用します。許可グル
ープを操作するには AdminSecurityManager・ロールの権限がユーザーには必要です。セキュリティー
- 47 -
構成を行うコマンドは、 AuthorizationGroupCommands コマンド群により提供されています。
AuthorizationGroupCommands コマンド群のコマンドを一覧表示するには以下のコマンドを実行しま
す。
AuthorizationGroupCommands コマンド群のコマンドを一覧表示するコマンド
$AdminTask help AuthorizationGroupCommands
以下に、ある許可グループにリソースとユーザーを追加するコマンドを紹介します。
・許可グループ作成
$AdminTask createAuthorizationGroup {-authorizationGroupName authGroup1 }
・許可グループにリソース追加
$AdminTask addResourceToAuthorizationGroup {-authorizationGroupName authGroup1
-resourceName Server=server1}
$AdminTask addResourceToAuthorizationGroup {-authorizationGroupName authGroup1
-resourceName Application=DefaultApplication}
・許可グループにセキュリティロールをもったユーザーまたはグループを追加
$AdminTask mapUsersToAdminRole {-authorizationGroupName authGroup1 -roleName
administrator -userids user1}
$AdminTask mapGroupsToAdminRole {-authorizationGroupName authGroup1 -roleName デ
プロイヤー -groupids authGroup1}
最後に構成を保存し、許可テーブルへの変更を反映するためにアプリケーション・サーバーの再
起動を行います。再起動を行わない場合には、AuthorizationGroupManager refreshAll MBean メ
ソッドを使用してメモリーのリフレッシュを行います。
set a [$AdminControl queryNames type=AuthorizationGroupManager,process=dmgr,*]
$AdminControl invoke $a refreshAll
5-8 JACC
この節では、WAS V6 から実装されている Java Authorization Contract for Containers(以下、JACC)の
機能およびその設定方法について説明します
5-8-1 JACCとは
JACC は、JSR115 プロセスを通じて、J2EE1.4 で導入された新しい J2EE コンポーネントの１つです。こ
の仕様では、J2EE コンテナーと JACC プロバイダーの間の実装方法が定義されています。この仕様に
準拠することにより、サード・パーティーの JACC プロバイダーを J2EE1.4 アプリケーション・サーバーに
プラグインし、J2EE リソースがアクセスされた場合の許可決定を行うことができます。
5-8-2 JACCプロバイダー
JACC では、アプリケーション・サーバーおよびプロバイダーの両方のコンテナーがいくつかの要件を
満たしている必要があります。コンテナーは、アプリケーションのデプロイ時にセキュリティー・ポリシー情
報をプロバイダーに伝搬し、全ての許可の決定に対してプロバイダーを呼び出す必要があります。ま
た、プロバイダーは、アプリケーションのデプロイ時に、ポリシー情報をリポジトリーに保管する必要があり
ます。プロバイダーは、この情報を使用してコンテナーから呼び出されたときに許可を決定します。
- 48 -
WAS は JACC をサポートしており、以下のような２つのタイプの JACC プロバイダーをサポートしていま
す。
•
•
デフォルトの JACC プロバイダー
WAS のデフォルトの JACC プロバイダーです。Tivoli Access Manager(以下、TAM)のクライア
ントおよびサーバーの両方で実装されています。TAM のクライアント部分は WAS に組み込ま
れています。
サード・パーティーの JACC プロバイダー
サード・パーティー製の JACC プロバイダーです。WAS にプラグインするには、そのサード・
パーティーJACC プロバイダーが、JACC 仕様で必要なポリシー・クラス、ポリシー構成ファクトリ
ー・クラス、およびポリシー構成インターフェースを実装している必要があります。JACC 仕様で
は、コンテナーとプロバイダー間の許可テーブル情報の処理方法が指定されていません。その
情報を処理する管理機能の提供は、プロバイダーの責任です。コンテナーがバインディング・
ファイルの許可テーブル情報をプロバイダーに提供する必要はありません。
JACC プロバイダーとして TAM を使用することにより、さまざまなメリットを享受できます。例えば、TAM
を使用すれば、パスワードに使用する文字の種類や長さ、有効期限などといったポリシーを設定するこ
とができます。更に、そういった設定内容の変更は WAS を再起動することなく、動的に行うことができま
す。
WAS に同梱されている TAM には、ソフトウェア製品版としての TAM のコンポーネントの一部分が含
まれており、JACC プロバイダーとしての使用のみがサポートされています。TAM を JACC プロバイダー
以外の目的で使用する場合は、別途 TAM ソフトウェア製品版のライセンス証書を取得する必要がありま
す。
5-8-3 設定方法
WAS で JACC プロバイダーを構成するための設定方法を紹介します。
ここでは、WAS の導入・構成、TAM の導入・構成、③LDAP への WAS 管理ユーザーの作成、WAS の
管理セキュリティー設定に関しては既に完了していることを前提とします。参考として、LDAP への WAS
管理ユーザーの作成に関しては、WAS V6.0 の管理ガイドの「セキュリティー構成」-「[参考]LDAP サー
バーの導入と構成」を、ご参照ください。また、管理セキュリティーの設定に関しては、当資料「5-1-4 設
定方法」をご参照ください。LDAP への WAS 管理ユーザーの作成に関しては、「[参考]LDAP サーバー
の導入と構成」で記述されているような LDAP に直接作成する方法ではなく、TAM を経由して管理（ユ
ーザーの作成、削除など）する方法もあります。TAM を経由する方法では、TAM の管理コマンドを使用
してユーザーを一括登録できるなどのメリットがあります。その方法については、IBM Tivoli Access
Manager for e-business 5.1 の InfoCenter をご参照ください。
IBM Tivoli Access Manager for e-business 5.1
http://publib.boulder.ibm.com/tividd/td/IBMAccessManagerfore-business5.1.html
WAS の管理コンソールを使用して JACC 設定を行う手順を紹介します。WAS では、TAM 用の JACC
プロバイダーがデフォルトで構成されています。ここでは、TAM 用の JACC プロバイダーを使用可能に
する設定を紹介します。
1). JACC プロバイダーの外部許可
- 49 -
管理コンソールの[セキュリティー]→[管理、アプリケーション、およびインフラストラクチャーの保護]→
[外部許可プロバイダー]を選択し、[JACC プロバイダーを使用する外部許可]にチェックを入れて[OK]
をクリックします。
•
デフォルト許可
TAM などの外部セキュリティー・プロバイダーで JACC 仕様に基づいた J2EE アプリケーシ
ョンの許可決定を実行する場合以外は、常にこのオプションを使用します。
•
JACC プロバイダーを使用する外部許可
JACC 仕様を仕様する J2EE アプリケーションに対する許可決定を実行するために、TAM
など外部セキュリティー・プロバイダーを使用する場合にのみ、このオプションを使用可能
にします。
2). 外部 JACC プロバイダー
管理コンソールの[セキュリティー]→[管理、アプリケーション、およびインフラストラクチャーの保護]→
関連項目の[外部許可プロバイダー]を選択します。TAM 用の JACC プロバイダー設定が表示されます
ので、TAM 構成を正しく機能させるために、正しく設定されていることを確認します。
•
名前
•
説明
外部 JACC プロバイダーの識別に使用される名前を指定します。
JACC プロバイダーの説明を提供します。
•
ポリシー・クラス名
- 50 -
JACC 仕様に従って、javax.security.jacc.policy.provider プロパティーを表す完全修飾クラ
ス名を指定します。このクラスは、java.security.Policy 抽象メソッドのプロバイダー固有のイ
ンプリメンテーションを表します。クラス・ファイルは、各 WAS プロセスのクラスパスに常駐
している必要があります。このクラスは、許可を決定する際に使用されます。
•
ポリシー構成ファクトリーのクラス名
JACC 仕様に従って、 javax.security.jacc.PolicyConfigurationFactory.provider プロパテ
ィーを表す完全修飾クラス名を指定します。このクラスは、
javax.security.jacc.PolicyConfigurationFactory 抽象メソッドのプロバイダー固有のインプ
リメンテーションを表します。このクラスは、 PolicyConfigurationFactory 抽象クラスのプロ
バイダー固有のインプリメンテーションを表します。クラス・ファイルは、各 WAS プロセスの
クラスパスに常駐している必要があります。このクラスは、J2EE アプリケーションのインスト
ール時に、 JACC プロバイダーにセキュリティー・ポリシー情報を伝搬するのに使用され
ます。
•
ロール構成ファクトリーのクラス名
com.ibm.wsspi.security.authorization.RoleConfigurationFactory インターフェースを実装
する完全修飾クラス名を指定します。クラス・ファイルは、各 WAS プロセスのクラスパスに
常駐している必要があります。このクラスを実装すると、バインディング・ファイル内の許可
テーブル情報が、 J2EE アプリケーションのインストール時にプロバイダーに伝搬されま
す。
•
プロバイダー初期設定クラス名
com.ibm.wsspi.security.authorization.InitializeJACCProvider インターフェースを実装する
完全修飾クラス名を指定します。クラス・ファイルは、各 WAS プロセスのクラスパスに常駐
している必要があります。このクラスは、実装されるとアプリケーション・サーバーの全プロ
セスの開始時および停止時に呼び出されます。このクラスは、プロバイダー・クライアント・
コードがプロバイダー・サーバーとの通信に必要とする任意の初期設定で使用できます。
•
アクセス決定に EJB 引数ポリシー・コンテキスト・ハンドラーを必要とする
JACC プロバイダーがアクセスを決定するのに EJBArgumentsPolicyContextHandler を
必要とするかどうかを指定します。このオプションはパフォーマンスに影響を及ぼすので、
プロバイダーで必要でない限り、設定しないでください。通常、このハンドラーが必要なの
は、プロバイダーがインスタンス・ベースの許可をサポートしている場合のみです。TAM
は、 J2EE アプリケーションではこのオプションをサポートしていません。
•
動的モジュール更新のサポート
実行中のアプリケーションで Web モジュールのセキュリティー・ポリシーに加えられた変
更を、そのアプリケーションの他の部分に影響を与えることなく、動的に適用できるかどう
かを指定します。このオプションを使用可能にすると、追加または変更した Web モジュ
ールのセキュリティー・ポリシーは、 JACC プロバイダーに伝搬され、影響を受けた Web
モジュールのみが開始されます。このオプションを使用不可にすると、モジュール・レベ
ルの変更に対して、アプリケーション全体のセキュリティー・ポリシーが JACC プロバイダ
ーに伝搬されます。変更内容を有効にするには、アプリケーション全体を再始動します。
通常、外部 JACC プロバイダーに対しては使用可能になっています。
3). Tivoli Access Manager プロパティー
管理コンソールの[セキュリティー]→[管理、アプリケーション、およびインフラストラクチャーの保護]→
[外部許可プロバイダー]→関連項目[外部 JACC プロバイダー] →追加プロパティー[Tivoli Access
- 51 -
Manager プロパティー]を開きます。[組み込み Tivoli Access Manager を使用可能にする]にチェックを
入れ、TAM と WAS の各値を正しく設定して[OK]をクリックします。
•
•
組み込み Tivoli Access Manager を使用可能にする
組み込み Tivoli Access Manager 構成を使用可能または使用不可にします。
組み込み Tivoli Access Manager 使用不可時のエラーを無視
これを選択すると、組み込み Tivoli Access Manager を使用不可にしている間は、エラーは
無視されます。このオプションは、組み込み Tivoli Access Manager を再構成する場合、ま
たは組み込み TAM を使用不可にしている場合にのみ、適用できます。
- 52 -
•
•
•
•
•
•
•
•
クライアント listen ポートの設定
TAM クライアントが listen ポートとして使用するポートを入力します。WAS は、TCP/IP ポ
ートで、ポリシー・サーバーからの許可データベース更新を listen する必要があります。
特定のノードまたはマシン上で複数のプロセスが実行される場合があるため、それらのプ
ロセスで使用されるポートのリストが必要になります。ポートの範囲を指定する場合は、下
限の値と上限の値をコロンで区切ります。単一ポートとポート範囲は、別々の行で指定し
ます。
ポリシー・サーバー
Tivoli Access Manager ポリシー・サーバーの名前、完全修飾ドメイン・ネーム、または IP
アドレスと、接続ポートを入力します。policy_server:port という形式を使用します。ポリシ
ー・サーバーの通信ポートは、 TAM の構成時に設定されます。デフォルトは 7135 で
す。
許可サーバー
Tivoli Access Manager 許可サーバーの名前、完全修飾ドメイン・ネーム、または IP アド
レスを入力します。形式は auth_server:port:priority のようになります。許可サーバーの
通信ポートは、TAM の構成時に設定されます。デフォルトは 7136 です。各サーバー
を別々の行に入力することで、複数の許可サーバーを指定することができます。複数の
許可サーバーを構成しておくと、フェイルオーバーやパフォーマンスの点で役に立ちま
す。優先度の値は、許可サーバーが使用される順序です。
管理者ユーザー名
TAM の構成時に作成した Tivoli Access Manager 管理ユーザーID を入力します。通常
は、sec_master です。
管理者ユーザー・パスワード
「管理者ユーザー名」で入力したユーザーID に対する、Tivoli Access Manager 管理パス
ワードを入力します。
ユーザー・レジストリー識別名の接尾部
TAM と WAS で共用されるユーザー・レジストリーの、識別名の接尾部を入力します。例
えば、o=ise,c=jp のように設定します。
セキュリティー・ドメイン
WAS のユーザーおよびグループを保管するのに使用される、Tivoli Access Manager セ
キュリティー・ドメインの名前を入力します。Tivoli Access Manager ドメインを指定する必
要があるのは、TAM では、管理ユーザーごとに複数のセキュリティー・ドメインが作成でき
るためです。特定のドメイン内にユーザー、グループ、およびその他のオブジェクトが作
成され、別のドメイン内のリソースへのアクセスは許可されません。TAM の構成時にセキ
ュリティー・ドメインを設定していない場合は、値をデフォルトのままにしておいてくださ
い。
管理者ユーザーの識別名
WAS セキュリティー管理者 ID の完全識別名を入力します。例えば、
cn=wasadm,o=ise,c=jp のように設定します。
4). 構成の保管
最後に、構成を保管して WAS を再起動します。
5-9 Java 2 セキュリティー
この節では、Java 2 セキュリティーについて説明します。
- 53 -
5-9-1 Java 2 セキュリティーとは
Java 2 セキュリティーでは、ポリシー・ベースの精密なアクセス制御メカニズムが提供されます。このメ
カニズムにより、保護された特定のシステム・リソースへのアクセスには、必ずアクセス権の検査が行われ
るため、システム全体の保全性が高まります。Java 2 セキュリティーは、ファイル入出力、ソケット、およ
びプロパティーなどのシステム・リソースへのアクセスを保護します。
アプリケーションが Java 2 セキュリティーに対応していない場合、管理者は Java 2 セキュリティーを使
用することによって起こりうる問題を事前に把握しておかなければなりません。
5-9-2 Java 2 セキュリティー・ポリシー・ファイル
Java プロセス用のセキュリティー・ポリシーを定義するために、IBM JDK によっていくつかの静的ポリ
シー・ファイルが提供されています。また、WAS は、エンタープライズ・アプリケーションのリソースおよび
ライブラリーに関する動的ポリシーをサポートしています。アクセスの許可は、アプリケーション実行時に
ポリシー・ファイルに基づいて判断されます。
JDK によって提供されるポリシー・ツールを使用することで、ポリシー・ファイルを編集することができま
す。セル構成の場合は、編集前にポリシー・ファイルをリポジトリーから抽出する必要があります。ポリシ
ー・ファイルの抽出後はポリシー・ツールを使用してファイルを編集し、変更したポリシー・ファイルをリポ
ジトリーに入れてから他のノードと同期させる必要があります。ポリシー・ファイルに構文エラーがあると、
エンタープライズ・アプリケーションまたはサーバー・プロセスが始動に失敗する可能性がありますので、
これらのポリシー・ファイルを編集する際は注意が必要です。
5-9-3 静的ポリシー・ファイル
WAS でサポートされているポリシー・ファイルのタイプには静的ポリシー・ファイルと動的ポリシー・ファ
イルの 2 種類があります。それらのうち、静的ポリシー・ファイルは、デフォルト・アクセス権を提供します。
静的ポリシー・ファイルは、リポジトリーおよびファイル複製サービスによって管理される構成ファイルで
はありません。このファイルへの変更はローカルであり、他のマシンに複製されることはありません。
静的ポリシー・ファイルには、以下の種類のファイルがあります。
•
java.policy （<WAS_root>/java/jre/lib/security/java.policy）
全てのクラスに付与されるデフォルトの許可です。このファイルのポリシーは、WAS によっ
て起動される全てのプロセスに適用されます。
•
server.policy （<AS_Profile_root>/properties/server.policy）
製品の全てのサーバーに付与されるデフォルトの許可です。
•
client.policy （<AS_Profile_root>/properties/client.policy）
ノード上の全ての製品クライアント・コンテナーおよびアプレットに対するデフォルトの許可
です。
- 54 -
5-9-4 動的ポリシー・ファイル
WAS でサポートされているポリシー・ファイルのタイプには静的ポリシー・ファイルと動的ポリシー・ファ
イルの 2 種類があります。それらのうち、動的ポリシー・ファイルは、アプリケーションのアクセス権を提供
します。動的ポリシーは、特定のリソース・タイプに対するアクセス権のテンプレートです。
動的ポリシー・ファイルには、以下の種類のファイルがあります。
•
spi.policy （<AS_Profile_root>/config/cells/Cell_name/nodes/Node_name/spi.policy）
このテンプレートは、サービス・プロバイダー・インターフェース（SPI）、または製品に組み
込まれているサード・パーティー製リソースのためのものです。SPI の例には、MQ Series
の Java Message Service（JMS）および JDBC ドライバーがあります。組み込みリソースのコ
ード・ベースは、構成（resource.xml ファイル）およびランタイム・データから動的に決定さ
れ、spi.policy ファイルで定義されている許可は、自動的にこれらのリソースおよび
ResourceAdapter のクラスパスで指定された JAR ファイルに適用されます。spi.policy ファ
イルのデフォルト許可は、java.security.AllPermissions です。
•
library.policy （<AS_Profile_root>/config/cells/Cell_name/nodes/Node_name/library.policy）
このテンプレートは、ライブラリー（Java ライブラリー・クラス）用です。共用ライブラリーは、
複数の製品アプリケーションで使用するように定義できます。library.policy のデフォルト
の許可は null です。
•
app.policy （<AS_Profile_root>/config/cells/Cell_name/nodes/Node_name/app.policy）
このファイルは、Cell_name 内の Node_name で実行される全てのエンタープライズ・アプリ
ケーションに付与されるデフォルトの許可を定義します。
•
was.policy
（ <WAS_root>/config/cells/Cell_name/applications/ear_file_name/deployments/application_name/
META-INF/was.policy）
このテンプレートは、アプリケーション固有の許可のためのものです。was.policy は、エンタ
ープライズ・アーカイブ（EAR）ファイルに組み込まれています。
•
was.policy.rar （rar_file_name/META-INF/was.policy.rar）
このファイルには、ra.xml ファイルで定義された許可の仕様を含めることができます。
ra.xml ファイルは、RAR ファイルに組み込まれています。
5-10 JAAS
この節では、WAS が以前のバージョンより引き続きサポートしている JAAS について説明します。
5-10-1 JAASとは
JAAS 1.0 は、Java 2 プラットフォームの Java 2 セキュリティー・アーキテクチャーを拡張したもので、
プリンシパルとユーザーによるアクセス制御の実施がサポートされます。 JAAS は、プラグ可能認証モ
ジュール (PAM) 標準フレームワークの Java バージョンを実装し、Java 2 プラットフォームのアクセス制
御アーキテクチャーを拡張します。WAS は、JAAS アーキテクチャーを完全にサポートします。JAAS
は、アクセス制御アーキテクチャーを拡張して、サーブレット、JSP、および EJB コンポーネントを含む
J2EE リソースのロール・ベースの許可をサポートします。
- 55 -
5-10-2 JAASの許可
Java 2 セキュリティー・アーキテクチャーは、コードの特性 (コードの発生元、デジタル署名がなされ
ているか、署名者は誰か、など) に基づいて許可が与えられます。JAAS では、ユーザーを中心とする
新規アクセス制御により、コード中心の既存のアクセス制御が強化されます。許可は、実行されているコ
ードとそのコードの実行者に基づいて与えられます。
JAAS 認証によりユーザー認証を行う場合、認証済みユーザーを表す subject が作成されます。subject
は、プリンシパルのセットから構成され、各プリンシパルはそのユーザーの ID を表します。許可は、ポリ
シーで特定のプリンシパルに与えることができます。ユーザーが認証されると、アプリケーションは、
subject を現行のアクセス制御コンテキストに関連付けることができます。セキュリティーが検査された後
続の各オペレーションご毎に、Java ランタイムは、ポリシーが要求された許可を特定のプリンシパルにの
み与えるかどうかを自動的に判断します。与える場合は、アクセス制御コンテキストに関連した subject に
指定されたプリンシパルのみが含まれる場合に、その操作を行うことができます。
subject を現行のアクセス制御コンテキストに関連付けるには、その subject のクラスから静的 doAs メソ
ッドを呼び出して、認証済みの subject と java.security.PrivilegedAction メソッドまたは
java.security.PrivilegedExceptionAction メソッドを渡します。doAs メソッドは、指定された subject を現行
のアクセス制御コンテキストに関連付け、アクションから実行メソッドを呼び出します。実行メソッドのイン
プリメンテーションには、指定した subject として実行されたコードがすべて含まれています。これにより、
アクションは、指定した subject として実行されます。
J2EE プログラミング・モデルでは、EJB またはサーブレットから EJB メソッドを呼び出す場合、そのメソ
ッドは Run-As 設定により決められるユーザーID を使用して実行されます。J2EE 1.4 では、EJB コード
またはサーブレット・コード内の Subject.doAs アクション・ブロックから EJB を呼び出す場合に使用す
るユーザー ID は示されません。論理拡張機能では、Subject.doAs アクション・ブロック内で EJB メソ
ッドを呼び出す場合に、サブジェクト内に指定された適切な ID を使用することになっています。
Subject.doAs アクションに Run-As ID 設定を上書きさせるのは、 JAAS プログラミング・モデルを
J2EE ランタイム環境に統合する上で理想的な方法です。ただし、JAAS では、JDK V1.3 以降で、
JAAS V1.0 以降のインプリメンテーションと Java 2 セキュリティー・アーキテクチャーを統合する際に、
問題が発生しました。アクセス制御コンテキストに関連付けられたサブジェクトは、 doPrivileged 呼び出
しが Subject.doAs アクション・ブロック内で発生した場合、その doPrivileged 呼び出しによりカットオフ
されます。この問題が解決されるまでは、 J2EE ランタイム環境での Subject.doAs アクションの正しい
振る舞いを保証できる、信頼性が高くてランタイム効率のよい方法はありません。
- 56 -