セキュリティーガイド
JBoss Enterprise Application Platform 6 向け
エディッション 1
Nidhi Chaudhary
Lucas Costi
Russell Dickenson
Sande Gilda
Vikram Goyal
Eamon Logue
Darrin Mison
Scott Mumford
David Ryan
Misty Stanley-Jones
Keerat Verma
Tom Wells
概要
前書き
パート I. JBoss Enterprise Application Platform 6 のセキュリティー
第1章 はじめに
1.1. セキュリティーについて
1.2. システム管理者のセキュリティー
1.3. J2EE 開発者のセキュリティー
- アプリケーション開発者 - 開発レベルにおけるセキュリティーを担当し、ロール、ルール、およびビジネスロジックをアプリケーションロジックに定義します。
- アプリケーションアセンブラー - アプリケーションにまたがる脆弱性が最低限になるよう EAR および WAR がパッケージ化されるようにします。
- アプリケーションデプロイヤー - EAR のデプロイメントをセキュアにし、アクセス制御リストを割り当て、維持します。
パート II. プラットフォームのセキュア化
第2章 セキュリティーサブシステム
2.1. セキュリティーサブシステムについて
ディープコピーサブジェクトモードが無効化されている場合 (デフォルト)、セキュリティーデータ構造をコピーすると、データ構造全体をコピーするのではなく、オリジナルが参照されます。この動作はより効率的ですが、フラッシュまたはログアウトの操作によって同一 ID の複数のスレッドが件名を消去すると、データの破損が発生する傾向にあります。
java.security.Security
クラスに適用されるシステム全体のセキュリティープロパティーを設定できます。
セキュリティードメインとは、認証、承認、監査、およびマッピングを制御するために単一または複数のアプリケーションが使用する Java Authentication and Authorization Service (JAAS) 宣言型セキュリティー設定のセットです。デフォルトでは、jboss-ejb-policy
、jboss-web-policy
、および other
の 3 つのセキュリティードメインが含まれています。アプリケーションの必要性に対応するため、セキュリティードメインは必要に応じていくつでも作成できます。
2.2. セキュリティーサブシステムの構造について
例2.1 セキュリティーサブシステムの設定例
<subsystem xmlns="urn:jboss:domain:security:1.2"> <security-management> ... </security-management> <security-domains> <security-domain name="other" cache-type="default"> <authentication> <login-module code="Remoting" flag="optional"> <module-option name="password-stacking" value="useFirstPass"/> </login-module> <login-module code="RealmUsersRoles" flag="required"> <module-option name="usersProperties" value="${jboss.domain.config.dir}/application-users.properties"/> <module-option name="rolesProperties" value="${jboss.domain.config.dir}/application-roles.properties"/> <module-option name="realm" value="ApplicationRealm"/> <module-option name="password-stacking" value="useFirstPass"/> </login-module> </authentication> </security-domain> <security-domain name="jboss-web-policy" cache-type="default"> <authorization> <policy-module code="Delegating" flag="required"/> </authorization> </security-domain> <security-domain name="jboss-ejb-policy" cache-type="default"> <authorization> <policy-module code="Delegating" flag="required"/> </authorization> </security-domain> </security-domains> <vault> ... </vault> </subsystem>
<security-management>
、 <subject-factory>
および <security-properties>
要素はデフォルト設定では存在しません。<subject-factory>
および <security-properties>
要素は JBoss Enterprise Application Platform 6.1 およびそれ以降のバージョンで廃止になりました。
2.3. 暗号化について
2.4. 宣言的セキュリティーについて
2.5. セキュリティーサブシステムの設定
- <security-management>
- このセクションはセキュリティーサブシステムのハイレベルの挙動を上書きします。各設定は任意です。ディープコピーサブジェクトモード以外で、これらの設定を変更することはほとんどありません。
オプション 説明 deep-copy-subject-mode スレッドの安全性を高めるため、セキュリティートークンへコピーまたはリンクするかどうかを指定します。authentication-manager-class-name 使用する代替の AuthenticationManager 実装クラス名を指定します。default-callback-handler-class-name ログインモジュールで使用される CallbackHandler 実装のグローバルクラス名を指定します。authorization-manager-class-name 使用する代替の AuthorizationManager 実装クラス名を指定します。audit-manager-class-name 使用する代替の AuditManager 実装クラス名を指定します。identity-trust-manager-class-name 使用する代替の IdentityTrustManager 実装クラス名を指定します。mapping-manager-class-name 使用する MappingManager 実装クラス名を指定します。 - <subject-factory>
- サブジェクトファクトリはサブジェクトインスタンスの作成を制御します。呼び出し側を検証するため、認証マネージャーを使用することがあります。サブジェクトファクトリは、主に JCA コンポーネントがサブジェクトを確立するために使用されます。サブジェクトファクトリを変更する必要はあまりありません。
- <security-domains>
- 複数のセキュリティードメインを保持するコンテナ要素です。セキュリティードメインには認証、承認、マッピング、監査モジュール、JASPI 認証、および JSSE 設定の情報が含まれることがあります。アプリケーションはセキュリティードメインを指定してセキュリティー情報を管理します。
- <security-properties>
- java.security.Security クラスに設定されるプロパティーの名前と値が含まれます。
第3章 管理インターフェースセキュリティー
3.1. 管理インターフェースのセキュア化
テスト環境では、管理コンソール、管理 CLI および他の API 実装で構成される管理インターフェース上で、セキュリティーレイヤーがない状態で JBoss Enterprise Application Platform 6 を実行することがよくあります。これにより、開発や設定を迅速に変更できます。
3.2. デフォルトのユーザーセキュリティー設定
JBoss Enterprise Application Platform 6 のすべての管理インターフェースはデフォルトで保護されます。このセキュリティーには、2 つの形式があります。
- ローカルインターフェースは、ローカルクライアントとローカルクライアントが接続するサーバーとの間の SASL コントラクトによって保護されます。このセキュリティーメカニズムは、ローカルファイルシステムにアクセスするクライアントの機能に基づきます。ローカルシステムへアクセスできるとクライアントによるユーザーの追加が可能で、他のセキュリティーメカニズムを無効にするよう設定を変更できるからです。これにより、ファイルシステムへ物理的にアクセスできると、他のセキュリティーメカニズムが不要になるという原則が厳守されます。このメカニズムは 4 つの手順で実現されます。
注記
HTTP を使用してローカルホストへ接続する場合でも、HTTP のアクセスはリモートと見なされます。- ローカル SASL メカニズムを用いて認証する要求が含まれるメッセージをクライアントがサーバーに送信します。
- サーバーはワンタイムトークンを生成し、固有のファイルに書き込み、ファイルのフルパスが含まれるメッセージをクライアントへ送信します。
- クライアントはファイルよりトークンを読み取り、サーバーへ送信し、ファイルシステムへローカルアクセスできるかを検証します。
- サーバーはトークンを検証し、ファイルを削除します。
- ローカル HTTP クライアントを含むリモートクライアントはレルムベースのセキュリティーを使用します。管理インターフェースを使用して JBoss Enterprise Application Platform 6 をリモートで設定するパーミッションを持つデフォルトのレルムは
ManagementRealm
です。このレルム (またはユーザーが作成したレルム) にユーザーを追加できるスクリプトが提供されます。ユーザーの追加の詳細については、JBoss Enterprise Application Platform 6 のインストールガイドの章「JBoss Enterprise Application Platform 6 を初めて使用」を参照してください。ユーザーごとに、ユーザー名、ハッシュ化されたパスワード、およびレルムがファイルに格納されます。- スタンドアロンサーバー
JPP_HOME/standalone/configuration/mgmt-users.properties
mgmt-users.properties
の内容はマスクされていますが、機密ファイルとして取り扱うようにしてください。ファイルモードを、ファイル所有者による読み書きアクセスのみが許可される600
に設定することが推奨されます。
3.3. 管理インターフェースの詳細設定の概要
EAP_HOME/domain/configuration/host.xml
または EAP_HOME/standalone/configuration/standalone.xml
の管理インターフェース設定は、ホストコントローラープロセスのバインド先となるネットワークインターフェース、利用可能な管理インターフェースのタイプ、各インターフェースでユーザー認証に使用する認証システムのタイプを制御します。本トピックでは、ご使用の環境に合わせて管理インターフェースを設定する方法について説明します。
<management>
要素と、以下の 3 つの設定可能な子要素で構成されます。セキュリティーレルムと送信接続はそれぞれ最初に定義されてから、管理インターフェースに属性として適用されます。
<security-realms>
<outbound-connections>
<management-interfaces>
セキュリティーレルムは、管理 API、管理 CLI、または Web ベースの管理コンソールを介して JBoss Enterprise Application Platform の管理を許可されているユーザーの認証と認証を行います。
ManagementRealm
と ApplicationRealm
です。これらのセキュリティレルムはそれぞれ -users.properties
ファイルを使用してユーザーおよびハッシュ化されたパスワードを保管し、-roles.properties
でユーザーとロール間のマッピングを保管します。サポートは LDAP 対応のセキュリティーレルムにも含まれています
注記
一部のセキュリティーレルムは、LDAP サーバーなどの外部インターフェースに接続します。送信接続は、この接続の確立方法を定義します。 事前に定義された接続タイプ ldap-connection
は、LDAP サーバーに接続して資格情報を検証するための必須およびオプションの属性をすべて設定します。
管理インターフェースには、JBoss Enterprise Application Platform の接続および設定方法に関するプロパティーが含まれています。この情報には、名前付きのネットワークインターフェース、ポート、セキュリティーレルム、およびインターフェースに関するその他の設定可能な情報が含まれます。デフォルトのインストールには 2 つのインターフェースが含まれています。
http-interface
は Web ベースの管理コンソールの設定です。native-interface
はコマンドライン管理 CLI および REST ライクな管理 API の設定です。
3.4. HTTP 管理インターフェースの無効化
注記
console-enabled-attribute
を false
に設定できます。
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=false)
例3.1 HTTP インターフェースの設定の読み込み
/host=master/core-service=management/management-interface=http-interface/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
{
"outcome" => "success",
"result" => {
"console-enabled" => true,
"interface" => "management",
"port" => expression "${jboss.management.http.port:9990}",
"secure-port" => undefined,
"security-realm" => "ManagementRealm"
}
}
例3.2 HTTP インターフェースの削除
/host=master/core-service=management/management-interface=http-interface/:remove
例3.3 HTTP インターフェースの再作成
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=true)
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=interface,value=management)
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=port,value=${jboss.management.http.port:9990})
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=ManagementRealm)
3.5. デフォルトセキュリティーレルムからのサイレント認証の削除
JBoss Enterprise Application Platform 6 には、ローカル管理 CLI ユーザーに対するサイレント認証方法が含まれます。これにより、ローカルユーザーは、ユーザー名またはパスワード認証なしで管理 CLI にアクセスできるようになります。この機能は、利便性のために有効であり、ローカルユーザーが認証なしで管理 CLI スクリプトを実行する場合に役に立ちます。この機能は、ローカル設定へのアクセスにより、ユーザーが独自のユーザー詳細を追加できる (または、セキュリティーチェックを無効にする) ため、役に立つ機能です。
security-realm
セクション内で local
要素を削除することにより、実現できます。これは、スタンドアロンサーバーインスタンス用の standalone.xml
と管理対象ドメイン用の host.xml
の両方に適用されます。特定のサーバー設定に与える可能性がある影響を考えると、local
要素を削除することをお勧めします。
local
要素を直接削除することです。
例3.4 security-realm
の local
要素の例
<security-realms> <security-realm name="ManagementRealm"> <authentication> <local default-user="$local"/> <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/> </authentication> </security-realm> <security-realm name="ApplicationRealm"> <authentication> <local default-user="$local" allowed-users="*"/> <properties path="application-users.properties" relative-to="jboss.server.config.dir"/> </authentication> <authorization> <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/> </authorization> </security-realm> </security-realms>
手順3.1 デフォルトセキュリティーレルムからのサイレント認証の削除
管理 CLI でのサイレント認証の削除
必要に応じて、管理レルムとアプリケーションレルムからlocal
要素を削除します。- 管理レルムから
local
要素を削除します。スタンドアロンの場合
/core-service=management/security-realm=ManagementRealm/authentication=local:remove
管理対象ドメインの場合
/host=HOST_NAME/core-service=management/security-realm=ManagementRealm/authentication=local:remove
- アプリケーションレルムから
local
要素を削除します。スタンドアロンの場合
/core-service=management/security-realm=ApplicationRealm/authentication=local:remove
管理対象ドメインの場合
/host=HOST_NAME/core-service=management/security-realm=ApplicationRealm/authentication=local:remove
サイレント認証モードが、ManagementRealm
と ApplicationRealm
から削除されます。
3.6. JMX サブシステムへのリモートアクセスの無効化
/profile=default
の部分を変更します。スタンドアロンサーバーの場合には、この部分を完全に削除してください。
注記
例3.5 JMX サブシステムからのリモートコネクターの削除
/profile=default/subsystem=jmx/remoting-connector=jmx/:remove
例3.6 JMX サブシステムの削除
/profile=default/subsystem=jmx/:remove
3.7. 管理インターフェースのセキュリティーレルムの設定
以下の例は、ManagementRealm
セキュリティーレルムのデフォルト設定を示しています。mgmt-users.properties
というファイルを使用して設定情報を保管します。
例3.7 デフォルトの ManagementRealm
/host=master/core-service=management/security-realm=ManagementRealm/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
{
"outcome" => "success",
"result" => {
"authorization" => undefined,
"server-identity" => undefined,
"authentication" => {"properties" => {
"path" => "mgmt-users.properties",
"plain-text" => false,
"relative-to" => "jboss.domain.config.dir"
}}
}
}
以下のコマンドは TestRealm
というセキュリティーレルムを作成し、関連プロパティーファイルの名前とディレクトリを設定します。
例3.8 セキュリティーレルムの書き込み
/host=master/core-service=management/security-realm=TestRealm/:add
/host=master/core-service=management/security-realm=TestRealm/authentication=properties/:add(path=TestUsers.properties, relative-to=jboss.domain.config.dir)
セキュリティーレルムを追加したら、その名前を管理インターフェースへの参照として指定します。
例3.9 管理インターフェースへのセキュリティーレルムの追加
host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=TestRealm)
3.8. 機密性の高い文字列のパスワードボールト
3.8.1. クリアテキストファイルでの機密性が高い文字列のセキュア化について
3.8.2. 機密性が高い文字列を格納する Java キーストアの作成
要件
keytool
コマンドを使用出来る必要があります。これは Java Runtime Environment (JRE) により提供されます。このファイルのパスを見つけます。Red Hat Enterprise Linux では、これは/usr/bin/keytool
にインストールされます。
手順3.2 Java キーストアの設定
キーストアと他の暗号化された情報を格納するディレクトリーを作成します。
キーストアと他の重要な情報を保持するディレクトリーを作成します。この残りの手順では、ディレクトリーが/home/USER/vault/
であることを前提とします。keytool
で使用するパラメーターを決定します。以下のパラメーターを決定します。- alias
- エイリアスは資格情報コンテナまたはキーストアに格納された vault または他のデータの一意の ID です。この手順の最後にあるコマンド例のエイリアスは
vault
です。エイリアスは大文字と小文字を区別します。 - keyalg
- 暗号化に使用するアルゴリズム。デフォルト値は
DSA
です。この手順の例ではRSA
です。利用可能な他の選択肢については、JRE およびオペレーティングシステムのドキュメンテーションを参照してください。 - keysize
- 暗号化キーのサイズにより、ブルートフォース攻撃により復号化する困難さが影響を受けます。キーのデフォルトサイズは 1024 です。これは 512 〜 1024 の範囲にあり、64 の倍数である必要があります。この手順の例では
1024
を使用します。 - keystore
- 暗号化された情報と暗号化方法に関する情報を保持するデータベースのキーストア。キーストアを指定しない場合、使用するデフォルトのキーストアはホームディレクトリーの
.keystore
という名前のファイルです。これは、キーストアにデータを初めて追加したときに作成されます。この手順の例では、vault.keystore
キーストアを使用します。
keystore
コマンドには他の多くのオプションがあります。詳細については、JRE またはオペレーティングシステムのドキュメンテーションを参照してください。keystore
コマンドが尋ねる質問の回答を決定します。keystore
は、キーストアエントリーに値を入力するために次の情報を必要とします。- キーストアパスワード
- キーストアを作成する場合は、パスワードを設定する必要があります。将来キーストアを使用するために、パスワードを提供する必要があります。覚えやすい強度の高いパスワードを作成します。キーストアは、パスワードや、キーストアが存在するファイルシステムおよびオペレーティングシステムのセキュリティーと同程度にセキュアです。
- キーパスワード (任意設定)
- キーストアパスワードに加え、保持する各キーにパスワードを指定することが可能です。このようなキーを使用するには、使用するたびにパスワードを提供する必要があります。通常、このファシリティーは使用されません。
- 名前 (名) と 名字 (姓)
- この情報と一覧の他の情報は、一意にキーを識別して他のキーの階層に置くのに役立ちます。名前である必要はありませんが、キーに一意な 2 つの言葉である必要があります。この手順の例では、
Accounting Administrator
を使用します。これが証明書のコモンネームになります。 - 組織単位
- 証明書を使用する人物を特定する単一の言葉です。アプリケーションユニットやビジネスユニットである場合もあります。この手順の例では
AccountingServices
を使用します。通常、1 つのグループやアプリケーションによって使用されるキーストアはすべて同じ組織単位を使用します。 - 組織
- 通常、所属する組織名を表す単一の言葉になります。一般的に、1 つの組織で使用されるすべての証明書で同じになります。この例では
MyOrganization
を使用します。 - 市または自治体
- お住まいの市名。
- 州または県
- お住まいの州や県、または同等の行政区画
- 国
- 2 文字の国コード
これらすべての情報によってキーストアや証明書の階層が作成され、一貫性のある一意な名前付け構造が確実に使用されるようにします。keytool
コマンドを実行し、収集した情報を提供します。例3.10
keystore
コマンドの入出力例$ keytool -genkey -alias vault -keyalg RSA -keysize 1024 -keystore /home/USER/vault/vault.keystore Enter keystore password: vault22 Re-enter new password:vault22 What is your first and last name? [Unknown]:
Accounting Administrator
What is the name of your organizational unit? [Unknown]:AccountingServices
What is the name of your organization? [Unknown]:MyOrganization
What is the name of your City or Locality? [Unknown]:Raleigh
What is the name of your State or Province? [Unknown]:NC
What is the two-letter country code for this unit? [Unknown]:US
Is CN=Accounting Administrator, OU=AccountingServices, O=MyOrganization, L=Raleigh, ST=NC, C=US correct? [no]:yes
Enter key password for <vault> (RETURN if same as keystore password):
/home/USER/vault/
ディレクトリに vault.keystore
という名前のファイルが作成されます。JBoss Enterprise Application Platform のパスワードなど、暗号化された文字列を格納するため使用される vault
という 1 つのキーがこのファイルに保存されます。
3.8.3. キーストアパスワードのマスキングとパスワード vault の初期化
要件
EAP_HOME/bin/vault.sh
アプリケーションはコマンドラインインターフェースからアクセスできる必要があります。
vault.sh
コマンドを実行します。EAP_HOME/bin/vault.sh
を実行します。0
を入力して新しい対話セッションを開始します。暗号化されたファイルが保存されるディレクトリを入力します。
このディレクトリはある程度保護されている必要がありますが、JBoss Enterprise Application Platform がアクセスできなければなりません。「機密性が高い文字列を格納する Java キーストアの作成」 の手順に従うと、キーストアはホームディレクトリにあるvault/
というディレクトリの中にあります。この例では/home/USER/vault/
を使用します。注記
必ずディレクトリ名の最後にスラッシュが含まれるようにしてください。ご使用のオペレーティングシステムに応じて/
または\
を使用します。キーストアへのパスを入力します。
キーストアファイルへの完全パスを入力します。この例では/home/USER/vault/vault.keystore
を使用します。キーストアパスワードを暗号化します。
次の手順に従って、設定ファイルやアプリケーションで安全に使用できるようキーストアのパスワードを暗号化します。キーストアパスワードを入力します。
入力を促されたらキーストアのパスワードを入力します。salt 値を入力します。
8 文字の salt 値を入力します。salt 値は反復回数(下記) と共にハッシュ値の作成に使用されます。反復回数を入力します。
反復回数の値を入力します。マスクされたパスワード情報を書き留めておきます。
マスクされたパスワード と salt、反復回数は標準出力へ書き出されます。これらの情報を安全な場所に書き留めておきます。攻撃者がこれらの情報を使用してパスワードを復号化する可能性があるからです。vault のエイリアスを入力します。
入力を促されたら、vault のエイリアスを入力します。「機密性が高い文字列を格納する Java キーストアの作成」 に従って vault を作成した場合、エイリアスはvault
になります。
対話コンソールを終了します。
exit
を入力して対話コンソールを終了します。
設定ファイルとデプロイメントで使用するため、キーストアパスワードがマスキングされます。また、vault が完全設定され、すぐ使用できる状態になります。
3.8.4. パスワード vault を使用するよう JBoss Enterprise Application Platform を設定
設定ファイルにあるパスワードや機密性の高いその他の属性をマスキングする前に、これらを保存し復号化するパスワード vault を JBoss Enterprise Application Platform が認識するようにする必要があります。次の手順に従ってこの機能を有効にします。
手順3.3 パスワード vault の設定
コマンドの適切な値を決定します。
キーストアの作成に使用されるコマンドによって決定される以下のパラメーターの値を決定します。キーストア作成の詳細は 「機密性が高い文字列を格納する Java キーストアの作成」 および 「キーストアパスワードのマスキングとパスワード vault の初期化」 を参照してください。パラメーター 説明 KEYSTORE_URL ファイルシステムのパスまたはキーストアファイル。通常vault.keystore
のようになります。KEYSTORE_PASSWORD キーストアのアクセスに使用されるパスワード。この値はマスクされる必要があります。KEYSTORE_ALIAS キーストアの名前。SALT キーストアの値を暗号化および復号化するために使用されるソルト。ITERATION_COUNT 暗号化アルゴリズムが実行される回数。ENC_FILE_DIR キーストアコマンドが実行されるディレクトリへのパス。通常、パスワード vault が含まれるディレクトリになります。host (管理対象ドメインのみ) 設定するホストの名前。管理 CLI を使用してパスワード vault を有効にします。
次のコマンドの 1 つを実行します。実行するコマンドは、管理対象ドメインを使用するか、スタンドアロンサーバー設定を使用するかによって異なります。コマンドの値は、手順の最初で使用した値に置き換えます。管理対象ドメイン
/host=YOUR_HOST/core-service=vault:add(vault-options=[("KEYSTORE_URL" => "PATH_TO_KEYSTORE"), ("KEYSTORE_PASSWORD" => "MASKED_PASSWORD"), ("KEYSTORE_ALIAS" => "ALIAS"), ("SALT" => "SALT"),("ITERATION_COUNT" => "ITERATION_COUNT"), ("ENC_FILE_DIR" => "ENC_FILE_DIR")])
スタンドアロンサーバー
/core-service=vault:add(vault-options=[("KEYSTORE_URL" => "PATH_TO_KEYSTORE"), ("KEYSTORE_PASSWORD" => "MASKED_PASSWORD"), ("KEYSTORE_ALIAS" => "ALIAS"), ("SALT" => "SALT"),("ITERATION_COUNT" => "ITERATION_COUNT"), ("ENC_FILE_DIR" => "ENC_FILE_DIR")])
仮の値を用いたコマンドの例は次のとおりです。/core-service=vault:add(vault-options=[("KEYSTORE_URL" => "/home/user/vault/vault.keystore"), ("KEYSTORE_PASSWORD" => "MASK-3y28rCZlcKR"), ("KEYSTORE_ALIAS" => "vault"), ("SALT" => "12438567"),("ITERATION_COUNT" => "50"), ("ENC_FILE_DIR" => "/home/user/vault/")])
パスワード vault を使用してマスキングされた文字列を復号化するよう JBoss Enterprise Application Platform が設定されます。vault に文字列を追加し、設定で使用する場合は 「Java キーストアに暗号化された機密性の高い文字列の保存および読み出し」 を参照してください。
3.8.5. Java キーストアに暗号化された機密性の高い文字列の保存および読み出し
パスワードや、機密性の高いその他の文字列が平文の設定ファイルに含まれるのはセキュアではありません。JBoss Enterprise Application Platform には、このような機密性の高い文字列をマスキングして暗号化されたキーストアに保存する機能や、設定ファイルでマスクされた値を使用する機能が含まれています。
要件
EAP_HOME/bin/vault.sh
アプリケーションはコマンドラインインターフェースからアクセスできる必要があります。
手順3.4 Java キーストアの設定
vault.sh
コマンドを実行します。EAP_HOME/bin/vault.sh
を実行します。0
を入力して新しい対話セッションを開始します。暗号化されたファイルが保存されるディレクトリを入力します。
「機密性が高い文字列を格納する Java キーストアの作成」 に従って作業を行った場合は、キーストアはホームディレクトリのvault/
というディレクトリにあります。ほとんどの場合では、暗号化されたすべての情報をキーストアとして同じ場所に保存するのが普通です。この例では/home/USER/vault/
ディレクトリを使用します。注記
必ずディレクトリ名の最後にスラッシュが含まれるようにしてください。ご使用のオペレーティングシステムに応じて/
または\
を使用します。キーストアへのパスを入力します。
キーストアファイルへの完全パスを入力します。この例では/home/USER/vault/vault.keystore
を使用します。キーストアパスワード、vault 名、ソルト、反復回数を入力します。
入力を促されたら、キーストアパスワード、vault 名、ソルト、反復回数を入力します。ハンドシェイクが実行されます。パスワードを保存するオプションを選択します。
オプション0
を選択して、パスワードや機密性の高い他の文字列を保存します。値を入力します。
入力を促されたら、値を 2 回入力します。値が一致しない場合は再度入力するよう要求されます。vault ブロックを入力します。
同じリソースに関連する属性のコンテナである vault ブロックを入力します。属性名の例としてはds_ExampleDS
などが挙げられます。データソースまたは他のサービス定義で、暗号化された文字列への参照の一部を形成します。属性名を入力します。
保存する属性の名前を入力します。password
が属性名の例の 1 つになります。結果属性が保存されたことが、以下のようなメッセージによって示されます。
Attribute Value for (ds_ExampleDS, password) saved
暗号化された文字列に関する情報を書き留めます。
メッセージは vault ブロック、属性名、共有キー、および設定で文字列を使用する場合のアドバイスを表示する標準出力を出力します。安全な場所にこの情報を書き留めておくようにしてください。出力例は次のとおりです。******************************************** Vault Block:ds_ExampleDS Attribute Name:password Shared Key:N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0 Configuration should be done as follows: VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0 ********************************************
設定で暗号化された文字列を使用します。
プレーンテキストの文字列の代わりに、前の設定手順の文字列を使用します。以下は、上記の暗号化されたパスワードを使用するデータソースになります。... <subsystem xmlns="urn:jboss:domain:datasources:1.0"> <datasources> <datasource jndi-name="java:jboss/datasources/ExampleDS" enabled="true" use-java-context="true" pool-name="H2DS"> <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url> <driver>h2</driver> <pool></pool> <security> <user-name>sa</user-name> <password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password> </security> </datasource> <drivers> <driver name="h2" module="com.h2database.h2"> <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class> </driver> </drivers> </datasources> </subsystem> ...
式が許可されるドメインまたはスタンドアロン設定ファイルであれば、どこでも暗号化された文字列を使用することができます。注記
特定のサブシステム内で式が許可されるかを確認するには、そのサブシステムに対して次の CLI コマンドを実行します。/host=master/core-service=management/security-realm=TestRealm:read-resource-description(recursive=true)
このコマンドの出力で、expressions-allowed
パラメーターの値を探します。値が true であればこのサブシステムの設定内で式を使用できます。文字列をキーストアに格納した後、次の構文を使用してクリアテキストの文字列を暗号化された文字列に置き換えます。${VAULT::<replaceable>VAULT_BLOCK</replaceable>::<replaceable>ATTRIBUTE_NAME</replaceable>::<replaceable>ENCRYPTED_VALUE</replaceable>}
実環境の値の例は次のとおりです。vault ブロックはds_ExampleDS
、属性はpassword
です。<password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password>
3.8.6. アプリケーションで機密性の高い文字列を保存および解決
JBoss Enterprise Application Platform の設定要素は、セキュリティー vault メカニズムを通じて Java キーストアに保存される値に対して暗号化された文字列を解決する機能をサポートしています。この機能に対するサポートを独自のアプリケーションに追加することができます。
この手順を実行する前に、vault ファイルを格納するディレクトリが存在することを確認してください。JBoss Enterprise Application Platform を実行するユーザーが vault ファイルを読み書きできるパーミッションを持っていれば、vault ファイルの場所はどこでも構いません。この例では、vault/
ディレクトリを /home/USER/vault/
ディレクトリに置きます。vault 自体は vault/
ディレクトリの中にある vault.keystore
と呼ばれるファイルになります。
例3.11 vault へのパスワードの文字列の追加
EAP_HOME/bin/vault.sh
コマンドを用いて文字列を vault へ追加します。次の画面出力にコマンドと応答がすべて含まれています。ユーザー入力の値は強調文字で表されています。出力の一部は書式上、削除されています。Microsoft Windows ではコマンド名は vault.bat
になります。Microsoft Windows のファイルパスでは、ディレクトリの分離記号として /
ではなく \
が使用されることに注意してください。
[user@host bin]$ ./vault.sh ********************************** **** JBoss Vault ******** ********************************** Please enter a Digit:: 0: Start Interactive Session 1: Remove Interactive Session 2: Exit0
Starting an interactive session Enter directory to store encrypted files:/home/user/vault/
Enter Keystore URL:/home/user/vault/vault.keystore
Enter Keystore password:...
Enter Keystore password again:...
Values match Enter 8 character salt:12345678
Enter iteration count as a number (Eg: 44):25
Enter Keystore Alias:vault
Vault is initialized and ready for use Handshake with Vault complete Please enter a Digit:: 0: Store a password 1: Check whether password exists 2: Exit0
Task: Store a password Please enter attribute value:sa
Please enter attribute value again:sa
Values match Enter Vault Block:DS
Enter Attribute Name:thePass
Attribute Value for (DS, thePass) saved Please make note of the following: ******************************************** Vault Block:DS Attribute Name:thePass Shared Key:OWY5M2I5NzctYzdkOS00MmZhLWExZGYtNjczM2U5ZGUyOWIxTElORV9CUkVBS3ZhdWx0 Configuration should be done as follows: VAULT::DS::thePass::OWY5M2I5NzctYzdkOS00MmZhLWExZGYtNjczM2U5ZGUyOWIxTElORV9CUkVBS3ZhdWx0 ******************************************** Please enter a Digit:: 0: Store a password 1: Check whether password exists 2: Exit2
VAULT
で始まる行です。
例3.12 vault されたパスワードを使用するサーブレット
package vaulterror.web; import java.io.IOException; import java.io.Writer; import javax.annotation.Resource; import javax.annotation.sql.DataSourceDefinition; import javax.servlet.ServletException; import javax.servlet.annotation.WebServlet; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.sql.DataSource; /*@DataSourceDefinition( name = "java:jboss/datasources/LoginDS", user = "sa", password = "sa", className = "org.h2.jdbcx.JdbcDataSource", url = "jdbc:h2:tcp://localhost/mem:test" )*/ @DataSourceDefinition( name = "java:jboss/datasources/LoginDS", user = "sa", password = "VAULT::DS::thePass::OWY5M2I5NzctYzdkOS00MmZhLWExZGYtNjczM2U5ZGUyOWIxTElORV9CUkVBS3ZhdWx0", className = "org.h2.jdbcx.JdbcDataSource", url = "jdbc:h2:tcp://localhost/mem:test" ) @WebServlet(name = "MyTestServlet", urlPatterns = { "/my/" }, loadOnStartup = 1) public class MyTestServlet extends HttpServlet { private static final long serialVersionUID = 1L; @Resource(lookup = "java:jboss/datasources/LoginDS") private DataSource ds; @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { Writer writer = resp.getWriter(); writer.write((ds != null) + ""); } }
3.9. LDAP
3.9.1. LDAP について
3.9.2. 管理インターフェースに対する LDAP を使用した認証
- LDAP サーバーへの送信接続を作成します。
- LDAP 対応のセキュリティーレルムを作成します。
- 管理インターフェースの新規セキュリティードメインを参照します。
LDAP 送信接続には、以下の属性を使用することができます。
表3.1 LDAP 送信接続の属性
属性 | 必要性 | 説明 |
---|---|---|
name | 必要 |
この接続を識別するための名前。この名前はセキュリティーレルムの定義に使用されます。
|
url | 必要 |
ディレクトリサーバーの URL アドレス。
|
search-dn | 必要 |
検索の実行を許可されているユーザーの完全識別名 (DN)
|
search-credentials | 必要 |
検索の実行を許可されているユーザーのパスワード。
|
initial-context-factory | 不必要 |
接続を確立する際に使用する初期コンテキストファクトリ。デフォルトでは
com.sun.jndi.ldap.LdapCtxFactory に設定されています。
|
例3.13 LDAP 送信接続の追加
- DN の検索:
cn=search,dc=acme,dc=com
- 証明情報の検索:
myPass
- URL:
ldap://127.0.0.1:389
/host=master/core-service=management/ldap-connection=ldap_connection/:add(search-credential=myPass,url=ldap://127.0.0.1:389,search-dn="cn=search,dc=acme,dc=com")
例3.14 LDAP 送信出力を示す XML
<outbound-connections> <ldap name="ldap_connection" url="ldap://127.0.0.1:389" search-dn="cn=search,dc=acme,dc=com" search-credential="myPass" /> </outboundconnections>
管理インターフェースは、デフォルトで設定されているプロパティーファイルをベースとするセキュリティーレルムの代わりに LDAP サーバーに対して認証を行うことができます。LDAP のオーセンティケーターは、最初にリモートディレクトリサーバーへの接続を確立します。次に、LDAP レコードの完全修飾識別名 (DN) を探すため、ユーザーが認証システムに渡したユーザー名を使用して検索を実行します。認証情報としてユーザーの DN とユーザー提供のパスワードを使用して、新規接続が確立されます。 このLDAP サーバーに対するこの検証に成功すると、DN が有効であることが検証されます。
- connection
<outbound-connections>
に定義されている接続の名前。LDAP ディレクトリへの接続に使用します。- base-dn
- ユーザー検索を開始するためのコンテキストの識別名
- recursive
- LDAP ディレクトリツリー全体にわたって再帰的に検索を行うか、指定のコンテキストのみを検索するかを指定します。デフォルトでは
false
に設定されています。 - user-dn
- 識別名を持つするユーザーの属性。これは、後で認証のテストに使用されます。デフォルトでは
dn
に設定されています。 - 子要素として、
username-filter
またはadvanced-filter
のいずれか。 username-filter
はattribute
という単一の属性を取り、値はuserName
やsambaAccountName
などのユーザー名を持つ LDAP 属性の名前です。advanced-filter
はfilter
と呼ばれる単一の属性を取ります。この属性には、標準的な LDAP 構文のフィルタークエリが含まれています。&
文字を&
に変更し、エスケープすることに注意してください。フィルターの例は次のとおりです。(&(sAMAccountName={0})(memberOf=cn=admin,cn=users,dc=acme,dc=com))
アンパサンド文字をエスケープすると、フィルターは次のようになります。(&(sAMAccountName={0})(memberOf=cn=admin,cn=users,dc=acme,dc=com))
例3.15 LDAP 対応のセキュリティーレルムを示す XML
- connection -
ldap_connection
- base-dn -
cn=users,dc=acme,dc=com
. - username-filter -
attribute="sambaAccountName"
<security-realm name="TestRealm"> <authentication> <ldap connection="ldap_connection" base-dn="cn=users,dc=acme,dc=com"> <username-filter attribute="sambaAccountName" /> </ldap> </authentication> </security-realm>
警告
例3.16 LDAP セキュリティーレルムの追加
/host=master/core-service=management/security-realm=ldap_security_realm/authentication=ldap:add(base-dn="DC=mycompany,DC=org", recursive=true, username-attribute="MyAccountName", connection="ldap_connection")
セキュリティーレルムの作成が完了したら、管理インターフェースの設定でそのドメインを参照する必要があります。管理インターフェースは、HTTP ダイジェスト認証用のセキュリティーレルムを使用します。
例3.17 HTTP インターフェースへのセキュリティーレルムの適用
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=TestRealm)
第4章 Java セキュリティマネージャー
4.1. Java Security Manager について
Java Security Manager は、Java 仮想マシン (JVM) サンドボックスの外部境界を管理するクラスで、JVM 内で実行するコードが JVM 外のリソースと対話する方法を制御します。Java Security Manager が有効な場合、Java API は安全でない可能性のある操作を行う前に Security Manager が承認するか確認します。
4.2. Java Security Manager のポリシーについて
様々なコードのクラスに対する定義済みのパーミッションセット。Java Security Manager はアプリケーションが要求したアクションと、このセキュリティーポリシーを比較します。ポリシーでアクションが許可された場合、Security Manager により、アクションの実行が許可されます。ポリシーによりアクションが許可されない場合、Security Manager はこのアクションを拒否します。セキュリティーポリシーは、コードの場所やコードのシグネチャーを基にパーミッションを定義することができます。
java.security.manager
や java.security.policy
を使用して設定されます。
4.3. Java Security Manager 内での JBoss Enterprise Application Platform の実行
domain.sh
スクリプトまたは standalone.sh
スクリプトにパラメーターをオプションとして渡すことはできません。次の手順を実行すると、インスタンスが Java Security Manager ポリシー内で実行されるよう設定できます。
要件
- この手順を実行する前に、Java Development Kit (JDK) に含まれる
policytool
コマンドを使用してセキュリティーポリシーを記述する必要があります。この手順では、ポリシーがEAP_HOME/bin/server.policy
にあることを前提としています。 - 設定ファイルを編集する前に、ドメインまたはスタンドアロンサーバーを完全に停止する必要があります。
手順4.1 設定ファイルの編集
設定ファイルを開きます。
編集のために設定ファイルを開きます。このファイルは、管理対象ドメインを使用しているか、スタンドアロンサーバーを使用しているかに応じて、2 つの場所のいずれかに存在します。これは、サーバーまたはドメインを起動するために使用される実行可能ファイルではありません。管理対象ドメイン
EAP_HOME/bin/domain.conf
スタンドアロンサーバー
EAP_HOME/bin/standalone.conf
ファイルの最後に Java オプションを追加します。
以下の行をファイルの最後に追加します。-Djava.security.policy
値を変更してセキュリティーポリシーの場所を指定できます。改行をせずに 1 行で指定する必要があります。デバッグレベルを指定して-Djava.security.debug
を変更し、さらに多くの情報または少ない情報をログに記録できます。最も冗長なのはfailure,access,policy
です。JAVA_OPTS="$JAVA_OPTS -Djava.security.manager -Djboss.home.dir=$PWD/.. -Djava.security.policy==$PWD/server.policy -Djava.security.debug=failure"
ドメインサーバーを起動します。
ドメインまたはサーバーを通常どおり起動します。
4.4. Java Security Manager ポリシーの記述
ほとんどの JDK および JRE ディストリビューションには、Java Security Manager セキュリティーポリシーを作成および編集するための policytool
という名前のアプリケーションが含まれます。policytool
の詳細については、http://docs.oracle.com/javase/6/docs/technotes/tools/ を参照してください。
セキュリティーポリシーは、次の設定要素から構成されます。
- CodeBase
- コードの元の URL の場所 (ホストとドメイン情報を除外)。オプションのパラメーターです。
- SignedBy
- コードを署名するためにプライベートキーが使用された署名者を参照するキーストアで使用されたエイリアス。これは、単一値またはカンマ区切りの値リストになります。オプションのパラメーターです。省略された場合は、署名の有無に関わらず Java Security Manager に影響はありません。
- Principals
- principal_type/principal_name ペアのリスト。これは、実行スレッドのプリンシパルセット内に存在する必要があります。Principals エントリはオプションです。省略された場合は、「任意のプリンシパル」を意味します。
- Permissions
- パーミッションは、コードに与えられるアクセスです。多くのパーミッションは、Java Enterprise Edition 6 (Java EE 6) 仕様の一部として提供されます。本書では、JBoss Enterprise Application Platform で提供される追加のパーミッションについてのみ説明します。
手順4.2 新しい Java Security Manager ポリシーの設定
policytool
を起動します。policytool
ツールを次のいずれかの方法で起動します。Red Hat Enterprise Linux
GUI またはコマンドプロンプトで、/usr/bin/policytool
を実行します。Microsoft Windows Server
スタート メニューまたは Java インストールのbin\
から、policytool.exe
を実行します。場所は異なることがあります。
ポリシーを新規作成します。
ポリシーを新規作成するには、Add Policy Entry を選択します。必要なパラメーターを追加し、Done をクリックします。既存のポリシーの編集
既存のポリシーのリストからポリシーを選択し、Edit Policy Entry ボタンを選択します。必要に応じて、パラメーターを編集します。既存のポリシーを削除します。
既存のポリシーのリストからポリシーを選択し、Delete Policy Entry ボタンを選択します。
JBoss Enterprise Application Platform に固有なパーミッション
- org.jboss.security.SecurityAssociation.getPrincipalInfo
org.jboss.security.SecurityAssociation.
getPrincipal()
メソッドとgetCredential()
メソッドにアクセスを提供します。このランタイムパーミッションを使用する場合、現在のスレッド呼び出し元プリンシパルとクレデンシャルを設定できるというリスクが発生します。- org.jboss.security.SecurityAssociation.getSubject
org.jboss.security.SecurityAssociation
getSubject()
メソッドにアクセスを提供します。- org.jboss.security.SecurityAssociation.setPrincipalInfo
org.jboss.security.SecurityAssociation.
setPrincipal()
メソッド、setCredential()
メソッド、setSubject()
メソッド、pushSubjectContext()
メソッド、およびpopSubjectContext()
メソッドにアクセスを提供します。このランタイムパーミッションを使用する場合、現在のスレッド呼び出し元プリンシパルとクレデンシャルを見ることができるというリスクが発生します。- org.jboss.security.SecurityAssociation.setServer
org.jboss.security.SecurityAssociation.
setServer()
メソッドにアクセスを提供します。このランタイムパーミッションを使用する場合、呼び出し元プリンシパルとクレデンシャルのマルチスレッドストレージを有効または無効にできるというリスクが発生します。- org.jboss.security.SecurityAssociation.setRunAsRole
org.jboss.security.SecurityAssociation.
pushRunAsRole()
メソッド、popRunAsRole()
メソッド,pushRunAsIdentity()
メソッド、およびpopRunAsIdentity()
メソッドにアクセスを提供します。このランタイムパーミッションを使用する場合、現在の呼び出し元プリンシパルの run-as ロールプリンシパルを変更できるというリスクが発生します。- org.jboss.security.SecurityAssociation.accessContextInfo
org.jboss.security.SecurityAssociation
accessContextInfo
およびaccessContextInfo
の getter および setter メソッドにアクセスを提供します。これにより、現在のセキュリティーコンテキスト情報を設定および取得できます。- org.jboss.naming.JndiPermission
- 特別なパーミッションを、指定された JNDI ツリーパスのファイルおよびディレクトリーに提供するか、またはすべてのファイルとディレクトリーに対して再帰的に提供します。JndiPermission は、ファイルまたはディレクトリーに関連するパス名および有効なパーミッションセットから構成されます。利用可能なパーミッションには以下のものがあります。
- bind
- rebind
- unbind
- lookup
- list
- listBindings
- createSubcontext
- all
/*
で終わるパス名は、指定されたパーミッションがパス名のすべてのファイルとディレクトリに適用されることを示します。/-
で終わるパス名は、パス名のすべてのファイルとサブディレクトリに対して再帰的にパーミッションが与えられることを示します。パス名は、任意のディレクトリーの任意のファイルに一致する特別なトークン <<ALL BINDINGS>> から構成されます。 - org.jboss.security.srp.SRPPermission
- プライベートセッションキーやプライベートキーなどの機密性の高い SRP 情報へのアクセスを保護するカスタムパーミッションクラス。
getSessionKey
ターゲットは、SRP ネゴシエーションの結果得られるプライベートセッションへのアクセスを提供します。このキーへのアクセスでは、セッションキーで暗号化されたメッセージを暗号化および復号化できます。 - org.hibernate.secure.HibernatePermission
- このパーミッションクラスは、Hibernate セッションをセキュアにする基本的なパーミッションを提供します。このプロパティーのターゲットはエンティティー名です。利用可能なアクセスには以下のものがあります。
- insert
- delete
- update
- read
- * (all)
- org.jboss.metadata.spi.stack.MetaDataStackPermission
- 読み出し元がメタデータスタックと対話する方法を制御するカスタムパーミッションクラスを提供します。利用可能なパーミッションは以下のとおりです。
- modify
- push (スタックに対する)
- pop (スタックから)
- peek (スタックに対する)
- * (all)
- org.jboss.config.spi.ConfigurationPermission
- 設定プロパティーの設定をセキュアにします。パーミッションターゲット名のみを定義し、アクションを定義しません。このプロパティーのターゲットには以下のものが含まれます。
- <property name> (このコードが設定するパーミッションを持つプロパティー)
- * (すべてのプロパティー)
- org.jboss.kernel.KernelPermission
- カーネル設定へのアクセスをセキュアにします。パーミッションターゲット名のみを定義し、アクションを定義しません。このプロパティーのターゲットには以下のものが含まれます。
- access (カーネル設定に対する)
- configure (アクセスを含む)
- * (all)
- org.jboss.kernel.plugins.util.KernelLocatorPermission
- カーネルへのアクセスをセキュアにします。パーミッションターゲット名のみを定義し、アクションを定義しません。このプロパティーのターゲットには以下のものが含まれます。
- kernel
- * (all)
4.5. Security Manager ポリシーのデバッグ
java.security.debug
オプションは、報告されたセキュリティー関連情報のレベルを設定します。コマンド java -Djava.security.debug=help
は、すべてのデバッグオプションのヘルプ出力を表示します。デバッグレベルを all
に設定すると、原因がまったくわからないセキュリティー関連の障害をトラブルシューティングするときに役に立ちますが、一般的な使用には多すぎる量の情報が表示されます。一般的に適切なデフォルト値は access:failure
です。
手順4.3 一般的なデバッグの有効化
この手順を実行すると、セキュリティー関連デバッグ情報の一般的な機密レベルを有効にすることができます。
次の行をサーバー設定ファイルに追加します。- 管理対象ドメインで JBoss Enterprise Application Platform インスタンスが実行されている場合、以下の行は Linux では
bin/domain.conf
ファイル、Windows ではbin/domain.conf.bat
ファイルに追加されます。 - JBoss Enterprise Application Platform インスタンスがスタンドアロンサーバーとして実行されている場合、以下の行は Linux では
bin/standalone.conf
ファイル、Windows ではbin\standalone.conf.bat
ファイルに追加されます。
Linux
JAVA_OPTS="$JAVA_OPTS -Djava.security.debug=access:failure"
Windows
JAVA_OPTS="%JAVA_OPTS% -Djava.security.debug=access:failure"
セキュリティー関連デバッグ情報の一般的なレベルが有効になります。
第5章 パッチインストール
5.1. パッチングの仕組み
- 計画された更新: 既存製品のマイクロ、マイナー、またはメジャーアップグレード。
- 非同期更新: 既存製品の通常のアップグレードサイクル以外にリリースされる 1 回限りのパッチ。
- バグ悪用の容易さ。
- 悪用された場合、どのような被害があるか。
- 欠陥の影響を低減する他の要素はあるか (ファイアウォール、Security-Enhanced Linux、コンパイラー指示文など)。
5.2. パッチメーリングリストへのサブスクライブ
Red Hat の JBoss チームは、Red Hat JBoss Enterprise Middleware 製品のセキュリティーに関する情報をお知らせするメーリングリストを管理しています。ここでは、このリストへサブスクライブする方法について取り上げます。
要件
- なし
手順5.1 JBoss Watch List へのサブスクライブ
- 次のリンクをクリックして、JBoss Watch メーリングリストのページへ移動します: JBoss Watch Mailing List。
- Subscribing to Jboss-watch-list にメールアドレスを入力します。
- 名前を入力し、パスワードを選択することも可能です。名前とパスワードの指定は任意ですが推奨されます。
- Subscribe ボタンを押してサブスクリプションプロセスを開始します。
- メーリングリストのアーカイブは JBoss Watch Mailing List Archives で閲覧できます。
メールアカウントの確認後、JBoss パッチメーリングリストへのサブスクライブが完了し、セキュリティー関連の通知を受け取るようになります。
5.3. zip 形式のパッチをインストールする
JBoss セキュリティーパッチは、zip (全製品) と RPM (製品のサブセット) の 2 つの形式で配布されます。JBoss バグ修正パッチは zip 形式でのみ配布されます。このタスクでは、zip 形式でパッチ (セキュリティーまたはバグ修正) をインストールするために必要な手順について説明します。
要件
- Red Hat カスタマーポータルへの有効なアクセスおよびサブスクリプション。
- zip 形式でインストールされた JBoss 製品の現在のサブスクリプション。
手順5.2 zip 形式で JBoss 製品へパッチを適用する
警告
- JBoss watch メーリングリストにサブスクライブするか、JBoss watch メーリングリストのアーカイブを閲覧して、セキュリティーパッチに関する情報を入手します。
注記
JBoss watch メーリングリストではセキュリティーパッチのお知らせのみが通知されます。 - エラータを読んでセキュリティーパッチに関する情報を取得し、使用環境の JBoss 製品に適用されることを確認します。
- セキュリティーパッチが使用環境の JBoss 製品に適用される場合は、リンク先の Red Hat カスタマーポータルからパッチをダウンロードします。
- カスタマーポータルのダウンロード可能な zip ファイルには、セキュリティーの問題やバグの修正に必要なファイルがすべて含まれています。ご使用の JBoss 製品がある場所にこのパッチ zip ファイルをダウンロードします。
- JBoss 製品がインストールされている場所でパッチファイルを展開します。パッチ適用済みのバージョンは既存ファイルを上書きします。
zip 形式を使用して JBoss 製品に最新の更新が適用されます。
5.4. RPM 形式のパッチをインストールする
JBoss のパッチは、zip (全製品) と RPM (製品のサブセット) の 2 つの形式で配布されます。このタスクでは、RPM 形式でパッチをインストールするために必要な手順について説明します。RPM の更新方法は、セキュリティー非同期パッチと、製品のマクロ、マイナー、およびメジャー更新のみを配布するために使用されます。
要件
- Red Hat Network への有効なサブスクリプション。
- RPM パッケージでインストールされた JBoss 製品の現在のサブスクリプション。
手順5.3 RPM 形式で JBoss 製品へパッチを適用する
警告
- JBoss watch メーリングリストにサブスクライブするか、JBoss watch メーリングリストのアーカイブを閲覧して、セキュリティーパッチに関する情報を入手します。
- エラータを読んでセキュリティーパッチに関する情報を取得し、使用環境の JBoss 製品に適用されることを確認します。
- セキュリティーパッチが使用環境の JBoss 製品に適用される場合は、リンク先よりエラータに含まれている更新済みの RPM パッケージをダウンロードします。
- パッチをインストールするには、以下のコマンドまたは同様のコマンドを実行します。
yum update
RPM 形式を使用して JBoss 製品に最新の更新が適用されます。
5.5. JBoss セキュリティーパッチの深刻度および影響度
表5.1 JBoss セキュリティーパッチの深刻度
深刻度 | 説明 |
---|---|
Critical (重大) |
非認証のリモート攻撃者が簡単に悪用でき、ユーザーとやりとりしなくてもシステムが危険にさらされる (任意コード実行) 欠陥にこの深刻度が適用されます。ワームによって悪用される脆弱性になります。認証されたリモートユーザー、ローカルユーザー、または想定外の設定を必要とする欠陥は重大な欠陥とは分類されません。
|
Important (高) |
リソースの機密性、整合性、または可用性が簡単に危険にさらされる欠陥にこの深刻度が付けられます。ローカルユーザーが権限を取得できる場合、非認証のリモートユーザーが認証によって保護されるリソースを閲覧できる場合、認証されたリモートユーザーが任意コードを実行できる場合、あるいはサービス拒否がローカルまたはリモートユーザーによって引き起こされる場合、この脆弱性タイプになります。
|
Moderate (中) |
悪用するのは比較的困難であっても、リソースの機密性、整合性、または可用性が一部危険にさらされる原因となる欠陥にこの深刻度が付けられます。重大または重要な影響を与える可能性はあっても、欠陥の技術評価を基にするとそれほど簡単には悪用できなかったり、想定外の設定に影響しない脆弱性のタイプになります。
|
Low (低) |
セキュリティーに影響する問題で、前述の深刻度に該当しないものにこの深刻度が適用されます。想定外の状況でのみ悪用される可能性があるとみられる脆弱性や、悪用されても影響が最小限にとどまる脆弱性のタイプになります。
|
例5.1 CVSS v2 の影響スコア
C:N/I:P/A:C
第6章 セキュリティードメイン
6.1. セキュリティードメインについて
6.2. Picketbox について
- 「承認について」 およびアクセス制御
- プリンシパル、ロール、および属性の 「セキュリティーマッピングについて」
6.3. 認証について
6.4. セキュリティードメインでの認証の設定
手順6.1 セキュリティードメインの認証設定
セキュリティードメインの詳細ビューを開きます。
管理コンソールの右上にある Profiles ラベルをクリックします。管理対象ドメインで、Profile ビューの左上にある Profile 選択ボックスから変更するプロファイルを選択します。左側の Security メニュー項目をクリックし、展開されたメニューで Security Domains をクリックします。編集するセキュリティードメインの View リンクをクリックします。認証サブシステム設定に移動します。
ビューの最上部の Authentication ラベルをクリックします (まだ設定されていない場合)。設定領域が Login Modules と Details の 2 つの領域に分割されます。ログインモジュールは、設定の基本単位です。セキュリティードメインには複数のログインモジュールを含めることができ、各ログインモジュールには複数の属性とオプションを含めることができます。認証モジュールを追加します。
Add ボタンをクリックして JAAS 認証モジュールを追加します。モジュールの詳細を記入します。Code がモジュールのクラス名です。Flags は、モジュールが同じセキュリティードメイン内で他の認証モジュールにどのように関係するかを制御します。フラグの説明Java Enterprise Edition 6 の仕様では、セキュリティーモジュールの次の説明が提供されます。次のリストは、http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA に記載されています。詳細については、このドキュメントを参照してください。
フラグ 詳細 required LoginModule は成功する必要があります。成功または失敗すると、LoginModule リストで認証が引き続き続行されます。requisite LoginModule は成功する必要があります。成功すると、LoginModule リストで認証が続行されます。失敗すると、制御がアプリケーションにすぐに戻ります (認証は LoginModule リストで続行されません)。sufficient LoginModule は成功する必要はありません。成功した場合は、制御がアプリケーションにすぐに戻ります (認証は LoginModule リストで続行されません)。失敗すると、認証は LoginModule リストで続行されます。optional LoginModule は成功する必要がありません。成功または失敗した場合、認証は LoginModule リストで続行されます。モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code または Flags を変更できます。Attributes タブが選択されていることを確認します。モジュールオプションを追加、編集、または削除します (任意)。
モジュールにオプションを追加する必要がある場合は、Login Modules リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add ボタンをクリックし、オプションのキーと値を提供します。すでに存在するオプションを編集するには、キーをクリックするか、変更します。Remove ボタンを使用してオプションを削除します。
認証モジュールが、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。
jboss.security.security_domain
モジュールのオプション
デフォルトでは、セキュリティードメインに定義された各ログインモジュールには jboss.security.security_domain
モジュールオプションが自動的に追加されます。既知のオプションのみが定義されるようチェックを行うログインモジュールでは、このオプションが問題の原因となります。このようなログインモジュールの 1 つが IBM Kerberos ログインモジュールの com.ibm.security.auth.module.Krb5LoginModule
です。
true
に設定します。以下を起動パラメーターに追加します。
-Djboss.security.disable.secdomain.option=true
6.5. 承認について
6.6. セキュリティードメインにおける承認の設定
手順6.2 セキュリティードメインの承認設定
セキュリティードメインの詳細ビューを開きます。
管理コンソールの右上にある Profiles ラベルをクリックします。管理対象ドメインで、Profile ビューの左上にある Profile 選択ボックスから変更するプロファイルを選択します。左側の Security メニュー項目をクリックし、展開されたメニューで Security Domains をクリックします。編集するセキュリティードメインの View リンクをクリックします。承認サブシステム設定に移動します。
ビューの最上部にある Authorization ラベルをクリックします (選択されていない場合)。設定領域が Policies と Details の 2 つの領域に分割されます。ログインモジュールは、設定の基本単位です。セキュリティードメインには複数の承認ポリシーを含めることができ、各ログインモジュールには複数の属性とオプションを含めることができます。ポリシーを追加します。
Add ボタンをクリックして JAAS 承認ポリシーモジュールを追加します。モジュールの詳細を記入します。Code がモジュールのクラス名です。Flags は、モジュールが同じセキュリティードメイン内で他の承認ポリシーモジュールにどのように関係するかを制御します。フラグの説明Java Enterprise Edition 6 の仕様では、セキュリティーモジュールの次の説明が提供されます。次のリストは、http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA に記載されています。詳細については、このドキュメントを参照してください。
フラグ 詳細 required LoginModule は成功する必要があります。成功または失敗すると、LoginModule リストで承認が引き続き続行されます。requisite LoginModule は成功する必要があります。成功すると、LoginModule リストで承認が続行されます。失敗すると、制御がアプリケーションにすぐに戻ります (承認は LoginModule リストで続行されません)。sufficient LoginModule は成功する必要はありません。成功した場合は、制御がアプリケーションにすぐに戻ります (承認は LoginModule リストで続行されません)。失敗すると、承認は LoginModule リストで続行されます。optional LoginModule は成功する必要がありません。成功または失敗した場合、承認は LoginModule リストで続行されます。モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code または Flags を変更できます。Attributes タブが選択されていることを確認します。モジュールオプションを追加、編集、または削除します (任意)。
モジュールにオプションを追加する必要がある場合は、Login Modules リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add ボタンをクリックし、オプションのキーと値を提供します。すでに存在するオプションを編集するには、キーをクリックするか、変更します。Remove ボタンを使用してオプションを削除します。
承認ポリシーモジュールが、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。
6.7. セキュリティー監査について
6.8. セキュリティー監査の設定
手順6.3 セキュリティードメインのセキュリティー監査の設定
セキュリティードメインの詳細ビューを開きます。
管理コンソールの右上にある Profiles ラベルをクリックします。スタンドアロンサーバーでは、タブに Profile ラベルがあります。管理対象ドメインでは、Profile ビューの左上にある Profile 選択ボックスから変更するプロファイルを選択します。左側の Security メニュー項目をクリックし、展開されたメニューで Security Domains をクリックします。編集するセキュリティードメインの View リンクをクリックします。監査サブシステム設定に移動します。
ビューの最上部の Audit ラベルをクリックします (まだ設定されていない場合)。設定領域が Provider Modules と Details の 2 つの領域に分割されます。プロバイダーモジュールは、設定の基本単位です。セキュリティードメインには複数のプロバイダーモジュールを含めることができ、各ログインモジュールには属性とオプションを含めることができます。プロバイダーモジュールを追加します。
Add ボタンをクリックしてプロアクティブモジュールを追加します。Code セクションに、プロバイダーモジュールのクラス名を入力します。モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code を変更できます。Attributes タブが選択されていることを確認します。モジュールの挙動を確認します。
監査モジュールの目的は、セキュリティーサブシステムのイベントを監視する方法を提供することです。ログファイルの記述、メールによる通知、またはその他の監査メカニズムによって監視を行うことが可能です。たとえば、JBoss Enterprise Application Server にはデフォルトでLogAuditProvider
モジュールが含まれています。この監査モジュールを前述の手順に従って有効にすると、EAP_HOME
ディレクトリ内のlog
サブフォルダーにあるaudit.log
ファイルにセキュリティー通知を書き込みます。前述の手順がLogAuditProvider
のコンテキスト内で動作するか確認するには、通知が発生するようなアクションを実行した後、監査ログファイルをチェックします。含まれるセキュリティー監査プロバイダーモジュールの完全一覧は 「含まれるセキュリティー監査プロバイダーモジュール」 を参照してください。モジュールオプションを追加、編集、または削除します (任意)。
モジュールにオプションを追加する必要がある場合は、Modules リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add ボタンをクリックし、オプションのキーと値を提供します。すでに存在するオプションを編集するには、Remove ラベルをクリックして削除するか、Add ボタンをクリックして正しいオプションで再び追加します。
セキュリティー監査モジュールは、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。
6.9. セキュリティーマッピングについて
6.10. セキュリティードメインでのセキュリティーマッピングの設定
手順6.4 セキュリティードメインでのセキュリティーマッピングの設定
セキュリティードメインの詳細ビューを開きます。
管理コンソールの右上にある Profiles ラベルをクリックします。スタンドアロンサーバーでは、タブに Profile ラベルがあります。管理対象ドメインでは、Profile ビューの左上にある Profile 選択ボックスから変更するプロファイルを選択します。左側の Security メニュー項目をクリックし、展開されたメニューで Security Domains をクリックします。編集するセキュリティードメインの View リンクをクリックします。マッピングサブシステム設定に移動します。
ビューの最上部の Mapping ラベルをクリックします (まだ設定されていない場合)。設定領域が Modules と Details の 2 つの領域に分割されます。マッピングモジュールは、設定の基本単位です。セキュリティードメインには複数のマッピングモジュールを含めることができ、各ログインモジュールには複数の属性とオプションを含めることができます。モジュールを追加します。
Add ボタンをクリックしてセキュリティーマッピングモジュールを追加します。モジュールの詳細を記入します。Code がモジュールのクラス名です。Type フィールドは、このモジュールが実行するマッピングのタイプを示します。許可される値は principal、role、attribute、または credential です。モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code または Type を変更できます。Attributes タブが選択されていることを確認します。モジュールオプションを追加、編集、または削除します (任意)。
モジュールにオプションを追加する必要がある場合は、Modules リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add ボタンをクリックし、オプションのキーと値を提供します。すでに存在するオプションを編集するには、Remove ラベルキーをクリックして削除するか、新しい値で再び追加します。Remove ボタンを使用してオプションを削除します。
セキュリティーマッピングモジュールは、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。
第7章 SSL 暗号化
7.1. SSL 暗号化について
7.2. JBoss Enterprise Application Platform Web Server での SSL 暗号化の実装
多くの Web アプリケーションでは、クライアントとサーバー間で SSL 暗号化接続 (HTTPS
接続とも呼ばれます) が必要です。以下の手順を使用すると、サーバーまたはサーバーグループで HTTPS
を有効にできます。
要件
- SSL 暗号化キーセットと SSL 暗号化証明書が必要です。これらは、証明書署名認証局から購入したり、コマンドラインユーティリティーを使用して生成したりできます。Red Hat Enterprise Linux ユーティリティーを使用して暗号化キーを生成するには、「SSL 暗号化キーおよび証明書の生成」を参照してください。
- 特定の環境とセットアップについて以下の詳細を知る必要があります。
- 証明書ファイルに対する完全ディレクトリー名およびパス。
- 暗号化キーの暗号化パスワード。
- 管理 CLI を実行し、ドメインコントローラまたはスタンドアロンサーバーに接続する必要があります。
注記
/profile=default
を削除して管理 CLI コマンドを変更します。
手順7.1 JBoss Web Server が HTTPS を使用するよう設定
新しい HTTPS コネクターを追加します。
プロファイルを適切に変更し、以下の管理 CLI コマンドを実行します。これにより、HTTPS
という名前のセキュアコネクターが新規作成されます。これはhttps
スキーム、https
ソケットバインディング (デフォルト値は8443
) を使用し、セキュアに設定されます。例7.1 管理 CLI コマンド
/profile=default/subsystem=web/connector=HTTPS/:add(socket-binding=https,scheme=https,protocol=HTTP/1.1,secure=true)
SSL 暗号化証明書およびキーを設定します。
例の値を独自の値に置き換え、以下の CLI コマンドを実行して SSL 証明書を設定します。この例では、キーストアはサーバー設定ディレクトリ (管理対象ドメインではEAP_HOME/domain/configuration/
) へコピーされることを想定しています。例7.2 管理 CLI コマンド
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration:add(name=https,certificate-key-file=${jboss.server.config.dir}/keystore.jks,password=SECRET, key-alias=KEY_ALIAS)
コネクターの SSL プロパティーに設定できるパラメーターの完全な一覧については、「SSL コネクターリファレンス」を参照してください。アプリケーションをデプロイします。
設定したプロファイルを使用するサーバーグループにアプリケーションをデプロイします。スタンドアロンサーバーを使用する場合、アプリケーションをサーバーにデプロイします。アプリケーションに対する HTTP 要求は新しい SSL 暗号化接続を使用します。
7.3. SSL 暗号化キーおよび証明書の生成
要件
- Java Development Kit 実装で提供される
keytool
ユーティリティーが必要です。このコマンドは、Red Hat Enterprise Linux 上の OpenJDK により/usr/bin/keytool
にインストールされます。 keytool
コマンドの構文およびパラメーターについて理解してください。この手順では、非常に一般的な手順を実行します。本書では、SSL 証明書またはkeytool
コマンドの固有な説明は範囲外です。
手順7.2 SSL 暗号化キーおよび証明書の生成
パブリックキーおよびプライベートキーとともにキーストアを生成します。
以下のコマンドを実行し、jboss
というエイリアスを持つserver.keystore
という名前のキーストアをカレントディレクトリに生成します。keytool -genkey -alias jboss -keyalg RSA -keystore server.keystore -storepass mykeystorepass --dname "CN=jsmith,OU=Engineering,O=mycompany.com,L=Raleigh,S=NC,C=US"
この keytool コマンドで使用されるパラメーターの説明は次のとおりです。パラメーター 説明 -genkey
keytool
コマンドは公開鍵と秘密鍵が含まれるキーペアを生成します。-alias
キーストアのエイリアス。この値は任意ですが、エイリアス jboss
はデフォルトで JBoss Web サーバーによって使用されます。-keyalg
キーペア生成のアルゴリズム。この例では RSA
になります。-keystore
キーストアファイルの名前と場所。デフォルトの場所はカレントディレクトリです。選択する名前は任意です。この例では、ファイルの名前は server.keystore
になります。-storepass
このパスワードは、キーの読み取りを可能にするためキーストアに対して認証を行うために使用されます。パスワードは 6 文字以上である必要があり、キーストアがアクセスされた時に提供しなければなりません。この例では、 mykeystorepass
が使用されています。このパラメーターを省略すると、コマンドの実行時に入力するよう要求されます。-keypass
実際の鍵のパスワードです。注記
実装の制限により、ストアと同じパスワードを使用する必要があります。--dname
キーの識別名を記述する引用符で囲まれた文字列 (例: "CN=jsmith,OU=Engineering,O=mycompany.com,L=Raleigh,C=US")。以下のコンポーネントが連結された文字列になります。 CN
- 共通名またはホスト名。ホスト名が jsmith.mycompany.com の場合、CN
は jsmith になります。OU
- 組織単位 (例: Engineering)。O
- 組織名 (例: mycompany.com)。L
- 地域 (例: Raleigh または London)。S
- 州 (例: NC)。このパラメーターの使用は任意です。C
- 2 文字の国コード (例: US または UK)。
上記のコマンドを実行すると、次の情報が要求されます。- コマンドラインで
-storepass
パラメーターを使用しなかった場合、キーストアのパスワードを入力するよう要求されます。次に要求されたら新しいパスワードを再入力します。 - コマンドラインで
-keypass
パラメーターを使用しなかった場合、キーのパスワードを入力するよう要求されます。Enter を押し、キーストアのパスワードと同じ値を設定します。
コマンドが終了すると、ファイルserver.keystore
にエイリアスjboss
を持つ単一のキーが含まれるようになります。キーを検証します。
以下のコマンドを使用して、キーが正常に動作することを検証します。keytool -list -keystore server.keystore
キーストアのパスワードを入力するよう求められます。キーストアの内容 (この場合はjboss
という名前の単一キー) が表示されます。jboss
キーの種類がkeyEntry
であることに注意してください。これは、キーストアにこのキーのパブリックおよびプライベートエントリが含まれることを示します。証明書署名要求を生成します。
次のコマンドを実行し、手順 1 で作成したキーストアより公開鍵を使用して証明書署名要求を生成します。keytool -certreq -keyalg RSA -alias jboss -keystore server.keystore -file certreq.csr
キーストアに対する認証を行うために、パスワードを入力するよう求められます。keytool
コマンドにより、現在の作業ディレクトリにcertreq.csr
という名前の証明書署名要求が新規作成されます。新しく生成された証明書署名要求をテストします。
以下のコマンドを使用して証明書の内容をテストします。openssl req -in certreq.csr -noout -text
証明書の詳細が表示されます。オプション: 証明書署名要求を認証局 (CA) に送信します。
認証局 (CA) は、証明書を認証できます。この結果、証明書は、サードパーティークライアントが信用できると見なされます。CA により、署名済み証明書が提供されます。また、オプションで 1 つまたは複数の中間証明書が提供されます。オプション: キーストアからの自己署名証明書のエクスポート
テストまたは内部使用のためにのみ証明書が必要な場合は、自己署名証明書を使用できます。次のように、手順 1 で作成したキーストアからエクスポートします。keytool -export -alias jboss -keystore server.keystore -file server.crt
キーストアに対して認証するためパスワードの入力が求められます。server.crt
という名前の自己署名証明書が現在の作業ディレクトリに作成されます。署名済み証明書を中間証明書とともにインポートします。
CA で指示された順序で各証明書をインポートします。各証明書をインポートするには、intermediate.ca
またはserver.crt
を実際のファイル名に置き換えます。証明書が別のファイルとして提供されない場合は、各証明書に対して個別のファイルを作成し、その内容をファイルに貼り付けます。注記
署名済み証明書および証明書キーは機密情報です。サーバー間での転送方法に注意してください。keytool -import -keystore server.keystore -alias intermediateCA -file intermediate.ca
keytool -import -alias jboss -keystore server.keystore -file server.crt
証明書が正常にインポートされたことをテストします。
以下のコマンドを実行し、要求された場合にキーストアパスワードを入力します。キーストアの内容が表示され、証明書がリストの一部になります。keytool -list -keystore server.keystore
署名済み証明書はキーストアに含まれ、HTTPS Web サーバー通信を含む SSL 接続を暗号化するために使用できます。
7.4. SSL コネクターリファレンス
default
を使用した管理対象ドメイン向けに設計されています。プロファイル名を、管理対象ドメインに対して設定する名前に変更するか、コマンドの /profile=default
部分を省略します (スタンドアロンサーバーの場合)。
表7.1 SSL コネクター属性
属性 | 説明 | CLI コマンド |
---|---|---|
name |
SSL コネクターの表示名。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=name,value=https) |
verify-client |
接続を受け入れる前にクライアントから有効な証明書チェーンが必要な場合は、
true に設定します。SSL スタックでクライアント証明書を要求し、クライアント証明書が提示されない場合でもエラーが発生しないようにするには、want に設定します。CLIENT-CERT 認証を使用するセキュリティー制約によって保護されたリソースをクライアントが要求する場合を除き、証明書チェーンを必要としないときは false (デフォルト値) に設定します。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=verify-client,value=want) |
verify-depth |
クライアントが有効な証明を持たないと判断するまでにチェックされる中間証明書発行者の最大数。デフォルト値は
10 です。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=verify-depth,value=10) |
certificate-key-file |
署名済みサーバー証明書が格納されるキーストアの完全ファイルパスおよびファイル名。JSSE 暗号化の場合、この証明書ファイルが唯一のファイルになり、OpenSSL は複数のファイルを使用します。デフォルト値は JBoss Enterprise Application Platform を実行しているユーザーのホームディレクトリー内にある
.keystore ファイルになります。keystoreType がファイルを使用しない場合は、パラメーターを空の文字列に設定します。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=certificate-key-file,value=../domain/configuration/server.keystore) |
certificate-file |
OpenSSL 暗号化を使用する場合は、このパラメーターの値を、サーバー証明書を含むファイルに対するパスに設定します。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=certificate-file,value=server.crt) |
password |
トラストストアおよびキーストアに対するパスワード。デフォルト値は
changeit であるため、設定が動作するためにはキーストアのパスワードに一致するようこの値を変更する必要があります。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=password,value=changeit) |
protocol |
使用する SSL プロトコルのバージョン。サポートされる値には、
SLv2 、SSLv3 、TLSv1 、SSLv2+SSLv3 、および ALL があります。デフォルト値は ALL です。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=protocol,value=ALL) |
cipher-suite |
許可される暗号のカンマ区切りのリスト。JSSE の JVM デフォルト値には、使用すべきでない強度が低い暗号が含まれます。例では可能な暗号が 2 つのみですが、実際ではそれ以上の暗号を使用することになります。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=cipher-suite, value="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA") |
key-alias |
キーストア内のサーバー証明書に使用されるエイリアス。デフォルト値は
jboss です。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=key-alias,value=jboss) |
truststore-type |
トラストストアのタイプ。
PKCS12 や Java の標準 JKS など、さまざまなタイプのキーストアが使用可能です。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=truststore-type,value=jks) |
keystore-type |
キーストアのタイプ。
PKCS12 や Java の標準 JKS など、さまざまなタイプのキーストアが使用可能です。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=keystore-type,value=jks) |
ca-certificate-file |
CA 証明書が含まれるファイル。JSSE の場合、これは
truststoreFile であり、キーストアと同じパスワードを使用します。クライアント証明書を検証するには、ca-certificate-file ファイルが使用されます。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=certificate-file,value=ca.crt) |
ca-certificate-password | ca-certificate-file の証明書パスワード。下記の例では、パスワードを独自のマスクされたパスワードに置き換えます。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=ca-certificate-password,value=MASKED_PASSWORD) |
ca-revocation-url |
呼び出しリストが含まれるファイルまたは URL。JSSE の場合は、
crlFile を参照し、SSL の場合は、SSLCARevocationFile を参照します。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=ca-revocation-url,value=ca.crl) |
session-cache-size |
SSLSession キャッシュのサイズ。デフォルト値は
0 であり、セッションキャッシュを無効にします。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=session-cache-size,value=100) |
session-timeout |
キャッシュされた SSLSession の有効期限が切れるまでの秒数。デフォルト値は
86400 秒 (24 時間) です。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=session-timeout,value=43200) |
第8章 セキュリティレルム
8.1. セキュリティーレルムについて
ManagementRealm
は、管理 CLI や Web ベースの管理コンソールに機能を提供する管理 API のユーザーやパスワード、ロール情報を保存します。JBoss Enterprise Application Platform を管理するため認証システムを提供します。管理 API に使用する同じビジネスルールでアプリケーションを認証する必要がある場合にManagementRealm
を使用することもできます。ApplicationRealm
は Web アプリケーションと EJB のユーザーやパスワード、ロール情報を保存します。
REALM-users.properties
はユーザー名とハッシュ化されたパスワードを保存します。REALM-users.properties
はユーザーからロールへのマッピングを保存します。
domain/configuration/
および standalone/configuration/
ディレクトリに保存されます。ファイルは add-user.sh
や add-user.bat
コマンドによって同時に書き込まれます。コマンドを実行する時、新しいユーザーをどのレルムに追加するか最初に決定します。
8.2. 新しいセキュリティーレルムの追加
Management CLI を実行します。
jboss-cli.sh
またはjboss-cli.bat
コマンドを開始し、サーバーに接続します。セキュリティーレルムを新規作成します。
次のコマンドを実行し、ドメインコントローラーまたはスタンドアロンサーバー上でMyDomainRealm
という名前の新しいセキュリティーレルムを作成します。/host=master/core-service=management/security-realm=MyDomainRealm:add()
新しいロールの情報を保存するプロパティーファイルへの参照を作成します。
次のコマンドを実行し、新しいロールに関連するプロパティーが含まれるmyfile.properties
という名前のファイルのポインターを作成します。注記
新規作成されたプロパティーファイルは、含まれるadd-user.sh
およびadd-user.bat
スクリプトによって管理されません。そのため、外部から管理する必要があります。/host=master/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
セキュリティーレルムが新規作成されます。この新規作成されたレルムにユーザーやロールを追加すると、デフォルトのセキュリティーレルムとは別のファイルに情報が保存されます。新規ファイルはご使用のアプリケーションやプロシージャーを使用して管理できます。
8.3. セキュリティーレルムへユーザーを追加
add-user.sh
またはadd-user.bat
コマンドを実行します。コマンドラインインターフェース (CLI) を開きます。EAP_HOME/bin/
ディレクトリへ移動します。Red Hat Enterprise Linux や他の UNIX 系のオペレーティングシステムを稼働している場合はadd-user.sh
を実行します。Microsoft Windows Server を稼働している場合はadd-user.bat
を実行します。管理ユーザーかアプリケーションユーザーのどちらを追加するか選択します。
この手順ではb
を入力し、アプリケーションユーザーを追加します。ユーザーが追加されるレルムを選択します。
デフォルトでは、ApplicationRealm
のみが選択可能です。カスタムレルムが追加されている場合はその名前を入力します。入力を促されたらユーザー名、パスワード、ロールを入力します。
入力を促されたら希望のユーザー名、パスワード、任意のロールを入力します。yes
を入力して選択を確認するか、no
を入力して変更をキャンセルします。変更はセキュリティーレルムの各プロパティーファイルに書き込まれます。
第9章 サブシステムの設定
9.1. トランザクションサブシステムの設定
9.1.1. JTS トランザクション用 ORB の設定
注記
full
および full-ha
プロファイルでのみ利用可能です。スタンドアロンサーバーでは、standalone-full.xml
または standalone-full-ha.xml
設定で利用可能です。
手順9.1 管理コンソールを使用した ORB の設定
プロファイル設定を表示します。
管理コンソールの右上から Profiles (管理対象ドメイン) または Profile (スタンドアロンサーバー) を選択します。管理対象ドメインを使用する場合は、左上にある選択ボックスから full または full-ha プロファイルを選択します。Initializers 設定の変更
必要な場合は、左側にある Subsystems メニューを展開します。Container サブメニューを展開し、JacORB をクリックします。メイン画面に表示されるフォームで、Initializers タブを選択し、Edit ボタンをクリックします。Security の値をon
に設定して、セキュリティーインターセプターを有効にします。JTS 用 ORB を有効にするには、Transaction Interceptors 値をデフォルトのspec
ではなくon
に設定します。これらの値に関する詳細な説明については、フォームの Need Help? リンクを参照してください。値の編集が完了したら、Save をクリックします。高度な ORB 設定
高度な設定オプションについては、フォームの他のセクションを参照してください。各セクションには、パラメーターに関する詳細な情報とともに Need Help? リンクが含まれます。
管理 CLI を使用して ORB の各側面を設定できます。以下のコマンドは、管理コンソールに対するイニシャライザーに上記の手順と同じ値を設定します。これは、JTS と使用する ORB の最小設定です。
/profile=full
部分を省略します。
例9.1 セキュリティーインターセプターの有効化
/profile=full/subsystem=jacorb/:write-attribute(name=security,value=on)
例9.2 JTS 用 ORB の有効化
/profile=full/subsystem=jacorb/:write-attribute(name=transactions,value=on)
9.2. JMS の設定
9.2.1. HornetQ 設定属性のリファレンス
read-resource
操作で設定可能または表示可能な属性を公開できます。
例9.3 例
[standalone@localhost:9999 /] /subsystem=messaging/hornetq-server=default:read-resource
表9.1 HornetQ 属性
属性 | サンプル値 | タイプ |
---|---|---|
allow-failback | true | BOOLEAN |
async-connection-execution-enabled | true | BOOLEAN |
backup | false | BOOLEAN |
cluster-password | somethingsecure | STRING |
cluster-user | HORNETQ.CLUSTER.ADMIN.USER | STRING |
clustered | false | BOOLEAN |
connection-ttl-override | -1 | LONG |
create-bindings-dir | true | BOOLEAN |
create-journal-dir | true | BOOLEAN |
failback-delay | 5000 | LONG |
failover-on-shutdown | false | BOOLEAN |
id-cache-size | 2000 | INT |
jmx-domain | org.hornetq | STRING |
jmx-management-enabled | false | BOOLEAN |
journal-buffer-size | 100 | LONG |
journal-buffer-timeout | 100 | LONG |
journal-compact-min-files | 10 | INT |
journal-compact-percentage | 30 | INT |
journal-file-size | 102400 | LONG |
journal-max-io | 1 | INT |
journal-min-files | 2 | INT |
journal-sync-non-transactional | true | BOOLEAN |
journal-sync-transactional | true | BOOLEAN |
journal-type | ASYNCIO | STRING |
live-connector-ref | reference | STRING |
log-journal-write-rate | false | BOOLEAN |
management-address | jms.queue.hornetq.management | STRING |
management-notification-address | hornetq.notifications | STRING |
memory-measure-interval | -1 | LONG |
memory-warning-threshold | 25 | INT |
message-counter-enabled | false | BOOLEAN |
message-counter-max-day-history | 10 | INT |
message-counter-sample-period | 10000 | LONG |
message-expiry-scan-period | 30000 | LONG |
message-expiry-thread-priority | 3 | INT |
page-max-concurrent-io | 5 | INT |
perf-blast-pages | -1 | INT |
persist-delivery-count-before-delivery | false | BOOLEAN |
persist-id-cache | true | BOOLEAN |
persistence-enabled | true | BOOLEAN |
remoting-interceptors | 未定義 | LIST |
run-sync-speed-test | false | BOOLEAN |
scheduled-thread-pool-max-size | 5 | INT |
security-domain | other | STRING |
security-enabled | true | BOOLEAN |
security-invalidation-interval | 10000 | LONG |
server-dump-interval | -1 | LONG |
shared-store | true | BOOLEAN |
started | true | BOOLEAN |
thread-pool-max-size | 30 | INT |
transaction-timeout | 300000 | LONG |
transaction-timeout-scan-period | 1000 | LONG |
version | 2.2.16.Final (HQ_2_2_16_FINAL, 122) | STRING |
wild-card-routing-enabled | true | BOOLEAN |
警告
journal-file-size
の値がサーバーへ送信されたメッセージのサイズよりも大きくないと、サーバーはメッセージを格納できません。
第10章 Web、HTTP コネクター、および HTTP クラスタリング
10.1. mod_cluster ワーカーノードの設定
mod_cluster
サブシステムを介して 1 度だけ設定されます。mod_cluster
サブシステムを設定するには、『管理および設定ガイド』 の 『mod_cluster サブシステムの設定』 を参照してください。各ワーカーノードは別々に設定されるため、クラスターを追加する各ノードに対してこの手順を繰り返してください。
ワーカーノード設定
- スタンドアロンサーバーを使用する場合は、スタンドアロンサーバーを
standalone-ha
プロファイルで起動する必要があります。 - 管理対象ドメインを使用する場合、サーバーグループは
ha
またはfull-ha
プロファイルとha-sockets
またはfull-ha-sockets
ソケットバインディンググループを使用する必要があります。JBoss Enterprise Application Platform には、これらの要件を満たすother-server-group
という名前のクラスター対応サーバーグループが同梱されます。
注記
/profile=full-ha
部分を削除します。
手順10.1 ワーカーノードの設定
ネットワークインターフェースの設定
デフォルトでは、ネットワークインターフェースがすべて127.0.0.1
に設定されます。スタンドアロンサーバーまたはサーバーグループ内の 1 つまたは複数のサーバーをホストする各物理ホストでは、インターフェースが他のサーバーが見つけることができるパブリック IP アドレスを使用するよう設定する必要があります。JBoss Enterprise Application Platform ホストの IP アドレスを変更するには、ホストをシャットダウンし、設定ファイルを直接編集する必要があります。これは、管理コンソールと管理 CLI を駆動する管理 API は固定管理アドレスに依存するためです。クラスター内の各サーバーの IP アドレスをマスターのパブリック IP アドレスに変更するには、次の手順を実行します。- サーバーを完全にシャットダウンします。
EAP_HOME/domain/configuration/
内にある管理対象ドメイン用のhost.xml
またはEAP_HOME/standalone/configuration/
内にあるスタンドアロンサーバー用のstandalone-ha.xml
を編集します。<interfaces>
要素を見つけます。management
、public
、およびunsecured
の 3 つのインターフェースが設定されます。これらそれぞれに対して、値127.0.0.1
をホストの外部 IP アドレスに変更します。- 管理対象ドメインに参加し、マスターでないホストの場合は、
<host
要素を見つけます。この要素には>
閉じ記号がないことに注意してください。これはこの要素が属性を含むためです。名前属性の値をmaster
から一意の名前 (スレーブごとに異なる名前) 変更します。この名前は、スレーブがクラスター対して身元を示すためにも使用されるため、注意してください。 - 管理対象ドメインを参加する必要がある新しく設定されたホストの場合は、
<domain-controller>
要素を見つけます。<local />
要素をコメントアウトまたは削除し、次の行を追加して、IP アドレス (X.X.X.X
) をドメインコントローラーのアドレスに変更します。この手順は、スタンドアロンサーバーには適用されません。<remote host="X.X.X.X" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm"/>
- ファイルを保存し、終了します。
各スレーブサーバーの認証を設定します。
各スレーブサーバーでは、ドメインコントローラーまたはスタンドアロンマスターのManagementRealm
で作成されたユーザー名とパスワードが必要です。ドメインコントローラーまたはスタンドアロンマスターで、EAP_HOME/add-user.sh
コマンドを実行します。同じユーザー名を持つユーザーをスレーブとしてManagementRealm
に追加します。このユーザーが外部 JBoss AS インスタンスに対して認証する必要があるかどうか尋ねられた場合は、yes
と回答します。パスワードchangeme
を使用した、slave1
という名前のスレーブに対するコマンドの入力および出力の例は以下のとおりです。user:bin user$ ./add-user.sh What type of user do you wish to add? a) Management User (mgmt-users.properties) b) Application User (application-users.properties) (a):
a
Enter the details of the new user to add. Realm (ManagementRealm) : Username :slave1
Password :changeme
Re-enter Password :changeme
About to add user 'slave1' for realm 'ManagementRealm' Is this correct yes/no?yes
Added user 'slave1' to file '/home/user/jboss-eap-6.0/standalone/configuration/mgmt-users.properties' Added user 'slave1' to file '/home/user/jboss-eap-6.0/domain/configuration/mgmt-users.properties' Is this new user going to be used for one AS process to connect to another AS process e.g. slave domain controller? yes/no? yes To represent the user add the following to the server-identities definition <secret value="Y2hhbmdlbWU=" />add-user.sh
の出力から Base64 でエンコードされた<secret>
要素をコピーします。認証に Base64 でエンコードされたパスワード値を指定したい場合、add-user.sh
の出力の最終行より<secret>
要素値をコピーします。次の手順でこの値が必要になります。新しい認証を使用するようスレーブホストのセキュリティーレルムを変更します。
- スレーブホストの
host.xml
またはstandalone-ha.xml
ファイルを再度開きます。 <security-realms>
要素を探します。ここにセキュリティーレルムを設定します。- 以下の方法の 1 つを用いて秘密の値を指定できます。
設定ファイルに Base64 でエンコードされたパスワード値を指定します。
- 以下の XML コードを
<security-realm name="ManagementRealm">
行のすぐ下に追加します。<server-identities> <secret value="Y2hhbmdlbWU="/> </server-identities>
- "Y2hhbmdlbWU=" を前の手順で
add-user.sh
の出力より返された秘密の値に置き換えます。
ホストを設定し、ボールトよりパスワードを取得します。
vault.sh
スクリプトを使用してマスクされたパスワードを生成します。次のような文字列が生成されます:VAULT::secret::password::ODVmYmJjNGMtZDU2ZC00YmNlLWE4ODMtZjQ1NWNmNDU4ZDc1TElORV9CUkVBS3ZhdWx0
。ボールトに関する詳細は、「機密性の高い文字列のパスワード vault」の項にある 「クリアテキストファイルでの機密性が高い文字列のセキュア化について」 を参照してください。- 以下の XML コードを
<security-realm name="ManagementRealm">
行のすぐ下に追加します。<server-identities> <secret value="${VAULT::secret::password::ODVmYmJjNGMtZDU2ZC00YmNlLWE4ODMtZjQ1NWNmNDU4ZDc1TElORV9CUkVBS3ZhdWx0}"/> </server-identities>
必ず秘密の値を前の手順で生成したマスクされたパスワードに置き換えるようにしてください。注記
ボールトでパスワードを作成する場合、Base64 エンコードではなくプレーンテキストで指定する必要があります。
システムプロパティーとしてパスワードを指定します。
- 以下の XML コードを
<security-realm name="ManagementRealm">
行のすぐ下に追加します。<server-identities> <secret value=${server.identity.password}/> </server-identities>
- システムプロパティーとしてパスワードを指定する場合、次の方法のいずれかを用いてホストを設定できます。
- 次の例のように、プレーンテキストのパスワードをコマンドライン引数として入力し、サーバーを起動します。
-Dserver.identity.password=changeme
注記
パスワードはプレーンテキストで入力する必要があります。ps -ef
コマンドを実行するユーザーはこのパスワードを見ることができます。 - パスワードをプロパティーファイルに格納し、プロパティーファイルの URL をコマンドライン引数として渡します。
- キーと値のペアをプロパティーファイルに追加します。例は次の通りです。
server.identity.password=changeme
- コマンドライン引数を用いてサーバーを起動します。
--properties=URL_TO_PROPERTIES_FILE
.
- ファイルを保存し、終了します。
サーバーを再起動します。
ホスト名をユーザー名として使用し、暗号化された文字列をパスワードとして使用してスレーブがマスターに対して認証されます。
第11章 ネットワークセキュリティー
11.1. 管理インターフェースのセキュア化
テスト環境では、管理コンソール、管理 CLI および他の API 実装で構成される管理インターフェース上で、セキュリティーレイヤーがない状態で JBoss Enterprise Application Platform 6 を実行することがよくあります。これにより、開発や設定を迅速に変更できます。
11.2. JBoss Enterprise Application Platform が使用するネットワークインターフェースの指定
サービスを必要なクライアントにのみアクセスできるようサービスを隔離すると、ネットワークのセキュリティーが強化されます。JBoss Enterprise Application Platform には、デフォルト設定の 2 つのインターフェースが含まれ、どちらもデフォルトで IP アドレス 127.0.0.1
または localhost
にバインドされます。インターフェースの 1 つは management
と呼ばれ、管理コンソール、CLI、および API によって使用されます。他のインターフェースは public
と呼ばれ、アプリケーションをデプロイするために使用されます。これらのインターフェースは、特別なものではありませんが、作業を始める土台として提供されます。
management
インターフェースはデフォルトでポート 9990 と 9999 を使用し、public
インターフェースはポート 8080 または 8443 (HTTPS を使用する場合) を使用します。
警告
JBoss Enterprise Application Platform を停止します。
オペレーティングシステムに適切な方法で割り込みを送信して JBoss Enterprise Application Platform を停止します。JBoss Enterprise Application Platform をフォアグラウンドアプリケーションとして実行している場合、通常は Ctrl+C を押してこれを行います。バインドアドレスを指定して JBoss Enterprise Application Platform を再起動します。
-b
コマンドラインスイッチを使用して特定のインターフェースで JBoss Enterprise Application Platform を起動します。例11.1 パブリックインターフェースを指定します。
EAP_HOME/bin/domain.sh -b 10.1.1.1
例11.2 管理インターフェースを指定します。
EAP_HOME/bin/domain.sh -bmanagement=10.1.1.1
例11.3 各インターフェースに異なるアドレスを指定します。
EAP_HOME/bin/domain.sh -bmanagement=127.0.0.1 -b 10.1.1.1
例11.4 すべてのネットワークインターフェースにパブリックインターフェースをバインドします。
EAP_HOME/bin/domain.sh -b 0.0.0.0
-b
コマンドラインスイッチを使用してランタイム時に IP アドレスを指定できなくなるため、お勧めしません。この作業を行う場合は、XML ファイルを編集する前に JBoss Enterprise Application Platform を完全に停止する必要があります。
11.3. JBoss Enterprise Application Platform 6 で動作するようネットワークファイアウォールを設定
ほとんどの本番稼動環境では、ネットワークセキュリティー全体の方針の一部としてファイアウォールを使用します。複数のインスタンスが相互に通信したり、Web サーバーやデータベースなどの外部サービスと通信したりする必要がある場合は、ファイアウォールでこれを考慮する必要があります。適切に管理されたファイアウォールでは、操作する必要があるポートのみが開かれ、特定の IP アドレス、サブネット、およびネットワークプロトコルに対するポートへのアクセスが制限されます。
要件
- 開く必要があるポートを決定します。それぞれの環境のポートのリストを決定するには、「JBoss Enterprise Application Platform 6 により使用されるネットワークポート」を参照してください。
- ファイアウォールソフトウェアについて理解する必要があります。この手順では、Red Hat Enterprise Linux 6 の
system-config-firewall
コマンドを使用します。Microsoft Windows Server には、ファイアウォールが組み込まれ、各プラットフォーム用の複数のサードパーティー製ファイアウォールソリューションが利用可能です。
この手順では、以下の前提で環境のファイアウォールを設定します。
- オペレーティングシステムは Red Hat Enterprise Linux 6 です。
- JBoss Enterprise Application Platform 6 がホスト
10.1.1.2
で実行されます。オプションで、サーバーには独自のファイアウォールがあります。 - ネットワークファイアウォールサーバーは、ホスト
10.1.1.1
のインターフェースeth0
で実行され、外部インターフェースeth1
を持ちます。 - ポート 5445 (JMS で使用されるポート) のトラフィックを JBoss Enterprise Application Platform 6 に転送します。ネットワークファイアウォールで他のトラフィックは許可されません。
手順11.1 ネットワークファイアウォールと JBoss Enterprise Application Platform 6 が共に動作するよう管理
管理コンソールにログインします。
管理コンソールにログインします。デフォルトでは、http://localhost:9990/console/ で実行されます。ソケットバインディンググループが使用するソケットバインディングを決定します。
管理コンソールの右上にある Profiles ラベルをクリックします。画面の左側に一連のメニューが表示されます。下部のメニュー見出しは General Configuration です。この見出しの下の Socket Binding Groups 項目をクリックします。Socket Binding Declarations 画面が表示されます。最初に、standard-sockets
グループが表示されます。異なるグループは、右側のコンボボックスで選択することにより選択できます。注記
スタンドアロンサーバーを使用する場合は、1 つのソケットバインディンググループのみが存在します。ソケット名とポートのリストが表示されます (1 ページあたり 6 つの値)。テーブルの矢印ナビゲーションを使用してページを移動できます。開く必要があるポートを決定します。
お使いの環境の特別なポートの機能とニーズによっては、一部のポートがファイアウォールを介してアクセスできる必要があります。ソケットバインディングの目的がわからない場合は、「JBoss Enterprise Application Platform 6 により使用されるネットワークポート」を参照して、デフォルトのソケットバインディングとその目的のリストを確認してください。JBoss Enterprise Application Platform 6 にトラフィックを転送するようファイアウォールを設定します。
以下の手順を実行して、必要なポートでトラフィックを許可するようネットワークファイアウォールを設定します。- root ユーザーとしてファイアウォールマシンにログインし、コマンドプロンプトにアクセスします。
system-config-firewall
コマンドを実行してファイアウォール設定ユーティリティーを起動します。ファイアウォールシステムにログインした方法に応じて、GUI またはコマンドラインユーティリティーが起動します。このタスクでは、SSH 経由でコマンドラインインターフェースを使用してログインしていることを前提とします。- キーボードで TAB キーを使用して Customize ボタンに移動し、ENTER キーを押します。Trusted Services 画面が表示されます。
- どの値も変更せずに、TAB キーを使用して Forward ボタンに移動し、ENTER を押して次の画面に進みます。Other Ports 画面が表示されます。
- TAB キーを使用して <Add> ボタンに移動し、ENTER を押します。Port and Protocol 画面が表示されます。
- Port / Port Range フィールドに
5445
と入力し、TAB キーを使用して Protocol フィールドに移動し、tcp
と入力します。TAB キーを使用して OK ボタンに移動し、ENTER を押します。 - TAB キーを使用して、Forward ボタンに移動し、Port Forwarding 画面にアクセスします。
- TAB キーを使用して <Add> ボタンに移動し、ENTER キーを押します。
- 以下の値を入力してポート 5445 のポート転送を設定します。
- 送信元インターフェース: eth1
- プロトコル: tcp
- ポート/ポート範囲: 5445
- 送信先 IP アドレス: 10.1.1.2
- ポート/ポート範囲: 5445
TAB キーを使用して OK ボタンに移動し、ENTER を押します。 - TAB キーを使用して Close ボタンに移動し、ENTER を押します。
- TAB キーを使用して OK ボタンに移動し、ENTER を押します。変更内容を適用するには、警告を読み、Yes をクリックします。
JBoss Enterprise Application Platform 6 ホストでファイアウォールを設定します。
一部の組織では、JBoss Enterprise Application Platform 6 サーバー自体でファイアウォールを設定し、運用に必要ないすべてのポートを閉じます。「JBoss Enterprise Application Platform 6 により使用されるネットワークポート」 を参照して開くポートを決定し、残りのポートを閉じます。Red Hat Enterprise Linux 6 のデフォルトの設定では、22 (Secure Shell (SSH) 用) と 5353 (マルチキャスト DNS 用) 以外のすべてのポートが閉じられます。ポートを設定する場合は、間違ってロックアウトされないよう物理的にアクセスしてください。
ファイアウォールが、ファイアウォール設定で指定したように、内部 JBoss Enterprise Application Platform 6 サーバーにトラフィックを転送します。サーバーでファイアウォールを有効にした場合は、アプリケーションを実行するために必要なポート以外はすべて閉じられます。
11.4. JBoss Enterprise Application Platform 6 により使用されるネットワークポート
- サーバーグループがデフォルトのソケットバインディンググループのいずれかを使用するか、またはカスタムグループを使用するかどうか。
- 個別デプロイメントの要件。
注記
デフォルトのソケットバインディンググループ
full-ha-sockets
full-sockets
ha-sockets
standard-sockets
表11.1 デフォルトのソケットバインディングの参照
名前 | ポート | マルチキャストポート | 説明 | full-ha-sockets | full-sockets | ha-socket | standard-socket |
---|---|---|---|---|---|---|---|
ajp | 8009 | Apache JServ プロトコル。HTTP クラスタリングおよび負荷分散に使用します。 | ○ | ○ | ○ | ○ | |
http | 8080 | デプロイされた Web アプリケーションのデフォルトポート。 | ○ | ○ | ○ | ○ | |
https | 8443 | デプロイされた Web アプリケーションとクライアント間の SSL 暗号化接続。 | ○ | ○ | ○ | ○ | |
jacorb | 3528 | JTS トランザクションおよび他の ORB 依存サービス用の CORBA サービス。 | ○ | ○ | × | × | |
jacorb-ssl | 3529 | SSL 暗号化 CORBA サービス。 | ○ | ○ | × | × | |
jgroups-diagnostics | 7500 | マルチキャスト。HA クラスターでピア検出に使用されます。 | ○ | × | ○ | × | |
jgroups-mping | 45700 | マルチキャスト。HA クラスタでの初期メンバーシップを検出するために使用されます。 | ○ | × | ○ | × | |
jgroups-tcp | 7600 | TCP を使用した、HA クラスター内でのユニキャストピア検出。 | ○ | × | ○ | × | |
jgroups-tcp-fd | 57600 | TCP を介した HA 障害検出に使用されます。 | ○ | × | ○ | × | |
jgroups-udp | 55200 | 45688 | UDP を使用した、HA クラスター内でのユニキャストピア検出。 | ○ | × | ○ | × |
jgroups-udp-fd | 54200 | UDP を介した HA 障害検出に使用されます。 | ○ | × | ○ | × | |
messaging | 5445 | JMS サービス。 | ○ | ○ | × | × | |
messaging-group | HornetQ JMS ブロードキャストと検出グループにより参照されます。 | ○ | ○ | × | × | ||
messaging-throughput | 5455 | JMS Remoting により使用されます。 | ○ | ○ | × | × | |
mod_cluster | 23364 | JBoss Enterprise Application Platform と HTTP ロードバランサー間の通信に対するマルチキャストポート。 | ○ | × | ○ | × | |
osgi-http | 8090 | OSGi サブシステムを使用する内部コンポーネントにより使用されます。 | ○ | ○ | ○ | ○ | |
remoting | 4447 | リモート EJB の呼び出しに使用されます。 | ○ | ○ | ○ | ○ | |
txn-recovery-environment | 4712 | JTA トランザクションリカバリーマネージャー。 | ○ | ○ | ○ | ○ | |
txn-status-manager | 4713 | JTA / JTS トランザクションマネージャー。 | ○ | ○ | ○ | ○ |
ソケットバインディンググループ以外に、各ホストコントローラーは管理用にさらに 2 つのポートを開きます。
- 9990 - Web 管理コンソールポート
- 9999 - 管理コンソールと管理 API により使用されるポート
パート III. アプリケーションのセキュア化
第12章 アプリケーションのセキュリティー
12.1. 記述子ベースのプロパティー置換の有効化/無効化
警告
12.2. データソースセキュリティー
12.2.1. データソースセキュリティーについて
- セキュリティードメイン: 「セキュリティードメインについて」
- パスワード vault: 「クリアテキストファイルでの機密性が高い文字列のセキュア化について」
例12.1 セキュリティードメインの例
<security> <security-domain>mySecurityDomain</security-domain> </security>
例12.2 パスワード vault の例
<security> <user-name>admin</user-name> <password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password> </security>
12.3. EJB アプリケーションセキュリティー
12.3.1. セキュリティアイデンティティ (ID)
12.3.1.1. EJB のセキュリティーアイデンティティーについて
<security-identity>
タグのことです。これは、EJB がコンポーネントでメソッド呼び出しを行う際に必ず使う必要のあるアイデンティティーを指します。
<use-caller-identity>
タグがあり、特定ロールの場合は <run-as>
タグが使用されます。
12.3.1.2. EJB のセキュリティーアイデンティティーの設定
例12.3 呼び出し側と同じになるように EJB のセキュリティーアイデンティティーを設定する
<security-identity>
要素の宣言を指定しない場合、この挙動がデフォルトになります。
<ejb-jar> <enterprise-beans> <session> <ejb-name>ASessionBean</ejb-name> <!-- ... --> <security-identity> <use-caller-identity/> </security-identity> </session> <!-- ... --> </enterprise-beans> </ejb-jar>
例12.4 特定ロールに EJB のセキュリティーアイデンティティーを設定する
<security-identity>
タグの中に <run-as>
または <role>
タグを使用します。
<ejb-jar> <enterprise-beans> <session> <ejb-name>RunAsBean</ejb-name> <!-- ... --> <security-identity> <run-as> <description>A private internal role</description> <role-name>InternalRole</role-name> </run-as> </security-identity> </session> </enterprise-beans> <!-- ... --> </ejb-jar>
<run-as>
を使用すると anonymous
という名前のプリンシパルが発信呼び出しへ割り当てられます。違うプリンシパルを割り当てる場合は <run-as-principle>
を使用します。
<session> <ejb-name>RunAsBean</ejb-name> <security-identity> <run-as-principal>internal</run-as-principal> </security-identity> </session>
注記
<run-as>
要素と <run-as-principal>
要素を使用することもできます。
以下も参照してください。
12.3.2. EJB メソッドのパーミッション
12.3.2.1. EJB メソッドパーミッションについて
<method-permisison>
要素の宣言を提供します。この宣言により、EJB のインターフェースメソッドを呼び出し可能なロールを設定します。以下の組み合わせに対してパーミッションの指定が可能です。
- 名前付き EJB のホームおよびコンポーネントインターフェースメソッド
- 名前付き EJB のホームあるいはコンポーネントインターフェースの指定メソッド
- オーバーロードした名前を持つメソッドセット内の指定メソッド
12.3.2.2. EJB メソッドパーミッションの使用
<method-permission>
要素は、<method>
要素によって定義される EJB メソッドへアクセスできる論理ロールを定義します。XML の構文を表す例は複数あります。メソッドパーミッションステートメントは複数存在することがあり、累積的な影響があります。<method-permission>
要素は <ejb-jar>
記述子の <assembly-descriptor>
要素の子要素です。
例12.5 ロールが EJB の全メソッドへのアクセスできるようにする
<method-permission> <description>The employee and temp-employee roles may access any method of the EmployeeService bean </description> <role-name>employee</role-name> <role-name>temp-employee</role-name> <method> <ejb-name>EmployeeService</ejb-name> <method-name>*</method-name> </method> </method-permission>
例12.6 EJB の特定メソッドへのみロールがアクセスできるようにし、パラメーターが渡すことができるメソッドを制限します。
<method-permission> <description>The employee role may access the findByPrimaryKey, getEmployeeInfo, and the updateEmployeeInfo(String) method of the AcmekPayroll bean </description> <role-name>employee</role-name> <method> <ejb-name>AcmekPayroll</ejb-name> <method-name>findByPrimaryKey</method-name> </method> <method> <ejb-name>AcmePayroll</ejb-name> <method-name>getEmployeeInfo</method-name> </method> <method> <ejb-name>AcmePayroll</ejb-name> <method-name>updateEmployeeInfo</method-name> <method-params> <method-param>java.lang.String</method-param> </method-params> </method> </method-permission>
例12.7 認証された全ユーザーが EJB のメソッドにアクセスできるようにする
<unchecked/>
要素を使用すると、認証された全ユーザーが指定のメソッドを使用できます。
<method-permission> <description>Any authenticated user may access any method of the EmployeeServiceHelp bean</description> <unchecked/> <method> <ejb-name>EmployeeServiceHelp</ejb-name> <method-name>*</method-name> </method> </method-permission>
例12.8 特定の EJB メソッドを完全に除外して使用されないようにする
<exclude-list> <description>No fireTheCTO methods of the EmployeeFiring bean may be used in this deployment</description> <method> <ejb-name>EmployeeFiring</ejb-name> <method-name>fireTheCTO</method-name> </method> </exclude-list>
例12.9 複数の <method-permission>
ブロックが含まれる完全な <assembly-descriptor>
<ejb-jar> <assembly-descriptor> <method-permission> <description>The employee and temp-employee roles may access any method of the EmployeeService bean </description> <role-name>employee</role-name> <role-name>temp-employee</role-name> <method> <ejb-name>EmployeeService</ejb-name> <method-name>*</method-name> </method> </method-permission> <method-permission> <description>The employee role may access the findByPrimaryKey, getEmployeeInfo, and the updateEmployeeInfo(String) method of the AcmePayroll bean </description> <role-name>employee</role-name> <method> <ejb-name>AcmePayroll</ejb-name> <method-name>findByPrimaryKey</method-name> </method> <method> <ejb-name>AcmePayroll</ejb-name> <method-name>getEmployeeInfo</method-name> </method> <method> <ejb-name>AcmePayroll</ejb-name> <method-name>updateEmployeeInfo</method-name> <method-params> <method-param>java.lang.String</method-param> </method-params> </method> </method-permission> <method-permission> <description>The admin role may access any method of the EmployeeServiceAdmin bean </description> <role-name>admin</role-name> <method> <ejb-name>EmployeeServiceAdmin</ejb-name> <method-name>*</method-name> </method> </method-permission> <method-permission> <description>Any authenticated user may access any method of the EmployeeServiceHelp bean</description> <unchecked/> <method> <ejb-name>EmployeeServiceHelp</ejb-name> <method-name>*</method-name> </method> </method-permission> <exclude-list> <description>No fireTheCTO methods of the EmployeeFiring bean may be used in this deployment</description> <method> <ejb-name>EmployeeFiring</ejb-name> <method-name>fireTheCTO</method-name> </method> </exclude-list> </assembly-descriptor> </ejb-jar>
12.3.3. EJB セキュリティアノテーション
12.3.3.1. EJB セキュリティーアノテーションについて
- @DeclareRoles
- どのロールが利用可能か宣言します。
- @SecurityDomain
- EJB に使用するセキュリティードメインを指定します。承認のため、EJB に
@RolesAllowed
アノテーションが付いている場合、EJB にセキュリティードメインがアノテーション付けされている場合のみ承認を適用します。 - @RolesAllowed、@PermitAll、@DenyAll
- どのメソッドパーミッションが可能か指定します。メソッドパーミッションについては 「EJB メソッドパーミッションについて」 を参照してください。
- @RolesAllowed、@PermitAll、@DenyAll
- どのメソッドパーミッションが可能か指定します。メソッドパーミッションについては 「EJB メソッドパーミッションについて」 を参照してください。
- @RunAs
- コンポーネントの伝搬されたセキュリティー ID を設定します。
12.3.3.2. EJB セキュリティーアノテーションの使用
XML 記述子かアノテーションを使用して、どのセキュリティーロールが Enterprise JavaBean (EJB) でメソッドを呼び出しできるかを制御することができます。XML 記述子の使用については 「EJB メソッドパーミッションの使用」 を参照してください。
EJB のセキュリティーパーミッションを制御するアノテーション
- @DeclareRoles
- @DeclareRoles を使用して、どのセキュリティーロールに対してパーミッションをチェックするか定義します。@DeclareRoles が存在しない場合、@RolesAllowed アノテーションよりリストが自動的に構築されます。
- @SecurityDomain
- EJB に使用するセキュリティードメインを指定します。承認のため、EJB に
@RolesAllowed
アノテーションが付いている場合、EJB にセキュリティードメインがアノテーション付けされている場合のみ承認を適用します。 - @RolesAllowed、@PermitAll、@DenyAll
- @RolesAllowed を使用して、1 つまたは複数のメソッドへのアクセスが許可されるロールをリストします。すべてのロールに対して 1 つまたは複数のメソッドの使用を許可する場合は @PermitAll、すべてのロールに対してメソッドの使用を拒否する場合は @DenyAll を使用します。
- @RunAs
- @RunAs を使用してロールを指定すると、メソッドが常にそのロールとして実行されるようにします。
例12.10 セキュリティーアノテーションの例
@Stateless @RolesAllowed({"admin"}) @SecurityDomain("other") public class WelcomeEJB implements Welcome { @PermitAll public String WelcomeEveryone(String msg) { return "Welcome to " + msg; } @RunAs("tempemployee") public String GoodBye(String msg) { return "Goodbye, " + msg; } public String public String GoodbyeAdmin(String msg) { return "See you later, " + msg; } }
WelcomeEveryone
メソッドにアクセスできます。GoodBye
メソッドは tempemployee
ロールとして実行されます。GoodbyeAdmin
メソッドと、セキュリティーアノテーションのない他のメソッドへは admin
ロールのみがアクセスできます。
12.3.4. EJB へのリモートアクセス
12.3.4.1. リモートメソッドアクセスについて
サポートされているトランスポートタイプ
- ソケット / セキュアソケット
- RMI / RMI over SSL
- HTTP / HTTPS
- サーブレット / セキュアサーブレット
- バイソケット (Bisocket) / セキュアバイソケット (Secure Bisocket)
Remoting システムはデータのマーシャリングサービスやアンマーシャリングサービスも提供します。データのマーシャリングとは、別のシステムで処理を実行できるようネットワークやプラットフォーム境界の全体で安全にデータを移動できる機能のことを言います。処理結果は元のシステムへ返送され、ローカルで処理されたように動作します。
Remoting を使用するクライアントアプリケーションを設計する場合、URL 型の形式の単純な文字列である InvokerLocator
と呼ばれる特別なリソースロケーターを使用するよう設定し、アプリケーションがサーバーと通信するようにします。remoting
サブシステムの一部として設定される connector
上で、サーバーはリモートリソースの要求をリッスンします。connector
は設定済みの ServerInvocationHandler
へ要求を渡します。各 ServerInvocationHandler
は要求の対処方法を認識するメソッド invoke(InvocationRequest)
を実装します。
JBoss Remoting フレームワークレイヤー
- ユーザーは外部レイヤーとやりとりします。クライアント側では外部レイヤーは呼び出し要求を送信する
Client
クラスになります。サーバー側ではユーザーによって実装され、呼び出し要求を受信する InvocationHandler になります。 - トランスポートはインボーカーレイヤーによって制御されます。
- 最も下のレイヤーにはデータ形式をワイヤー形式に変換するマーシャラーとアンマーシャラーが含まれています。
12.3.4.2. Remoting コールバックについて
InvocationRequest
をクライアントに送信します。コールバックが同期的または非同期的であるかに関わらず、サーバー側のコードは同様に動作します。クライアントのみが違いを認識する必要があります。サーバーの InvocationRequest は responseObject
をクライアントに送信します。これはクライアントが要求したペイロードで、要求やイベント通知への直接応答になる場合があります。
m_listeners
オブジェクトを使用してリスナーを追跡します。これにはサーバーハンドラーに追加された全リスナーのリストが含まれます。ServerInvocationHandler
インターフェースにはこのリストを管理できるようにするメソッドが含まれます。
org.jboss.remoting.InvokerCallbackHandler
の実装で、コールバックデータを処理します。コールバックハンドラーの実装後、プルコールバックのリスナーを追加するか、プッシュコールバックのコールバックサーバーを実装します。
プルコールバックでは、Client.addListener()
メソッドを使用してクライアントが自身にサーバーのリスナーリストをを追加します。その後、コールバックデータを同期的に配信するためサーバーを周期的にプルします。ここでは Client.getCallbacks()
を使用してプルが実行されます。
プッシュコールバックではクライアントアプリケーションが独自の InvocationHandler を実行する必要があります。これには、クライアント上で Remoting サービスを実行する必要があります。これは コールバックサーバーと呼ばれます。コールバックサーバーは受信する要求を非同期的に許可し、要求元 (この場合はサーバー) のために処理します。メインサーバーを用いてクライアントのコールバックサーバーを登録するには、コールバックサーバーの InvokerLocator
を addListener
への 2 番目の引数として渡します。
12.3.4.3. リモーティングサーバーの検出について
12.3.4.4. Remoting サブシステムの設定
JBoss Remoting にはワーカースレッドプール、1 つ以上のコネクター、複数のローカルおよびリモート接続 URI の 3 つのトップレベル設定可能要素があります。ここでは設定可能な項目の説明、各項目の設定方法に対する CLI コマンド例、完全設定されたサブシステムの XML 例について取り上げます。この設定はサーバーのみに適用されます。独自のアプリケーションにカスタムコネクターを使用する場合を除き、Remoting のサブシステムの設定は必要でないことがほとんどです。EJB など Remoting クライアントとして動作するアプリケーションには特定のコネクターに接続するための個別の設定が必要になります。
注記
デフォルトの default
プロファイルを設定する時の CLI コマンドについて説明します。異なるプロファイルを設定するには、プロファイルの名前を置き換えます。スタンドアロンサーバーではコマンドの /profile=default
の部分を省略します。
remoting
サブシステム外部となる設定もあります。
- ネットワークインターフェース
remoting
サブシステムによって使用されるネットワークネットワークインターフェースはdomain/configuration/domain.xml
またはstandalone/configuration/standalone.xml
で定義されるunsecure
インターフェースです。<interfaces> <interface name="management"/> <interface name="public"/> <interface name="unsecure"/> </interfaces>
unsecure
インターフェースのホストごとの定義はdomain.xml
またはstandalone.xml
と同じディレクトリにあるhost.xml
で定義されます。また、このインターフェースは複数の他のサブシステムによっても使用されます。変更する場合は十分注意してください。<interfaces> <interface name="management"> <inet-address value="${jboss.bind.address.management:127.0.0.1}"/> </interface> <interface name="public"> <inet-address value="${jboss.bind.address:127.0.0.1}"/> </interface> <interface name="unsecure"> <!-- Used for IIOP sockets in the standard configuration. To secure JacORB you need to setup SSL --> <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/> </interface> </interfaces>
- socket-binding
remoting
サブシステムによって使用されるデフォルトの socket-binding は TCP ポート 4777 へバインドします。この設定を変更する必要がある場合はソケットバインディングとソケットバインディンググループに関するドキュメントを参照してください。- EJB の リモーティングコネクター参照
- EJB サブシステムにはリモートメソッド呼び出しに対するリモーティングコネクターへの参照が含まれています。デフォルト設定は次の通りです。
<remote connector-ref="remoting-connector" thread-pool-name="default"/>
- セキュアなトランスポート設定
- Remoting はクライアントの要求があれば StartTLS を使用してセキュアな接続 (HTTPS、Secure Servlet など) を使用します。セキュアな接続とセキュアでない接続の両方で同じソケットバインディング (ネットワークポート) が使用されるため、サーバー側に追加の設定をする必要はありません。クライアントはニーズに従ってセキュアなトランスポートまたはセキュアでないトランスポートを要求します。EJB、ORB、JMS プロバイダーなどの Remoting を使用する JBoss Enterprise Application Platform のコンポーネントはデフォルトでセキュアなインターフェースを使用します。
警告
ワーカースレッドプールは、Remoting コネクターからの作業を処理できるスレッドのグループのことです。単一の要素 <worker-thread-pool>
で、複数の属性を取ります。ネットワークタイムアウトやスレッド不足が発生したり、メモリーの使用を制限する場合にこれらの属性を調節します。特定の推奨設定は状況によって異なります。詳細は Red Hat グローバルサポートサービスまでご連絡ください。
表12.1 ワーカースレッドプールの属性
属性 | 説明 | CLI コマンド |
---|---|---|
read-threads |
リモーティングワーカーに対して作成する読み取りスレッドの数。デフォルトは
1 です。
| /profile=default/subsystem=remoting/:write-attribute(name=worker-read-threads,value=1)
|
write-threads |
リモーティングワーカーに対して作成する書き込みスレッドの数。デフォルトは
1 です。
| /profile=default/subsystem=remoting/:write-attribute(name=worker-write-threads,value=1)
|
task-keepalive |
コアでないリモーティングワーカーのタスクスレッドを生存させておく期間 (ミリ秒単位) です。デフォルトは
60 です。
| /profile=default/subsystem=remoting/:write-attribute(name=worker-task-keepalive,value=60)
|
task-max-threads |
モーティングワーカーのタスクスレッドプールに対するスレッドの最大数です。デフォルトは
16 です。
| /profile=default/subsystem=remoting/:write-attribute(name=worker-task-max-threads,value=16)
|
task-core-threads |
モーティングワーカーのタスクスレッドプールに対するコアスレッドの数です。デフォルトは
4 です。
| /profile=default/subsystem=remoting/:write-attribute(name=worker-task-core-threads,value=4)
|
task-limit |
挿入前に許可されるリモーティングワーカータスクの最大数です。デフォルトは
16384 です。
| /profile=default/subsystem=remoting/:write-attribute(name=worker-task-limit,value=16384)
|
コネクターは主な Remoting 設定要素です。複数のコネクターを設定できます。各コネクターは、サブ要素を持つ <connector>
要素より構成され、複数の属性が含まれることもあります。デフォルトのコネクターは JBoss Enterprise Application Platform の複数のサブシステムによって使用されます。カスタムコネクターの要素や属性の設定はアプリケーションによって異なるため、詳細は Red Hat グローバルサポートサービスまでご連絡ください。
表12.2 コネクターの属性
属性 | 説明 | CLI コマンド |
---|---|---|
name | JNDI によって使用されるコネクターの名前です。 | /profile=default/subsystem=remoting/connector=remoting-connector/:write-attribute(name=name,value=remoting-connector)
|
socket-binding | このコネクターに使用するソケットバインディングの名前です。 | /profile=default/subsystem=remoting/connector=remoting-connector/:write-attribute(name=socket-binding,value=remoting)
|
authentication-provider |
このコネクターと使用する JASPIC (Java Authentication Service Provider Interface) モジュールです。このモジュールはクラスパスに存在しなければなりません。
| /profile=default/subsystem=remoting/connector=remoting-connector/:write-attribute(name=authentication-provider,value=myProvider)
|
security-realm |
任意の設定です。アプリケーションのユーザーやパスワード、ロールが含まれるセキュリティーレルムになります。EJB または Web アプリケーションがセキュリティーレルムに対して認証を行います。
ApplicationRealm はデフォルトの JBoss Enterprise Application Platform インストールで使用可能です。
| /profile=default/subsystem=remoting/connector=remoting-connector/:write-attribute(name=security-realm,value=ApplicationRealm)
|
表12.3 コネクター要素
属性 | 説明 | CLI コマンド |
---|---|---|
sasl |
SASL (Simple Authentication and Security Layer) 認証メカニズムの囲み要素です。
| N/A
|
properties |
1 つ以上の
<property> 要素が含まれ、各要素には name 属性と任意の value 属性が含まれます。
| /profile=default/subsystem=remoting/connector=remoting-connector/property=myProp/:add(value=myPropValue)
|
3 つのタイプの送信接続を指定することができます。
- URI への送信接続。
- ローカルの送信接続 – ソケットなどのローカルリソースへ接続します。
- リモートの送信接続 – リモートリソースへ接続し、セキュリティーレルムを使用して認証を行います。
<outbound-connections>
要素で囲まれます。各接続タイプは outbound-socket-binding-ref
属性を取ります。送信接続は uri
属性を取ります。リモートの送信接続は任意の username
属性と security-realm
属性を取り、認証に使用します。
表12.4 送信接続要素
属性 | 説明 | CLI コマンド |
---|---|---|
outbound-connection | 汎用の送信接続。 | /profile=default/subsystem=remoting/outbound-connection=my-connection/:add(uri=http://my-connection)
|
local-outbound-connection | 暗黙の local:// URI スキームを持つ送信接続。 | /profile=default/subsystem=remoting/local-outbound-connection=my-connection/:add(outbound-socket-binding-ref=remoting2)
|
remote-outbound-connection |
セキュリティーレルムを用いた基本またはダイジェスト認証を使用する remote:// URI スキームの送信接続です。
| /profile=default/subsystem=remoting/remote-outbound-connection=my-connection/:add(outbound-socket-binding-ref=remoting,username=myUser,security-realm=ApplicationRealm)
|
SASL 子要素を定義する前に初期 SASL 要素を作成する必要があります。次のコマンドを使用します。
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:add
属性 | 説明 | CLI コマンド |
---|---|---|
include-mechanisms |
SASL メカニズムのスペース区切りのリストである
value 属性が含まれています。
|
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=include-mechanisms,value=["DIGEST","PLAIN","GSSAPI"]) |
qop |
SASL の保護品質値が希望順に並ぶスペース区切りのリストである
value 属性が含まれます。
|
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=qop,value=["auth"]) |
strength |
SASL の暗号強度の値が希望順に並ぶスペース区切りのリストである
value 属性が含まれます。
|
/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=strength,value=["medium"]) |
reuse-session |
ブール値である
value 属性が含まれます。true の場合、セッションの再使用を試みます。
|
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=reuse-session,value=false) |
server-auth |
ブール値である
value 属性が含まれます。true の場合、サーバーはクライアントに対して認証します。
|
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=server-auth,value=false) |
policy |
以下の要素がゼロ個以上含まれ、各要素が単一の
value を取るエンクロージング要素です。
|
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:add /profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=forward-secrecy,value=true) /profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-active,value=false) /profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-dictionary,value=true) /profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-plain-text,value=false) /profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=pass-credentials,value=true) |
properties |
1 つ以上の
<property> 要素が含まれ、各要素には name 属性と任意の value 属性が含まれます。
|
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/property=myprop:add(value=1) /profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/property=myprop2:add(value=2) |
例12.11 設定例
<subsystem xmlns="urn:jboss:domain:remoting:1.1"> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/> </subsystem>
<subsystem xmlns="urn:jboss:domain:remoting:1.1"> <worker-thread-pool read-threads="1" task-keepalive="60' task-max-threads="16" task-core-thread="4" task-limit="16384" write-threads="1" /> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"> <sasl> <include-mechanisms value="GSSAPI PLAIN DIGEST-MD5" /> <qop value="auth" /> <strength value="medium" /> <reuse-session value="false" /> <server-auth value="false" /> <policy> <forward-secrecy value="true" /> <no-active value="false" /> <no-anonymous value="false" /> <no-dictionary value="true" /> <no-plain-text value="false" /> <pass-credentials value="true" /> </policy> <properties> <property name="myprop1" value="1" /> <property name="myprop2" value="2" /> </properties> </sasl> <authentication-provider name="myprovider" /> <properties> <property name="myprop3" value="propValue" /> </properties> </connector> <outbound-connections> <outbound-connection name="my-outbound-connection" uri="htt\ p://myhost:7777/"/> <remote-outbound-connection name="my-remote-connection" outbound-socket-binding-ref="my-remote-socket" username="myUser" security-realm="ApplicationRealm"/> <local-outbound-connection name="myLocalConnection" outbound-socket-binding-ref="my-outbound-socket"/> </outbound-connections> </subsystem>
文書化されていない設定の側面
- JIDI および マルチキャスト自動検出
12.3.4.5. リモート EJB クライアントを用いたセキュリティーレルムの使用
- 新しいセキュリティーレルムをドメインコントローラーかスタンドアロンサーバーに追加します。
- 次のパラメーターをアプリケーションのクラスパスにある
jboss-ejb-client.properties
ファイルに追加します。この例では、ファイルの他のパラメーターは接続をdefault
として見なすことを前提とします。¶ remote.connection.default.username=appuser¶ remote.connection.default.password=apppassword¶
- 新しいセキュリティーレルムを使用するドメインまたはスタンドアロンサーバー上にカスタム Remoting コネクターを作成します。
- カスタム Remoting コネクターを用いてプロファイルを使用するよう設定されているサーバーグループに EJB をデプロイします。管理されたドメインを使用していない場合はスタンドアロンサーバーに EJB をデプロイします。
12.3.4.6. 新しいセキュリティーレルムの追加
Management CLI を実行します。
jboss-cli.sh
またはjboss-cli.bat
コマンドを開始し、サーバーに接続します。セキュリティーレルムを新規作成します。
次のコマンドを実行し、ドメインコントローラーまたはスタンドアロンサーバー上でMyDomainRealm
という名前の新しいセキュリティーレルムを作成します。/host=master/core-service=management/security-realm=MyDomainRealm:add()
新しいロールの情報を保存するプロパティーファイルへの参照を作成します。
次のコマンドを実行し、新しいロールに関連するプロパティーが含まれるmyfile.properties
という名前のファイルのポインターを作成します。注記
新規作成されたプロパティーファイルは、含まれるadd-user.sh
およびadd-user.bat
スクリプトによって管理されません。そのため、外部から管理する必要があります。/host=master/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
セキュリティーレルムが新規作成されます。この新規作成されたレルムにユーザーやロールを追加すると、デフォルトのセキュリティーレルムとは別のファイルに情報が保存されます。新規ファイルはご使用のアプリケーションやプロシージャーを使用して管理できます。
12.3.4.7. セキュリティーレルムへユーザーを追加
add-user.sh
またはadd-user.bat
コマンドを実行します。コマンドラインインターフェース (CLI) を開きます。EAP_HOME/bin/
ディレクトリへ移動します。Red Hat Enterprise Linux や他の UNIX 系のオペレーティングシステムを稼働している場合はadd-user.sh
を実行します。Microsoft Windows Server を稼働している場合はadd-user.bat
を実行します。管理ユーザーかアプリケーションユーザーのどちらを追加するか選択します。
この手順ではb
を入力し、アプリケーションユーザーを追加します。ユーザーが追加されるレルムを選択します。
デフォルトでは、ApplicationRealm
のみが選択可能です。カスタムレルムが追加されている場合はその名前を入力します。入力を促されたらユーザー名、パスワード、ロールを入力します。
入力を促されたら希望のユーザー名、パスワード、任意のロールを入力します。yes
を入力して選択を確認するか、no
を入力して変更をキャンセルします。変更はセキュリティーレルムの各プロパティーファイルに書き込まれます。
12.3.4.8. SSL による暗号化を使用したリモート EJB アクセスについて
12.4. JAX-RS アプリケーションセキュリティー
12.4.1. RESTEasy JAX-RS Web サービスのロールベースのセキュリティーを有効にする
RESTEasy は JAX-RS メソッドの @RolesAllowed、@PermitAll、@DenyAll アノテーションをサポートしますが、デフォルトではこれらのアノテーションを認識しません。次の手順に従って web.xml
ファイルを設定し、ロールベースセキュリティーを有効にします。
警告
手順12.1 RESTEasy JAX-RS Web サービスのロールベースのセキュリティーを有効にする
- テキストエディターでアプリケーションの
web.xml
ファイルを開きます。 - 以下の <context-param> をファイルの
web-app
タグ内に追加します。<context-param> <param-name>resteasy.role.based.security</param-name> <param-value>true</param-value> </context-param>
- <security-role> タグを使用して RESTEasy JAX-RS WAR ファイル内で使用されるすべてのロールを宣言します。
<security-role><role-name>ROLE_NAME</role-name></security-role><security-role><role-name>ROLE_NAME</role-name></security-role>
- すべてのロールに対して JAX-RS ランタイムが対応する全 URL へのアクセスを承認します。
<security-constraint><web-resource-collection><web-resource-name>Resteasy</web-resource-name><url-pattern>/PATH</url-pattern></web-resource-collection><auth-constraint><role-name>ROLE_NAME</role-name><role-name>ROLE_NAME</role-name></auth-constraint></security-constraint>
ロールベースセキュリティーが定義されたロールのセットによりアプリケーション内で有効になります。
例12.12 ロールベースセキュリティーの設定例
<web-app> <context-param> <param-name>resteasy.role.based.security</param-name> <param-value>true</param-value> </context-param> <servlet-mapping> <servlet-name>Resteasy</servlet-name> <url-pattern>/*</url-pattern> </servlet-mapping> <security-constraint> <web-resource-collection> <web-resource-name>Resteasy</web-resource-name> <url-pattern>/security</url-pattern> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> <role-name>user</role-name> </auth-constraint> </security-constraint> <security-role> <role-name>admin</role-name> </security-role> <security-role> <role-name>user</role-name> </security-role> </web-app>
12.4.2. アノテーションを使用した JAX-RS Web サービスの保護
サポート対象のセキュリティーアノテーションを使用して JAX-RS Web サービスを保護する手順を取り上げます。
手順12.2 サポート対象のセキュリティーアノテーションを使用した JAX-RS Web サービスのセキュア化
- ロールベースセキュリティーを有効にします。詳細は 「RESTEasy JAX-RS Web サービスのロールベースのセキュリティーを有効にする」 を参照してください。
- JAX-RS Web サービスにセキュリティーアノテーションを追加します。RESTEasy は次のアノテーションをサポートします。
- @RolesAllowed
- メソッドにアクセスできるロールを定義します。ロールはすべて
web.xml
ファイルに定義する必要があります。 - @PermitAll
web.xml
ファイルに定義されている全ロールによるメソッドへのアクセスを許可します。- @DenyAll
- メソッドへのアクセスをすべて拒否します。
12.5. リモートパスワードプロトコルの保護
12.5.1. SRP (セキュアリモートパスワード) プロトコルについて
この文書は SRP (セキュアリモートパスワード) プロトコルとして知られる、強固なネットワーク暗号化方式について説明しています。このメカニズムは従来の再利用可能なパスワードで起きていたセキュリティーの問題を排除しつつ、ユーザーによって提供されるパスワードを使いセキュアな接続をネゴシエーションするのに適しています。この仕組みは、認証プロセスでセキュアな鍵交換を行い、セッション時にセキュリティー層 (プライバシーや整合性保護) を有効にすることが可能です。信頼されたキーサーバーや証明書インフラストラクチャーは必要なく、また長期鍵の保存や管理にクライアントを必要としません。SRP には、既存のチャレンジレスポンス方式と比べセキュリティーやデプロイメントに両方において様々な利点があり、SRP は安全なパスワード認証が必要な場合に、互換性のある理想的な代用方式となります。
12.5.2. セキュアリモートパスワード (SRP) プロトコルの設定
SRPVerifierStore
インターフェースを実装する MBean を作成します。実装に関する詳細は SRPVerifierStore 実装 で確認できます。
手順12.3 既存パスワードストアの統合
ハッシュ化されたパスワード情報ストアを作成します。
パスワードが既に不可逆的にハッシュ化され、保存されている場合、この作業をユーザーごとに行う必要があります。noOP メソッドとしてsetUserVerifier(String, VerifierInfo)
を実装するか、ストアが読み取り専用であることを知らせる例外をスローするメソッドとしてsetUserVerifier(String, VerifierInfo)
を実装することができます。SRPVerifierStore インターフェースを作成します。
作成したストアよりVerifierInfo
を取得できるカスタムのSRPVerifierStore
インターフェース実装を作成します。verifyUserChallenge(String, Object)
を使用すると、SafeWord や Radius のような既存のハードウェアトークンベースのスキームを SRP アルゴリズムへ統合することができます。このインターフェースメソッドは、クライアントの SRPLoginModule 設定で hasAuxChallenge オプションが指定されている場合のみ呼び出されます。JNDI MBean を作成します。
JNDI が使用できるSRPVerifierStore
インターフェースを公開し、必要な設定可能パラメーターを公開する MBean を作成します。デフォルトのorg.jboss.security.srp.SRPVerifierStoreService
でこれを実装することが可能です。また、SRPVerifierStore
の Java プロパティーファイル実装を使用して MBean を実装することもできます。
すべてのパスワードハッシュ情報がシリアライズされたオブジェクトのファイルとして使用できなければならないため、SRPVerifierStore
インターフェースのデフォルト実装は実稼動システムでは推奨されません。
SRPVerifierStore
実装は、特定のユーザー名に対して SRPVerifierStore.VerifierInfo
オブジェクトへのアクセスを提供します。SRP アルゴリズムが必要とするパラメーターを取得するため、getUserVerifier(String)
メソッドはユーザー SRP セッションの最初に SRPService によって呼び出されます。
VerifierInfo オブジェクトの要素
- username
- 認証に使用されるユーザー名またはユーザー ID です。
- verifier
- アイデンティティーの証拠としてユーザーが入力するパスワードの一方向ハッシュです。
org.jboss.security.Util
クラスにはパスワードハッシュ化アルゴリズムを実行するcalculateVerifier
メソッドが含まれています。出力パスワードはH(salt | H(username | ':' | password))
の形式を取ります。H
は RFC2945 で定義されている SHA セキュアハッシュ関数になります。ユーザー名は UTF-8 エンコーディングを使用して文字列から byte[] へ変換されます。 - salt
- データベースの情報が漏えいされた場合に、ベリファイアーパスワードデータベース上での総当たり辞書攻撃を難しくするために使用される乱数です。ユーザーの既存のクリアテキストパスワードがハッシュ化される時に、暗号強度が高い乱数アルゴリズムより値が生成されなければなりません。
- g
- SRP アルゴリズムプリミティブジェネレーターです。ユーザーごとの設定ではなく、既知の固定パラメーターとなります。
org.jboss.security.srp.SRPConf
ユーティリティクラスはg
の設定を複数提供します。 これにはSRPConf.getDefaultParams().g()
により取得される適切なデフォルトなどが含まれます。 - N
- SRP アルゴリズムセーフプライムモジュールです。ユーザーごとの設定ではなく、既知の固定パラメーターとなります。 org.jboss.security.srp.SRPConf ユーティリティクラスは
org.jboss.security.srp.SRPConf
は N の設定を複数提供します。これにはSRPConf.getDefaultParams().N()
より取得される適切なデフォルトなどが含まれます。
例12.13 SRPVerifierStore インターフェース
package org.jboss.security.srp; import java.io.IOException; import java.io.Serializable; import java.security.KeyException; public interface SRPVerifierStore { public static class VerifierInfo implements Serializable { public String username; public byte[] salt; public byte[] g; public byte[] N; } public VerifierInfo getUserVerifier(String username) throws KeyException, IOException; public void setUserVerifier(String username, VerifierInfo info) throws IOException; public void verifyUserChallenge(String username, Object auxChallenge) throws SecurityException; }
第13章 シングルサインオン (SSO)
13.1. Web アプリケーションのシングルサインオン (SSO) について
SSO (シングルサインオン) は 1 つのリソースへの認証を用いて他のリソースへのアクセスを暗黙的に承認できるようにします。
クラスター化されていない SSO は、アプリケーションの承認情報の共有を同じ仮想ホスト内に制限します。また、ホストの障害に対する耐性を持ちません。クラスター化された SSO データは複数の仮想ホストのアプリケーション間で共有することができ、フェイルオーバーに対する耐性を持ちます。さらに、クラスター化された SSO はロードバランサーからのリクエストを受信することができます。
リソースが保護されていない場合、ユーザーの認証は完全に無視されます。ユーザーが保護されたリソースにアクセスすると、ユーザーの認証が必要になります。
SSO の制限
- サードパーティー境界にまたがる伝搬がない
- JBoss Enterprise Application Platform のコンテナ内にデプロイされたアプリケーションの間でのみ SSO を使用できます。
- コンテナ管理の認証のみ使用可能
- アプリケーションの
web.xml
で<login-config>
などのコンテナ管理認証要素を使用しなければなりません。 - クッキーが必要
- SSO はブラウザークッキーを介して維持されます。URL の再書き込みはサポートされていません。
- レルムとセキュリティードメインの制限
requireReauthentication
パラメーターがtrue
に設定されている場合を除き、同じ SSO バルブに設定されたすべての Web アプリケーションは、web.xml
の同じレルム設定と同じセキュリティードメインを共有しなければなりません。関与する Web アプリケーションの 1 つに対し、Host 要素内または Engine 要素周囲で Realm 要素をネストできますが、context.xml 要素内で Realm 要素はネストできません。jboss-web.xml
に設定された<security-domain>
はすべての Web アプリケーション全体で一貫していなければなりません。すべてのセキュリティー統合が同じ認証情報 (ユーザー名やパスワードなど) を許可しなければなりません。
13.2. Web アプリケーションのクラスター化されたシングルサインオン (SSO) について
jboss-web.xml
に設定されます。
- Apache Tomcat の ClusteredSingleSignOn
- Apache Tomcat の IDPWebBrowserSSOValve
- PicketLink によって提供される SPNEGO ベースの SSO
13.3. 適切な SSO 実装の選択
Microsoft Active Directory など、Kerberos ベースの認証承認システムがすでに組織で使用されている場合は、同じシステムを使用して JBoss Enterprise Application Platform 上で実行されているエンタープライズアプリケーションを透過的に認証することができます。
同じサーバーグループやインスタンス内で実行するアプリケーション間でセキュリティー情報を伝播する必要がある場合、クラスター化されていない SSO を使用することができます。この場合、アプリケーションの jboss-web.xml
記述子にバルブを設定することのみが必要となります。
複数の JBoss Enterprise Application Platform インスタンス全体のクラスター化された環境で実行されるアプリケーションの間でセキュリティー情報を伝播する必要がある場合、クラスター化された SSO バルブを使用することができます。このバルブはアプリケーションの jboss-web.xml
に設定されます。
13.4. Web アプリケーションでの SSO (シングルサインオン) の使用
SSO (シングルサインオン) の機能は Web および Infinispan サブシステムによって提供されます。この手順に従って Web アプリケーションに SSO を設定します。
要件
- 認証と承認を処理するセキュリティードメインが設定されている必要があります。
infinispan
サブシステムが存在する必要があります。管理対象ドメインの場合、このサブシステムはfull-ha
プロファイルにあります。スタンドアロンサーバーではstandalone-full-ha.xml
設定を使用します。web
cache-container
と SSO cache-container が存在する必要があります。例の設定ファイルにはweb
cache-container がすでに含まれており、一部の設定には SSO cache-container も含まれています。以下のコマンドを使用して SSO キャッシュコンテナをチェックし、有効にします。これらのコマンドは管理対象ドメインのfull
プロファイルを変更することに注意してください。スタンドアロンサーバーに対して異なるプロファイルを使用したり、コマンドの/profile=full
部分を削除するため、コマンドを変更することもできます。例13.1
web
cache-container の確認前述のプロファイルや設定には、デフォルトとしてweb
cache-container が含まれています。次のコマンドを使用して、web
cache-container の存在を確認します。異なるプロファイルを使用する場合は、ha
をその名前に置き換えます。/profile=ha/subsystem=infinispan/cache-container=web/:read-resource(recursive=false,proxies=false,include-runtime=false,include-defaults=true)
サブシステムが存在する場合、結果はsuccess
になります。存在しない場合は追加する必要があります。例13.2
web
cache-container の追加次の 3 つのコマンドを使用してweb
cache-container を設定に対して有効にします。必要に応じてプロファイルの名前やその他のパラメーターを変更します。以下のパラメーターはデフォルト設定で使用されるパラメーターになります。/profile=ha/subsystem=infinispan/cache-container=web:add(aliases=["standard-session-cache"],default-cache="repl",module="org.jboss.as.clustering.web.infinispan")
/profile=ha/subsystem=infinispan/cache-container=web/transport=TRANSPORT:add(lock-timeout=60000)
/profile=ha/subsystem=infinispan/cache-container=web/replicated-cache=repl:add(mode="ASYNC",batching=true)
例13.3
SSO
cache-container の確認次の管理 CLI コマンドを実行します。/profile=ha/subsystem=infinispan/cache-container=web/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
"sso" => {
のような出力を探します。このような出力が見つからない場合、設定に SSO cache-container は存在しません。例13.4
SSO
cache-container の追加/profile=ha/subsystem=infinispan/cache-container=web/replicated-cache=sso:add(mode="SYNC", batching=true)
- SSO を使用するよう
web
サブシステムを設定する必要があります。次のコマンドは、default-host
という仮想サーバー上と、クッキードメインdomain.com
で SSO を有効にします。キャッシュ名はsso
で、再認証は無効になっています。/profile=ha/subsystem=web/virtual-server=default-host/sso=configuration:add(cache-container="web",cache-name="sso",reauthenticate="false",domain="domain.com")
- SSO 情報を共有する各アプリケーションは、
jboss-web.xml
デプロイメント記述子にある同じ <security-domain> とweb.xml
設定ファイルにある同じレルムを使用するよう設定されている必要があります。
クラスター化された SSO では個別のホスト間で認証を共有できますが、クラスター化されていない SSO では共有できません。どちらの SSO も同じように設定されますが、クラスター化された SSO には永続データのクラスタリングレプリケーションを制御する cacheConfig
や processExpiresInterval
、 maxEmptyLife
パラメーターが含まれています。
例13.5 クラスター化された SSO 設定の例
tomcat
と呼ばれるセキュリティードメインを使用します。
<jboss-web> <security-domain>tomcat</security-domain> <valve> <class-name>org.jboss.web.tomcat.service.sso.ClusteredSingleSignOn</class-name> <param> <param-name>maxEmptyLife</param-name> <param-value>900</param-value> </param> </valve> </jboss-web>
表13.1 SSO 設定のオプション
オプション | 説明 |
---|---|
cookieDomain |
SSO クッキーに使用するホストドメインです。デフォルトは
/ です。app1.xyz.com と app2.xyz.com によるクッキーの共有を許可するには、cookieDomain を xyz.com に設定します。
|
maxEmptyLife |
クラスター化された SSO のみ設定可能です。失効する前に、アクティブなセッションを持たない SSO バルブを 1 つのリクエストが使用できる最大秒数。唯一バルブにアクティブなセッションが付加されている場合、正の値を設定するとノードのシャットダウンが適切に処理されるようになります。maxEmptyLife を
0 に設定すると、ローカルセッションがコピーされると同時にバルブが終了しますが、クラスター化されたアプリケーションからのセッションのバックアップコピーは他のクラスターノードが使用できるようになります。バルブの管理セッションの生存期間を越えてバルブが生存できるようにすると、他のリクエストを実行する時間がユーザーに与えられます。このリクエストはセッションのバックアップコピーをアクティベートする他のノードへフェイルオーバーすることができます。デフォルトは 1800 秒 (30 分) です。
|
processExpiresInterval |
クラスター化された SSO のみ設定可能です。
MaxEmptyLife タイムアウトを失効した SSO インスタンスをバルブが発見し無効化する動作の間隔の最初秒数。デフォルトは 60 (1 分) です。
|
requiresReauthentication |
true の場合、各リクエストはキャッシュされた認証情報を使用してセキュリティーレルムへ再認証します。false の場合 (デフォルト)、バルブによる新しい要求の認証には有効な SSO クッキーのみが必要になります。
|
アプリケーションはメソッド javax.servlet.http.HttpSession.invalidate()
を呼び出し、プログラムを用いてセッションを無効化することができます。
13.5. Kerberos について
13.6. SPNEGO について
13.7. Microsoft Active Directory ディレクトリについて
- ユーザーやコンピューター、パスワードなどのリソースの情報を保存する LDAP (Lightweight Directory Access Protocol) 。
- ネットワーク上で安全な認証を提供する Kerberos.
- IP アドレスやコンピューターのホスト名、ネットワーク上のその他のデバイス間でマッピングを提供する DNS (Domain Name Service)。
13.8. Web アプリケーションに対して Kerberos または Microsoft Active Directory のデスクトップ SSO を設定する
Microsoft Active Directory など、組織における既存の Kerberos ベースの認証承認インフラストラクチャーを使用して Web アプリケーションや EJB アプリケーションを認証するため、Enterprise Application Platform 6 に内蔵される JBoss Negotiation の機能を使用することが可能です。Web アプリケーションを適切に設定すれば、デスクトップまたはネットワークへのログインに成功するだけでWeb アプリケーションに対して透過的な認証を行えるため、追加のログインプロンプトは必要ありません。
JBoss Enterprise Application Platform 6 と以前のバージョンには顕著な違いがいくつかあります。
- セキュリティードメインは、管理対象ドメインの各プロファイルまたは各スタンドアロンサーバーに対して設定されます。セキュリティードメインはデプロイメントの一部ではありません。デプロイメントが使用する必要のあるセキュリティードメインは、デプロイメントの
jboss-web.xml
またはjboss-ejb3.xml
ファイルに名前が指定されています。 - セキュリティープロパティーは設定の一部分で、セキュリティードメインの一部として設定されます。デプロイメントの一部ではありません。
- デプロイメントの一部としてオーセンティケーターを上書きすることができなくなりましたが、NegotiationAuthenticator バルブを
jboss-web.xml
記述子に追加すると同じ結果を得ることができます。バルブでも<security-constraint>
および<login-config>
要素がweb.xml
に定義されている必要があります。これらはセキュアなリソースを決定するために使用されますが、選択された auth-method はjboss-web.xml
の NegotiationAuthenticator バルブによって上書きされます。 - セキュリティードメインの
CODE
属性は、完全修飾クラス名ではなく、単純名を使用するようになりました。次の表は、これらのクラスと JBoss Negotiation に使用されるクラスとのマッピングを表しています。
表13.2 ログインモジュールコードとクラス名
単純名 | クラス名 | 目的 |
---|---|---|
Kerberos | com.sun.security.auth.module.Krb5LoginModule | Kerberos ログインモジュール |
SPNEGO | org.jboss.security.negotiation.spnego.SPNEGOLoginModule | Web アプリケーションが Kerberos 認証サーバーへ認証できるようにするメカニズム。 |
AdvancedLdap | org.jboss.security.negotiation.AdvancedLdapLoginModule | Microsoft Active Directory 以外の LDAP サーバーと使用されます。 |
AdvancedAdLdap | org.jboss.security.negotiation.AdvancedADLoginModule | Microsoft Active Directory の LDAP サーバーを使用されます。 |
JBoss Negotiation Toolkit
は https://community.jboss.org/servlet/JiveServlet/download/16876-2-34629/jboss-negotiation-toolkit.war よりダウンロード可能なデバッグ用のツールです。アプリケーションを実稼動環境に導入する前に認証メカニズムをデバッグし、テストできるようにするため提供されている追加のツールです。サポート対象のツールではありませんが、SPENEGO を Web アプリケーションに対して設定することは難しいこともあるため、大変便利なツールと言えます。
手順13.1 Web または EJB アプリケーションへ SSO 認証を設定
サーバーのアイデンティティーを表すセキュリティードメインを 1 つ設定します。必要な場合はシステムプロパティーを設定します。
最初のセキュリティードメインは、コンテナ自体をディレクトリーサービスへ認証します。ユーザーではなくコンテナ自体の認証であるため、ある種の静的ログインメカニズムを受容するログインモジュールを使用する必要があります。この例では静的プリンシパルを使用し、認証情報が含まれるキータブファイルを参照します。明確にするため、この例では XML コードが提供されていますが、管理コンソールまたは管理 CLI を使用してセキュリティードメインを設定するようにしてください。<security-domain name="host" cache-type="default"> <authentication> <login-module code="Kerberos" flag="required"> <module-option name="storeKey" value="true"/> <module-option name="useKeyTab" value="true"/> <module-option name="principal" value="host/testserver@MY_REALM"/> <module-option name="keyTab" value="/home/username/service.keytab"/> <module-option name="doNotPrompt" value="true"/> <module-option name="debug" value="false"/> </login-module> </authentication> </security-domain>
Web アプリケーションやアプリケーションをセキュアにするため、2 つ目のセキュリティードメインを設定します。必要な場合はシステムプロパティーを設定します。
2 つ目のセキュリティードメインは、個別のユーザーを Kerberos または SPNEGO 認証サーバーへ認証するために使用されます。ユーザーの認証に最低でも 1 つのログインモジュールが必要で、ユーザーに適用するロールを検索するために別のログインモジュールが必要となります。次の XML コードは SPNEGO セキュリティードメインの例を表しています。これには、ロールを個別のユーザーにマッピングする承認モジュールが含まれます。認証サーバー上でロールを検索するモジュールを使用することもできます。<security-domain name="SPNEGO" cache-type="default"> <authentication> <!-- Check the username and password --> <login-module code="SPNEGO" flag="requisite"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="serverSecurityDomain" value="host"/> </login-module> <!-- Search for roles --> <login-module code="UserRoles" flag="required"> <module-option name="password-stacking" value="useFirstPass" /> <module-option name="usersProperties" value="spnego-users.properties" /> <module-option name="rolesProperties" value="spnego-roles.properties" /> </login-module> </authentication> </security-domain>
web.xml
の security-constraint と login-config を指定します。web.xml
記述子にはセキュリティー制約とログイン設定に関する情報が含まれています。セキュリティー制約とログイン情報の値の例は次の通りです。<security-constraint> <display-name>Security Constraint on Conversation</display-name> <web-resource-collection> <web-resource-name>examplesWebApp</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>RequiredRole</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>SPNEGO</auth-method> <realm-name>SPNEGO</realm-name> </login-config> <security-role> <description> role required to log in to the Application</description> <role-name>RequiredRole</role-name> </security-role>
jboss-web.xml
記述子にセキュリティードメインと他の設定を指定します。クライアント側のセキュリティードメイン (例の 2 番目のセキュリティードメイン) の名前をデプロイメントのjboss-web.xml
記述子に指定し、アプリケーションがこのセキュリティードメインを使用するよう指示します。オーセンティケーターを直接上書きすることができなくなりましたが、必要な場合は NegotiationAuthenticator をバルブとしてjboss-web.xml
記述子に追加することができます。<jacc-star-role-allow>
は任意で、複数のロール名を一致させるためアスタリスク (*) の使用を許可します。<jboss-web> <security-domain>java:/jaas/SPNEGO</security-domain> <valve> <class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name> </valve> <jacc-star-role-allow>true</jacc-star-role-allow> </jboss-web>
アプリケーションの
MANIFEST.MF
に依存関係を追加し、Negotiation クラスを見つけます。Web アプリケーションが JBoss Negotiation クラスを見つけるには、クラスorg.jboss.security.negotiation
上の依存関係をデプロイメントのMETA-INF/MANIFEST.MF
マニフェストに追加する必要があります。適切にフォーマットされたエントリは次の通りです。Manifest-Version: 1.0 Build-Jdk: 1.6.0_24 Dependencies: org.jboss.security.negotiation
Web アプリケーションが Kerberos や Microsoft Active Directory、 SPNEGO 対応のディレクトリサービスに対して認証情報を許可し、認証します。既にディレクトリサービスにログインしているシステムよりユーザーがアプリケーションを実行し、必要なロールが既にユーザーに適用されている場合、Web アプリケーションは認証を要求しないため、SSO の機能が実現されます。
第14章 アプリケーションのロールベースセキュリティー
14.1. アプリケーションセキュリティーについて
14.2. セキュリティー監査について
14.3. セキュリティーマッピングについて
14.4. セキュリティー拡張アーキテクチャーについて
インフラストラクチャーの最初の部分は JAAS API になります。JAAS はセキュリティーインフラストラクチャーとアプリケーションの間の抽象化レイヤーを提供するプラグイン可能なフレームワークです。
AuthenticationManager
インターフェースと RealmMapping
インターフェースを実装する org.jboss.security.plugins.JaasSecurityManager
です。JaasSecurityManager
は、対応するコンポーネントデプロイメント記述子の <security-domain>
要素を基に、EJB レイヤーと Web コンテナレイヤーに統合します。
JaasSecurityManagerService
MBean
JaasSecurityManagerService
MBean サービスはセキュリティーマネージャーを管理します。名前は JAAS で始まりますが、処理するセキュリティーマネージャーは実装で JAAS を使用する必要はありません。この名前は、デフォルトのセキュリティーマネージャー実装が JaasSecurityManager
であることを示しています。
JaasSecurityManagerService
の主要な役割はセキュリティーマネージャー実装を外部化することです。AuthenticationManager
インターフェースと RealmMapping
インターフェースの代替の実装を提供してセキュリティーマネージャーの実装を変更することができます。
JaasSecurityManagerService
の 2 つ目の基礎的な役割は、JNDI javax.naming.spi.ObjectFactory
実装を提供して JNDI 名とセキュリティーマネージャー実装との間でバインディングの簡単なコードのない管理を実現することです。セキュリティーを有効にするには、<security-domain>
デプロイメント記述子要素よりセキュリティーマネージャー実装の JNDI 名を指定します。
JaasSecurityManagerService
が 次のネーミングシステムリファレンス をバインドし、java:/jaas
という名前の JNDI の ObjectFactory
として JaasSecurityManagerService
自体をノミネートします。これにより、java:/jaas/XYZ
という形式の命名規則を <security-domain>
要素の値とすることができます。セキュリティードメインの名前を取るコンストラクターを使用して SecurityManagerClassName
属性によって指定されるクラスのインスタンスを作成して、XYZ
セキュリティードメインのセキュリティーマネージャーインスタンスは必要な時に作成されます。
注記
java:/jaas
プレフィックスがデプロイメント記述子に含まれるようにする必要はありません。後方互換性を維持するため指定することがあるかもしれませんが、このプレフィックスは無視されます。
org.jboss.security.plugins.JaasSecurityDomain
は、 SSL やその他の暗号化のユースケースをサポートするため KeyStore
や KeyManagerFactory
、TrustManagerFactory
の概念を追加する JaasSecurityManager
の拡張です。
詳細や動作しているセキュリティーアーキテクチャーの実例については 「Java Authentication and Authorization Service (JAAS) について」 を参照してください。
14.5. Java Authentication and Authorization Service (JAAS) について
サーバーグループ (管理対象ドメイン内) とサーバー (スタンドアロンサーバー内) にはセキュリティードメインの設定が含まれます。セキュリティードメインには、認証、承認、マッピング、監査のモジュールの組み合わせと設定詳細に関する情報が含まれています。アプリケーションは必要なセキュリティードメインを名前で jboss-web.xml
に指定します。
アプリケーション固有の設定は次の 4 つのファイルの 1 つ以上に設定されます。
表14.1 アプリケーション固有の設定ファイル
ファイル | 説明 |
---|---|
ejb-jar.xml |
EJB の
META-INF ディレクトリにある Enterprise JavaBean (EJB) アプリケーションのデプロイメント記述子です。ejb-jar.xml を使用してロールを指定し、アプリケーションレベルでプリンシパルへマッピングします。また、特定のメソッドやクラスを特定のロールへ制限することも可能です。セキュリティーに関係しない他の EJB 固有の設定に対しても使用できます。
|
web.xml |
Java Enterprise Edition (EE) の Web アプリケーションのデプロイメント記述子です。
web.xml を使用して、認証や承認にアプリケーションが使用するセキュリティードメインを宣言します。また、許可される HTTP リクエストのタイプを制限するなど、アプリケーションのリソースやトランスポートを制約するため使用することもできます。このファイルに簡単な Web ベースの認証を設定することもできます。セキュリティーに関係しない他のアプリケーション固有の設定に使用することもできます。
|
jboss-ejb3.xml | ejb-jar.xml 記述子への JBoss 固有の拡張が含まれます。
|
jboss-web.xml | web.xml 記述子への JBoss 固有の拡張が含まれます。
|
注記
ejb-jar.xml
と web.xml
は Java Enterprise Edition (Java EE) 仕様に定義されています。jboss-ejb3.xml
は ejb-jar.xml
の JBoss 固有の拡張を提供し、jboss-web.xml
は web.xml
の JBoss 固有の拡張を提供します。
Java Authentication and Authorization Service (JAAS) はプラグ可能認証モジュール (PAM) を使用した、 Java アプリケーションのユーザーレベルのセキュリティーに対するフレームワークです。JAAS は Java ランタイム環境 (JRE) に統合されます。JBoss Enterprise Application Platform では、コンテナ側のコンポーネントは org.jboss.security.plugins.JaasSecurityManager
MBean で、AuthenticationManager
インターフェースと RealmMapping
インターフェースのデフォルト実装を提供します。
JaasSecurityManager は JAAS パッケージを使用して AuthenticationManager と RealmMapping インターフェースの動作を実装します。JaasSecurityManager へ割り当てられたセキュリティードメインに設定されたログインモジュールインスタンスを実行するとこの動作が生じます。ログインモジュールはセキュリティードメインのプリンシパルの認証やロールマッピングの挙動を実装します。ドメインの異なるログインモジュール設定を組み込むと、異なるセキュリティードメイン全体で JaasSecurityManager を使用することができます。
EJBHome
を実装するメソッドのクライアント呼び出しの概要になります。EJB は既にサーバーにデプロイされ、EJBHome
インターフェースメソッドは ejb-jar.xml
記述子の <method-permission> 要素を使用してセキュアな状態になっています。jboss-ejb3.xml
ファイルの <security-domain> 要素に指定される jwdomain
セキュリティードメインを使用します。以下の図は後で説明する手順を表しています。

図14.1 保護された EJB メソッド呼び出しの手順
- クライアントが JAAS のログインを実行し、認証のプリンシパルと認証情報を確立します。上図では Client Side Login とラベル付けされます。JNDI より実行することも可能です。JAAS ログインを実行するには、LoginContext インスタンスを作成し、使用する設定の名前を渡します。ここでの設定名は
other
になります。このワンタイムログインは、ログインプリンシパルと認証情報を後続の EJB メソッド呼び出しすべてへ関連付けます。プロセスがユーザーを認証するとは限りません。クライアント側のログインの性質は、クライアントが使用するログインモジュール設定によって異なります。この例では、other
というクライアント側ログイン設定エントリーがClientLoginModule
ログインモジュールを使用します。サーバー上で後で認証が行われるため、このモジュールはユーザー名とパスワードを EJB 呼び出しレイヤーへバインドします。クライアントのアイデンティティーはクライアント上で認証されません。 - クライアントは
EJBHome
メソッドを取得し、このメソッドをサーバー上で呼び出します。呼び出しにはクライアントによって渡されたメソッド引数や、クライアント側 JAAS ログインからのユーザー ID や認証情報が含まれます。 - サーバー上では、セキュリティーインターセプターがメソッドを呼び出したユーザーを認証します。これには別の JAAS ログインが関係します。
- セキュリティードメインはログインモジュールの選択を決定します。セキュリティードメインの名前はログイン設定エントリー名として
LoginContext
コンストラクターへ渡されます。EJB セキュリティードメインはjwdomain
です。JAAS 認証に成功すると、JAAS サブジェクトが作成されます。JAAS サブジェクトには次の詳細を含む PrincipalSet が含まれます。- デプロイメントセキュリティー環境よりクライアントアイデンティティーへ対応する
java.security.Principal
インスタンス。 - ユーザーのアプリケーションドメインからのロール名が含まれる
Roles
と呼ばれるjava.security.acl.Group
。org.jboss.security.SimplePrincipal
タイプのオブジェクトはロール名を表します。これらのロールは、ejb-jar.xml
とEJBContext.isCallerInRole(String)
メソッド実装の制約に従って EJB メソッドへのアクセスを検証します。 - アプリケーションドメインの呼び出し側のアイデンティティーに対応する 1 つの
org.jboss.security.SimplePrincipal
が含まれるCallerPrincipal
という名前の任意のjava.security.acl.Group
。CallerPrincipal グループメンバーはEJBContext.getCallerPrincipal()
メソッドによって返される値です。このマッピングは、運用セキュリティー環境のプリンシパルがアプリケーションが認識するプリンシパルへマッピングできるようにします。CallerPrincipal マッピングが存在しない場合、運用プリンシパルはアプリケーションドメインプリンシパルと同じになります。
- EJB メソッドを呼び出しているユーザーは呼び出しが許可されているユーザーであることをサーバーが検証します。次の手順でこの承認を実行します。
- EJB コンテナから EJBメソッドへアクセスすることが許可されるロールの名前を取得します。呼び出されたメソッドが含まれるすべての <method-permission> 要素の
ejb-jar.xml
記述子 <role-name> 要素によってロール名が判断されます。 - 割り当てられたロールがなかったり、メソッドが exclude-list 要素に指定されている場合、メソッドへのアクセスは拒否されます。それ以外の場合は、セキュリティーインターセプターによってセキュリティーマネージャー上で
doesUserHaveRole
メソッドが呼び出され、呼び出し側に割り当てられたロール名の 1 つがあるかどうかを確認します。このメソッドはロール名より繰り返され、認証されたユーザーのSubject Roles
グループに割り当てられたロール名を持つ SimplePrincipal が含まれるか確認します。Roles グループメンバーのロール名がある場合はアクセスが許可されます。メンバーのロール名がない場合はアクセスが拒否されます。 - EJB がカスタムのセキュリティープロキシを使用する場合、メソッドの呼び出しはプロキシへ委譲されます。セキュリティープロキシが呼び出し側へのアクセスを拒否すると、
java.lang.SecurityException
がスローされます。それ以外の場合は EJB メソッドへのアクセスは許可され、メソッド呼び出しは次のコンテナインターセプターへ渡されます。SecurityProxyInterceptor はこのチェックを処理し、このインターセプターは表示されません。 - Web 接続要求の場合、
web.xml
で定義され、要求されたリソースとアクセスされた HTTP メソッドに一致するセキュリティー制約を Web サーバーがチェックします。要求に対して制約が存在する場合、Web サーバーは JaasSecurityManager を呼び出し、プリンシパルの認証を行います。これにより、確実にユーザーロールがプリンシパルオブジェクトへ関連付けられているようにします。
14.6. アプリケーションでのセキュリティードメインの使用
アプリケーションでセキュリティードメインを使用するには、最初にサーバーの設定ファイルまたはアプリケーションの記述子ファイルのいずれかにドメインを設定する必要があります。その後、使用する EJB に必要なアノテーションを追加する必要があります。ここでは、アプリケーションでセキュリティードメインを使用するために必要な手順について取り上げます。
手順14.1 セキュリティードメインを使用するようアプリケーションを設定
セキュリティードメインの定義
セキュリティードメインは、サーバーの設定ファイルまたはアプリケーションの記述子ファイルのいずれかに定義できます。サーバーの設定ファイルへセキュリティードメインを設定
セキュリティードメインは、サーバーの設定ファイルのsecurity
サブシステムに設定されます。JBoss Enterprise Application Platform インスタンスが管理対象ドメインで実行されている場合、domain/configuration/domain.xml
ファイルになります。JBoss Enterprise Application Platform インスタンスがスタンドアロンサーバーとして実行されている場合はstandalone/configuration/standalone.xml
ファイルになります。other
、jboss-web-policy
およびjboss-ejb-policy
セキュリティードメインはデフォルトとして JBoss Enterprise Application Platform 6 に提供されます。次の XML の例は、サーバーの設定ファイルのsecurity
サブシステムよりコピーされました。<subsystem xmlns="urn:jboss:domain:security:1.2"> <security-domains> <security-domain name="other" cache-type="default"> <authentication> <login-module code="Remoting" flag="optional"> <module-option name="password-stacking" value="useFirstPass"/> </login-module> <login-module code="RealmDirect" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> </login-module> </authentication> </security-domain> <security-domain name="jboss-web-policy" cache-type="default"> <authorization> <policy-module code="Delegating" flag="required"/> </authorization> </security-domain> <security-domain name="jboss-ejb-policy" cache-type="default"> <authorization> <policy-module code="Delegating" flag="required"/> </authorization> </security-domain> </security-domains> </subsystem>
管理コンソールまたは CLI を使用して、追加のセキュリティードメインを必要に応じて設定することができます。アプリケーションの記述子ファイルにセキュリティードメインを設定
セキュリティードメインはアプリケーションのWEB-INF/web.xml
ファイルにある<jboss-web>
要素の<security-domain>
子要素に指定されます。次の例はmy-domain
という名前のセキュリティードメインを設定します。<jboss-web> <security-domain>my-domain</security-domain> </jboss-web>
これがWEB-INF/jboss-web.xml
記述子に指定できる多くの設定の 1 つになります。
EJB へ必要なアノテーションを追加
@SecurityDomain
および@RolesAllowed
アノテーションを使用してセキュリティーを EJB に設定します。次の EJBコードの例は、guest
ロールのユーザーによるother
セキュリティードメインへのアクセスを制限します。package example.ejb3; import java.security.Principal; import javax.annotation.Resource; import javax.annotation.security.RolesAllowed; import javax.ejb.SessionContext; import javax.ejb.Stateless; import org.jboss.ejb3.annotation.SecurityDomain; /** * Simple secured EJB using EJB security annotations * Allow access to "other" security domain by users in a "guest" role. */ @Stateless @RolesAllowed({ "guest" }) @SecurityDomain("other") public class SecuredEJB { // Inject the Session Context @Resource private SessionContext ctx; /** * Secured EJB method using security annotations */ public String getSecurityInfo() { // Session context injected using the resource annotation Principal principal = ctx.getCallerPrincipal(); return principal.toString(); } }
その他のコード例は、Red Hat カスタマーポータルより入手できる JBoss Enterprise Application Platform 6 Quickstarts バンドルのejb-security
クイックスタートを参照してください。
14.7. サーブレットでのロールベースセキュリティーの使用
jboss-web.xml
に指定されたセキュリティードメインによって処理されます。
サーブレットで ロールベースセキュリティーを使用する前に、アクセスの認証と承認に使用されるセキュリティードメインを JBoss Enterprise Application Platform のコンテナに設定する必要があります。
手順14.2 ロールベースセキュリティーのサーブレットへの追加
サーブレットと URL パターンの間にマッピングを追加します。
web.xml
の<servlet-mapping>
要素を使用して各サーブレットを URL パターンへマッピングします。次の例はDisplayOpResult
と呼ばれるサーブレットを URL パターン/DisplayOpResult
にマッピングします。<servlet-mapping> <servlet-name>DisplayOpResult</servlet-name> <url-pattern>/DisplayOpResult</url-pattern> </servlet-mapping>
URL パターンにセキュリティー制約を追加します。
URL パターンをセキュリティー制約へマッピングするには、<security-constraint>
を使用します。次の例は、URL パターン/DisplayOpResult
のアクセスを、ロールeap_admin
を持つプリンシパルのみに許可します。セキュリティードメインにロールが存在していなければなりません。<security-constraint> <display-name>Restrict access to role eap_admin</display-name> <web-resource-collection> <web-resource-name>Restrict access to role eap_admin</web-resource-name> <url-pattern>/DisplayOpResult/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>eap_admin</role-name> </auth-constraint> <security-role> <role-name>eap_admin</role-name> </security-role> </security-constraint>
WAR の
jboss-web.xml
にセキュリティードメインを指定します。セキュリティードメインにサーブレットを接続するため、WAR のjboss-web.xml
にセキュリティードメインを追加します。セキュリティードメインにはセキュリティー制約に対してプリンシパルを認証および承認する方法が設定されています。次の例はacme_domain
というセキュリティードメインを使用します。<jboss-web> ... <security-domain>acme_domain</security-domain> ... </jboss-web>
14.8. アプリケーションにおけるサードパーティー認証システムの使用
注記
context.xml
デプロイメント記述子には設定されないようになりました。バルブは直接 jboss-web.xml
記述子に設定されます。context.xml
は無視されるようになりました。
例14.1 基本的な認証バルブ
<jboss-web> <valve> <class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name> </valve> </jboss-web>
例14.2 ヘッダー属性セットを持つカスタムバルブ
<jboss-web> <valve> <class-name>org.jboss.web.tomcat.security.GenericHeaderAuthenticator</class-name> <param> <param-name>httpHeaderForSSOAuth</param-name> <param-value>sm_ssoid,ct-remote-user,HTTP_OBLIX_UID</param-value> </param> <param> <param-name>sessionCookieForSSOAuth</param-name> <param-value>SMSESSION,CTSESSION,ObSSOCookie</param-value> </param> </valve> </jboss-web>
独自のオーセンティケーターの作成については本書の範囲外となりますが、次の Java コードが例として提供されています。
例14.3 GenericHeaderAuthenticator.java
/* * JBoss, Home of Professional Open Source. * Copyright 2006, Red Hat Middleware LLC, and individual contributors * as indicated by the @author tags. See the copyright.txt file in the * distribution for a full listing of individual contributors. * * This is free software; you can redistribute it and/or modify it * under the terms of the GNU Lesser General Public License as * published by the Free Software Foundation; either version 2.1 of * the License, or (at your option) any later version. * * This software is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this software; if not, write to the Free * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA * 02110-1301 USA, or see the FSF site: http://www.fsf.org. */ package org.jboss.web.tomcat.security; import java.io.IOException; import java.security.Principal; import java.util.StringTokenizer; import javax.management.JMException; import javax.management.ObjectName; import javax.servlet.http.Cookie; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import org.apache.catalina.Realm; import org.apache.catalina.Session; import org.apache.catalina.authenticator.Constants; import org.apache.catalina.connector.Request; import org.apache.catalina.connector.Response; import org.apache.catalina.deploy.LoginConfig; import org.jboss.logging.Logger; import org.jboss.as.web.security.ExtendedFormAuthenticator; /** * JBAS-2283: Provide custom header based authentication support * * Header Authenticator that deals with userid from the request header Requires * two attributes configured on the Tomcat Service - one for the http header * denoting the authenticated identity and the other is the SESSION cookie * * @author <a href="mailto:Anil.Saldhana@jboss.org">Anil Saldhana</a> * @author <a href="mailto:sguilhen@redhat.com">Stefan Guilhen</a> * @version $Revision$ * @since Sep 11, 2006 */ public class GenericHeaderAuthenticator extends ExtendedFormAuthenticator { protected static Logger log = Logger .getLogger(GenericHeaderAuthenticator.class); protected boolean trace = log.isTraceEnabled(); // JBAS-4804: GenericHeaderAuthenticator injection of ssoid and // sessioncookie name. private String httpHeaderForSSOAuth = null; private String sessionCookieForSSOAuth = null; /** * <p> * Obtain the value of the <code>httpHeaderForSSOAuth</code> attribute. This * attribute is used to indicate the request header ids that have to be * checked in order to retrieve the SSO identity set by a third party * security system. * </p> * * @return a <code>String</code> containing the value of the * <code>httpHeaderForSSOAuth</code> attribute. */ public String getHttpHeaderForSSOAuth() { return httpHeaderForSSOAuth; } /** * <p> * Set the value of the <code>httpHeaderForSSOAuth</code> attribute. This * attribute is used to indicate the request header ids that have to be * checked in order to retrieve the SSO identity set by a third party * security system. * </p> * * @param httpHeaderForSSOAuth * a <code>String</code> containing the value of the * <code>httpHeaderForSSOAuth</code> attribute. */ public void setHttpHeaderForSSOAuth(String httpHeaderForSSOAuth) { this.httpHeaderForSSOAuth = httpHeaderForSSOAuth; } /** * <p> * Obtain the value of the <code>sessionCookieForSSOAuth</code> attribute. * This attribute is used to indicate the names of the SSO cookies that may * be present in the request object. * </p> * * @return a <code>String</code> containing the names (separated by a * <code>','</code>) of the SSO cookies that may have been set by a * third party security system in the request. */ public String getSessionCookieForSSOAuth() { return sessionCookieForSSOAuth; } /** * <p> * Set the value of the <code>sessionCookieForSSOAuth</code> attribute. This * attribute is used to indicate the names of the SSO cookies that may be * present in the request object. * </p> * * @param sessionCookieForSSOAuth * a <code>String</code> containing the names (separated by a * <code>','</code>) of the SSO cookies that may have been set by * a third party security system in the request. */ public void setSessionCookieForSSOAuth(String sessionCookieForSSOAuth) { this.sessionCookieForSSOAuth = sessionCookieForSSOAuth; } /** * <p> * Creates an instance of <code>GenericHeaderAuthenticator</code>. * </p> */ public GenericHeaderAuthenticator() { super(); } public boolean authenticate(Request request, HttpServletResponse response, LoginConfig config) throws IOException { log.trace("Authenticating user"); Principal principal = request.getUserPrincipal(); if (principal != null) { if (trace) log.trace("Already authenticated '" + principal.getName() + "'"); return true; } Realm realm = context.getRealm(); Session session = request.getSessionInternal(true); String username = getUserId(request); String password = getSessionCookie(request); // Check if there is sso id as well as sessionkey if (username == null || password == null) { log.trace("Username is null or password(sessionkey) is null:fallback to form auth"); return super.authenticate(request, response, config); } principal = realm.authenticate(username, password); if (principal == null) { forwardToErrorPage(request, response, config); return false; } session.setNote(Constants.SESS_USERNAME_NOTE, username); session.setNote(Constants.SESS_PASSWORD_NOTE, password); request.setUserPrincipal(principal); register(request, response, principal, HttpServletRequest.FORM_AUTH, username, password); return true; } /** * Get the username from the request header * * @param request * @return */ protected String getUserId(Request request) { String ssoid = null; // We can have a comma-separated ids String ids = ""; try { ids = this.getIdentityHeaderId(); } catch (JMException e) { if (trace) log.trace("getUserId exception", e); } if (ids == null || ids.length() == 0) throw new IllegalStateException( "Http headers configuration in tomcat service missing"); StringTokenizer st = new StringTokenizer(ids, ","); while (st.hasMoreTokens()) { ssoid = request.getHeader(st.nextToken()); if (ssoid != null) break; } if (trace) log.trace("SSOID-" + ssoid); return ssoid; } /** * Obtain the session cookie from the request * * @param request * @return */ protected String getSessionCookie(Request request) { Cookie[] cookies = request.getCookies(); log.trace("Cookies:" + cookies); int numCookies = cookies != null ? cookies.length : 0; // We can have comma-separated ids String ids = ""; try { ids = this.getSessionCookieId(); log.trace("Session Cookie Ids=" + ids); } catch (JMException e) { if (trace) log.trace("checkSessionCookie exception", e); } if (ids == null || ids.length() == 0) throw new IllegalStateException( "Session cookies configuration in tomcat service missing"); StringTokenizer st = new StringTokenizer(ids, ","); while (st.hasMoreTokens()) { String cookieToken = st.nextToken(); String val = getCookieValue(cookies, numCookies, cookieToken); if (val != null) return val; } if (trace) log.trace("Session Cookie not found"); return null; } /** * Get the configured header identity id in the tomcat service * * @return * @throws JMException */ protected String getIdentityHeaderId() throws JMException { if (this.httpHeaderForSSOAuth != null) return this.httpHeaderForSSOAuth; return (String) mserver.getAttribute(new ObjectName( "jboss.web:service=WebServer"), "HttpHeaderForSSOAuth"); } /** * Get the configured session cookie id in the tomcat service * * @return * @throws JMException */ protected String getSessionCookieId() throws JMException { if (this.sessionCookieForSSOAuth != null) return this.sessionCookieForSSOAuth; return (String) mserver.getAttribute(new ObjectName( "jboss.web:service=WebServer"), "SessionCookieForSSOAuth"); } /** * Get the value of a cookie if the name matches the token * * @param cookies * array of cookies * @param numCookies * number of cookies in the array * @param token * Key * @return value of cookie */ protected String getCookieValue(Cookie[] cookies, int numCookies, String token) { for (int i = 0; i < numCookies; i++) { Cookie cookie = cookies[i]; log.trace("Matching cookieToken:" + token + " with cookie name=" + cookie.getName()); if (token.equals(cookie.getName())) { if (trace) log.trace("Cookie-" + token + " value=" + cookie.getValue()); return cookie.getValue(); } } return null; } }
第15章 マイグレーション
15.1. アプリケーションセキュリティーの変更設定
UsersRolesLoginModule
は常にクラスパスのプロパティーファイルを検索しました。以前のバージョンの JBoss Enterprise Application Platform では、EAP_HOME/server/SERVER_NAME/conf/
ディレクトリーに置かれたプロパティーファイルはクラスパス上にあり、UsersRolesLoginModule
によって簡単に見つかりました。JBoss Enterprise Application Platform 6 ではディレクトリー構造が変更されました。プロパティーファイルをアプリケーション内でパッケージ化し、クラスパスで使用できるようにする必要があります。
重要
security-domains
下の新しいセキュリティードメインを standalone/configuration/standalone.xml
または domain/configuration/domain.xml
サーバー設定ファイルに追加します。
<security-domain name="example"> <authentication> <login-module code="UsersRoles" flag="required"> <module-option name="usersProperties" value="${jboss.server.config.dir}/example-users.properties"/> <module-option name="rolesProperties" value="${jboss.server.config.dir}/example-roles.properties"/> </login-module> </authentication> </security-domain>
${jboss.server.config.dir}
は EAP_HOME/standalone/configuration/
ディレクトリーを参照します。インスタンスが管理対象ドメインで実行されている場合、${jboss.server.config.dir}
は EAP_HOME/domain/configuration/
ディレクトリーを参照します。
JBoss Enterprise Application Platform 6 では、セキュリティードメインは名前で接頭辞 java:/jaas/
を使用しなくなりました。
- Web アプリケーションの場合は、
jboss-web.xml
のセキュリティードメイン設定からこの接頭辞を削除する必要があります。 - Enterprise アプリケーションの場合は、
jboss-ejb3.xml
ファイルのセキュリティードメイン設定からこの接頭辞を削除する必要があります。JBoss Enterprise Application Platform 6 では、jboss.xml
はこのファイルに置き換えられました。
第16章 認証および承認
16.1. 認証について
16.2. 承認について
16.3. Java Authentication and Authorization Service (JAAS)
16.4. Java Authentication and Authorization Service (JAAS) について
サーバーグループ (管理対象ドメイン内) とサーバー (スタンドアロンサーバー内) にはセキュリティードメインの設定が含まれます。セキュリティードメインには、認証、承認、マッピング、監査のモジュールの組み合わせと設定詳細に関する情報が含まれています。アプリケーションは必要なセキュリティードメインを名前で jboss-web.xml
に指定します。
アプリケーション固有の設定は次の 4 つのファイルの 1 つ以上に設定されます。
表16.1 アプリケーション固有の設定ファイル
ファイル | 説明 |
---|---|
ejb-jar.xml |
EJB の
META-INF ディレクトリにある Enterprise JavaBean (EJB) アプリケーションのデプロイメント記述子です。ejb-jar.xml を使用してロールを指定し、アプリケーションレベルでプリンシパルへマッピングします。また、特定のメソッドやクラスを特定のロールへ制限することも可能です。セキュリティーに関係しない他の EJB 固有の設定に対しても使用できます。
|
web.xml |
Java Enterprise Edition (EE) の Web アプリケーションのデプロイメント記述子です。
web.xml を使用して、認証や承認にアプリケーションが使用するセキュリティードメインを宣言します。また、許可される HTTP リクエストのタイプを制限するなど、アプリケーションのリソースやトランスポートを制約するため使用することもできます。このファイルに簡単な Web ベースの認証を設定することもできます。セキュリティーに関係しない他のアプリケーション固有の設定に使用することもできます。
|
jboss-ejb3.xml | ejb-jar.xml 記述子への JBoss 固有の拡張が含まれます。
|
jboss-web.xml | web.xml 記述子への JBoss 固有の拡張が含まれます。
|
注記
ejb-jar.xml
と web.xml
は Java Enterprise Edition (Java EE) 仕様に定義されています。jboss-ejb3.xml
は ejb-jar.xml
の JBoss 固有の拡張を提供し、jboss-web.xml
は web.xml
の JBoss 固有の拡張を提供します。
Java Authentication and Authorization Service (JAAS) はプラグ可能認証モジュール (PAM) を使用した、 Java アプリケーションのユーザーレベルのセキュリティーに対するフレームワークです。JAAS は Java ランタイム環境 (JRE) に統合されます。JBoss Enterprise Application Platform では、コンテナ側のコンポーネントは org.jboss.security.plugins.JaasSecurityManager
MBean で、AuthenticationManager
インターフェースと RealmMapping
インターフェースのデフォルト実装を提供します。
JaasSecurityManager は JAAS パッケージを使用して AuthenticationManager と RealmMapping インターフェースの動作を実装します。JaasSecurityManager へ割り当てられたセキュリティードメインに設定されたログインモジュールインスタンスを実行するとこの動作が生じます。ログインモジュールはセキュリティードメインのプリンシパルの認証やロールマッピングの挙動を実装します。ドメインの異なるログインモジュール設定を組み込むと、異なるセキュリティードメイン全体で JaasSecurityManager を使用することができます。
EJBHome
を実装するメソッドのクライアント呼び出しの概要になります。EJB は既にサーバーにデプロイされ、EJBHome
インターフェースメソッドは ejb-jar.xml
記述子の <method-permission> 要素を使用してセキュアな状態になっています。jboss-ejb3.xml
ファイルの <security-domain> 要素に指定される jwdomain
セキュリティードメインを使用します。以下の図は後で説明する手順を表しています。

図16.1 保護された EJB メソッド呼び出しの手順
- クライアントが JAAS のログインを実行し、認証のプリンシパルと認証情報を確立します。上図では Client Side Login とラベル付けされます。JNDI より実行することも可能です。JAAS ログインを実行するには、LoginContext インスタンスを作成し、使用する設定の名前を渡します。ここでの設定名は
other
になります。このワンタイムログインは、ログインプリンシパルと認証情報を後続の EJB メソッド呼び出しすべてへ関連付けます。プロセスがユーザーを認証するとは限りません。クライアント側のログインの性質は、クライアントが使用するログインモジュール設定によって異なります。この例では、other
というクライアント側ログイン設定エントリーがClientLoginModule
ログインモジュールを使用します。サーバー上で後で認証が行われるため、このモジュールはユーザー名とパスワードを EJB 呼び出しレイヤーへバインドします。クライアントのアイデンティティーはクライアント上で認証されません。 - クライアントは
EJBHome
メソッドを取得し、このメソッドをサーバー上で呼び出します。呼び出しにはクライアントによって渡されたメソッド引数や、クライアント側 JAAS ログインからのユーザー ID や認証情報が含まれます。 - サーバー上では、セキュリティーインターセプターがメソッドを呼び出したユーザーを認証します。これには別の JAAS ログインが関係します。
- セキュリティードメインはログインモジュールの選択を決定します。セキュリティードメインの名前はログイン設定エントリー名として
LoginContext
コンストラクターへ渡されます。EJB セキュリティードメインはjwdomain
です。JAAS 認証に成功すると、JAAS サブジェクトが作成されます。JAAS サブジェクトには次の詳細を含む PrincipalSet が含まれます。- デプロイメントセキュリティー環境よりクライアントアイデンティティーへ対応する
java.security.Principal
インスタンス。 - ユーザーのアプリケーションドメインからのロール名が含まれる
Roles
と呼ばれるjava.security.acl.Group
。org.jboss.security.SimplePrincipal
タイプのオブジェクトはロール名を表します。これらのロールは、ejb-jar.xml
とEJBContext.isCallerInRole(String)
メソッド実装の制約に従って EJB メソッドへのアクセスを検証します。 - アプリケーションドメインの呼び出し側のアイデンティティーに対応する 1 つの
org.jboss.security.SimplePrincipal
が含まれるCallerPrincipal
という名前の任意のjava.security.acl.Group
。CallerPrincipal グループメンバーはEJBContext.getCallerPrincipal()
メソッドによって返される値です。このマッピングは、運用セキュリティー環境のプリンシパルがアプリケーションが認識するプリンシパルへマッピングできるようにします。CallerPrincipal マッピングが存在しない場合、運用プリンシパルはアプリケーションドメインプリンシパルと同じになります。
- EJB メソッドを呼び出しているユーザーは呼び出しが許可されているユーザーであることをサーバーが検証します。次の手順でこの承認を実行します。
- EJB コンテナから EJBメソッドへアクセスすることが許可されるロールの名前を取得します。呼び出されたメソッドが含まれるすべての <method-permission> 要素の
ejb-jar.xml
記述子 <role-name> 要素によってロール名が判断されます。 - 割り当てられたロールがなかったり、メソッドが exclude-list 要素に指定されている場合、メソッドへのアクセスは拒否されます。それ以外の場合は、セキュリティーインターセプターによってセキュリティーマネージャー上で
doesUserHaveRole
メソッドが呼び出され、呼び出し側に割り当てられたロール名の 1 つがあるかどうかを確認します。このメソッドはロール名より繰り返され、認証されたユーザーのSubject Roles
グループに割り当てられたロール名を持つ SimplePrincipal が含まれるか確認します。Roles グループメンバーのロール名がある場合はアクセスが許可されます。メンバーのロール名がない場合はアクセスが拒否されます。 - EJB がカスタムのセキュリティープロキシを使用する場合、メソッドの呼び出しはプロキシへ委譲されます。セキュリティープロキシが呼び出し側へのアクセスを拒否すると、
java.lang.SecurityException
がスローされます。それ以外の場合は EJB メソッドへのアクセスは許可され、メソッド呼び出しは次のコンテナインターセプターへ渡されます。SecurityProxyInterceptor はこのチェックを処理し、このインターセプターは表示されません。 - Web 接続要求の場合、
web.xml
で定義され、要求されたリソースとアクセスされた HTTP メソッドに一致するセキュリティー制約を Web サーバーがチェックします。要求に対して制約が存在する場合、Web サーバーは JaasSecurityManager を呼び出し、プリンシパルの認証を行います。これにより、確実にユーザーロールがプリンシパルオブジェクトへ関連付けられているようにします。
16.5. JACC (Java Authorization Contract for Containers)
16.5.1. JACC (Java Authorization Contract for Containers) について
16.5.2. JACC (Java Authorization Contract for Containers) のセキュリティーの設定
jboss-web.xml
を編集する必要があります。
セキュリティードメインに JACC サポートを追加するには、required
フラグセットで JACC
承認ポリシーをセキュリティードメインの承認スタックへ追加します。以下は JACC サポートを持つセキュリティードメインの例になりますが、セキュリティードメインは 直接 XML には設定されず、管理コンソールまたは管理 CLI で設定されます。
<security-domain name="jacc" cache-type="default"> <authentication> <login-module code="UsersRoles" flag="required"> </login-module> </authentication> <authorization> <policy-module code="JACC" flag="required"/> </authorization> </security-domain>
jboss-web.xml
は デプロイメントの META-INF/
または WEB-INF/
ディレクトリに存在し、Web コンテナに対する追加の JBoss 固有の設定を格納し、上書きします。JACC が有効になっているセキュリティードメインを使用するには、<security-domain>
要素が含まれるようにし、 さらに <use-jboss-authorization>
要素を true
に設定する必要があります。以下は、上記の JACC セキュリティードメインを使用するよう適切に設定されているアプリケーションになります。
<jboss-web> <security-domain>jacc</security-domain> <use-jboss-authorization>true</use-jboss-authorization> </jboss-web>
セキュリティードメインと JACC を使用するよう EJB を設定する方法は Web アプリケーションの場合とは異なります。EJB の場合、ejb-jar.xml
記述子にてメソッドまたはメソッドのグループ上でメソッドパーミッションを宣言できます。<ejb-jar>
要素内では、すべての子 <method-permission>
要素に JACC ロールに関する情報が含まれます。詳細は設定例を参照してください。EJBMethodPermission
クラスは Java Enterprise Edition 6 API の一部で、http://docs.oracle.com/javaee/6/api/javax/security/jacc/EJBMethodPermission.html で説明されています。
例16.1 EJB の JACC メソッドパーミッション例
<ejb-jar> <method-permission> <description>The employee and temp-employee roles may access any method of the EmployeeService bean </description> <role-name>employee</role-name> <role-name>temp-employee</role-name> <method> <ejb-name>EmployeeService</ejb-name> <method-name>*</method-name> </method> </method-permission> </ejb-jar>
<security>
子要素の jboss-ejb3.xml
記述子に宣言されます。セキュリティードメインの他に、EJB が実行されるプリンシパルを変更する run-as プリンシパル を指定することもできます。
例16.2 EJB におけるセキュリティードメイン宣言の例
<security> <ejb-name>*</ejb-name> <security-domain>myDomain</s:security-domain> <run-as-principal>myPrincipal</s:run-as-principal> </s:security>
16.6. JASPI (Java Authentication SPI for Containers)
16.6.1. JASPI (Java Authentication SPI for Containers) のセキュリティーについて
16.6.2. JASPI (Java Authentication SPI for Containers) のセキュリティーの設定
<authentication-jaspi>
要素をセキュリティードメインに追加します。設定は標準的な認証モジュールと似ていますが、ログインモジュール要素は <login-module-stack>
要素で囲まれています。設定の構成は次のとおりです。
例16.3 authentication-jaspi
要素の構成
<authentication-jaspi> <login-module-stack name="..."> <login-module code="..." flag="..."> <module-option name="..." value="..."/> </login-module> </login-module-stack> <auth-module code="..." login-module-stack-ref="..."> <module-option name="..." value="..."/> </auth-module> </authentication-jaspi>
EAP_HOME/domain/configuration/domain.xml
または EAP_HOME/standalone/configuration/standalone.xml
へ直接追加する必要があります。
付録A 参考資料
A.1. 含まれる認証モジュール
Role
という単語が Code
名に含まれます。
Code
値またはフルネーム (パッケージ修飾) 使用します。
認証モジュール
表A.1 Client
コード | Client
|
クラス | org.jboss.security.ClientLoginModule
|
説明 |
このログインモジュールは、JBoss Enterprise Application Platform がクライアントとして動作するときに呼び出し元 ID とクレデンシャルを確立するよう設定されています。これは、実際のサーバー認証に使用されるセキュリティードメインの一部として使用しないでください。
|
表A.2 クライアントモジュールオプション
オプション | タイプ | デフォルト | 説明 |
---|---|---|---|
multi-threaded | true または false
| false
|
各スレッドが独自のプリンシパルとクレデンシャルストレージを持つ場合は、true に設定します。VM 内のすべてのスレッドが同じ ID とクレデンシャルを共有するよう指定する場合は false に設定します。
|
password-stacking
| useFirstPass または false
| false
|
このログインモジュールが ID として使用する LoginContext に格納された情報を探すよう指定する場合は、useFirstPass に設定します。このオプションは、他のログインモジュールをスタックする場合に使用できます。
|
>restore-login-identity
| true または false
| false
|
() メソッドの先頭に示された ID とクレデンシャルを logout() メソッドの呼び出し後に復元する必要がある場合は true に設定します。
|
表A.3 Certificate
コード | Certificate
|
クラス | org.jboss.security.auth.spi.BaseCertLoginModule
|
説明 |
このログインモジュールは、
X509 Certificates に基づいてユーザーを認証するよう設計されています。この使用例は、Web アプリケーションの CLIENT-CERT 認証です。
|
表A.4 Certificate
モジュールオプション
オプション | タイプ | デフォルト | 説明 |
---|---|---|---|
securityDomain
| 文字列 |
なし
|
信頼済み証明書を保持するトラストストア用 JSSE 設定を持つセキュリティードメインの名前。
|
verifier
| クラス |
なし
|
ログイン証明書の検証に使用する
org.jboss.security.auth.certs.X509CertificateVerifier のクラス名。
|
表A.5 CertificateUsers
コード | CertificateUsers
|
クラス | org.jboss.security.auth.spi.UsersRolesLoginModule
|
説明 |
プロパティーリソースを使用します。最初のコードがユーザー名をパスワードにマッピングし、次のコードがユーザー名をロールにマッピングします。
|
表A.6 CertificateUsers
モジュールオプション
オプション | タイプ | デフォルト | 説明 |
---|---|---|---|
unauthenticatedIdentity
| 文字列 |
なし
|
認証情報を含まない要求に割り当てる必要があるプリンシパル名を定義します。これにより、保護されていないサーブレットは特定のロールを必要としない EJB でメソッドを呼び出すことができるようになります。このようなプリンシパルでは、ロールが割り当てられず、
unchecked permission 制約に関連付けられたセキュアでない EJB または EJB メソッドにのみアクセスできます。
|
password-stacking
| useFirstPass または false
| false
|
このログインモジュールが ID として使用する
LoginContext に格納された情報を探すよう指定する場合は、useFirstPass に設定します。このオプションは、他のログインモジュールをスタックする場合に使用できます。
|
hashAlgorithm | 文字列 |
なし
|
パスワードをハッシュ化するために使用する
java.security.MessageDigest アルゴリズムの名前。デフォルト値はないため、ハッシュを有効にするためにこのオプションを明示的に設定する必要があります。hashAlgorithm が指定された場合は、inputPassword 引数として UsernamePasswordLoginModule.validatePassword に渡す前に CallbackHandler から取得されたクリアテキストパスワードがハッシュ化されます。users.properties ファイルに格納された expectedPassword も、同様にハッシュ化する必要があります。java.security.MessageDigest およびこのクラスがサポートするアルゴリズムの詳細は http://docs.oracle.com/javase/6/docs/api/java/security/MessageDigest.html を参照してください。
|
hashEncoding
| base64 または hex
| base64
| hashAlgorithm も設定されている場合、ハッシュ化されたパスワードの文字列形式。
|
hashCharSet
| 文字列 |
コンテナの環境で設定されたデフォルトのエンコーディング。
|
クリアテキストのパスワードをバイトアレイに変換するために使用されるエンコーディング。
|
usersProperties
|
プロパティーファイルまたはリソースの完全修飾ファイルパスまたは完全修飾ファイル名。
| users.properties
|
ユーザーとパスワード間のマッピングが含まれるファイル。ファイルの各プロパティーの形式は
username=password です。
|
rolesProperties
| プロパティーファイルまたはリソースの完全修飾ファイルパスまたは完全修飾ファイル名。 | roles.properties
|
ユーザーとロール間のマッピングを含むファイル。ファイルの各プロパティーの形式は
username=role1,role2,...,roleN です。
|
ignorePasswordCase
| true または false
| false
|
パスワード比較で大文字と小文字の区別を無視するかどうか。これは、ハッシュ化されたパスワードが大文字であるか小文字であるかが重要でない、ハッシュ化パスワードエンコーディングの場合に役に立ちます。
|
principalClass
| 完全修飾クラス名 |
なし
|
プリンシパル名として String 引数を取るコンストラクターを含む
Principal 実装クラス。
|
roleGroupSeparator
|
単一の文字
| . (ピリオド 1 つ)
| rolesGroup ファイルでユーザー名とロールグループ名を区別するために使用される文字。
|
defaultUsersProperties
| 文字列 | defaultUsers.properties
|
usersProperties ファイルが見つからない場合に使用するリソースまたはファイルの名前。
|
defaultRolesProperties
| 文字列 | defaultRoles.properties
| rolesProperties ファイルが見つからない場合に使用するリソースまたはファイルの名前。
|
hashUserPassword
| true または false
| true
| hashAlgorithm が指定された場合にユーザーが入力したパスワードをハッシュ化するかどうか。デフォルト値は true です。
|
hashStorePassword
| true または false
| true
| hashAlgorithm が指定された場合に getUsersPassword() から返されたストアパスワードをハッシュ化するかどうか。
|
digestCallback
| 完全修飾クラス名 |
なし
|
ソルト値などのプレまたはポストダイジェストコンテンツを含む
org.jboss.crypto.digest.DigestCallback 実装のクラス名。hashAlgorithm が指定された場合にのみ使用されます。
|
storeDigestCallback
| 完全修飾クラス名 |
なし
|
ストアパスワードをハッシュ化するソルト値などのプレまたはポストダイジェストコンテンツを含む
org.jboss.crypto.digest.DigestCallback 実装のクラス名。hashStorePassword が true であり、hashAlgorithm が指定された場合にのみ使用されます。
|
callback.option.STRING
| 各種 | なし | callback.option. の前に指定されたすべてのオプションは、DigestCallback.init(Map) メソッドに渡されます。入力されたユーザー名は、常に javax.security.auth.login.name オプションを介して渡され、入力/ストアパスワードは、javax.security.auth.login.password オプションを介して digestCallback または storeDigestCallback に渡されます。
|
表A.7 CertificateRoles
コード | CertificateRoles
|
クラス | org.jboss.security.auth.spi.CertRolesLoginModule
|
説明 |
このログインモジュールは、Certificate ログインモジュールを拡張して、プロパティーファイルからロールマッピング機能を追加します。同じすべてのオプションを Certificate ログインモジュールとして取得し、次のオプションを追加します。
|
表A.8 CertificateRoles
モジュールオプション
オプション | タイプ | デフォルト | 説明 |
---|---|---|---|
rolesProperties
| 文字列 | roles.properties
|
各ユーザーに割り当てるロールを含むリソースまたはファイルの名前。ロールプロパティーファイルの形式は username=role1,role2 である必要があります。username は証明書の DN で、
= (等記号) やスペース文字をすべてエスケープします。正しい形式を用いた例は次のとおりです。
CN\=unit-tests-client,\ OU\=Red\ Hat\ Inc.,\ O\=Red\ Hat\ Inc.,\ ST\=North\ Carolina,\ C\=US=JBossAdmin |
defaultRolesProperties
| 文字列 | defaultRoles.properties
| rolesProperties ファイルが見つからない場合に使用するリソースまたはファイルの名前。
|
roleGroupSeparator
| 単一の文字 | . (ピリオド 1 つ)
| roleProperties ファイルでどの文字をロールグループセパレーターとして使用するか。
|
表A.9 Database
コード | Database |
クラス | org.jboss.security.auth.spi.DatabaseServerLoginModule
|
説明 |
認証とロールマッピングをサポートする JDBC ベースのログインモジュール。これは、次の定義を使用して、2 つの論理テーブルに基づきます。
|
表A.10 Database
モジュールオプション
オプション | タイプ | デフォルト | 説明 |
---|---|---|---|
dsJndiName
| JNDI リソース |
なし
|
認証情報を保持する JNDI リソースの名前。このオプションは必須です。
|
principalsQuery
| 準備済み SQL ステートメント | select Password from Principals where PrincipalID=?
|
プリンシパルに関する情報を取得するための準備済み SQL クエリー。
|
rolesQuery
| 準備済み SQL ステートメント | select Role, RoleGroup from Roles where PrincipalID=?
|
ロールの情報を取得するための準備済み SQL クエリー。
select Role, RoleGroup from Roles where PrincipalID=? と同等である必要があります。ここで、Role はロール名で、RoleGroup 列の値は常に R が大文字である Roles または CallerPrincipal である必要があります。
|
表A.11 DatabaseCertificate
コード | DatabaseCertificate
|
クラス | org.jboss.security.auth.spi.DatabaseCertLoginModule
|
説明 |
このログインモジュールは、Certificate ログインモジュールを拡張して、データベーステーブルからロールマッピング機能を追加します。同じオプションと次の追加オプションが存在します。
|
表A.12 DatabaseCertificate
モジュールオプション
オプション | タイプ | デフォルト | 説明 |
---|---|---|---|
dsJndiName
| JNDI リソース |
|
認証情報を保持する JNDI リソースの名前。このオプションは必須です。
|
rolesQuery
| 準備済み SQL ステートメント | select Role,RoleGroup from Roles where PrincipalID=?
|
ロールをマップするために実行される SQL 準備済みステートメント。これは、
select Role, RoleGroup from Roles where PrincipalID=? と同等である必要があります。Role はロール名で、RoleGroup 列の値は常に R が大文字である Roles または CallerPrincipal である必要があります。
|
suspendResume
| true または false
| true
|
データベース操作中に既存の JTA トランザクションを一時停止するかどうか。
|
表A.13 Identity
コード | Identity
|
クラス | org.jboss.security.auth.spi.IdentityLoginModule
|
説明 |
モジュールオプションで指定されたプリンシパルをモジュールに対して認証されたサブジェクトと関連付けます。使用される Principal クラスのタイプは
org.jboss.security.SimplePrincipal. です。プリンシパルオプションが指定されない場合は、名前が guest のプリンシパルが使用されます。
|
表A.14 Identity
モジュールオプション
オプション | タイプ | デフォルト | 説明 |
---|---|---|---|
principal
| 文字列 | guest
|
プリンシパルに使用する名前。
|
roles
| 文字列のカンマ区切りリスト |
なし
|
サブジェクトに割り当てられるロールのカンマ区切りリスト。
|
表A.15 Ldap
コード | Ldap
|
クラス | org.jboss.security.auth.spi.LdapLoginModule
|
説明 |
ユーザー名とパスワードが、JNDI LDAP プロバイダーを使用してアクセスできる LDAP サーバーに格納された場合に、LDAP サーバーに対して認証します。多くのオプションは、LDAP プロバイダーまたは環境によって決定されるため、必須ではありません。
|
表A.16 Ldap
モジュールオプション
オプション | タイプ | デフォルト | 説明 |
---|---|---|---|
java.naming.factory.initial
| クラス名 | com.sun.jndi.ldap.LdapCtxFactory
| InitialContextFactory 実装クラス名。
|
java.naming.provider.url
| ldap:// URL
|
なし
|
LDAP サーバーの URL。
|
java.naming.security.authentication
| none 、simple 、または SASL メカニズムの名前。
| simple
|
LDAP サーバーにバインドするために使用するセキュリティーレベル。
|
java.naming.security.protocol
| トランスポートプロトコル |
指定されない場合は、プロバイダーによって決定されます。
|
SSL などの、セキュアアクセスに使用するトランスポートプロトコル。
|
java.naming.security.principal
| 文字列 |
なし
|
サービスに対する呼び出し元を認証するプリンシパルの名前。これは、以下に示された他のプロパティーから構築されます。
|
java.naming.security.credentials
| クレデンシャルタイプ |
なし
|
認証スキームにより使用されるクレデンシャルのタイプ。一部の例には、ハッシュ化されたパスワード、クリアテキストパスワード、キー、または証明書が含まれます。このプロパティーが指定されない場合は、動作がサービスプロバイダーにより決定されます。
|
principalDNPrefix
| 文字列 |
なし
|
ユーザー DN を形成するユーザー名に追加されるプレフィックス。ユーザーにユーザー名の指定を要求したり、
principalDNPrefix および principalDNSuffix を使用して完全修飾 DN を構築したりできます。
|
principalDNSuffix
| 文字列 |
|
ユーザー DN を形成するユーザー名に追加されるサフィックス。ユーザーにユーザー名の指定を要求したり、
principalDNPrefix および principalDNSuffix を使用して完全修飾 DN を構築したりできます。
|
useObjectCredential
| true または false
|
false
|
JAAS PasswordCallback を使用した char[] パスワードではなく Callback の
org.jboss.security.auth.callback.ObjectCallback タイプを使用した不透明なオブジェクトとしてクレデンシャルを取得するかどうか。これにより、non-char[] クレデンシャル情報を LDAP サーバーに渡すことができるようになります。
|
rolesCtxDN
| 完全修飾 DN |
なし
|
ユーザーロールを検索するコンテキストの完全修飾 DN。
|
userRolesCtxDNAttributeName
|
属性
|
なし
|
ユーザーロールを検索するコンテキストの DN を含むユーザーオブジェクトの属性。これは、
rolesCtxDN と異なるため、ユーザーのロールを検索するコンテキストは各ユーザーに対して一意になることがあります。
|
rolesAttributeID
| 属性 | roles
|
ユーザーロールを含む属性の名前。
|
rolesAttributeIsDN
| true または false
| false
| roleAttributeID にロールオブジェクトの完全修飾 DN が含まれるかどうか。false の場合は、コンテキスト名の roleNameAttributeId 属性の値からロール名が取得されます。Microsoft Active Directory などの特定のディレクトリースキーマでは、この属性を true に設定する必要があります。
|
rolesNameAttributeID
| 属性 | group
|
ロール名を含む
roleCtxDN コンテキスト内の属性の名前。roleAttributeIsDN プロパティーが true に設定された場合、このプロパティーはロールオブジェクトの名前属性を見つけるために使用されます。
|
uidAttributeID
| 属性 | uid
|
ユーザー ID に対応する
UserRolesAttributeDN の属性の名前。これは、ユーザーロールを見つけるために使用されます。
|
matchOnUserDN
| true または false
| false
|
ユーザーロールの検索でユーザーの完全識別 DN またはユーザー名のみに一致するかどうか。
true の場合、完全 userDN は一致する値として使用されます。false の場合は、ユーザー名のみが uidAttributeName 属性に対して一致する値として使用されます。
|
allowEmptyPasswords
| true または false
| true
|
空白のパスワードを許可するかどうか。ほとんどの LDAP サーバーでは、空白のパスワードが匿名ログイン試行として扱われます。空のパスワードを拒否するには、これを false に設定します。
|
表A.17 LdapExtended
コード | LdapExtended
|
クラス | org.jboss.security.auth.spi.LdapExtLoginModule
|
説明 |
検索を使用してバインドユーザーと関連するロールを見つける別の LDAP ログインモジュール実装。ロールクエリーは再帰的に DN に従い、階層ロール構造をナビゲートします。同じ
java.naming オプションを Ldap モジュールとして使用し、Ldap モジュールの他のオプションの代わりに次のオプションを使用します。
認証は 2 つの手順で行われます。
|
表A.18 LdapExtended
モジュールオプション
オプション | タイプ | デフォルト | 説明 |
---|---|---|---|
baseCtxDN
| 完全修飾 DN |
なし
|
ユーザー検索を開始する最上位コンテキストの固定 DN。
|
bindDN
| 完全修飾 DN |
なし
|
ユーザーおよびロールクエリーのために LDAP サーバーに対してバインドするために使用される DN。この DN は
baseCtxDN および rolesCtxDN の値に対する読み取りおよび検索パーミッションを必要とします。
|
bindCredential
| 文字列、オプションで暗号化 |
なし
| bindDN のパスワード。これは、jaasSecurityDomain が指定された場合に暗号化できます。
|
jaasSecurityDomain
| JMX ObjectName |
なし
| bindCredential を暗号化するために使用する JaasSecurityDomain の JMX ObjectName 。パスワードの暗号化形式は、JaasSecurityDomain.encrypt64(byte[]) メソッドにより返された形式です。
|
baseFilter
| LDAP フィルター文字列 |
なし
|
認証するユーザーのコンテキストを見つけるために使用される検索フィルター。入力ユーザー名またはログインモジュールコールバックから取得された userDN が、
{0} 式が使用されたフィルターに置換されます。検索フィルターの一般的な例は (uid={0}) です。
|
rolesCtxDN
| 完全修飾 DN |
なし
|
ユーザーロールを検索するコンテキストの固定 DN。これは、実際のロールが存在する DN ではなく、ユーザーロールを含むオブジェクトが存在する DN です。たとえば、Microsoft Active Directory サーバーでは、これは、ユーザーアカウントが存在する DN です。
|
roleFilter
| LDAP フィルター文字列 |
|
認証済みユーザーと関連付けられたロールを検索するために使用される検索フィルター。入力ユーザー名またはログインモジュールコールバックから取得された userDN が
{0} 式が使用されたフィルターに置換されます。認証済み userDN は、{1} が使用されたフィルターに置換されます。入力ユーザー名に一致する検索フィルター例は、(member={0}) です。認証済み userDN に一致する他の例は (member={1}) です。
|
roleAttributeIsDN | true または false
| false
| roleAttributeID にロールオブジェクトの完全修飾 DN が含まれるかどうか。false の場合は、コンテキスト名の roleNameAttributeId 属性の値からロール名が取得されます。Microsoft Active Directory などの特定のディレクトリースキーマでは、この属性を true に設定する必要があります。
|
defaultRole
|
ロール名
|
なし
|
認証された全ユーザーに対して含まれるロール
|
parseRoleNameFromDN
| true または false
| false
|
クエリによって返された DN に roleNameAttributeID が含まれるかどうかを示すフラグ。
true に設定された場合、DN は roleNameATtributeID に対してチェックされます。false に設定された場合、DN は roleNameATtributeID に対してチェックされません。このフラグは LDAP クエリのパフォーマンスを向上できます。
|
parseUsername
| true または false
| false
|
DN がユーザー名に対して解析されるかどうかを示すフラグ。
true に設定された場合、 DN はユーザー名に対して解析されます。false に設定された場合、 DN はユーザー名に対して解析されません。このオプションは usernameBeginString および usernameEndString と共に使用されます。
|
usernameBeginString
|
文字列
|
なし
|
ユーザー名を公開するため、DN の最初から削除される文字列を定義します。このオプションは
usernameEndString と共に使用されます。
|
usernameEndString
|
文字列
|
なし
|
ユーザー名を公開するため、DN の最後から削除される文字列を定義します。このオプションは
usernameBeginString と共に使用されます。
|
roleNameAttributeID
| 属性 | group
|
ロール名を含む
roleCtxDN コンテキスト内の属性の名前。roleAttributeIsDN プロパティーが true に設定された場合、このプロパティーはロールオブジェクトの名前属性を見つけるために使用されます。
|
distinguishedNameAttribute
| 属性 | distinguishedName
|
ユーザーの DN を含むユーザーエントリーの属性の名前。これは、ユーザー自身の DN に正しいユーザーマッピングを防ぐ特殊文字 (バックスラッシュなど) が含まれる場合に、必要になることがあります。属性が存在しない場合は、エントリーの DN が使用されます。
|
roleRecursion
| 整数 | 0
|
ロール検索が一致するコンテキストで行われる再帰のレベル数。再帰を無効にするには、これを
0 に設定します。
|
searchTimeLimit
| 整数 | 10000 (10 秒)
|
ユーザーまたはロール検索のタイムアウト (ミリ秒単位)。
|
searchScope
| OBJECT_SCOPE, ONELEVEL_SCOPE, SUBTREE_SCOPE のいずれか。
| SUBTREE_SCOPE
|
使用する検索範囲。
|
allowEmptyPasswords
| true または false
| true
|
空白のパスワードを許可するかどうか。ほとんどの LDAP サーバーでは、空白のパスワードが匿名ログイン試行として扱われます。空のパスワードを拒否するには、これを false に設定します。
|
表A.19 RoleMapping
コード | RoleMapping
|
クラス | org.jboss.security.auth.spi.RoleMappingLoginModule
|
説明 |
認証プロセスの結果であるロールを宣言ロールに対してマップします。このモジュールは、セキュリティードメインに追加する場合に
optional とフラグ付けする必要があります。
|
表A.20 RoleMapping
モジュールオプション
オプション | タイプ | デフォルト | 説明 |
---|---|---|---|
rolesProperties
| プロパティーファイルまたはリソースの完全修飾ファイルパスまたは完全修飾ファイル名。 | roles.properties
|
ロールを置換ロールに対してマップするプロパティーファイルまたはリソースの完全修飾ファイルパスまたはファイル名。形式は
original_role=role1,role2,role3 になります。
|
replaceRole
| true または false
| false
|
現在のロールを追加するか、現在のロールをマップされたロールに置き換えるか。
true に設定された場合は、置き換えられます。
|
表A.21 RunAs
コード | RunAs
|
クラス | Class: org.jboss.security.auth.spi.RunAsLoginModule
|
説明 | run as ロールを、認証のログイン段階の間スタックにプッシュし、コミットまたはアボート段階でスタックから run as ロールをポップするヘルパーモジュール。このログインモジュールは、セキュアな EJB にアクセスするログインモジュールなどの、認証を実行するためにセキュアなリソースにアクセスする必要がある他のログインモジュール用ロールを提供します。run as ロールを確立する必要があるログインモジュールの前に、RunAsLoginModule を設定する必要があります。
|
表A.22 RunAs
オプション
オプション | タイプ | デフォルト | 説明 |
---|---|---|---|
roleName
| ロール名。 | nobody
|
ログイン段階で
run as ロールとして使用するロールの名前。
|
表A.23 Simple
コード | Simple
|
クラス | org.jboss.security.auth.spi.SimpleServerLoginModule
|
説明 |
テスト目的でセキュリティーを素早くセットアップするモジュール。次の単純なアルゴリズムが実装されます。
|
Simple
モジュールオプション
Simple
モジュールにはオプションがありません。
表A.24 ConfiguredIdentity
コード | ConfiguredIdentity
|
クラス | org.picketbox.datasource.security.ConfiguredIdentityLoginModule
|
説明 |
モジュールオプションで指定されたプリンシパルをモジュールに対して認証されたサブジェクトに関連付けます。使用される Principal クラスのタイプは
org.jboss.security.SimplePrincipal です。
|
表A.25 ConfiguredIdentity
モジュールオプション
オプション | タイプ | デフォルト | 説明 |
---|---|---|---|
principal
| プリンシパルの名前。 | guest
|
モジュールに対して認証されるサブジェクトに関連付けられるプリンシパル。
|
表A.26 SecureIdentity
コード | SecureIdentity
|
クラス | org.picketbox.datasource.security.SecureIdentityLoginModule
|
説明 |
このモジュールは、レガシー対応のために提供されます。このモジュールを使用すると、パスワードを暗号化し、暗号化されたパスワードを最適なプリンシパルで使用します。アプリケーションが
SecureIdentity を使用する場合は、パスワード vault メカニズムを代わりに使用することを検討してください。
|
表A.27 SecureIdentity
モジュールオプション
オプション | タイプ | デフォルト | 説明 |
---|---|---|---|
username
| 文字列 | なし | 認証のユーザー名 |
password
| 暗号化文字列 | なし |
認証に使用するパスワード。パスワードを暗号化するには、コマンドラインで直接モジュールを使用します。
このコマンドの結果をモジュールオプションの値フィールドに貼り付けます。
|
managedConnectionFactoryName
| JCA リソース | なし |
データソースの JCA 接続ファクトリーの名前。
|
表A.28 PropertiesUsers
コード | PropertiesUsers
|
クラス | org.jboss.security.auth.spi.PropertiesUsersLoginModule
|
説明 |
認証用ユーザー名およびパスワードを格納するプロパティーファイルを使用します。認証 (ロールマッピング) は提供されません。このモジュールは、テスト向けのみに限定されます。
|
表A.29 PropertiesUsers
モジュールオプション
オプション | タイプ | デフォルト | 説明 |
---|---|---|---|
properties
| Java プロパティーファイルまたはリソースの完全修飾ファイルパスまたは完全修飾ファイル名。 | なし |
認証に使用するユーザー名とクリアテキストパスワードを含むプロパティーファイル。
|
表A.30 SimpleUsers
コード | SimpleUsers
|
クラス | org.jboss.security.auth.spi.SimpleUsersLoginModule
|
説明 |
このログインモジュールは、ユーザー名とクリアテキストパスワードを Java プロパティーファイルに格納します。これは、テスト用に提供され、本番稼働環境には適しません。
|
表A.31 SimpleUsers
モジュールオプション
オプション | タイプ | デフォルト | 説明 |
---|---|---|---|
username
| 文字列 | なし | 認証に使用するユーザー名。 |
password
| 文字列 | なし | 認証に使用するクリアテキストパスワード。 |
表A.32 LdapUsers
コード | LdapUsers
|
クラス | org.jboss.security.auth.spi.LdapUsersLoginModule
|
説明 | LdapUsers モジュールは ExtendedLDAP および AdvancedLdap モジュールが導入されたため廃止になりました。
|
表A.33 Kerberos
コード | Kerberos
|
クラス | com.sun.security.auth.module.Krb5LoginModule
|
説明 |
GSSAPI を使用して Kerberos ログイン認証を実行します。このモジュールは、Sun Microsystems により提供された API のセキュリティーフレームワークの一部です。詳細については、http://docs.oracle.com/javase/1.4.2/docs/guide/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html を参照してください。このモジュールは、認証とロールのマッピングを処理する別のモジュールと組み合わせる必要があります。
|
表A.34 Kerberos
モジュールオプション
オプション | タイプ | デフォルト | 説明 |
---|---|---|---|
storekey
| true または false
| false | KerberosKey をサブジェクトのプライベートクレデンシャルに追加するかどうか。
|
doNotPrompt
| true または false
| false | true に設定された場合、ユーザーはパスワードを要求されません。
|
useTicketCache
| true または false のブール値
| false | true の場合、GTG はチケットキャッシュから取得されます。false の場合、チケットキャッシュは使用されません。
|
ticketcache
| Kerberos チケットキャッシュを表すファイルまたはリソース。 |
デフォルトは使用するオペレーティングシステムによって異なります。
| チケットキャッシュの場所。 |
useKeyTab
| true または false
| false | キーテーブルファイルからプリンシパルのキーを取得するかどうか。 |
keytab
| Kerberos keytab を表すファイルまたはリソース。 |
オペレーティングシステムの Kerberos 設定ファイルの場所または
/home/user/krb5.keytab
| キーテーブルファイルの場所。 |
principal
| 文字列 | なし |
プリンシパルの名前。これは、
host/testserver.acme.com などの単純なユーザー名またはサービス名のいずれかになります。これは、キーテーブルからプリンシパルを取得する代わり、またはキーテーブルに複数のプリンシパルが含まれる場合に使用します。
|
useFirstPass
| true または false
| false | javax.security.auth.login.name および javax.security.auth.login.password をキーとして使用して、モジュールの共有状態からユーザー名とパスワードを取得するかどうか。認証が失敗した場合、再試行は行われません。
|
tryFirstPass
| true または false
| false | useFirstPass と同じです。ただし、認証が失敗した場合、モジュールは CallbackHandler を使用して新しいユーザー名とパスワードを取得します。2 番目の認証が失敗した場合、失敗は読み出し元アプリケーションに報告されます。
|
storePass
| true または false
| false |
モジュールの共有状態でユーザー名とパスワードを格納するかどうか。これは、キーが共有状態にすでにある場合、または認証に失敗した場合は、行われません。
|
clearPass
| true または false
| false |
これを
true に設定して、認証段階が完了した後に供給状態からユーザー名とパスワードを削除します。
|
表A.35 SPNEGOUsers
コード | SPNEGOUsers
|
クラス | org.jboss.security.negotiation.spnego.SPNEGOLoginModule
|
説明 |
Microsoft Active Directory サーバーまたは SPNEGO をサポートする他の環境に対して SPNEGO 認証を許可します。SPNEGO は Kerberos クレデンシャルを持つこともできます。このモジュールは、認証とロールのマッピングを処理する別のモジュールと組み合わせる必要があります。
|
表A.36 SPNEGO
モジュールオプション
オプション | タイプ | デフォルト | 説明 |
---|---|---|---|
storeKey
| true または false
| false
|
キーを格納するかどうか。
|
useKeyTab
| true または false
| false
|
キーテーブルを使用するかどうか。
|
principal
|
Kerberos 認証のプリンシパルを表す文字列
|
なし
|
認証のプリンシパルの名前。
|
keyTab
|
キーテーブルを表すファイルまたはリソース。
| none
|
キーテーブルの場所。
|
doNotPrompt
| true または false
| false
|
パスワードを要求するかどうか。
|
debug
| true または false
| false
|
デバッグ目的でより詳細なメッセージを記録するかどうか。
|
表A.37 AdvancedLdap
コード | AdvancedLdap |
クラス | org.jboss.security.negotiation.AdvancedLdapLoginModule
|
説明 |
SASL や JAAS セキュリティードメインの使用など、追加機能を提供するモジュール。
|
表A.38 AdvancedLdap
モジュールオプション
オプション | タイプ | デフォルト | 説明 |
---|---|---|---|
bindAuthentication
|
文字列
|
なし
|
ディレクトリサーバーへのバインディングに使用する SASL 認証のタイプ。
|
jassSecurityDomain
| string
|
なし
|
使用する JAAS セキュリティードメインの名前。
|
java.naming.provider.url
| string
|
なし
|
ディレクトリサーバーの URI。
|
baseCtxDN
|
完全修飾識別名 (DN)。
|
なし
|
検索の基盤として使用する識別名。
|
baseFilter
|
LDAP 検索フィルターを表す文字列。
|
なし
|
検索結果を絞り込むために使用するフィルター。
|
roleAttributeID
|
LDAP 属性を表す文字列。
|
なし
|
承認ロールの名前が含まれる LDAP 属性。
|
roleAttributeIsDN
| true または false
| false
|
ロール属性が識別名 (DN) であるかどうか。
|
roleNameAttributeID
|
LDAP 属性を表す文字列。
|
なし
|
実際のロール属性が含まれる
RoleAttributeId 内に格納された属性。
|
recurseRoles
| true または false
| false
|
ロールに対して
RoleAttributeId を再帰的に検索するかどうか。
|
表A.39 AdvancedADLdap
コード | AdvancedADLdap |
クラス | org.jboss.security.negotiation.AdvancedADLoginModule
|
説明 |
このモジュールは
AdvancedLdap ログインモジュールを拡張し、Microsoft Active Directory に関連する追加パラメーターを追加します。
|
表A.40 UsersRoles
コード | UsersRoles |
クラス | org.jboss.security.auth.spi.UsersRolesLoginModul
|
説明 |
2 つの異なるプロパティーファイルに格納された複数のユーザーおよびユーザーロールをサポートする簡単なログインモジュール。
|
表A.41 UsersRoles
モジュールオプション
オプション | タイプ | デフォルト | 説明 |
---|---|---|---|
usersProperties
|
ファイルまたはリソースへのパス。
| users.properties
|
ユーザーからパスワードへのマッピングが含まれるファイルまたはリソース。ファイルの形式は
user=hashed-password になります。
|
rolesProperties
|
ファイルまたはリソースへのパス。
| roles.properties
|
ユーザーからロールへのマッピングが含まれるファイルまたはリソース。ファイルの形式は
username=role1,role2,role3 になります。
|
password-stacking
| useFirstPass または false
| false
|
このログインモジュールが ID を見つけるため
LoginContext に格納された情報を最初に探すことを示す useFirstPass の値。このオプションは、他のログインモジュールをこのモジュールとスタックする場合に使用できます。
|
hashAlgorithm
|
パスワードをハッシュ化するアルゴリズムを表す文字列。
| none
|
パスワードをハッシュ化するために使用する
java.security.MessageDigest アルゴリズムの名前。デフォルト値はないため、ハッシュを有効にするためにこのオプションを明示的に設定する必要があります。hashAlgorithm が指定された場合は、inputPassword 引数として UsernamePasswordLoginModule.validatePassword に渡す前に CallbackHandler から取得されたクリアテキストパスワードがハッシュ化されます。users.properties ファイルに格納されたパスワードも、同様にハッシュ化する必要があります。
|
hashEncoding
| base64 または hex
| base64
|
hashAlgorithm も設定されている場合、ハッシュ化されたパスワードの文字列形式。
|
hashCharset
|
文字列
|
コンテナのランタイム環境に設定されるデフォルトのエンコーディング。
|
クリアテキストのパスワードをバイトアレイに変換するために使用されるエンコーディング。
|
unauthenticatedIdentity
|
プリンシパル名
|
なし
|
認証情報を含まない要求に割り当てるプリンシパル名を定義します。これにより、保護されていないサーブレットは特定のロールを必要としない EJB でメソッドを呼び出すことができるようになります。このようなプリンシパルは関連付けられたロールを持たず、
unchecked permission 制約に関連付けられたセキュアでない EJB または EJB メソッドにのみアクセスできます。
|
認証モジュールは、org.jboss.security.LoginModule
の実装です。カスタム認証モジュールの作成の詳細については、API ドキュメンテーションを参照してください。
A.2. 含まれる承認モジュール
コード | クラス |
---|---|
DenyAll | org.jboss.security.authorization.modules.AllDenyAuthorizationModule |
PermitAll | org.jboss.security.authorization.modules.AllPermitAuthorizationModule |
Delegating | org.jboss.security.authorization.modules.DelegatingAuthorizationModule |
Web | org.jboss.security.authorization.modules.WebAuthorizationModule |
JACC | org.jboss.security.authorization.modules.JACCAuthorizationModule |
A.3. 含まれるセキュリティーマッピングモジュール
コード | クラス |
---|---|
PropertiesRoles | org.jboss.security.mapping.providers.role.PropertiesRolesMappingProvider |
SimpleRoles | org.jboss.security.mapping.providers.role.SimpleRolesMappingProvider |
DeploymentRoles | org.jboss.security.mapping.providers.DeploymentRolesMappingProvider |
DatabaseRoles | org.jboss.security.mapping.providers.role.DatabaseRolesMappingProvider |
LdapRoles | org.jboss.security.mapping.providers.role.LdapRolesMappingProvider |
A.4. 含まれるセキュリティー監査プロバイダーモジュール
コード | クラス |
---|---|
LogAuditProvider | org.jboss.security.audit.providers.LogAuditProvider |
A.5. jboss-web.xml の設定に関する参考資料
jboss-web.xml
はデプロイメントの WEB-INF
または META-INF
ディレクトリ内にあるファイルです。このファイルには、JBoss Web コンテナが Servlet 3.0 仕様に追加する機能に関する設定情報が含まれています。Servlet 3.0 仕様は web.xml
の同じディレクトリに格納されます。
jboss-web.xml
ファイルのトップレベル要素は <jboss-web>
要素です。
使用可能な設定の多くは、アプリケーションの web.ml
に設定される要件をローカルリソースへマッピングします。web.xml
の設定に関する説明は http://docs.oracle.com/cd/E13222_01/wls/docs81/webapp/web_xml.html を参照してください。
web.xml
に jdbc/MyDataSource
が必要な場合、jboss-web.xml
はグローバルデータソース java:/DefaultDS
をマッピングして要件を満たすことがあります。WAR はグローバルデータソースを使用して jdbc/MyDataSource
に対する要求を満たします。
表A.42 一般的なトップレベル属性
属性 | 説明 |
---|---|
env-entry | web.xml が必要とする env-entry へのマッピング。
|
ejb-ref | web.xml が必要とする ejb-ref へのマッピング。
|
ejb-local-ref | web.xml が必要とする ejb-local-ref へのマッピング。
|
service-ref | web.xml が必要とする service-ref へのマッピング。
|
resource-ref | web.xml が必要とする resource-ref へのマッピング。
|
resource-env-ref | web.xml が必要とするresource-env-ref へのマッピング。
|
message-destination-ref | web.xml が必要とする message-destination-ref へのマッピング。
|
persistence-context-ref | web.xml が必要とする persistence-context-ref へのマッピング。
|
persistence-unit-ref | web.xml が必要とする persistence-unit-ref へのマッピング。
|
post-construct | web.xml が必要とする post-context へのマッピング。
|
pre-destroy | web.xml が必要とする pre-destroy へのマッピング。
|
data-source | web.xml が必要とする data-source へのマッピング。
|
context-root | アプリケーションのルートコンテキスト。デフォルト値は .war サフィックスを除いたデプロイメントの名前です。 |
virtual-host | アプリケーションがリクエストを許可する HTTP 仮想ホストの名前。HTTP の Host ヘッダーの内容を参照します。 |
annotation | アプリケーションによって使用されるアノテーションを記述します。詳細は <annotation> を参照してください。 |
listener | アプリケーションによって使用されるリスナーを記述します。詳細は <listener> を参照してください。 |
session-config | この要素は web.xml の <session-config> 要素と同じ関数を入力します。互換性維持の目的でのみ含まれます。 |
valve | アプリケーションによって使用されるバルブを記述します。詳細は <valve> を参照してください。 |
overlay | アプリケーションに追加するオーバーレイの名前。 |
security-domain | アプリケーションによって使用されるセキュリティードメインの名前。セキュリティードメイン自体は Web ベースの管理コンソールか管理 CLI に設定されます。 |
security-role | この要素は web.xml の <security-role> 要素と同じ関数を入力します。互換性維持の目的でのみ含まれます。 |
use-jboss-authorization | この要素が存在し、大文字と小文字を区別しない true という値が含まれる場合、JBoss Web 承認スタックが使用されます。この要素が存在しない場合や、true でない値が含まれる場合は、Java enterprise Edition 仕様に指定された承認メカニズムのみが使用されます。この要素は JBoss Enterprise Application Platform 6 に新規導入された要素です。 |
disable-audit | この空の要素が存在する場合、Web セキュリティー監査が無効になります。Web セキュリティー監査は Java EE 仕様の一部ではありません。この要素は JBoss Enterprise Application Platform 6 に初めて導入された要素です。 |
disable-cross-context | false の場合、アプリケーションは他のアプリケーションコンテキストを呼び出すことができます。デフォルトは true です。 |
アプリケーションによって使用されるアノテーションを記述します。下表は <annotation>
の子要素の一覧になります。
表A.43 アノテーション設定要素
属性 | 説明 |
---|---|
class-name |
アノテーションのクラスの名前。
|
servlet-security |
サーブレットのセキュリティーを表す
@ServletSecurity などの要素。
|
run-as |
run-as の情報を表す
@RunAs などの要素。
|
multi-part |
マルチパートの情報を表す
@MultiPart などの要素。
|
リスナーを記述します。下表は <listener>
の子要素の一覧になります。
表A.44 リスナー設定要素
属性 | 説明 |
---|---|
class-name |
リスナーのクラスの名前。
|
listener-type |
アプリケーションのコンテキストにどのようなリスナーを追加するかを示す
condition 要素の一覧です。以下を選択することが可能です。
|
module |
リスナークラスが含まれるモジュールの名前。
|
param |
パラメーター。
<param-name> と <param-value> の 2 つの子要素が含まれます。
|
アプリケーションのバルブを記述します。<listener> と同じ設定要素が含まれます。
A.6. EJB セキュリティーパラメーターについての参考資料
表A.45 EJB セキュリティーパラメーター要素
要素 | 説明 |
---|---|
<security-identity>
|
EJB のセキュリティー ID に付随する子要素が含まれています。
|
<use-caller-identity />
|
EJB が呼び出し側と同じセキュリティー ID を使うよう指定します。
|
<run-as>
| <role-name> 要素が含まれています。
|
<run-as-principal>
|
存在する場合、発信呼び出しへ割り当てられたプリンシパルを示します。存在しない場合、発信呼び出しは
anonymous という名前のプリンシパルへ割り当てられます。
|
<role-name>
|
EJB が実行されるロールを指定します。
|
<description>
| <role-name> に名前のあるロールを記述します。
|
例A.1 セキュリティー ID の例
<session>
の中でのみ利用可能です。
<ejb-jar> <enterprise-beans> <session> <ejb-name>ASessionBean</ejb-name> <security-identity> <use-caller-identity/> </security-identity> </session> <session> <ejb-name>RunAsBean</ejb-name> <security-identity> <run-as> <description>A private internal role</description> <role-name>InternalRole</role-name> </run-as> </security-identity> </session> <session> <ejb-name>RunAsBean</ejb-name> <security-identity> <run-as-principal>internal</run-as-principal> </security-identity> </session> </enterprise-beans> </ejb-jar>
付録B Revision History
改訂履歴 | |||
---|---|---|---|
改訂 1.1-3.405 | Sun Dec 15 2013 | Rüdiger Landmann | |
| |||
改訂 1.1-3 | Thu Jul 11 2013 | Russell Dickenson | |
|