セキュリティーガイド
Red Hat JBoss Enterprise Application Platform 6 向け
概要
パート I. Red Hat JBoss Enterprise Application Platform 6 のセキュリティー リンクのコピーリンクがクリップボードにコピーされました!
第1章 はじめに リンクのコピーリンクがクリップボードにコピーされました!
1.1. Red Hat JBoss Enterprise Application Platform 6 リンクのコピーリンクがクリップボードにコピーされました!
1.2. JBoss EAP 6 のセキュア化 リンクのコピーリンクがクリップボードにコピーされました!
パート II. プラットフォームのセキュア化 リンクのコピーリンクがクリップボードにコピーされました!
第2章 Java セキュリティーマネージャー リンクのコピーリンクがクリップボードにコピーされました!
2.1. Java Security Manager リンクのコピーリンクがクリップボードにコピーされました!
Java Security Manager は、Java 仮想マシン (JVM) サンドボックスの外部境界を管理するクラスで、JVM 内で実行するコードが JVM 外のリソースと対話する方法を制御します。Java Security Manager が有効な場合、Java API は安全でない可能性のある操作を行う前に Security Manager が承認するか確認します。
2.2. Java Security Manager のポリシー リンクのコピーリンクがクリップボードにコピーされました!
コードの異なるクラスに対する定義済みのパーミッション。Java Security Manager はアプリケーションがリクエストしたアクションとセキュリティポリシーを比較します。ポリシーによってアクションが許可される場合、Java Security Manager はアクションの実行を許可します。ポリシーによってアクションが許可されない場合は、Java Security Manager はこのアクションを拒否します。セキュリティポリシーは、コードの場所、コードの署名、またはサブジェクトのプリンシパルを基にパーミッションを定義できます。
java.security.manager や java.security.policy を使用して設定されます。
セキュリティーポリシーのエントリーは、policytool に関係のある以下の設定要素から構成されます。
- CodeBase
- コードの元の URL の場所 (ホストとドメインの情報以外)。オプションのパラメーターです。
- SignedBy
- コードを署名するためにプライベートキーが使用された署名者を参照するキーストアで使用されたエイリアス。これは、単一値またはカンマ区切りの値リストになります。オプションのパラメーターです。省略された場合は、署名の有無に関わらず Java Security Manager に影響はありません。
- Principal
principal_typeとprincipal_nameのペアのリスト。これは、実行スレッドのプリンシパルセット内に存在する必要があります。Principals エントリーは任意です。このエントリーを省略すると、実行スレッドのプリンシパルによる Java Security Manager への影響はありません。- Permission
- permission は、コードに与えられるアクセス権です。多くのパーミッションは、Java Enterprise Edition 6 (Java EE 6) 仕様の一部として提供されます。
2.3. Java Security Manager 内での JBoss EAP 6 の実行 リンクのコピーリンクがクリップボードにコピーされました!
domain.sh スクリプトまたは standalone.sh スクリプトにパラメーターをオプションとして渡すことはできません。次の手順を実行すると、インスタンスが Java Security Manager ポリシー内で実行されるよう設定できます。
要件
- この手順を実行する前に、Java Development Kit (JDK) に含まれる
policytoolコマンドを使用してセキュリティーポリシーを記述する必要があります。この手順では、ポリシーがEAP_HOME/bin/server.policyにあることを前提としています。この代わりに、テキストエディターを使用してセキュリティーポリシーを書き、EAP_HOME/bin/server.policyとして手作業で保存することもできます。 - 設定ファイルを編集する前に、ドメインまたはスタンドアロンサーバーを完全に停止する必要があります。
手順2.1 JBoss EAP 6 向けのセキュリティーマネージャーの設定
設定ファイルを開きます。
編集のために設定ファイルを開きます。このファイルの場所は、管理対象ドメインとスタンドアロンサーバーのどちらを使用しているかによって異なります。このファイルは、サーバーまたはドメインを起動するために使用される実行可能ファイルではありません。管理対象ドメイン
- Linux の場合:
EAP_HOME/bin/domain.conf - Windows の場合:
EAP_HOME\bin\domain.conf.bat
スタンドアロンサーバー
- Linux の場合:
EAP_HOME/bin/standalone.conf - Windows の場合:
EAP_HOME\bin\standalone.conf.bat
ファイルに Java オプションを追加します。
確実に Java オプションが使用されるようにするため、以下で始まるコードブロックに Java オプションを追加します。if [ "x$JAVA_OPTS" = "x" ]; then
if [ "x$JAVA_OPTS" = "x" ]; thenCopy to Clipboard Copied! Toggle word wrap Toggle overflow -Djava.security.policyの値を編集して、セキュリティーポリシーの場所を指定できます。改行を入れずに 1 行で指定する必要があります。-Djava.security.policyプロパティーを設定するときに==を使用して指定すると、セキュリティーマネージャーは指定されたポリシーファイルのみを使用します。=を使用して指定すると、セキュリティーマネージャーは指定されたポリシーとJAVA_HOME/lib/security/java.securityのpolicy.urlセクションに指定されたポリシーを一緒に使用します。重要
JBoss Enterprise Application Platform 6.2.2 およびそれ以降のリリースでは、システムプロパティーjboss.modules.policy-permissionsを true に設定する必要があります。例2.1 domain.conf
JAVA_OPTS="$JAVA_OPTS -Djava.security.manager -Djava.security.policy==$PWD/server.policy -Djboss.home.dir=/path/to/EAP_HOME -Djboss.modules.policy-permissions=true"
JAVA_OPTS="$JAVA_OPTS -Djava.security.manager -Djava.security.policy==$PWD/server.policy -Djboss.home.dir=/path/to/EAP_HOME -Djboss.modules.policy-permissions=true"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例2.2 domain.conf.bat
set "JAVA_OPTS=%JAVA_OPTS% -Djava.security.manager -Djava.security.policy==\path\to\server.policy -Djboss.home.dir=\path\to\EAP_HOME -Djboss.modules.policy-permissions=true"
set "JAVA_OPTS=%JAVA_OPTS% -Djava.security.manager -Djava.security.policy==\path\to\server.policy -Djboss.home.dir=\path\to\EAP_HOME -Djboss.modules.policy-permissions=true"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例2.3 standalone.conf
JAVA_OPTS="$JAVA_OPTS -Djava.security.manager -Djava.security.policy==$PWD/server.policy -Djboss.home.dir=$JBOSS_HOME -Djboss.modules.policy-permissions=true"
JAVA_OPTS="$JAVA_OPTS -Djava.security.manager -Djava.security.policy==$PWD/server.policy -Djboss.home.dir=$JBOSS_HOME -Djboss.modules.policy-permissions=true"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例2.4 standalone.conf.bat
set "JAVA_OPTS=%JAVA_OPTS% -Djava.security.manager -Djava.security.policy==\path\to\server.policy -Djboss.home.dir=%JBOSS_HOME% -Djboss.modules.policy-permissions=true"
set "JAVA_OPTS=%JAVA_OPTS% -Djava.security.manager -Djava.security.policy==\path\to\server.policy -Djboss.home.dir=%JBOSS_HOME% -Djboss.modules.policy-permissions=true"Copy to Clipboard Copied! Toggle word wrap Toggle overflow ドメインサーバーを起動します。
ドメインまたはサーバーを通常どおり起動します。
2.4. Java Security Manager ポリシーの記述 リンクのコピーリンクがクリップボードにコピーされました!
ほとんどの JDK および JRE ディストリビューションには、Java Security Manager セキュリティーポリシーを作成および編集するための policytool という名前のアプリケーションが含まれます。policytool の詳細については、http://docs.oracle.com/javase/6/docs/technotes/tools/ を参照してください。
手順2.2 新しい Java Security Manager ポリシーの設定
policytoolを起動します。policytoolツールを次のいずれかの方法で起動します。Red Hat Enterprise Linux
GUI またはコマンドプロンプトで、/usr/bin/policytoolを実行します。Microsoft Windows Server
スタートメニューまたは Java インストールのbin\から、policytool.exeを実行します。場所は異なることがあります。
ポリシーを作成します。
ポリシーを作成するには、 を選択します。必要なパラメーターを追加し、 をクリックします。既存のポリシーを編集します。
既存のポリシーのリストからポリシーを選択し、 ボタンを選択します。必要に応じて、パラメーターを編集します。既存のポリシーを削除します。
既存のポリシーのリストからポリシーを選択し、 ボタンを選択します。
2.5. IBM JRE および Java Security Manager リンクのコピーリンクがクリップボードにコピーされました!
JAVA_HOME/jre/lib/security/java.security ファイルを編集し、policy.provider の値を sun.security.provider.PolicyFile に設定します。
policy.provider=sun.security.provider.PolicyFile
policy.provider=sun.security.provider.PolicyFile
2.6. Security Manager ポリシーのデバッグ リンクのコピーリンクがクリップボードにコピーされました!
java.security.debug オプションは、報告されたセキュリティー関連情報のレベルを設定します。コマンド java -Djava.security.debug=help は、すべてのデバッグオプションのヘルプ出力を表示します。デバッグレベルを all に設定すると、原因不明のセキュリティー関連の障害をトラブルシューティングするときに役に立ちますが、一般的な使用には多すぎる量の情報が表示されます。一般的に適切なデフォルト値は access:failure です。
手順2.3 一般的なデバッグの有効化
この手順を実行すると、セキュリティー関連デバッグ情報の一般的な機密レベルを有効にすることができます。
次の行をサーバー設定ファイルに追加します。- 管理対象ドメインで JBoss EAP 6 インスタンスが実行されている場合、以下の行は Linux では
bin/domain.confファイル、Windows ではbin\domain.conf.batファイルに追加されます。 - JBoss EAP 6 インスタンスがスタンドアロンサーバーとして実行されている場合、以下の行は Linux では
bin/standalone.confファイル、Windows ではbin\standalone.conf.batファイルに追加されます。
Linux
JAVA_OPTS="$JAVA_OPTS -Djava.security.debug=access:failure"
JAVA_OPTS="$JAVA_OPTS -Djava.security.debug=access:failure"
Windows
set "JAVA_OPTS=%JAVA_OPTS% -Djava.security.debug=access:failure"
set "JAVA_OPTS=%JAVA_OPTS% -Djava.security.debug=access:failure"
セキュリティー関連デバッグ情報の一般的なレベルが有効になります。
第3章 セキュリティーレルム リンクのコピーリンクがクリップボードにコピーされました!
3.1. セキュリティーレルム リンクのコピーリンクがクリップボードにコピーされました!
ManagementRealmは、管理 CLI や Web ベースの管理コンソールに機能を提供する管理 API の認証情報を保存します。これは、JBoss EAP 6 を管理するための認証システムを提供します。管理 API に使用する同じビジネスルールでアプリケーションを認証する必要がある場合には、ManagementRealmを使用することもできます。ApplicationRealmは Web アプリケーションと EJB のユーザー、パスワード、およびロール情報を保存します。
REALM-users.propertiesはユーザー名とハッシュ化されたパスワードを保存します。REALM-roles.propertiesはユーザー対ロールのマッピングを保存します。mgmt-groups.propertiesはManagementRealmのユーザー対グループのマッピングを保存します。ロールベースアクセス制御 (RBAC: Role-based Access Control) が有効な場合のみ使用されます。
domain/configuration/ および standalone/configuration/ ディレクトリーに保存されます。ファイルは add-user.sh や add-user.bat コマンドによって同時に書き込まれます。コマンドの実行時、新しいユーザーをどのレルムに追加するかを最初に決定します。
3.2. 新しいセキュリティーレルムの追加 リンクのコピーリンクがクリップボードにコピーされました!
管理 CLI を実行します。
jboss-cli.shまたはjboss-cli.batコマンドを開始し、サーバーに接続します。新しいセキュリティーレルムを作成します。
次のコマンドを実行し、ドメインコントローラーまたはスタンドアロンサーバー上でMyDomainRealmという名前の新しいセキュリティーレルムを作成します。ドメインインスタンスでは以下コマンドを使用します。/host=master/core-service=management/security-realm=MyDomainRealm:add()
/host=master/core-service=management/security-realm=MyDomainRealm:add()Copy to Clipboard Copied! Toggle word wrap Toggle overflow スタンドアロンインスタンスでは以下のコマンドを使用します。/core-service=management/security-realm=MyDomainRealm:add()
/core-service=management/security-realm=MyDomainRealm:add()Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいロールの情報を保存するプロパティーファイルへの参照を作成します。
次のコマンドを実行し、新しいロールに関連するプロパティーが含まれるmyfile.propertiesという名前のファイルのポインターを作成します。注記
新たに作成されたプロパティーファイルは、含まれるadd-user.shおよびadd-user.batスクリプトによって管理されません。そのため、外部で管理する必要があります。ドメインインスタンスでは以下コマンドを使用します。/host=master/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
/host=master/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)Copy to Clipboard Copied! Toggle word wrap Toggle overflow スタンドアロンインスタンスでは以下のコマンドを使用します。/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
新しいセキュリティーレルムが作成されます。新たに作成されたこのレルムにユーザーやロールを追加すると、デフォルトのセキュリティーレルムとは別のファイルに情報が保存されます。新規ファイルはご使用のアプリケーションやプロシージャーを使用して管理できます。
3.3. セキュリティーレルムへのユーザーの追加 リンクのコピーリンクがクリップボードにコピーされました!
add-user.shまたはadd-user.batコマンドを実行します。ターミナルを開き、EAP_HOME/bin/ディレクトリーへ移動します。Red Hat Enterprise Linux や他の UNIX 系のオペレーティングシステムを稼働している場合は、add-user.shを実行します。Microsoft Windows Server を稼働している場合はadd-user.batを実行します。管理ユーザーかアプリケーションユーザーのどちらを追加するか選択します。
この手順ではbを入力し、アプリケーションユーザーを追加します。ユーザーが追加されるレルムを選択します。
デフォルトでは、ApplicationRealmのみが選択可能です。カスタムレルムが追加されている場合はその名前を入力します。入力を促されたらユーザー名、パスワード、ロールを入力します。
入力を促されたら希望のユーザー名、パスワード、任意のロールを入力します。yesを入力して選択を確認するか、noを入力して変更をキャンセルします。変更はセキュリティーレルムの各プロパティーファイルに書き込まれます。
第4章 ネットワークトラフィックの暗号化 リンクのコピーリンクがクリップボードにコピーされました!
4.1. JBoss EAP 6 が使用するネットワークインターフェースの指定 リンクのコピーリンクがクリップボードにコピーされました!
サービスを必要とするクライアントにのみアクセスできるようサービスを分離すると、ネットワークのセキュリティーが強化されます。JBoss EAP 6 には、デフォルト設定の 2 つのインターフェースが含まれ、どちらもデフォルトで IP アドレス 127.0.0.1 または localhost にバインドされます。インターフェースの 1 つは management と呼ばれ、管理コンソール、CLI、および API によって使用されます。他のインターフェースは public と呼ばれ、アプリケーションをデプロイするために使用されます。これらのインターフェースは、特別なものではありませんが、作業を始める土台として提供されます。
management インターフェースはデフォルトでポート 9990 および 9999 を使用し、public インターフェースはポート 8080 または 8443 (HTTPS を使用する場合) を使用します。
警告
JBoss EAP 6 を停止します。
オペレーティングシステムに適切な方法で割り込みを送信して JBoss EAP 6 を停止します。JBoss EAP 6 をフォアグラウンドアプリケーションとして実行している場合、通常は Ctrl+C を押してこれを行います。バインドアドレスを指定して JBoss EAP 6 を再起動します。
-bコマンドラインスイッチを使用して、特定のインターフェースで JBoss EAP 6 を起動します。例4.1 パブリックインターフェースの指定
EAP_HOME/bin/domain.sh -b 10.1.1.1
EAP_HOME/bin/domain.sh -b 10.1.1.1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例4.2 管理インターフェースの指定
EAP_HOME/bin/domain.sh -bmanagement=10.1.1.1
EAP_HOME/bin/domain.sh -bmanagement=10.1.1.1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例4.3 各インターフェースへの異なるアドレスの指定
EAP_HOME/bin/domain.sh -bmanagement=127.0.0.1 -b 10.1.1.1
EAP_HOME/bin/domain.sh -bmanagement=127.0.0.1 -b 10.1.1.1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例4.4 すべてのネットワークインターフェースへのパブリックインターフェースのバインド
EAP_HOME/bin/domain.sh -b 0.0.0.0
EAP_HOME/bin/domain.sh -b 0.0.0.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-b コマンドラインスイッチを使用してランタイム時に IP アドレスを指定できなくなるため、お勧めしません。この作業を行う場合は、XML ファイルを編集する前に JBoss EAP 6 を完全に停止する必要があります。
4.2. JBoss EAP 6 で動作可能なネットワークファイアウォールの設定 リンクのコピーリンクがクリップボードにコピーされました!
ほとんどの本番環境では、ネットワークセキュリティー全体の方針の一部としてファイアウォールを使用します。複数のサーバーインスタンスがお互いに通信したり、Web サーバーやデータベースなどの外部サービスと通信したりする必要がある場合は、ファイアウォールでこれを考慮する必要があります。適切に管理されたファイアウォールでは、操作に必要なポートのみが開かれ、特定の IP アドレス、サブネット、およびネットワークプロトコルに対するポートへのアクセスが制限されます。
要件
- 開く必要があるポートを判断します。
- ファイアウォールソフトウェアについて理解する必要があります。この手順では、Red Hat Enterprise Linux 6 の
system-config-firewallコマンドを使用します。Microsoft Windows Server には、ファイアウォールが組み込まれ、各プラットフォーム用の複数のサードパーティー製ファイアウォールソリューションが利用可能です。Microsoft Windows Server では、PowerShell を使用してファイアウォールを設定できます。
この手順では、以下を前提として環境のファイアウォールを設定します。
- オペレーティングシステムは Red Hat Enterprise Linux 6 です。
- JBoss EAP 6 はホスト
10.1.1.2で実行されます。オプションで、サーバーには独自のファイアウォールがあります。 - ネットワークファイアウォールサーバーは、ホスト
10.1.1.1のインターフェースeth0で実行され、外部インターフェースeth1を持ちます。 - ポート
5445(JMS で使用されるポート) のトラフィックを JBoss EAP 6 に転送します。ネットワークファイアウォールで他のトラフィックは許可されません。
手順4.1 ネットワークファイアウォールと JBoss EAP 6 が連携するための管理
管理コンソールへのログイン
管理コンソールにログインします。デフォルトでは、http://localhost:9990/console/ で実行されます。ソケットバインディンググループが使用するソケットバインディングを決定します。
- 管理コンソールの上部にある Configuration ラベルをクリックします。
- General Configuration メニューを展開します。Socket Binding を選択します。
- Socket Binding Declarations 画面が表示されます。最初に、
standard-socketsグループが表示されます。他のグループを選択する場合は、右側のコンボボックスから選択します。
注記
スタンドアロンサーバーを使用する場合は、1 つのソケットバインディンググループのみが存在します。ソケット名とポートのリストが表示されます (1 ページあたり 8 つの値)。テーブルの矢印ナビゲーションを使用してページを移動できます。開く必要があるポートを判断します。
特定ポートの機能および環境の要件によっては、一部のポートをファイアウォール上で開く必要がある場合があります。JBoss EAP 6 にトラフィックを転送するようファイアウォールを設定します。
以下の手順を実行して、必要なポートでトラフィックを許可するようネットワークファイアウォールを設定します。- root ユーザーとしてファイアウォールマシンにログインし、コマンドプロンプトにアクセスします。
system-config-firewallコマンドを実行してファイアウォール設定ユーティリティーを起動します。ファイアウォールシステムにログインした方法に応じて、GUI またはコマンドラインユーティリティーが起動します。このタスクでは、SSH 経由でコマンドラインインターフェースを使用してログインしていることを前提とします。- キーボードで TAB キーを使用して ボタンに移動し、ENTER キーを押します。Trusted Services 画面が表示されます。
- どの値も変更せずに、TAB キーを使用して ボタンに移動し、ENTER を押して次の画面に進みます。Other Ports 画面が表示されます。
- TAB キーを使用して <Add> ボタンに移動し、ENTER を押します。Port and Protocol 画面が表示されます。
- Port / Port Range フィールドに
5445と入力し、TAB キーを使用して Protocol フィールドに移動し、tcpと入力します。TAB キーを使用して ボタンに移動し、ENTER を押します。 - TAB キーを使用して、 ボタンに移動し、Port Forwarding 画面にアクセスします。
- TAB キーを使用して <Add> ボタンに移動し、ENTER キーを押します。
- 以下の値を入力してポート
5445のポート転送を設定します。- 送信元インターフェース:
eth1 - プロトコル:
tcp - ポート/ポート範囲:
5445 - 宛先 IP アドレス:
10.1.1.2 - ポート/ポート範囲:
5445
TAB キーを使用して ボタンに移動し、ENTER を押します。 - TAB キーを使用して ボタンに移動し、ENTER を押します。
- TAB キーを使用して ボタンに移動し、ENTER を押します。変更内容を適用するには、警告を読み、 をクリックします。
JBoss EAP 6 ホストでファイアウォールを設定します。
一部の組織では、JBoss EAP 6 サーバー自体でファイアウォールを設定し、運用に必要ないすべてのポートを閉じます。「JBoss EAP 6 により使用されるネットワークポート」を参照して開くポートを決定し、残りのポートを閉じます。Red Hat Enterprise Linux 6 のデフォルトの設定では、Secure Shell (SSH) に使用される22と、マルチキャスト DNS に使用される5353以外のポートが閉じられます。ポートを設定する場合は、誤ってロックアウトされないよう物理的にアクセスしてください。
ファイアウォール設定で指定したとおり、ファイアウォールによって内部 JBoss EAP 6 サーバーへトラフィックが転送されるようになります。サーバーでファイアウォールを有効にした場合は、アプリケーションを実行するために必要なポート以外はすべて閉じられます。
手順4.2 PowerShell を使用した Microsoft Windows 上でのファイアウォールの設定
- デバッグの目的でファイアウォールを停止し、現在のネットワークの挙動がファイアウォールの設定と関係しているかどうかを判断します。
Start-Process "$psHome\powershell.exe" -Verb Runas -ArgumentList '-command "NetSh Advfirewall set allprofiles state off"'
Start-Process "$psHome\powershell.exe" -Verb Runas -ArgumentList '-command "NetSh Advfirewall set allprofiles state off"'Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ポート 23364 上で UDP 接続を許可します。以下に例を示します。
Start-Process "$psHome\powershell.exe" -Verb Runas -ArgumentList '-command "NetSh Advfirewall firewall add rule name="UDP Port 23364" dir=in action=allow protocol=UDP localport=23364"' Start-Process "$psHome\powershell.exe" -Verb Runas -ArgumentList '-command "NetSh Advfirewall firewall add rule name="UDP Port 23364" dir=out action=allow protocol=UDP localport=23364"'
Start-Process "$psHome\powershell.exe" -Verb Runas -ArgumentList '-command "NetSh Advfirewall firewall add rule name="UDP Port 23364" dir=in action=allow protocol=UDP localport=23364"' Start-Process "$psHome\powershell.exe" -Verb Runas -ArgumentList '-command "NetSh Advfirewall firewall add rule name="UDP Port 23364" dir=out action=allow protocol=UDP localport=23364"'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
手順4.3 mod_cluster アドバタイズを許可するよう Red Hat Enterprise Linux 7 でファイアウォールを設定
- Red Hat Enterprise Linux 7 で mod_cluster のアドバタイズを有効にするには、以下のようにファイアウォールで UDP ポートを有効にする必要があります。
firewall-cmd --permanent --zone=public --add-port=23364/udp
firewall-cmd --permanent --zone=public --add-port=23364/udpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記
UDP マルチキャストをアドバタイズする mod_cluster バランサーのデフォルトアドレスおよびポートは 224.0.1.105:23364 です。
4.3. JBoss EAP 6 により使用されるネットワークポート リンクのコピーリンクがクリップボードにコピーされました!
- サーバーグループがデフォルトのソケットバインディンググループのいずれかを使用するか、またはカスタムグループを使用するかどうか。
- 個別デプロイメントの要件。
注記
8080 で、サーバーは 100 のポートオフセットを使用する場合、その HTTP ポートは 8180 になります。
デフォルトのソケットバインディンググループ
full-ha-socketsfull-socketsha-socketsstandard-sockets
| 名前 | ポート | マルチキャストポート | 説明 | 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 EAP 6 と HTTP ロードバランサー間の通信に対するマルチキャストポート。 | ○ | × | ○ | × | |
osgi-http | 8090 | OSGi サブシステムを使用する内部コンポーネントにより使用されます。管理インターフェースを使用して設定できません。 | ○ | ○ | ○ | ○ | |
remoting | 4447 | リモート EJB の呼び出しに使用されます。 | ○ | ○ | ○ | ○ | |
txn-recovery-environment | 4712 | JTA トランザクションリカバリーマネージャー。 | ○ | ○ | ○ | ○ | |
txn-status-manager | 4713 | JTA / JTS トランザクションマネージャー。 | ○ | ○ | ○ | ○ |
ソケットバインディンググループの他に、各ホストコントローラーによって 2 つのポートが管理目的で開かれます。
9990- Web 管理コンソールポート9999- 管理コンソールと管理 API によって使用されるポート
4.4. 暗号化 リンクのコピーリンクがクリップボードにコピーされました!
4.5. SSL 暗号化 リンクのコピーリンクがクリップボードにコピーされました!
警告
4.6. JBoss EAP 6 Web サーバーでの SSL 暗号化の実装 リンクのコピーリンクがクリップボードにコピーされました!
多くの Web アプリケーションでは、クライアントとサーバー間で SSL 暗号化接続 (HTTPS 接続とも呼ばれます) が必要です。以下の手順を使用すると、サーバーまたはサーバーグループで HTTPS を有効にできます。
警告
要件
- SSL 暗号化キーセットと SSL 暗号化証明書。これらは、証明書署名認証局から購入したり、コマンドラインユーティリティーを使用して生成したりできます。Red Hat Enterprise Linux のユーティリティーを使用して暗号化キーを生成するには、「SSL 暗号化キーおよび証明書の生成」を参照してください。
- 特定の環境と設定に関する以下の詳細。
- 証明書ファイルが保存されている完全なディレクトリー名。
- 暗号化キーの暗号化パスワード。
- ドメインコントローラーまたはスタンドアロンサーバーに接続する稼働中の管理 CLI。
- 適切な暗号化スイートを選択します。
暗号化スイートを構成するために使用される暗号プリミティブは複数あります。推奨される暗号プリミティブは最初の表に記載されています。2 つ目の表には、既存のソフトウェアとの互換性を維持するために使用できる 可能性がある 暗号プリミティブが記載されていますが、推奨されるプリミティブよりも安全性が低くなります。
警告
cipher-suite に使用することを推奨します。弱い暗号を使用するとセキュリティーリスクが増大します。互換性の問題がある可能性があるため、特定の暗号化スイートを決定する前に JDK ベンダーのドキュメントを確認してください。
| 2048 ビットキーと OAEP を使用する RSA |
| CBC モードの AES-128 |
| SHA-256 |
| HMAC-SHA-256 |
| HMAC-SHA-1 |
| 1024 以上のキーサイズとレガシーパディングを使用する RSA |
| AES-192 |
| AES-256 |
| 3DES (トリプル DES で、2 つまたは 3 つの 56 ビットキー) |
| RC4 (非推奨) |
| SHA-1 |
| HMAC-MD5 |
注記
/profile=default を削除して管理 CLI コマンドを変更します。
警告
手順4.4 JBoss Web Server が HTTPS を使用するよう設定
新しい HTTPS コネクターを追加します。
httpsスキームとhttpsソケットバインディング (デフォルトは8443) を使用し、セキュアとして設定される HTTPS という名前のセキュアなコネクターを作成します。/profile=default/subsystem=web/connector=HTTPS/:add(socket-binding=https,scheme=https,protocol=HTTP/1.1,secure=true)
/profile=default/subsystem=web/connector=HTTPS/:add(socket-binding=https,scheme=https,protocol=HTTP/1.1,secure=true)Copy to Clipboard Copied! Toggle word wrap Toggle overflow SSL 暗号化証明書およびキーを設定します。
例の値を独自の値に置き換え、SSL 証明書を設定します。この例では、キーストアはサーバー設定ディレクトリー (管理対象ドメインではEAP_HOME/domain/configuration/) へコピーされることを前提としています。/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, cipher-suite=CIPHERS)/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, cipher-suite=CIPHERS)Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロトコルを
TLSv1に設定します。/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=protocol,value=TLSv1)
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=protocol,value=TLSv1)Copy to Clipboard Copied! Toggle word wrap Toggle overflow アプリケーションをデプロイします。
設定したプロファイルを使用するサーバーグループにアプリケーションをデプロイします。スタンドアロンサーバーを使用する場合、アプリケーションをサーバーにデプロイします。アプリケーションに対する HTTPS 要求は新しい SSL 暗号化接続を使用します。
4.7. SSL 暗号化キーおよび証明書の生成 リンクのコピーリンクがクリップボードにコピーされました!
要件
- Java Development Kit 実装で提供される
keytoolユーティリティーが必要です。このコマンドは、Red Hat Enterprise Linux 上の OpenJDK により/usr/bin/keytoolにインストールされます。 keytoolコマンドの構文およびパラメーターについて理解してください。この手順では、非常に一般的な手順を実行します。本書では、SSL 証明書またはkeytoolコマンドに特有の説明は範囲外となります。
手順4.5 SSL 暗号化キーおよび証明書の生成
パブリックキーおよびプライベートキーとともにキーストアを生成します。
以下のコマンドを実行し、jbossというエイリアスを持つserver.keystoreという名前のキーストアをカレントディレクトリーに生成します。この keytool コマンドで使用されるパラメーターの説明は次のとおりです。keytool -genkeypair -alias jboss -keyalg RSA -keystore server.keystore -storepass mykeystorepass --dname "CN=jsmith,OU=Engineering,O=mycompany.com,L=Raleigh,S=NC,C=US"
keytool -genkeypair -alias jboss -keyalg RSA -keystore server.keystore -storepass mykeystorepass --dname "CN=jsmith,OU=Engineering,O=mycompany.com,L=Raleigh,S=NC,C=US"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Expand Parameter 説明 -genkeypairkeytoolコマンドは公開鍵と秘密鍵が含まれるキーペアを生成します。-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
keytool -list -keystore server.keystoreCopy to Clipboard Copied! Toggle word wrap Toggle overflow キーストアのパスワードを入力するよう求められます。キーストアの内容 (この場合はjbossという名前の単一キー) が表示されます。jbossキーの種類がPrivateKeyEntryであることに注意してください。これは、キーストアにこのキーのパブリックおよびプライベートエントリが含まれることを示します。証明書署名要求を生成します。
次のコマンドを実行し、手順 1 で作成したキーストアより公開鍵を使用して証明書署名要求を生成します。keytool -certreq -keyalg RSA -alias jboss -keystore server.keystore -file certreq.csr
keytool -certreq -keyalg RSA -alias jboss -keystore server.keystore -file certreq.csrCopy to Clipboard Copied! Toggle word wrap Toggle overflow キーストアに対する認証を行うために、パスワードを入力するよう求められます。keytoolコマンドにより、現在の作業ディレクトリーにcertreq.csrという名前の証明書署名要求が新規作成されます。新しく生成された証明書署名要求をテストします。
以下のコマンドを使用して証明書の内容をテストします。openssl req -in certreq.csr -noout -text
openssl req -in certreq.csr -noout -textCopy to Clipboard Copied! Toggle word wrap Toggle overflow 証明書の詳細が表示されます。オプション: 証明書署名要求を認証局 (CA) に送信します。
認証局 (CA) は、証明書を認証できます。この結果、証明書は、サードパーティークライアントが信用できると見なされます。CA により、署名済み証明書が提供されます。また、オプションで 1 つまたは複数の中間証明書が提供されます。オプション: キーストアからの自己署名証明書のエクスポート
テストまたは内部使用のためにのみ証明書が必要な場合は、自己署名証明書を使用できます。次のように、手順 1 で作成したキーストアからエクスポートします。keytool -export -alias jboss -keystore server.keystore -file server.crt
keytool -export -alias jboss -keystore server.keystore -file server.crtCopy to Clipboard Copied! Toggle word wrap Toggle overflow キーストアに対して認証するためパスワードの入力が求められます。server.crtという名前の自己署名証明書が現在の作業ディレクトリーに作成されます。署名済み証明書を中間証明書とともにインポートします。
CA で指示された順序で各証明書をインポートします。各証明書をインポートするには、intermediate.caまたはserver.crtを実際のファイル名に置き換えます。証明書が別のファイルとして提供されない場合は、各証明書に対して個別のファイルを作成し、その内容をファイルに貼り付けます。注記
署名済み証明書および証明書キーは機密情報です。サーバー間での転送方法に注意してください。keytool -import -keystore server.keystore -alias intermediateCA -file intermediate.ca
keytool -import -keystore server.keystore -alias intermediateCA -file intermediate.caCopy to Clipboard Copied! Toggle word wrap Toggle overflow keytool -importcert -alias jboss -keystore server.keystore -file server.crt
keytool -importcert -alias jboss -keystore server.keystore -file server.crtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 証明書が正常にインポートされたことをテストします。
以下のコマンドを実行し、要求された場合にキーストアパスワードを入力します。キーストアの内容が表示され、証明書がリストの一部になります。keytool -list -keystore server.keystore
keytool -list -keystore server.keystoreCopy to Clipboard Copied! Toggle word wrap Toggle overflow
署名済み証明書はキーストアに含まれ、HTTPS Web サーバー通信を含む SSL 接続を暗号化するために使用できます。
4.8. SSL コネクターリファレンス リンクのコピーリンクがクリップボードにコピーされました!
default を使用した管理対象ドメイン向けに設計されています。プロファイル名を、管理対象ドメインに対して設定する名前に変更するか、コマンドの /profile=default 部分を省略します (スタンドアロンサーバーの場合)。
| 属性 | 説明 | CLI コマンド |
|---|---|---|
| name |
SSL コネクターの表示名。
|
属性
name は読み取り専用です。
|
| verify-client |
HTTP/HTTPS コネクターまたはネイティブ APR コネクターが使用されるかによって、
verify-client の可能な値は異なります。
HTTP/HTTPS コネクター
可能な値は ネイティブ APR コネクター
可能な値は |
最初のコマンド例は HTTPS コネクターを使用します。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=verify-client,value=want)
2 つ目のコマンド例は APR コネクターを使用します。
/profile=default/subsystem=web/connector=APR/ssl=configuration/:write-attribute(name=verify-client,value=require)
|
| verify-depth |
クライアントが有効な証明を持たないと判断するまでにチェックされる中間証明書発行者の最大数。デフォルト値は
10 です。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=verify-depth,value=10)
|
| certificate-key-file |
署名済みサーバー証明書が格納されるキーストアの完全ファイルパスおよびファイル名。JSSE 暗号化の場合、この証明書ファイルが唯一のファイルになり、OpenSSL は複数のファイルを使用します。デフォルト値は JBoss EAP 6 を実行しているユーザーのホームディレクトリー内にある
.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 |
トラストストアおよびキーストアのパスワード。以下の例では、PASSWORD を実際のパスワードに置き換えます。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=password,value=PASSWORD)
|
| protocol |
使用する SSL プロトコルのバージョン。サポートされる値は基礎の SSL 実装 (JSSE または OpenSSL) によって異なります。Java SSE のドキュメントを参照してください。
また、プロトコルの組み合わせをコンマで区切って指定することもできます (例: TLSv1, TLSv1.1,TLSv1.2)。
警告
Red Hat は、影響するすべてのパッケージで TLSv1.1 または TLSv1.2 を利用するために SSL を明示的に無効化することを推奨しています。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=protocol,value=ALL)
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=protocol,value="TLSv1, TLSv1.1,TLSv1.2")
|
| cipher-suite |
許可される暗号のリスト。JSSE の構文ではカンマ区切りのリストを使用する必要があります。OpenSSL の構文ではコロン区切りのリストを使用する必要があります。必ず 1 つの構文のみを使用してください。
デフォルトは
HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5 です。
例では可能な暗号が 2 つのみですが、実際にはこれ以上の暗号を使用することになります。
重要
弱い暗号を使用するとセキュリティーリスクが増大します。NIST が推奨する暗号化スイートは http://www.nist.gov/manuscript-publication-search.cfm?pub_id=915295 を参照してください。
使用可能な OpenSSL の暗号のリストは https://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGS を参照してください。
@SECLEVEL、SUITEB128、SUITEB128ONLY、および SUITEB192 はサポートされないことに注意してください。
|
/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 |
キーストア内のサーバー証明書に使用されるエイリアス。以下の例では、KEY_ALIAS を実際の証明書のエイリアスに置き換えます。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=key-alias,value=KEY_ALIAS)
|
| 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 の証明書パスワード。以下の例では、MASKED_PASSWORD を実際のマスクされたパスワードに置き換えます。
|
/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 キャッシュのサイズ。この属性は、JSSE コネクターへのみ適用されます。デフォルト値は
0 で、無制限のキャッシュサイズが指定されます。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=session-cache-size,value=100)
|
| session-timeout |
キャッシュされた SSLSession が期限切れになるまでの秒数。この属性は JSSE コネクターへのみ適用されます。デフォルト値は
86400 秒 (24 時間) です。
|
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=session-timeout,value=43200)
|
4.9. FIPS 140-2 準拠の暗号化 リンクのコピーリンクがクリップボードにコピーされました!
4.9.1. FIPS 140-2 の準拠 リンクのコピーリンクがクリップボードにコピーされました!
4.9.2. IBM JDK での FIPS 140-2 準拠の暗号 リンクのコピーリンクがクリップボードにコピーされました!
鍵の格納
keytool を実行するには、以下のように各コマンドで -providerClass オプションを使用します。
keytool -list -storetype JCEKS -keystore mystore.jck -storepass mystorepass -providerClass com.ibm.crypto.fips.provider.IBMJCEFIPS
keytool -list -storetype JCEKS -keystore mystore.jck -storepass mystorepass -providerClass com.ibm.crypto.fips.provider.IBMJCEFIPS
FIPS プロバイダー情報の確認
standalone.conf または domain.conf に -Djavax.net.debug=true を追加して、debug レベルのロギングを有効にします。FIPS プロバイダーの情報は server.log に記録されます。例を以下に示します。
4.9.3. FIPS 140-2 準拠のパスワード リンクのコピーリンクがクリップボードにコピーされました!
- 7 文字以上であること。
- 以下の文字クラスのうち、3 クラス以上の文字が含まれること。
- ASCII 数字
- 小文字の ASCII
- 大文字の ASCII
- 英数字以外の ASCII
- ASCII 以外の文字
4.9.4. Red Hat Enterprise Linux 6 にて SSL の FIPS 140-2 準拠の暗号を有効化 リンクのコピーリンクがクリップボードにコピーされました!
要件
- Red Hat Enterprise Linux 6 が FIPS 140-2 に準拠するよう設定されている必要があります。https://access.redhat.com/knowledge/solutions/137833 を参照してください。
手順4.6 SSL に対して FIPS 140-2 準拠の暗号化を有効にする
データベースの作成
jbossユーザーが所有するディレクトリーに NSS データベースを作成します。mkdir -p /usr/share/jboss-as/nssdb chown jboss /usr/share/jboss-as/nssdb modutil -create -dbdir /usr/share/jboss-as/nssdb
$ mkdir -p /usr/share/jboss-as/nssdb $ chown jboss /usr/share/jboss-as/nssdb $ modutil -create -dbdir /usr/share/jboss-as/nssdbCopy to Clipboard Copied! Toggle word wrap Toggle overflow NSS 設定ファイルの作成
次の内容が含まれるnss_pkcsll_fips.cfgという名前の新しいテキストファイルを/usr/share/jboss-asディレクトリーに作成します。name = nss-fips nssLibraryDirectory=/usr/lib64 nssSecmodDirectory=/usr/share/jboss-as/nssdb nssModule = fips
name = nss-fips nssLibraryDirectory=/usr/lib64 nssSecmodDirectory=/usr/share/jboss-as/nssdb nssModule = fipsCopy to Clipboard Copied! Toggle word wrap Toggle overflow NSS 設定ファイルには以下が指定されている必要があります。- 名前
- NSS ライブラリーが存在するディレクトリー
- 手順 1 に従って作成された NSS データベースが存在するディレクトリー
Red Hat Enterprise Linux 6 の 64 ビットバージョンを実行していない場合は、/usr/lib64の代わりに/usr/libをnssLibraryDirectoryに設定します。SunPKCS11 プロバイダーの有効化
JRE ($JAVA_HOME/jre/lib/security/java.security) のjava.security設定ファイルを編集し、次の行を追加します。security.provider.1=sun.security.pkcs11.SunPKCS11 /usr/share/jboss-as/nss_pkcsll_fips.cfg
security.provider.1=sun.security.pkcs11.SunPKCS11 /usr/share/jboss-as/nss_pkcsll_fips.cfgCopy to Clipboard Copied! Toggle word wrap Toggle overflow この行に指定されている設定ファイルは手順 2 で作成されたファイルであることに注意してください。このプロバイダーを優先するため、このファイルにある他のsecurity.provider.X行の値 (X) に 1 を足す必要があります。NSS ライブラリーに対して FIPS モードを有効にする
次のようにmodutilコマンドを実行し、FIPS モードを有効にします。modutil -fips true -dbdir /usr/share/jboss-as/nssdb
modutil -fips true -dbdir /usr/share/jboss-as/nssdbCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここで指定するディレクトリーは手順 1 で作成したものであることに注意してください。この時点で、セキュリティーライブラリーエラーが発生し、NSS 共有オブジェクトの一部に対してライブラリー署名の再生成が必要になることがあります。FIPS トークンのパスワードの変更
次のコマンドを使用して FIPS トークンのパスワードを設定します。トークンの名前はNSS FIPS 140-2 Certificate DBでなければならないことに注意してください。modutil -changepw "NSS FIPS 140-2 Certificate DB" -dbdir /usr/share/jboss-as/nssdb
modutil -changepw "NSS FIPS 140-2 Certificate DB" -dbdir /usr/share/jboss-as/nssdbCopy to Clipboard Copied! Toggle word wrap Toggle overflow FIPS トークンに使用されるパスワードは FIPS 準拠のパスワードでなければなりません。NSS ツールを使用した証明書の作成
次のコマンドを入力し、NSS ツールを使用して証明書を作成します。certutil -S -k rsa -n jbossweb -t "u,u,u" -x -s "CN=localhost, OU=MYOU, O=MYORG, L=MYCITY, ST=MYSTATE, C=MY" -d /usr/share/jboss-as/nssdb
certutil -S -k rsa -n jbossweb -t "u,u,u" -x -s "CN=localhost, OU=MYOU, O=MYORG, L=MYCITY, ST=MYSTATE, C=MY" -d /usr/share/jboss-as/nssdbCopy to Clipboard Copied! Toggle word wrap Toggle overflow PKCS11 キーストアを使用するよう HTTPS コネクターを設定する
JBoss CLI ツールで次のコマンドを使用し、HTTPS コネクターを追加します。/subsystem=web/connector=https/:add(socket-binding=https,scheme=https,protocol=HTTP/1.1,secure=true)
/subsystem=web/connector=https/:add(socket-binding=https,scheme=https,protocol=HTTP/1.1,secure=true)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次に、以下のコマンドを使用して SSL 設定を追加します。PASSWORD を 手順 5 の FIPS 準拠のパスワードに置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 検証
次のコマンドを実行し、JVM が PKCS11 キーストアから公開鍵を読み取れることを検証します。keytool -list -storetype pkcs11
keytool -list -storetype pkcs11Copy to Clipboard Copied! Toggle word wrap Toggle overflow
例4.5 FIPS 140-2 に準拠した HTTPS コネクターの XML 設定
cipher-suite 属性には改行が挿入されていることに注意してください。
第5章 管理インターフェースのセキュア化 リンクのコピーリンクがクリップボードにコピーされました!
5.1. デフォルトのユーザーセキュリティー設定 リンクのコピーリンクがクリップボードにコピーされました!
JBoss EAP 6 のすべての管理インターフェースはデフォルトで保護されます。このセキュリティーには、2 つの形式があります。
- ローカルインターフェースは、ローカルクライアントとローカルクライアントが接続するサーバーとの間の SASL コントラクトによって保護されます。このセキュリティーメカニズムは、ローカルファイルシステムにアクセスするクライアントの機能に基づきます。ローカルシステムへアクセスできるとクライアントによるユーザーの追加が可能で、他のセキュリティーメカニズムを無効にするよう設定を変更できるからです。これにより、ファイルシステムへ物理的にアクセスできると、他のセキュリティーメカニズムが不要になるという原則が厳守されます。このメカニズムは 4 つの手順で実現されます。
注記
HTTP を使用してローカルホストへ接続する場合でも、HTTP のアクセスはリモートと見なされます。- ローカル SASL メカニズムを用いて認証する要求が含まれるメッセージをクライアントがサーバーに送信します。
- サーバーはワンタイムトークンを生成し、固有のファイルに書き込み、ファイルのフルパスが含まれるメッセージをクライアントへ送信します。
- クライアントはファイルよりトークンを読み取り、サーバーへ送信し、ファイルシステムへローカルアクセスできるかを検証します。
- サーバーはトークンを検証し、ファイルを削除します。
- ローカル HTTP クライアントを含むリモートクライアントはレルムベースのセキュリティーを使用します。管理インターフェースを使用して JBoss EAP 6 インスタンスをリモートで設定するパーミッションを持つデフォルトのレルムは
ManagementRealmです。このレルム (またはユーザーが作成したレルム) にユーザーを追加できるスクリプトが提供されます。ユーザーごとに、ユーザー名とハッシュ化されたパスワードがファイルに保存されます。- 管理対象ドメイン
EAP_HOME/domain/configuration/mgmt-users.properties- スタンドアロンサーバー
EAP_HOME/standalone/configuration/mgmt-users.properties
mgmt-users.propertiesの内容はマスクされていますが、機密ファイルとして扱う必要があります。ファイルモードを、ファイル所有者による読み書きのみが許可される600に設定することが推奨されます。
5.2. 管理インターフェースの詳細設定の概要 リンクのコピーリンクがクリップボードにコピーされました!
EAP_HOME/domain/configuration/host.xml または EAP_HOME/standalone/configuration/standalone.xml の管理インターフェース設定は、ホストコントローラープロセスのバインド先となるネットワークインターフェース、利用可能な管理インターフェースのタイプ、および各インターフェースのユーザーを認証するために使用される認証システムのタイプを制御します。本トピックでは、ご使用の環境に合わせて管理インターフェースを設定する方法について説明します。
<management> 要素で構成されます。セキュリティレルムと送信接続はそれぞれ最初に定義されてから、管理インターフェースに属性として適用されます。
- <security-realms>
- <outbound-connections>
- <management-interfaces>
- <audit-log>
注記
セキュリティーレルムは、管理 API、管理 CLI、または Web ベースの管理コンソールを介して JBoss EAP 6 の管理を許可されているユーザーの認証と承認を行います。
ManagementRealm と ApplicationRealm です。これらのセキュリティーレルムはそれぞれ -users.properties ファイルを使用してユーザーおよびハッシュ化されたパスワードを保存し、-roles.properties を使用してユーザーとロール間のマッピングを保存します。サポートは LDAP 対応のセキュリティーレルムにも含まれています。
注記
一部のセキュリティーレルムは、LDAP サーバーなどの外部インターフェースに接続します。送信接続は、この接続の確立方法を定義します。 事前に定義された接続タイプ ldap-connection は、LDAP サーバーに接続してクレデンシャルを検証するための必須およびオプションの属性をすべて設定します。
管理インターフェースには、JBoss EAP の接続および設定方法に関するプロパティーが含まれています。この情報には、名前付きのネットワークインターフェース、ポート、セキュリティーレルム、およびインターフェースに関するその他の設定可能な情報が含まれます。デフォルトのインストールには 2 つのインターフェースが含まれています。
http-interfaceは Web ベースの管理コンソールの設定です。native-interfaceはコマンドライン管理 CLI および REST ライクな管理 API の設定です。
5.3. HTTP 管理インターフェースの無効化 リンクのコピーリンクがクリップボードにコピーされました!
注記
console-enabled 属性 を false に設定できます。
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=false)
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=false)
例5.1 HTTP インターフェースの設定の読み込み
例5.2 HTTP インターフェースの削除
/host=master/core-service=management/management-interface=http-interface/:remove
/host=master/core-service=management/management-interface=http-interface/:remove
例5.3 HTTP インターフェースの再作成
/host=master/core-service=management/management-interface=http-interface:add(console-enabled=true,interface=management,port="${jboss.management.http.port:9990}",security-realm=ManagementRealm)
/host=master/core-service=management/management-interface=http-interface:add(console-enabled=true,interface=management,port="${jboss.management.http.port:9990}",security-realm=ManagementRealm)
5.4. デフォルトセキュリティーレルムからのサイレント認証の削除 リンクのコピーリンクがクリップボードにコピーされました!
JBoss EAP 6 には、ローカル管理 CLI ユーザーに対するサイレント認証方法が含まれます。これにより、ローカルユーザーは、ユーザー名またはパスワード認証なしで管理 CLI にアクセスできるようになります。この機能は、利便性のために有効であり、ローカルユーザーが認証なしで管理 CLI スクリプトを実行する場合に役に立ちます。この機能は、ローカル設定へのアクセスにより、ユーザーが独自のユーザー詳細を追加できる (または、セキュリティーチェックを無効にする) ため、役に立つ機能です。
security-realm セクション内で local 要素を削除することにより、実現できます。これは、スタンドアロンサーバーインスタンス用の standalone.xml と管理対象ドメイン用の host.xml の両方に適用されます。特定のサーバー設定への影響について理解している場合のみ、local 要素の削除を考慮するようにしてください。
local 要素を直接削除することです。
例5.4 security-realm の local 要素の例
要件
- JBoss EAP 6 インスタンスを起動します。
- 管理 CLI を起動します。
手順5.1 デフォルトセキュリティーレルムからのサイレント認証の削除
管理 CLI でのサイレント認証の削除
必要に応じて、管理レルムとアプリケーションレルムからlocal要素を削除します。- 管理レルムから
local要素を削除します。スタンドアロンの場合
/core-service=management/security-realm=ManagementRealm/authentication=local:remove
/core-service=management/security-realm=ManagementRealm/authentication=local:removeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 管理対象ドメインの場合
/host=HOST_NAME/core-service=management/security-realm=ManagementRealm/authentication=local:remove
/host=HOST_NAME/core-service=management/security-realm=ManagementRealm/authentication=local:removeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- アプリケーションレルムから
local要素を削除します。スタンドアロンの場合
/core-service=management/security-realm=ApplicationRealm/authentication=local:remove
/core-service=management/security-realm=ApplicationRealm/authentication=local:removeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 管理対象ドメインの場合
/host=HOST_NAME/core-service=management/security-realm=ApplicationRealm/authentication=local:remove
/host=HOST_NAME/core-service=management/security-realm=ApplicationRealm/authentication=local:removeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
サイレント認証モードが、ManagementRealm と ApplicationRealm から削除されます。
5.5. JMX サブシステムへのリモートアクセスの無効化 リンクのコピーリンクがクリップボードにコピーされました!
/profile=default 接頭辞を削除してください。
注記
例5.5 JMX サブシステムからのリモートコネクターの削除
/profile=default/subsystem=jmx/remoting-connector=jmx/:remove
/profile=default/subsystem=jmx/remoting-connector=jmx/:remove
例5.6 JMX サブシステムの削除
/profile=default/subsystem=jmx/:remove
/profile=default/subsystem=jmx/:remove
5.6. 管理インターフェースのセキュリティーレルムの設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、管理インターフェースは ManagementRealm セキュリティーレルムを使用するよう設定されています。ManagementRealm はユーザーとパスワードの組み合わせを mgmt-users.properties ファイルに格納します。
例5.7 デフォルトの ManagementRealm
以下のコマンドは TestRealm というセキュリティーレルムを作成し、関連するプロパティーファイルのディレクトリーを設定します。
例5.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)
/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)
セキュリティードメインを使用して管理インターフェースに対して認証を行うには、以下の手順に従います。
security-realm 属性の値として指定します。
例5.9 HTTP 管理インターフェースに使用するセキュリティーレルムの指定
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=TestRealm)
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=TestRealm)
5.7. HTTPS の管理コンソールの設定 リンクのコピーリンクがクリップボードにコピーされました!
standalone および domain モード設定の両方に適用されます。domain モードでは、/host=master のように、ホストの名前を管理 CLI コマンドの前に追加します。
手順5.2
キーストアを作成し、管理コンソールをセキュアにします。
注記
管理コンソールは JCEKS 形式のキーストアと互換性がないため、このキーストアは JKS 形式でなければなりません。ターミナルエミュレーターで以下のコマンドを入力します。alias、keypass、keystore、storepass、およびdnameパラメーターは、例の値を指定する値に置き換えます。validityパラメーターは鍵の有効期間を日数で指定します。値 730 は 2 年間になります。keytool -genkeypair -alias appserver -storetype jks -keyalg RSA -keysize 2048 -keypass password1 -keystore EAP_HOME/standalone/configuration/identity.jks -storepass password1 -dname "CN=appserver,OU=Sales,O=Systems Inc,L=Raleigh,ST=NC,C=US" -validity 730 -v
keytool -genkeypair -alias appserver -storetype jks -keyalg RSA -keysize 2048 -keypass password1 -keystore EAP_HOME/standalone/configuration/identity.jks -storepass password1 -dname "CN=appserver,OU=Sales,O=Systems Inc,L=Raleigh,ST=NC,C=US" -validity 730 -vCopy to Clipboard Copied! Toggle word wrap Toggle overflow 管理コンソールが HTTPS へバインドすることを確認します。
スタンドアロンモード
management-httpsを追加し、management-httpを削除して、管理コンソールがインターフェースに対するHTTPSへバインドするようにします。JBoss EAP インスタンスが実行されていることを確認した後、以下の管理 CLI コマンドを入力します。/core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)
/core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)Copy to Clipboard Copied! Toggle word wrap Toggle overflow /core-service=management/management-interface=http-interface:undefine-attribute(name=socket-binding)
/core-service=management/management-interface=http-interface:undefine-attribute(name=socket-binding)Copy to Clipboard Copied! Toggle word wrap Toggle overflow これらのコマンド実行後、以下のような出力が表示されるはずです。{"outcome" => "success"}{"outcome" => "success"}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記
この時点で、JBoss EAP のログに以下のようなエラーメッセージが表示されることがありますが、この時点では SSL の設定が完了していないため表示されます。JBAS015103: A secure port has been specified for the HTTP interface but no SSL configuration in the realm.
JBAS015103: A secure port has been specified for the HTTP interface but no SSL configuration in the realm.Copy to Clipboard Copied! Toggle word wrap Toggle overflow ドメインモード
secure-port を追加し、ポート設定を削除して、management-interface セクション内でソケット要素を変更します。JBoss EAP インスタンスが実行されていることを確認した後、以下の管理 CLI コマンドを入力します。/host=master/core-service=management/management-interface=http-interface:write-attribute(name=secure-port,value=9443) /host=master/core-service=management/management-interface=http-interface:undefine-attribute(name=port)
/host=master/core-service=management/management-interface=http-interface:write-attribute(name=secure-port,value=9443) /host=master/core-service=management/management-interface=http-interface:undefine-attribute(name=port)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記
この時点で、JBoss EAP のログに以下のようなエラーメッセージが表示されることがありますが、この時点では SSL の設定が完了していないため表示されます。JBAS015103: A secure port has been specified for the HTTP interface but no SSL configuration in the realm.
JBAS015103: A secure port has been specified for the HTTP interface but no SSL configuration in the realm.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
任意設定: カスタム socket-binding グループ
カスタムsocket-bindingグループを使用している場合は、management-httpsバインディングが定義されているようにしてください (このバインディングはデフォルトで存在し、ポート9443へバインドされます)。マスター設定ファイル (例:standalone.xml) が以下のとおりになるよう編集します。<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}"> <socket-binding name="management-native" interface="management" port="${jboss.management.native.port:9999}"/> <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9443}"/><socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}"> <socket-binding name="management-native" interface="management" port="${jboss.management.native.port:9999}"/> <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9443}"/>Copy to Clipboard Copied! Toggle word wrap Toggle overflow セキュリティーレルムを新たに作成します。
以下のコマンドを実行し、ManagementRealmHTTPSという名前の新しいセキュリティーレルムを作成します。/host=master/core-service=management/security-realm=ManagementRealmHTTPS/:add /host=master/core-service=management/security-realm=ManagementRealmHTTPS/authentication=properties/:add(path=ManagementUsers.properties, relative-to=jboss.domain.config.dir)
/host=master/core-service=management/security-realm=ManagementRealmHTTPS/:add /host=master/core-service=management/security-realm=ManagementRealmHTTPS/authentication=properties/:add(path=ManagementUsers.properties, relative-to=jboss.domain.config.dir)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいセキュリティーを使用するよう管理インターフェースを設定します。
以下のコマンドを入力します。/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=ManagementRealmHTTPS)
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=ManagementRealmHTTPS)Copy to Clipboard Copied! Toggle word wrap Toggle overflow キーストアを使用するよう管理コンソールを設定します。
以下の管理 CLI コマンドを入力します。file、passwordおよびaliasパラメーターの値は、「1. キーストアを作成し、管理コンソールをセキュアにします。」の値を使用する必要があります。/core-service=management/security-realm=ManagementRealmHTTPS/server-identity=ssl:add(keystore-path=identity.jks,keystore-relative-to=jboss.server.config.dir, keystore-password=password1, alias=appserver)
/core-service=management/security-realm=ManagementRealmHTTPS/server-identity=ssl:add(keystore-path=identity.jks,keystore-relative-to=jboss.server.config.dir, keystore-password=password1, alias=appserver)Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンド実行後、以下のような出力が表示されるはずです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow JBoss EAP サーバーを再起動します。
サーバーを再起動すると、以下がログに記録されるはずです (起動したサービスの数を表すテキストの直前)。管理コンソールがポート 9443 でリッスンします。これは手順が適切に実行されたことを示します。14:53:14,720 INFO [org.jboss.as] (Controller Boot Thread) JBAS015962: Http management interface listening on https://127.0.0.1:9443/management 14:53:14,721 INFO [org.jboss.as] (Controller Boot Thread) JBAS015952: Admin console listening on https://127.0.0.1:9443
14:53:14,720 INFO [org.jboss.as] (Controller Boot Thread) JBAS015962: Http management interface listening on https://127.0.0.1:9443/management 14:53:14,721 INFO [org.jboss.as] (Controller Boot Thread) JBAS015952: Admin console listening on https://127.0.0.1:9443Copy to Clipboard Copied! Toggle word wrap Toggle overflow
注記
5.8. 管理インターフェースへの HTTP および HTTPS 接続に異なるインターフェースを使用 リンクのコピーリンクがクリップボードにコピーされました!
interface 属性によって指定されたインターフェースとは異なるインターフェースを使用する場合、secure-interface 属性が HTTPS 管理通信のホストのソケットを開くネットワークインターフェースを指定します。この属性を指定しないと、interface 属性によって指定されたインターフェースが使用されます。
secure-port 属性が設定されていなくても secure-interface 属性には影響はありません。
secure-interface 属性が設定されている EAP_HOME/domain/configuration/host.xml の設定例は次のとおりです。
5.9. 管理インターフェースおよび CLI に対する双方向 SSL の使用 リンクのコピーリンクがクリップボードにコピーされました!
- HOST1
- JBoss サーバーホスト名 (例:
jboss.redhat.com)。 - HOST2
- クライアントに適した名前 (例:
myclient)。実際のホスト名でないことがあります。 - CA_HOST1
- HOST1 証明書に使用する DN (識別名)(例:
cn=jboss,dc=redhat,dc=com)。 - CA_HOST2
- HOST2 証明書に使用する DN (識別名)(例:
cn=myclient,dc=redhat,dc=com)。
要件
- パスワード vault を使用してキーストアおよびトラストストアのパスワードを格納する場合 (推奨方法)、パスワード vault は作成済みのはずです。「パスワード valut システム」を参照してください。
手順5.3
- ストアを生成します。
keytool -genkeypair -alias HOST1_alias -keyalg RSA -keysize 1024 -validity 365 -keystore host1.keystore.jks -dname "CA_HOST1" -keypass secret -storepass secret
keytool -genkeypair -alias HOST1_alias -keyalg RSA -keysize 1024 -validity 365 -keystore host1.keystore.jks -dname "CA_HOST1" -keypass secret -storepass secretCopy to Clipboard Copied! Toggle word wrap Toggle overflow keytool -genkeypair -alias HOST2_alias -keyalg RSA -keysize 1024 -validity 365 -keystore host2.keystore.jks -dname "CA_HOST2" -keypass secret -storepass secret
keytool -genkeypair -alias HOST2_alias -keyalg RSA -keysize 1024 -validity 365 -keystore host2.keystore.jks -dname "CA_HOST2" -keypass secret -storepass secretCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 証明書をエクスポートします。
keytool -exportcert -keystore HOST1.keystore.jks -alias HOST1_alias -keypass secret -storepass secret -file HOST1.cer
keytool -exportcert -keystore HOST1.keystore.jks -alias HOST1_alias -keypass secret -storepass secret -file HOST1.cerCopy to Clipboard Copied! Toggle word wrap Toggle overflow keytool -exportcert -keystore HOST2.keystore.jks -alias HOST2_alias -keypass secret -storepass secret -file HOST2.cer
keytool -exportcert -keystore HOST2.keystore.jks -alias HOST2_alias -keypass secret -storepass secret -file HOST2.cerCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 証明書を反対のトラストストアにインポートします。
keytool -importcert -keystore HOST1.truststore.jks -storepass secret -alias HOST2_alias -trustcacerts -file HOST2.cer
keytool -importcert -keystore HOST1.truststore.jks -storepass secret -alias HOST2_alias -trustcacerts -file HOST2.cerCopy to Clipboard Copied! Toggle word wrap Toggle overflow keytool -importcert -keystore HOST2.truststore.jks -storepass secret -alias HOST1_alias -trustcacerts -file HOST1.cer
keytool -importcert -keystore HOST2.truststore.jks -storepass secret -alias HOST1_alias -trustcacerts -file HOST1.cerCopy to Clipboard Copied! Toggle word wrap Toggle overflow - インストールの設定に CertificateRealm を定義し (
host.xmlまたはstandalone.xml)、インターフェースがそれを示すようにします。これを行うには、設定ファイルを手作業で編集するか (非推奨)、以下のコマンドを使用します。/core-service=management/security-realm=CertificateRealm:add()
/core-service=management/security-realm=CertificateRealm:add()Copy to Clipboard Copied! Toggle word wrap Toggle overflow /core-service=management/security-realm=CertificateRealm/server-identity=ssl:add(keystore-path=/path/to/HOST1.keystore.jks,keystore-password=secret, alias=HOST1_alias)
/core-service=management/security-realm=CertificateRealm/server-identity=ssl:add(keystore-path=/path/to/HOST1.keystore.jks,keystore-password=secret, alias=HOST1_alias)Copy to Clipboard Copied! Toggle word wrap Toggle overflow /core-service=management/security-realm=CertificateRealm/authentication=truststore:add(keystore-path=/path/to/HOST1.truststore.jks,keystore-password=secret)
/core-service=management/security-realm=CertificateRealm/authentication=truststore:add(keystore-path=/path/to/HOST1.truststore.jks,keystore-password=secret)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要
これらのコマンドはスタンドアロンモードのみに提供されます。ドメインモードでは各コマンドの前に/host=masterを追加します。 - ネイティブインターフェースの
security-realmを新しい証明書レルムに変更します。/host=master/core-service=management/management-interface=native-interface:write-attribute(name=security-realm,value=CertificateRealm)
/host=master/core-service=management/management-interface=native-interface:write-attribute(name=security-realm,value=CertificateRealm)Copy to Clipboard Copied! Toggle word wrap Toggle overflow EAP_HOME/bin/jboss-cli.xmlを設定ファイルとして使用する CLI の SSL 設定を追加します。パスワード vault を使用してキーストアおよびトラストストアのパスワードを保存するか (推奨方法)、プレーンテキストで保存します。- パスワード vault でキーストアおよびトラストストアのパスワードを保存する方法
EAP_HOME/bin/jboss-cli.xmlを編集し、SSL 設定を追加します (変数に適切な値を使用します)。また、vault の設定を追加します (各値をご使用の vault の値に置き換えます)。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - プレーンテキストでキーストアおよびトラストストアのパスワードを保存する方法
EAP_HOME/bin/jboss-cli.xmlを編集し、SSL 設定を追加します (変数に適切な値を使用します)。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.10. JAAS を用いた管理インタフェースのセキュア化 リンクのコピーリンクがクリップボードにコピーされました!
/subsystem=security/security-domain=UsersLMDomain:add(cache-type=default) /subsystem=security/security-domain=UsersLMDomain/authentication=classic:add /subsystem=security/security-domain=UsersLMDomain/authentication=classic/login-module=UsersRoles:add()
/subsystem=security/security-domain=UsersLMDomain:add(cache-type=default)
/subsystem=security/security-domain=UsersLMDomain/authentication=classic:add
/subsystem=security/security-domain=UsersLMDomain/authentication=classic/login-module=UsersRoles:add()
/core-service=management/security-realm=SecurityDomainAuthnRealm:add /core-service=management/security-realm=SecurityDomainAuthnRealm/authentication=jaas:add(name=UsersLMDomain)
/core-service=management/security-realm=SecurityDomainAuthnRealm:add
/core-service=management/security-realm=SecurityDomainAuthnRealm/authentication=jaas:add(name=UsersLMDomain)
assign-groups 属性は、セキュリティードメインからロードされたユーザーメンバーシップ情報がセキュリティーレルムのグループ割り当てに使用されるかどうかを決定します。true に設定すると、このグループの割り当てが RBAC (ロールベースアクセス制御) に使用されます。
assign-groups 属性を true に設定できます。
/core-service=management/security-realm=ManagementRealm/authentication=jaas:write-attribute(name=assign-groups,value=true)
/core-service=management/security-realm=ManagementRealm/authentication=jaas:write-attribute(name=assign-groups,value=true)
5.11. LDAP リンクのコピーリンクがクリップボードにコピーされました!
5.11.1. LDAP リンクのコピーリンクがクリップボードにコピーされました!
5.11.2. 管理インターフェースに対する LDAP を使用した認証 リンクのコピーリンクがクリップボードにコピーされました!
- LDAP サーバーへの送信接続を作成します。
- LDAP 対応のセキュリティーレルムを作成します。
- 管理インターフェースの新規セキュリティードメインを参照します。
LDAP 送信接続には、以下の属性を使用することができます。
| 属性 | 必須 | 説明 |
|---|---|---|
url | 必要 |
ディレクトリーサーバーの URL アドレス。
|
search-dn | 不要 |
検索の実行を許可されているユーザーの完全識別名 (DN)
|
search-credentials | 不要 |
検索の実行を許可されているユーザーのパスワード。
|
initial-context-factory | 不要 |
接続を確立する際に使用する初期コンテキストファクトリー。デフォルトでは
com.sun.jndi.ldap.LdapCtxFactory に設定されています。
|
security-realm | 不要 |
接続を確立するときに、使用する設定済みの
SSLContext を取得するために参照するセキュリティーレルム。
|
例5.10 LDAP 送信接続の追加
- DN の検索:
cn=search,dc=acme,dc=com - 証明情報の検索:
myPass - URL:
ldap://127.0.0.1:389
/host=master/core-service=management/security-realm=ldap_security_realm:add
/host=master/core-service=management/security-realm=ldap_security_realm:add
/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")
/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")
管理インターフェースは、デフォルトで設定されているプロパティーファイルをベースとするセキュリティーレルムの代わりに LDAP サーバーに対して認証を行うことができます。LDAP のオーセンティケーターは、最初にリモートディレクトリーサーバーへの接続を確立します。次に、LDAP レコードの完全修飾識別名 (DN) を探すため、ユーザーが認証システムに渡したユーザー名を使用して検索を実行します。クレデンシャルとしてユーザーの DN とユーザー提供のパスワードを使用して、新規接続が確立されます。 この LDAP サーバーに対するこの検証に成功すると、DN が有効であることが検証されます。
- connection
- LDAP ディレクトリーへ接続するために使用される
outbound-connectionsに定義されている接続の名前。 - advanced-filter
- 指定のユーザー ID を基にユーザーを検索するのに使用される完全に定義されたフィルター。フィルターには
{0}という形式の変数が含まれている必要があります。これは、後でユーザー指定のユーザー名に置き換えられます。 - base-dn
- ユーザー検索を開始するためのコンテキストの識別名
- recursive
- LDAP ディレクトリーツリー全体にわたって再帰的に検索を行うか、指定のコンテキストのみを検索するかを指定します。デフォルトでは
falseに設定されています。 - user-dn
- 識別名を保持するユーザーの属性。これは、後で認証のテストに使用されます。デフォルトでは
dnに設定されています。 - username-attribute
- ユーザーを検索するための属性の名前。このフィルターは、ユーザーによって入力されたユーザー名が指定の属性と一致する簡単な検索を行います。
- allow-empty-passwords
- この属性は、空白のパスワードが許可されるかどうかを決定します。この属性のデフォルト値は
falseです。 username-filterまたはadvanced-filterを指定する必要があります。advanced-filter属性には、標準の LDAP 構文のフィルタークエリーが含まれています。例を以下に示します。(&(sAMAccountName={0})(memberOf=cn=admin,cn=users,dc=acme,dc=com))(&(sAMAccountName={0})(memberOf=cn=admin,cn=users,dc=acme,dc=com))Copy to Clipboard Copied! Toggle word wrap Toggle overflow
例5.11 LDAP 対応のセキュリティーレルムを示す XML
- connection -
ldap_connection - base-dn -
cn=users,dc=acme,dc=com. - username-filter -
attribute="sambaAccountName"
警告
例5.12 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")
/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 ダイジェスト認証用のセキュリティーレルムを使用します。
例5.13 HTTP インターフェースへのセキュリティーレルムの適用
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=ldap_security_realm)
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=ldap_security_realm)
例5.14 セキュリティーレルムのネイティブインターフェースへの適用
/host=master/core-service=management/management-interface=native-interface/:write-attribute(name=security-realm,value=ldap_security_realm)
/host=master/core-service=management/management-interface=native-interface/:write-attribute(name=security-realm,value=ldap_security_realm)
5.11.3. 管理インターフェースおよび CLI の双方向 SSL でアウトバウンド LDAP を使用 リンクのコピーリンクがクリップボードにコピーされました!
手順5.4 双方向 SSL でのアウトバウンド LDAP の設定
- セキュリティーレルムのキーストアおよびトラストストアを設定します。セキュリティーレルムには、LDAP サーバーに対して認証を行うために JBoss EAP 6 サーバーが使用するキーを用いて設定されたキーストアが含まれている必要があります。また、セキュリティーレルムには LDAP サーバーの証明書を用いて設定されたトラストストアが含まれている必要もあります。キーストアとトラストストアの設定方法は、「管理インターフェースおよび CLI に対する双方向 SSL の使用」を参照してください。
- 設定されたセキュリティーレルムを指定し、LDAP サーバーへアウトバウンド接続を追加します。
/core-service=management/ldap-connection=LocalLdap:add(url="ldaps://LDAP_HOST:LDAP_PORT") /core-service=management/ldap-connection=LocalLdap:write-attribute(name=security-realm,value="LdapSSLRealm")
/core-service=management/ldap-connection=LocalLdap:add(url="ldaps://LDAP_HOST:LDAP_PORT") /core-service=management/ldap-connection=LocalLdap:write-attribute(name=security-realm,value="LdapSSLRealm")Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 「管理インターフェースに対する LDAP を使用した認証」に示されたとおり、セキュリティーレルムおよび管理インターフェース内に LDAP 認証を設定します。
第6章 ロールベースアクセス制御を用いた管理インターフェースのセキュア化 リンクのコピーリンクがクリップボードにコピーされました!
6.1. ロールベースアクセス制御 (RBAC) リンクのコピーリンクがクリップボードにコピーされました!
6.2. 管理コンソールおよび CLI でのロールベースアクセス制御 リンクのコピーリンクがクリップボードにコピーされました!
- 管理コンソール
- 管理コンソールでは、ユーザーに割り当てられたロールのパーミッションによっては、制御およびビューの一部が無効化 (灰色で表示) されたり、全く表示されないことがあります。リソース属性に対する読み取りパーミッションがない場合、その属性は管理コンソールでは空白で表示されます。たとえば、ほとんどのロールは、データソースのユーザー名およびパスワードフィールドを読み取りできません。リソース属性に対する書き込みパーミッションがない場合、その属性はリソースの編集フォームで無効化 (灰色で表示) されます。リソースに対する書き込みパーミッションがない場合、リソースの編集ボタンは表示されません。ユーザーがリソースまたは属性へアクセスするパーミッションを持たない場合 (ロールに対して「アドレス不可能」な場合)、コンソールではそのユーザーに対するリソースまたは属性が表示されません。アクセス制御システム自体がこの例で、デフォルトでは少数のロールのみに対して表示されます。
- 管理 CLI または API
- RBAC が有効である場合、API での 管理 CLI や管理 API の動作が若干異なります。読み取りできないリソースや属性は結果からフィルターされます。フィルターされた項目がロールによってアドレス可能である場合、結果の
response-headersセクションにこれらの名前がfiltered-attributesとしてリストされます。リソースまたは属性がロールによってアドレス可能でない場合は、リストされません。アドレス不可能なリソースにアクセスしようとすると、resource not found(リソースが見つかりません) というエラーが発生します。適切な読み書きパーミッションのないユーザーが、アドレス可能なリソースを読み書きしようとすると、Permission Denied(パーミッションが拒否されました) というエラーが返されます。
6.3. サポートされる認証スキーム リンクのコピーリンクがクリップボードにコピーされました!
username/password、client certificate、および local user です。
- Username/Password
- ユーザーはユーザー名とパスワードの組み合わせを使用して認証されます。この組み合わせは、
mgmt-users.propertiesファイルまたは LDAP サーバーに対して検証されます。 - Client Certificate
- トラストストアを使用します。
- Local User
- 同じマシン上で実行されているサーバーの場合、
jboss-cli.shは自動的に Local User として認証します。デフォルトでは、Local User はSuperUserグループのメンバーになります。
mgmt-users.properties ファイルまたは LDAP サーバーで認証する場合、これらのシステムはユーザーグループ情報を提供できます。ユーザーグループ情報は、ロールをユーザーに割り当てるために JBoss EAP が使用することも可能です。
6.4. 標準のロール リンクのコピーリンクがクリップボードにコピーされました!
- Monitor
- Monitor ロールのユーザーは、最も少ないパーミッションを持ち、現在の設定およびサーバーの状態のみを読み取りできます。これは、サーバーのパフォーマンスを追跡し、報告する必要があるユーザー向けのロールです。Monitor はサーバー設定を変更したり、機密データおよび操作にアクセスしたりできません。
- Operator
- Operator ロールは、サーバーのランタイム状態を変更する機能を追加して、Monitor ロールを拡張します。これにより、Operator はサーバーをリロードおよびシャットダウンでき、JMS 宛先を一時停止および再開できます。Operator ロールは、アプリケーションサーバーの物理または仮想ホストを管理するユーザーに向いており、必要時にサーバーが正しくシャットダウンおよび再起動されるようにします。Operator はサーバー設定を変更したり、機密データおよび操作にアクセスしたりできません。
- Maintainer
- Maintainer ロールは、機密データおよび操作以外のすべての設定と、ランタイム状態を表示および変更できます。Maintainer ロールは、機密データおよび操作へアクセスできない汎用のロールです。Maintainer ロールは、パスワードやその他の機密情報へのアクセス権限を付与せずに、ユーザーがサーバーをほぼ完全に管理できるようにします。Maintainer は機密データまたは操作へアクセスできません。
- Administrator
- Administrator ロールは、監査ロギングシステムを除くサーバー上のすべてのリソースおよび操作へ無制限にアクセスできます。Administrator ロールは、機密のデータおよび操作へアクセスできます。このロールはアクセス制御システムも設定できます。Administrator ロールは、機密データを処理する場合や、ユーザーとロールを設定する場合のみ必要です。Administrator は監査ロギングシステムへアクセスできず、Administrator 自身を Auditor または SuperUser ロールへ変更できません。
- SuperUser
- SuperUser ロールには制限がなく、監査ロギングシステムを含むサーバーのすべてのリソースおよび操作へ完全にアクセスできます。このロールは、以前のバージョンの JBoss EAP 6 (6.0 および 6.1) での管理者ユーザーと同等です。RBAC が無効である場合、すべての管理ユーザーは SuperUser ロールと同等のパーミッションを持ちます。
- Deployer
- Deployer ロールは Monitor と同じパーミッションを持ちますが、デプロイメントの設定や状態を変更でき、アプリケーションリソースとして有効になっている他のリソースタイプも変更できます。
- Auditor
- Auditor ロールは Monitor ロールと同じパーミッションを持ちますが、機密データを表示でき (変更はできません)、監査ロギングシステムへ完全にアクセスできます。Auditor ロールは SuperUser ロール以外で唯一監査ログインシステムへアクセスできるロールです。Auditor は機密データやリソースを変更できません。読み取りのみが許可されます。
6.5. ロールパーミッション リンクのコピーリンクがクリップボードにコピーされました!
|
Monitor
|
Operator
|
Maintainer
|
Deployer
|
Auditor
|
Administrator
|
SuperUser
| |
|
設定と状態の読み取り
|
○
|
○
|
○
|
○
|
○
|
○
|
○
|
|
機密データの読み取り [2]
|
○
|
○
|
○
| ||||
|
機密データの変更 [2]
|
○
|
○
| |||||
|
監査ログの読み取り/変更
|
○
|
○
| |||||
|
起動状態の変更
|
○
|
○
|
○[1]
|
○
|
○
| ||
|
永続化設定の変更
|
○
|
○[1]
|
○
|
○
| |||
|
アクセス制御の読み取り/変更
|
○
|
○
|
6.6. 制約 リンクのコピーリンクがクリップボードにコピーされました!
- アプリケーション制約
- アプリケーション制約は、Deployer ロールのユーザーがアクセスできるリソースおよび属性のセットを定義します。デフォルトでは、有効になっているアプリケーション制約は、デプロイメントやデプロイメントオーバーレイが含まれるコアのみです。また、アプリケーション制約はデータソース、ロギング、メール、メッセージング、ネーミング、リソースアダプター、およびセキュリティーに対しても含まれますが、デフォルトでは有効になっていません。これらの制約により、Deployer ユーザーはアプリケーションをデプロイできるだけでなく、これらのアプリケーションが必要とするリソースを設定および維持できます。アプリケーション制約の設定は、管理 API の
/core-service=management/access=authorization/constraint=application-classificationにあります。 - 機密性制約
- 機密性制約は、「機密」とされるリソースのセットを定義します。通常、機密リソースとは、パスワードなどの秘密のリソースや、ネットワーキング、JVM 設定、システムプロパティーなどのサーバー操作に深刻な影響を与えるリソースのことを言います。アクセス制御システム自体も機密であるとみなされます。機密リソースへの書き込みを許可されるロールは、Administrator と SuperUser のみです。Auditor ロールは、機密リソースの読み取りのみ可能です。他のロールは機密リソースへアクセスできません。機密性制約の設定は、管理 API の
/core-service=management/access=authorization/constraint=sensitivity-classificationにあります。 - Vault 式の制約
- vault 式制約は、vault 式の読み取りまたは書き込みが機密操作としてみなされるかどうかを定義します。デフォルトでは、vault 式の読み書き両方が機密操作とみなされます。vault 式制約の設定は、管理 API の
/core-service=management/access=authorization/constraint=vault-expressionにあります。
6.7. JMX およびロールベースアクセス制御 リンクのコピーリンクがクリップボードにコピーされました!
- JBoss EAP 6 の管理 API は JXM 管理 Bean として公開されます。これらの管理 Bean は「コア MBean」と呼ばれ、コア MBean へのアクセスは基盤の管理 API と全く同じように制御およびフィルターされます。
- JMX サブシステムは、書き込みパーミッションが「機密」で設定されます。そのため、Administrator および SuperUser ロールのユーザーのみがそのサブシステムに変更を追加できます。Auditor ロールのユーザーはこのサブシステムの設定を読み取りできます。
- デフォルトでは、デプロイされたアプリケーションおよびサービスによって登録された管理 Bean (コアでない MBean) へすべての管理ユーザーがアクセスできますが、Maintainer、Operator、Administrator、および SuperUser ロールのユーザーのみが書き込み可能です。
6.8. ロールベースアクセス制御の設定 リンクのコピーリンクがクリップボードにコピーされました!
6.8.1. RBAC 設定タスクの概要 リンクのコピーリンクがクリップボードにコピーされました!
- 各ユーザーへ割り当てられた (または除外された) ロールの表示および設定
- 各グループへ割り当てられた (または除外された) ロールの表示および設定。
- ロールごとのグループおよびユーザーメンバーシップの表示。
- ロールごとのデフォルトメンバーシップの設定。
- スコープ指定されたロールの作成。
- RBAC の有効化および無効化
- パーミッション組み合わせポリシーの変更
- アプリケーションリソースおよびリソース機密性の制約の設定
6.8.2. ロールベースアクセス制御の有効化 リンクのコピーリンクがクリップボードにコピーされました!
simple から rbac に変更します。この変更を行うには管理 CLI を使用しますが、サーバーがオフラインの場合はサーバー設定 XML ファイルを編集して変更できます。RBAC が稼働中のサーバー上で無効または有効になっている場合は、サーバー設定をリロードして変更を反映する必要があります。
SuperUser ロールとして実行されます。
手順6.1 RBAC の有効化
- 管理 CLI で RBAC を有効にするには、アクセス承認リソースの
write-attribute操作を使用して、プロバイダー属性をrbacに設定します。/core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
/core-service=management/access=authorization:write-attribute(name=provider, value=rbac)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow
手順6.2 RBAC の無効化
- 管理 CLI で RBAC を無効にするには、アクセス承認リソースの
write-attribute操作を使用して、プロバイダー属性をsimpleに設定します。/core-service=management/access=authorization:write-attribute(name=provider, value=simple)
/core-service=management/access=authorization:write-attribute(name=provider, value=simple)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow
access-control 要素にある provider 属性を編集します。有効にする場合は値を rbac に設定し、無効にする場合は simple に設定します。
6.8.3. パーミッション組み合わせポリシーの変更 リンクのコピーリンクがクリップボードにコピーされました!
permissive または rejecting に設定できます。デフォルトは permissive です。
permissive に設定されると、アクションを許可するロールがユーザーに割り当てられている場合に、そのアクションが許可されます。
rejecting に設定された場合、複数のロールが割り当てられたユーザーはすべてのアクションが禁止されます。そのため、ポリシーが rejecting に設定された場合は、各ユーザーに 1 つのロールのみが割り当てられるようにします。ポリシーが rejecting に設定されると、複数のロールが割り当てられたユーザーは管理コンソールや管理 CLI を使用できません。
permission-combination-policy 属性を permissive または rejecting に設定します。これは管理 CLI を使用して設定できますが、サーバーがオフラインの場合はサーバー設定 XML ファイルを編集して設定できます。
手順6.3 パーミッション組み合わせポリシーの設定
- アクセス承認リソースの
write-attribute操作を使用してpermission-combination-policy属性を必要なポリシー名に設定します。/core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=POLICYNAME)
/core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=POLICYNAME)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 有効なポリシー名は rejecting と permissive です。[standalone@localhost:9999 /] /core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=rejecting) {"outcome" => "success"} [standalone@localhost:9999 access=authorization][standalone@localhost:9999 /] /core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=rejecting) {"outcome" => "success"} [standalone@localhost:9999 access=authorization]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
permission-combination-policy 属性を編集します。
6.9. ロールの管理 リンクのコピーリンクがクリップボードにコピーされました!
6.9.1. ロールメンバーシップ リンクのコピーリンクがクリップボードにコピーされました!
- ユーザーが以下のいずれかである場合。
- ロールに含まれるユーザーとしてリストに記載されている。
- ロールに含まれるとリストに記載されたグループのメンバーである。
- ユーザーが以下のいずれかに該当しない場合。
- ロールから除外されるユーザーとしてリストに記載されている。
- ロールから除外されるとリストに記載されたグループのメンバーである。
6.9.2. ユーザーロール割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
SuperUser または Administrator ロールのユーザーのみです。
- 管理コンソールへログインします。
- タブをクリックします。
- Access Control メニューを展開し、 を選択します。
- タブを選択します。
手順6.4 ユーザーの新しいロール割り当ての作成
- 管理コンソールへログインします。
- Role Assignment セクションの タブに移動します。
- ユーザーリストの右上にある ボタンをクリックします。Add User ダイアログが表示されます。
図6.1 Add User ダイアログ
- ユーザー名を指定し、任意でレルムを指定します。
- Type メニューを include または exclude に設定します。
- include または exclude するロールのチェックボックスをクリックします。Control キー (OSX では Command キー) を押しながらクリックすると、複数のチェックボックスを選択できます。
- をクリックして終了します。正常に保存されると、Add User ダイアログが閉じられます。ユーザーのリストが更新され、変更内容が反映されます。正常に保存されなかった場合は、
Failed to save role assignmentというメッセージが表示されます。
手順6.5 ユーザーロール割り当ての更新
- 管理コンソールへログインします。
- Role Assignment セクションの タブに移動します。
- リストよりユーザーを選択します。
- をクリックします。選択パネルが編集モードになります。
図6.2 Selection Edit ビュー
ここで、ユーザーに割り当てられたロールや除外されたロールを追加および削除できます。- 割り当てられたロールを追加するには、左側の使用可能なロールのリストからロールを選択し、割り当てられたロールリストの横にある、右矢印のボタンをクリックします。ロールが、使用可能なロールのリストから割り当てられたロールのリストに移動します。
- 割り当てられたロールを削除するには、割り当てられたロールのリストからロールを選択し、割り当てられたロールリストの横にある左矢印のボタンをクリックします。ロールが、割り当てられたロールのリストから使用可能なロールのリストへ移動します。
- 除外されたロールを追加するには、左側の使用可能なロールのリストからロールを選択し、除外されたロールリストの横にある、右矢印のボタンをクリックします。ロールが、使用可能なロールのリストから除外されたロールのリストに移動します。
- 除外されたロールを削除するには、除外されたロールのリストからロールを選択し、除外されたロールリストの横にある左矢印のボタンをクリックします。ロールが、除外されたロールのリストから使用可能なロールのリストへ移動します。
- をクリックして終了します。正常に保存されると、編集ビューが閉じられます。ユーザーのリストが更新され、変更内容が反映されます。正常に保存されなかった場合は、
Failed to save role assignmentというメッセージが表示されます。
手順6.6 ユーザーのロール割り当ての削除
- 管理コンソールへログインします。
- Role Assignment セクションの タブへ移動します。
- リストよりユーザーを選択します。
- をクリックします。Remove Role Assignment 確認プロンプトが表示されます。
- をクリックします。正しく削除されると、ユーザーロール割り当てのリストにユーザーが表示されなくなります。
重要
6.9.3. 管理 CLI を用いたユーザーロール割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
role-mapping 要素とする /core-service=management/access=authorization にあります。
/core-service=management/access=authorization の場所を変更します。
[standalone@localhost:9999] cd /core-service=management/access=authorization
[standalone@localhost:9999] cd /core-service=management/access=authorization
手順6.7 ロール割り当て設定の表示
- :read-children-names 操作を使用して、設定されたロールの完全リストを取得します。
/core-service=management/access=authorization:read-children-names(child-type=role-mapping)
/core-service=management/access=authorization:read-children-names(child-type=role-mapping)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 指定されたロールマッピングの
read-resource操作を使用して、特定ロールの完全詳細を取得します。/core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)
/core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow
手順6.8 新規ロールの追加
add操作を使用して、新しいロール設定を追加します。/core-service=management/access=authorization/role-mapping=ROLENAME:add
/core-service=management/access=authorization/role-mapping=ROLENAME:addCopy to Clipboard Copied! Toggle word wrap Toggle overflow ROLENAME は新しいマッピングに対するロール名です。[standalone@localhost:9999 access=authorization] ./role-mapping=Auditor:add {"outcome" => "success"} [standalone@localhost:9999 access=authorization][standalone@localhost:9999 access=authorization] ./role-mapping=Auditor:add {"outcome" => "success"} [standalone@localhost:9999 access=authorization]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
手順6.9 ロールに include されるユーザーの追加
add操作を使用して、ユーザーエントリーをロールの include リストに追加します。/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=USERNAME, type=USER)
/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=USERNAME, type=USER)Copy to Clipboard Copied! Toggle word wrap Toggle overflow ROLENAME は設定されたロールの名前です。ALIASはこのマッピングの一意名です。Red Hat は、user-USERNAMEなどのエイリアスに命名規則を使用することを推奨します。USERNAME は、include リストに追加されたユーザーの名前です。[standalone@localhost:9999 access=authorization] ./role-mapping=Auditor/include=user-max:add(name=max, type=USER) {"outcome" => "success"} [standalone@localhost:9999 access=authorization][standalone@localhost:9999 access=authorization] ./role-mapping=Auditor/include=user-max:add(name=max, type=USER) {"outcome" => "success"} [standalone@localhost:9999 access=authorization]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
手順6.10 ロールに exclude されるユーザーの追加
add操作を使用して、ユーザーエントリーをロールの exclude リストに追加します。/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=USERNAME, type=USER)
/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=USERNAME, type=USER)Copy to Clipboard Copied! Toggle word wrap Toggle overflow ROLENAME は設定されたロールの名前です。USERNAME は、exclude リストに追加されたユーザーの名前です。ALIASはこのマッピングの一意名です。Red Hat は、user-USERNAMEなどのエイリアスに命名規則を使用することを推奨します。[standalone@localhost:9999 access=authorization] ./role-mapping=Auditor/exclude=user-max:add(name=max, type=USER) {"outcome" => "success"} [standalone@localhost:9999 access=authorization][standalone@localhost:9999 access=authorization] ./role-mapping=Auditor/exclude=user-max:add(name=max, type=USER) {"outcome" => "success"} [standalone@localhost:9999 access=authorization]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
手順6.11 ユーザーロールの include 設定の削除
remove操作を使用してエントリーを削除します。/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:removeCopy to Clipboard Copied! Toggle word wrap Toggle overflow ROLENAME は設定されたロールの名前です。ALIASはこのマッピングの一意名です。Red Hat は、user-USERNAMEなどのエイリアスに命名規則を使用することを推奨します。[standalone@localhost:9999 access=authorization] ./role-mapping=Auditor/include=user-max:remove {"outcome" => "success"} [standalone@localhost:9999 access=authorization][standalone@localhost:9999 access=authorization] ./role-mapping=Auditor/include=user-max:remove {"outcome" => "success"} [standalone@localhost:9999 access=authorization]Copy to Clipboard Copied! Toggle word wrap Toggle overflow include リストからユーザーを削除しても、ユーザーはシステムから削除されず、ロールがユーザーに割り当てられなくなる保証はありません。ロールはグループメンバーシップを基に割り当てられる可能性があります。
手順6.12 ユーザーロールの exclude 設定の削除
remove操作を使用してエントリーを削除します。/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:removeCopy to Clipboard Copied! Toggle word wrap Toggle overflow ROLENAME は設定されたロールの名前です。ALIASはこのマッピングの一意名です。Red Hat は、user-USERNAMEなどのエイリアスに命名規則を使用することを推奨します。[standalone@localhost:9999 access=authorization] ./role-mapping=Auditor/exclude=user-max:remove {"outcome" => "success"} [standalone@localhost:9999 access=authorization][standalone@localhost:9999 access=authorization] ./role-mapping=Auditor/exclude=user-max:remove {"outcome" => "success"} [standalone@localhost:9999 access=authorization]Copy to Clipboard Copied! Toggle word wrap Toggle overflow exclude リストからユーザーを削除しても、ユーザーはシステムから削除されず、ロールがユーザーに割り当てられる保証はありません。ロールはグループメンバーシップを基に除外される可能性があります。
6.9.4. ロールとユーザーグループ リンクのコピーリンクがクリップボードにコピーされました!
mgmt-users.properties ファイルまたは LDAP サーバーを使用して認証されるユーザーはユーザーグループのメンバーである可能性があります。ユーザーグループは、1 名以上のユーザーに割り当てできる任意のラベルです。
mgmt-users.properties ファイルを使用する場合、グループ情報は mgmt-groups.properties ファイルに保存されます。LDAP を使用する場合、グループ情報は LDAP サーバーに保存され、LDAP サーバーの管理者によって維持されます。
6.9.5. グループロール割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
SuperUser または Administrator ロールのユーザーのみです。
- 管理コンソールへログインします。
- タブをクリックします。
- メニューを展開し、 を選択します。
- タブを選択します。
手順6.13 グループの新しいロール割り当ての作成
- 管理コンソールへログインします。
- Role Assignment セクションの タブに移動します。
- ユーザーリストの右上にある ボタンをクリックします。Add Group ダイアログが表示されます。
図6.3 Add Group ダイアログ
- グループ名を指定し、任意でレルムを指定します。
- Type メニューを include または exclude に設定します。
- include または exclude するロールのチェックボックスをクリックします。Control キー (OSX では Command キー) を押しながらクリックすると、複数のチェックボックスを選択できます。
- をクリックして終了します。正常に保存されると、Add Group ダイアログが閉じられます。グループのリストが更新され、変更内容が反映されます。正常に保存されなかった場合は、
Failed to save role assignmentというメッセージが表示されます。
手順6.14 グループロール割り当ての更新
- 管理コンソールへログインします。
- Role Assignment セクションの タブへ移動します。
- リストよりグループを選択します。
- Edit をクリックします。Selection ビューが編集モードになります。
図6.4 Selection ビュー編集モード
ここで、グループに割り当てられたロールや除外されたロールを追加および削除できます。- 割り当てられたロールを追加するには、左側の使用可能なロールのリストからロールを選択し、割り当てられたロールリストの横にある、右矢印のボタンをクリックします。ロールが、使用可能なロールのリストから割り当てられたロールのリストに移動します。
- 割り当てられたロールを削除するには、割り当てられたロールのリストからロールを選択し、割り当てられたロールリストの横にある左矢印のボタンをクリックします。ロールが、割り当てられたロールのリストから使用可能なロールのリストへ移動します。
- 除外されたロールを追加するには、左側の使用可能なロールのリストからロールを選択し、除外されたロールリストの横にある、右矢印のボタンをクリックします。ロールが、使用可能なロールのリストから除外されたロールのリストに移動します。
- 除外されたロールを削除するには、除外されたロールのリストからロールを選択し、除外されたロールリストの横にある左矢印のボタンをクリックします。ロールが、除外されたロールのリストから使用可能なロールのリストへ移動します。
- をクリックして終了します。正常に保存されると、編集ビューが閉じられます。グループのリストが更新され、変更内容が反映されます。正常に保存されなかった場合は、 というメッセージが表示されます。
手順6.15 グループのロール割り当ての削除
- 管理コンソールへログインします。
- セクションの タブへ移動します。
- リストよりグループを選択します。
- をクリックします。Remove Role Assignment 確認プロンプトが表示されます。
- をクリックします。正しく削除されると、グループロール割り当てのリストにロールが表示されなくなります。ロール割り当てのリストからグループを削除しても、ユーザーグループはシステムから削除されず、そのグループのメンバーにロールが割り当てられなくなる保証はありません。各グループメンバーに直接ロールが割り当てられる可能性があります。
6.9.6. 管理 CLI を用いたグループロール割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
role-mapping 要素とする /core-service=management/access=authorization にあります。
/core-service=management/access=authorization の場所を変更します。
[standalone@localhost:9999] cd /core-service=management/access=authorization
[standalone@localhost:9999] cd /core-service=management/access=authorization
手順6.16 グループロール割り当て設定の表示
read-children-names操作を使用して、設定されたロールの完全リストを取得します。/core-service=management/access=authorization:read-children-names(child-type=role-mapping)
/core-service=management/access=authorization:read-children-names(child-type=role-mapping)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 指定されたロールマッピングの
read-resource操作を使用して、特定ロールの完全詳細を取得します。/core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)
/core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow
手順6.17 新規ロールの追加
add操作を使用して、新しいロール設定を追加します。/core-service=management/access=authorization/role-mapping=ROLENAME:add
/core-service=management/access=authorization/role-mapping=ROLENAME:addCopy to Clipboard Copied! Toggle word wrap Toggle overflow [standalone@localhost:9999 access=authorization] ./role-mapping=Auditor:add {"outcome" => "success"} [standalone@localhost:9999 access=authorization][standalone@localhost:9999 access=authorization] ./role-mapping=Auditor:add {"outcome" => "success"} [standalone@localhost:9999 access=authorization]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
手順6.18 グループに include されるユーザーの追加
add操作を使用して、グループエントリーをロールの include リストに追加します。/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=GROUPNAME, type=GROUP)
/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=GROUPNAME, type=GROUP)Copy to Clipboard Copied! Toggle word wrap Toggle overflow ROLENAME は設定されたロールの名前です。GROUPNAME は、include リストに追加されたグループの名前です。ALIASはこのマッピングの一意名です。Red Hat は、group-GROUPNAMEなどのエイリアスに命名規則を使用することを推奨します。[standalone@localhost:9999 access=authorization] ./role-mapping=Auditor/include=group-investigators:add(name=investigators, type=GROUP) {"outcome" => "success"} [standalone@localhost:9999 access=authorization][standalone@localhost:9999 access=authorization] ./role-mapping=Auditor/include=group-investigators:add(name=investigators, type=GROUP) {"outcome" => "success"} [standalone@localhost:9999 access=authorization]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
手順6.19 ロールに exclude されるグループの追加
add操作を使用して、グループエントリーをロールの exclude リストに追加します。/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=GROUPNAME, type=GROUP)
/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=GROUPNAME, type=GROUP)Copy to Clipboard Copied! Toggle word wrap Toggle overflow ROLENAME は設定されたロールの名前です。GROUPNAME は、include リストに追加されたグループの名前です。ALIASはこのマッピングの一意名です。Red Hat は、group-GROUPNAMEなどのエイリアスに命名規則を使用することを推奨します。[standalone@localhost:9999 access=authorization] ./role-mapping=Auditor/exclude=group-supervisors:add(name=supervisors, type=GROUP) {"outcome" => "success"} [standalone@localhost:9999 access=authorization][standalone@localhost:9999 access=authorization] ./role-mapping=Auditor/exclude=group-supervisors:add(name=supervisors, type=GROUP) {"outcome" => "success"} [standalone@localhost:9999 access=authorization]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
手順6.20 グループーロールの include 設定の削除
remove操作を使用してエントリーを削除します。/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:removeCopy to Clipboard Copied! Toggle word wrap Toggle overflow ROLENAME は設定されたロールの名前です。ALIASはこのマッピングの一意名です。Red Hat は、group-GROUPNAMEなどのエイリアスに命名規則を使用することを推奨します。[standalone@localhost:9999 access=authorization] ./role-mapping=Auditor/include=group-investigators:remove {"outcome" => "success"} [standalone@localhost:9999 access=authorization][standalone@localhost:9999 access=authorization] ./role-mapping=Auditor/include=group-investigators:remove {"outcome" => "success"} [standalone@localhost:9999 access=authorization]Copy to Clipboard Copied! Toggle word wrap Toggle overflow include リストからグループを削除しても、グループはシステムから削除されず、このグループのユーザーにロールが割り当てられなくなる保証はありません。ロールは、グループのユーザーへ個別に割り当てられる可能性があります。
手順6.21 ユーザーグループの exclude エントリーの削除
remove操作を使用してエントリーを削除します。/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:removeCopy to Clipboard Copied! Toggle word wrap Toggle overflow ROLENAME は設定されたロールの名前です。ALIASはこのマッピングの一意名です。Red Hat は、group-GROUPNAMEなどのエイリアスに命名規則を使用することを推奨します。[standalone@localhost:9999 access=authorization] ./role-mapping=Auditor/exclude=group-supervisors:remove {"outcome" => "success"} [standalone@localhost:9999 access=authorization][standalone@localhost:9999 access=authorization] ./role-mapping=Auditor/exclude=group-supervisors:remove {"outcome" => "success"} [standalone@localhost:9999 access=authorization]Copy to Clipboard Copied! Toggle word wrap Toggle overflow exclude リストからグループを削除しても、グループはシステムから削除されず、ロールがグループのメンバーに割り当てられる保証はありません。ロールはグループメンバーシップを基に除外される可能性があります。
6.9.7. LDAP での承認とグループローディング リンクのコピーリンクがクリップボードにコピーされました!
memberOf 属性を用いてユーザーエンティティーがユーザーが属するグループをマップしたり、 uniqueMember 属性を用いてグループエンティティーが属するユーザーをマップしたりすることがあります。また、両方のマッピングが LDAP サーバーによって維持されることもあります。
force が false に設定されている場合は承認クエリー中に再使用されます。force が true の場合は、承認中 (グループのロード中) に検索が再実行されます。通常、これは認証と承認が異なるサーバーによって実行される場合に行われます。
重要
force 属性で、デフォルト値の false に設定されていても必要となります。
username-to-dn
username-to-dn 要素は、ユーザー名をエントリーの識別名へマップする方法を指定します。この要素は、以下の両方の条件に見合う場合のみ必要となります。
- 認証および承認手順は異なる LDAP サーバーに対するものである。
- グループ検索が識別名を使用する。
- 1:1 username-to-dn
- リモートユーザーによって入力されたユーザー名はユーザーの識別名であると指定します。
<username-to-dn force="false"> <username-is-dn /> </username-to-dn>
<username-to-dn force="false"> <username-is-dn /> </username-to-dn>Copy to Clipboard Copied! Toggle word wrap Toggle overflow これは 1:1 マッピングを定義し、追加の設定はありません。 - username-filter
- 次のオプションは、前述の認証手順の簡単なオプションと似ています。指定のユーザー名に対して一致する指定の属性が検索されます。
<username-to-dn force="true"> <username-filter base-dn="dc=people,dc=harold,dc=example,dc=com" recursive="false" attribute="sn" user-dn-attribute="dn" /> </username-to-dn><username-to-dn force="true"> <username-filter base-dn="dc=people,dc=harold,dc=example,dc=com" recursive="false" attribute="sn" user-dn-attribute="dn" /> </username-to-dn>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定可能な属性は次のとおりです。base-dn: 検索を開始するコンテキストの識別名。recursive: サブコンテキストが検索対象となるかどうか。デフォルトはfalseです。attribute: 指定のユーザー名に対して一致されるユーザーエントリーの属性。デフォルトはuidです。user-dn-attribute: ユーザーの識別名を取得するために読み取る属性。デフォルトはdnです。
- advanced-filter
- 詳細フィルターを指定するオプションです。認証セクションでは、カスタムフィルターを使用してユーザーの識別名を見つけられます。
<username-to-dn force="true"> <advanced-filter base-dn="dc=people,dc=harold,dc=example,dc=com" recursive="false" filter="sAMAccountName={0}" user-dn-attribute="dn" /> </username-to-dn><username-to-dn force="true"> <advanced-filter base-dn="dc=people,dc=harold,dc=example,dc=com" recursive="false" filter="sAMAccountName={0}" user-dn-attribute="dn" /> </username-to-dn>Copy to Clipboard Copied! Toggle word wrap Toggle overflow username-filter の例と同じ属性は、意味とデフォルト値も同じです。新たな属性は以下の 1 つのみです。filter: ユーザー名が{0}プレースホルダーで置き換えられる、ユーザーのエントリーの検索に使用されるカスタムフィルター。
重要
フィルターの定義後も XML が有効である必要があるため、&などの特殊文字が使用される場合は、適切な形式が使用されるようにしてください。たとえば、&文字には&を使用します。
グループ検索
例6.1 LDIF の例: プリンシパルからグループ
TestUserOne は GroupOne のメンバーで、 GroupOne は GroupFive のメンバーです。グループメンバーシップは、memberOf 属性を使用して表されます。memberOf 属性は、ユーザー (またはグループ) がメンバーであるグループの識別名に設定されます。
memberOf 属性を設定することも可能です (ユーザーが直接メンバーであるグループごとに 1 つ)。
例6.2 LDIF の例: グループからプリンシパル
TestUserOne は GroupOne のメンバーで、 GroupOne は GroupFive のメンバーですが、相互参照にはグループからユーザーへ属性 uniqueMember が使用されます。
一般的なグループ検索
<group-search group-name="..." iterative="..." group-dn-attribute="..." group-name-attribute="..." >
...
</group-search>
<group-search group-name="..." iterative="..." group-dn-attribute="..." group-name-attribute="..." >
...
</group-search>
group-name: この属性は、ユーザーがメンバーであるグループのリストとして返されるグループ名に使用される形式を指定するために使用されます。これは、単純なグループ名またはグループの識別名になります。識別名が必要な場合は、この属性をDISTINGUISHED_NAMEに設定できます。デフォルトはSIMPLEです。iterative: ユーザーがメンバーであるグループを特定した後に、グループがメンバーであるグループを特定するため、グループを基に繰り返し検索するかどうかを指定するために使用される属性です。繰り返し検索が有効であると、他のグループのメンバーでないグループが見つかるか、サイクルが検出されるまで検索を続行します。デフォルトはfalseです。
重要
group-dn-attribute: 属性が識別名であるグループのエントリーです。デフォルトはdnです。group-name-attribute: 属性が単純名であるグループのエントリーです。デフォルトはuidです。
例6.3 プリンシパルからグループへの設定例
memberOf 属性です。
principal-to-group 要素が単一の属性で追加されていることです。
group-attribute: ユーザーがメンバーであるグループの識別名と一致する、ユーザーエントリー上の属性名。デフォルトはmemberOfです。
例6.4 グループからプリンシパルへの設定例
group-to-principal 要素が追加されています。この要素は、ユーザーエントリーを参照するグループの検索がどのように実行されるかを定義するために使用されます。以下の属性が設定されます。
base-dn: 検索を開始するために使用するコンテキストの識別名。recursive: サブコンテキストも検索されるかどうか。デフォルトはfalseです。search-by: 検索で使用されるロール名の形式です。有効な値はSIMPLEおよびDISTINGUISHED_NAMEです。デフォルトはDISTINGUISHED_NAMEです。
principal-attribute: ユーザーエントリーを参照する、グループエントリー上の属性名。デフォルトはmemberです。
6.9.8. スコープ指定ロール リンクのコピーリンクがクリップボードにコピーされました!
- 一意名。
- ベースになる標準ロール。
- サーバーグループまたはホストへ適用されるかどうか。
- スコープ指定ロールが制限されるサーバーグループまたはホストのリスト。
- すべてのユーザーが自動的に含まれるかどうか。デフォルトは false です。
- ホストスコープ指定ロール
- ホストスコープ指定されたロールは、そのロールのパーミッションを 1 つ以上のホストに制限します。これにより、関連する
/host=*/リソースツリーにアクセスできますが、他のホスト固有のリソースは表示されません。 - サーバーグループスコープ指定ロール
- サーバーグループスコープ指定のロールは、そのロールのパーミッションを 1 つ以上のサーバーグループに制限します。さらに、ロールパーミッションは、指定されたサーバーグループに関連するプロファイル、ソケットバインディンググループ、サーバー設定、およびサーバーリソースにも適用されます。サーバーグループに論理的に関連しないリソース内のサブリソースは、ユーザーに対して表示されません。
6.9.9. スコープ指定ロールの作成 リンクのコピーリンクがクリップボードにコピーされました!
SuperUser または Administrator ロールのユーザーのみです。
- 管理コンソールへログインします。
- タブをクリックします。
- メニューを展開し、 を選択します。
- タブを選択し、そのタブ内にある タブを選択します。
手順6.22 新しいスコープ指定ロールの追加
- 管理コンソールへログインします。
- タブの エリアに移動します。
- をクリックします。Add Scoped Role ダイアログが表示されます。
- 次の詳細を指定します。
- Name: 新しいスコープ指定ロールの一意名。
- Base Role: このロールのパーミッションがベースとなるロール。
- Type: このロールがホストまたはサーバーグループに制限されるかどうか。
- Scope: ロールが制限されるホストまたはサーバーグループのリスト。複数のエントリーを選択できます。
- Include All: このロールにすべてのユーザーが自動的に含まれるかどうか。デフォルトは no です。
- ボタンをクリックすると、ダイアログが閉じられ、新規作成されたロールがテーブルに表示されます。
手順6.23 スコープ指定ロールの編集
- 管理コンソールへログインします。
- タブの エリアに移動します。
- テーブル上で編集するスコープ指定ロールをクリックします。ロールの詳細がテーブルの下の Selection パネルに表示されます。
- Selection パネルの をクリックします。Selection パネルが編集モードになります。
- 変更する必要がある詳細を変更し、 ボタンをクリックします。Selection パネルが以前の状態に戻ります。Selection パネルとテーブルの両方に、新たに更新された詳細が表示されます。
手順6.24 スコープ指定ロールメンバーの表示
- 管理コンソールへログインします。
- タブの Scoped Roles エリアに移動します。
- テーブル上で、 を表示したいスコープ指定ロールをクリックし、 をクリックします。 ダイアログが表示されます。このダイアログには、ロールに含まれるまたは除外されるユーザーとグループが表示されます。
- 情報を確認した後、 ボタンをクリックします。
手順6.25 スコープ指定ロールの削除
重要
- 管理コンソールへログインします。
- タブの エリアに移動します。
- テーブル上で、削除するスコープ指定ロールを選択します。
- ボタンをクリックします。Remove Scoped Role ダイアログが表示されます。
- ボタンをクリックします。ダイアログが閉じられ、ロールが削除されます。
6.10. 制約の設定 リンクのコピーリンクがクリップボードにコピーされました!
6.10.1. 機密性制約の設定 リンクのコピーリンクがクリップボードにコピーされました!
/core-service=management/access=authorization/constraint=sensitivity-classification にあります。
classification として識別されます。classification (分類) は types にグループ化されます。39 個の分類が含まれ、それらは 13 個のタイプにグループ化されます。
write-attribute 操作を使用して configured-requires-read、configured-requires-write、または configured-requires-addressable 属性を設定します。操作のタイプを機密にするには、true を値として設定します。機密にしない場合は false を設定します。デフォルトではこれらの属性は設定されておらず、default-requires-read、default-requires-write、および default-requires-addressable の値が使用されます。configured 属性の値が設定されると、デフォルトの代わりにその値が使用されます。デフォルト値は変更できません。
例6.5 読み取りシステムプロパティーを機密操作にする
| 値 | requires-read | requires-write | requires-addressable |
|---|---|---|---|
true
|
読み取りは機密です。
Auditor、Administrator、および SuperUser のみ読み取りできます。
|
書き込みは機密です。
Administrator および SuperUser のみ書き込みできます。
|
アドレス指定は機密です。
Auditor、Administrator、および SuperUser のみアドレス可能です。
|
false
|
読み取りは機密ではありません。
すべての管理ユーザーが読み取りできます。
|
書き込みは機密ではありません。
Maintainer、Administrator、および SuperUser のみ書き込みできます。Deployers はアプリケーションリソースのアプリケーションを書き込みできます。
|
アドレス指定は機密ではありません。
すべての管理ユーザーがアドレス指定できます。
|
6.10.2. アプリケーションリソース制約の設定 リンクのコピーリンクがクリップボードにコピーされました!
/core-service=management/access=authorization/constraint=application-classification/ にあります。
classification として識別されます。classification (分類) は types にグループ化されます。14 個の分類が含まれ、それらは 8 つのタイプにグループ化されます。各分類には、分類設定が適用されるリソースパスパターンのリストである applies-to 要素が含まれます。
core のみです。core にはデプロイメント、デプロイメントオーバーレイ、およびデプロイメント操作が含まれます。
write-attribute 操作を使用して、分類の configured-application attribute を true に設定します。アプリケーションリソースを無効にするには、この属性を false に設定します。デフォルトでは、この属性は設定されていないため、default-application attribute の値が使用されます。デフォルトの値は変更できません。
例6.6 logger-profile アプリケーションリソースの分類を有効にする
重要
Deployer ユーザーに、あるデータソースリソースへのアクセスを許可し、他のデータソースリソースへのアクセスを拒否することはできません。このような分離レベルが必要な場合は、リソースを異なるサーバーグループに設定し、各グループに対して異なるスコープ指定の Deployer ロールを作成することが推奨されます。
6.10.3. Vault 式制約の設定 リンクのコピーリンクがクリップボードにコピーされました!
/core-service=management/access=authorization/constraint=vault-expression にあります。
write-attribute 操作を使用して configured-requires-write および configured-requires-read 属性を true または false に設定します。デフォルトでは、これらの属性は設定されていないため、default-requires-read および default-requires-write の値が使用されます。デフォルトの値は変更できません。
例6.7 vault 式への書き込みを非機密操作にする
| 値 | requires-read | requires-write |
|---|---|---|
true
|
読み取り操作は機密です。
Auditor、Administrator、および SuperUser のみ読み取りできます。
|
書き込み操作は機密です。
Administrator および SuperUser のみ書き込みできます。
|
false
|
読み取り操作は機密ではありません。
すべての管理ユーザーが読み取りできます。
|
書き込み操作は機密ではありません。
Maintainer、Administrator、および SuperUser が書き込みできます。Deployers はアプリケーションリソースに Vault 式がある場合に書き込みできます。
|
6.11. 制約に関する参考情報 リンクのコピーリンクがクリップボードにコピーされました!
6.11.1. アプリケーションリソース制約に関する参考情報 リンクのコピーリンクがクリップボードにコピーされました!
タイプ: core
- 分類: deployment-overlay
- デフォルト: true
- PATH: /deployment-overlay=*
- PATH: /deployment=*
- PATH: /操作:upload-deployment-stream、full-replace-deployment、 upload-deployment-url、upload-deployment-bytes
タイプ: datasources
- 分類: datasource
- デフォルト: false
- PATH: /deployment=*/subdeployment=*/subsystem=datasources/data-source=*
- PATH: /subsystem=datasources/data-source=*
- PATH: /subsystem=datasources/data-source=ExampleDS
- PATH: /deployment=*/subsystem=datasources/data-source=*
- 分類: jdbc-driver
- デフォルト: false
- PATH: /subsystem=datasources/jdbc-driver=*
- 分類: xa-data-source
- デフォルト: false
- PATH: /subsystem=datasources/xa-data-source=*
- PATH: /deployment=*/subsystem=datasources/xa-data-source=*
- PATH: /deployment=*/subdeployment=*/subsystem=datasources/xa-data-source=*
タイプ: logging
- 分類: logger
- デフォルト: false
- PATH: /subsystem=logging/logger=*
- PATH: /subsystem=logging/logging-profile=*/logger=*
- 分類: logging-profile
- デフォルト: false
- PATH: /subsystem=logging/logging-profile=*
タイプ: mail
- 分類: mail-session
- デフォルト: false
- PATH: /subsystem=mail/mail-session=*
タイプ: naming
- 分類: binding
- デフォルト: false
- PATH: /subsystem=naming/binding=*
タイプ: resource-adapters
- 分類: resource-adapters
- デフォルト: false
- PATH: /subsystem=resource-adapters/resource-adapter=*
タイプ: security
- 分類: security-domain
- デフォルト: false
- PATH: /subsystem=security/security-domain=*
6.11.2. 機密性制約に関する参考情報 リンクのコピーリンクがクリップボードにコピーされました!
タイプ: core
- 分類: access-control
- requires-addressable: true
- requires-read: true
- requires-write: true
- PATH: /core-service=management/access=authorization
- PATH: /subsystem=jmx ATTRIBUTE: non-core-mbean-sensitivity
- 分類: credential
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: /subsystem=mail/mail-session=*/server=pop3 ATTRIBUTE: username , password
- PATH: /subsystem=mail/mail-session=*/server=imap ATTRIBUTE: username , password
- PATH: /subsystem=datasources/xa-data-source=* ATTRIBUTE: user-name, recovery-username, password, recovery-password
- PATH: /subsystem=mail/mail-session=*/custom=* ATTRIBUTE: username, password
- PATH: /subsystem=datasources/data-source=*" ATTRIBUTE: user-name, password
- PATH: /subsystem=remoting/remote-outbound-connection=*" ATTRIBUTE: username
- PATH: /subsystem=mail/mail-session=*/server=smtp ATTRIBUTE: username, password
- PATH: /subsystem=web/connector=*/configuration=ssl ATTRIBUTE: key-alias, password
- PATH: /subsystem=resource-adapters/resource-adapter=*/connection-definitions=*" ATTRIBUTE: recovery-username, recovery-password
- 分類: domain-controller
- requires-addressable: false
- requires-read: false
- requires-write: true
- 分類: domain-names
- requires-addressable: false
- requires-read: false
- requires-write: true
- 分類: extensions
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /extension=*
- 分類: jvm
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /core-service=platform-mbean/type=runtime ATTRIBUTE: input-arguments, boot-class-path, class-path, boot-class-path-supported, library-path
- 分類: management-interfaces
- requires-addressable: false
- requires-read: false
- requires-write: true
- /core-service=management/management-interface=native-interface
- /core-service=management/management-interface=http-interface
- 分類: module-loading
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /core-service=module-loading
- 分類: patching
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /core-service=patching/addon=*
- PATH: /core-service=patching/layer=*"
- PATH: /core-service=patching
- 分類: read-whole-config
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: / OPERATION: read-config-as-xml
- 分類: security-domain
- requires-addressable: true
- requires-read: true
- requires-write: true
- PATH: /subsystem=security/security-domain=*
- 分類: security-domain-ref
- requires-addressable: true
- requires-read: true
- requires-write: true
- PATH: /subsystem=datasources/xa-data-source=* ATTRIBUTE: security-domain
- PATH: /subsystem=datasources/data-source=* ATTRIBUTE: security-domain
- PATH: /subsystem=ejb3 ATTRIBUTE: default-security-domain
- PATH: /subsystem=resource-adapters/resource-adapter=*/connection-definitions=* ATTRIBUTE: security-domain, recovery-security-domain, security-application, security-domain-and-application
- 分類: security-realm
- requires-addressable: true
- requires-read: true
- requires-write: true
- PATH: /core-service=management/security-realm=*
- 分類: security-realm-ref
- requires-addressable: true
- requires-read: true
- requires-write: true
- PATH: /subsystem=remoting/connector=* ATTRIBUTE: security-realm
- PATH: /core-service=management/management-interface=native-interface ATTRIBUTE: security-realm
- PATH: /core-service=management/management-interface=http-interface ATTRIBUTE: security-realm
- PATH: /subsystem=remoting/remote-outbound-connection=* ATTRIBUTE: security-realm
- 分類: security-vault
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /core-service=vault
- 分類: service-container
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /core-service=service-container
- 分類: snapshots
- requires-addressable: false
- requires-read: false
- requires-write: false
- PATH: / ATTRIBUTE: take-snapshot, list-snapshots, delete-snapshot
- 分類: socket-binding-ref
- requires-addressable: false
- requires-read: false
- requires-write: false
- PATH: /subsystem=mail/mail-session=*/server=pop3 ATTRIBUTE: outbound-socket-binding-ref
- PATH: /subsystem=mail/mail-session=*/server=imap ATTRIBUTE: outbound-socket-binding-ref
- PATH: /subsystem=remoting/connector=* ATTRIBUTE: socket-binding
- PATH: /subsystem=web/connector=* ATTRIBUTE: socket-binding
- PATH: /subsystem=remoting/local-outbound-connection=* ATTRIBUTE: outbound-socket-binding-ref
- PATH: /socket-binding-group=*/local-destination-outbound-socket-binding=* ATTRIBUTE: socket-binding-ref
- PATH: /subsystem=remoting/remote-outbound-connection=* ATTRIBUTE: outbound-socket-binding-ref
- PATH: /subsystem=mail/mail-session=*/server=smtp ATTRIBUTE: outbound-socket-binding-ref
- PATH: /subsystem=transactions ATTRIBUTE: process-id-socket-binding, status-socket-binding, socket-binding
- 分類: socket-config
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /interface=* OPERATION: resolve-internet-address
- PATH: /core-service=management/management-interface=native-interface ATTRIBUTE: port, interface, socket-binding
- PATH: /socket-binding-group=*
- PATH: /core-service=management/management-interface=http-interface ATTRIBUTE: port, secure-port, interface, secure-socket-binding, socket-binding
- PATH: / OPERATION: resolve-internet-address
- PATH: /subsystem=transactions ATTRIBUTE: process-id-socket-max-ports
- 分類: system-property
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /core-service=platform-mbean/type=runtime ATTRIBUTE: system-properties
- PATH: /system-property=*
- PATH: / OPERATION: resolve-expression
タイプ: datasources
- 分類: data-source-security
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: /subsystem=datasources/xa-data-source=* ATTRIBUTE: user-name, security-domain, password
- PATH: /subsystem=datasources/data-source=* ATTRIBUTE: user-name, security-domain, password
タイプ: jdr
- 分類: jdr
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /subsystem=jdr OPERATION: generate-jdr-report
タイプ: jmx
- 分類: jmx
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /subsystem=jmx
タイプ: mail
- 分類: mail-server-security
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /subsystem=mail/mail-session=*/server=pop3 ATTRIBUTE: username, tls, ssl, password
- PATH: /subsystem=mail/mail-session=*/server=imap ATTRIBUTE: username, tls, ssl, password
- PATH: /subsystem=mail/mail-session=*/custom=* ATTRIBUTE: username, tls, ssl, password
- PATH: /subsystem=mail/mail-session=*/server=smtp ATTRIBUTE: username, tls, ssl, password
タイプ: naming
- 分類: jndi-view
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: /subsystem=naming OPERATION: jndi-view
- 分類: naming-binding
- requires-addressable: false
- requires-read: false
- requires-write: false
- PATH: /subsystem=naming/binding=*
タイプ: remoting
- 分類: remoting-security
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: /subsystem=remoting/connector=* ATTRIBUTE: authentication-provider, security-realm
- PATH: /subsystem=remoting/remote-outbound-connection=* ATTRIBUTE: username, security-realm
- PATH: /subsystem=remoting/connector=*/security=sasl
タイプ: resource-adapters
- 分類: resource-adapter-security
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: /subsystem=resource-adapters/resource-adapter=*/connection-definitions=* ATTRIBUTE: security-domain, recovery-username, recovery-security-domain, security-application, security-domain-and-application, recovery-password
タイプ: security
- 分類: misc-security
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: /subsystem=security ATTRIBUTE: deep-copy-subject-mode
タイプ: web
- 分類: web-access-log
- requires-addressable: false
- requires-read: false
- requires-write: false
- PATH: /subsystem=web/virtual-server=*/configuration=access-log
- 分類: web-connector
- requires-addressable: false
- requires-read: false
- requires-write: false
- PATH: /subsystem=web/connector=*
- 分類: web-ssl
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: /subsystem=web/connector=*/configuration=ssl
- 分類: web-sso
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: /subsystem=web/virtual-server=*/configuration=sso
- 分類: web-valve
- requires-addressable: false
- requires-read: false
- requires-write: false
- PATH: /subsystem=web/valve=*
第7章 パスワード Vault を用いた、パスワードとその他の機密性が高い文字列のセキュア化 リンクのコピーリンクがクリップボードにコピーされました!
7.1. パスワード valut システム リンクのコピーリンクがクリップボードにコピーされました!
7.2. 機密性が高い文字列を格納する Java キーストアの作成 リンクのコピーリンクがクリップボードにコピーされました!
要件
keytoolコマンドを使用できる必要があります。これは Java Runtime Environment (JRE) により提供されます。このファイルのパスを見つけます。Red Hat Enterprise Linux では、これは/usr/bin/keytoolにインストールされます。
警告
keytool を使用して vault.keystore を生成する必要があります。
keytool によって生成された vault を別のベンダーの JDK で実行されている EAP インスタンスで使用すると、以下の例外が発生します。
java.io.IOException: com.sun.crypto.provider.SealedObjectForKeyProtector
java.io.IOException: com.sun.crypto.provider.SealedObjectForKeyProtector
手順7.1 Java キーストアの設定
キーストアと他の暗号化された情報を格納するディレクトリーを作成します。
キーストアと他の重要な情報を保持するディレクトリーを作成します。この残りの手順では、ディレクトリーがEAP_HOME/vault/であることを前提とします。このディレクトリーには機密情報が含まれるため、限られたユーザーのみがアクセスできるようにする必要があります。JBoss EAP が実行されるユーザーアカウントでは、最低でも読み書きアクセスが必要です。keytoolで使用するパラメーターを決定します。以下のパラメーターを決定します。- alias
- エイリアスは資格情報コンテナまたはキーストアに格納された vault または他のデータの一意の ID です。この手順の最後にあるコマンド例のエイリアスは
vaultです。エイリアスは大文字と小文字を区別します。 - keyalg
- 暗号化に使用するアルゴリズム。この手順の例では
AESを使用します。利用可能な他の選択肢については、JRE およびオペレーティングシステムのドキュメンテーションを参照してください。 - keysize
- 暗号化キーのサイズは、ブルートフォース攻撃で復号化を行う難しさに影響します。この手順の例では、
128を使用します。適切な値についての詳細情報は、keytoolで配布されるドキュメントを参照してください。 - keystore
- 暗号化された情報と暗号化方法に関する情報を保持するデータベースのキーストア。キーストアを指定しない場合、使用するデフォルトのキーストアはホームディレクトリーの
.keystoreという名前のファイルです。これは、キーストアにデータを初めて追加したときに作成されます。この手順の例では、vault.keystoreキーストアを使用します。
keytoolコマンドには他にも多くのオプションがあります。詳細については、JRE またはオペレーティングシステムのドキュメンテーションを参照してください。keystoreコマンドが尋ねる質問の回答を決定します。keystoreは、キーストアエントリーに値を入力するために次の情報を必要とします。- キーストアパスワード
- キーストアを作成する場合は、パスワードを設定する必要があります。将来キーストアを使用するために、パスワードを提供する必要があります。覚えやすい強度の高いパスワードを作成します。キーストアは、パスワードや、キーストアが存在するファイルシステムおよびオペレーティングシステムのセキュリティーと同程度にセキュアです。
- キーパスワード (任意設定)
- キーストアパスワードに加え、保持する各キーにパスワードを指定することが可能です。このようなキーを使用するには、使用するたびにパスワードを提供する必要があります。通常、このファシリティーは使用されません。
- 名前 (名) と 名字 (姓)
- この情報と一覧の他の情報は、一意にキーを識別して他のキーの階層に置くのに役立ちます。名前である必要はありませんが、キーに一意な 2 つの言葉である必要があります。この手順の例では、
Accounting Administratorを使用します。これが証明書のコモンネームになります。 - 組織単位
- 証明書を使用する人物を特定する単一の言葉です。アプリケーションユニットやビジネスユニットである場合もあります。この手順の例では
AccountingServicesを使用します。通常、1 つのグループやアプリケーションによって使用されるキーストアはすべて同じ組織単位を使用します。 - 組織
- 通常、所属する組織名を表す単一の言葉になります。一般的に、1 つの組織で使用されるすべての証明書で同じになります。この例では
MyOrganizationを使用します。 - 市または自治体
- お住まいの市名。
- 州または県
- お住まいの州や県、または同等の行政区画。
- 国
- 2 文字の国コード。
これらすべての情報によってキーストアや証明書の階層が作成され、一貫性のある一意な名前付け構造が確実に使用されるようにします。keytoolコマンドを実行し、収集した情報を提供します。例7.1
keystoreコマンドの入出力例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
EAP_HOME/vault/ ディレクトリーに vault.keystore という名前のファイルが作成されます。JBoss EAP 6 のパスワードなど、暗号化された文字列を格納するために使用される vault という 1 つのキーがこのファイルに保存されます。
7.3. キーストアパスワードのマスキングとパスワード vault の初期化 リンクのコピーリンクがクリップボードにコピーされました!
vault.shコマンドを実行します。EAP_HOME/bin/vault.shを実行します。0を入力して新しい対話セッションを開始します。暗号化されたファイルが保存されるディレクトリーを入力します。
限られたユーザーのみがこのディレクトリーにアクセスできるようにする必要があります。JBoss EAP が実行されるユーザーアカウントでは、最低でも読み書きアクセスが必要です。「機密性が高い文字列を格納する Java キーストアの作成」に従ってキーストアを作成した場合、キーストアはEAP_HOME/vault/というディレクトリーにあります。注記
必ずディレクトリー名の最後にスラッシュが含まれるようにしてください。ご使用のオペレーティングシステムに応じて/または\を使用します。キーストアへのパスを入力します。
キーストアファイルへのフルパスを入力します。この例ではEAP_HOME/vault/vault.keystoreを使用します。キーストアパスワードを暗号化します。
次の手順に従って、設定ファイルやアプリケーションで安全に使用できるようキーストアのパスワードを暗号化します。キーストアパスワードを入力します。
入力を促されたらキーストアのパスワードを入力します。salt 値を入力します。
8 文字の salt 値を入力します。salt 値は繰り返す回数 (下記) と共にハッシュ値の作成に使用されます。繰り返す回数を入力します。
繰り返す回数の値を入力します。マスクされたパスワード情報を書き留めておきます。
マスクされたパスワード、salt、および繰り返す回数は標準出力へ書き出されます。これらの情報を安全な場所に書き留めておきます。攻撃者がこれらの情報を使用してパスワードを復号化する可能性があるからです。vault のエイリアスを入力します。
入力を促されたら、vault のエイリアスを入力します。「機密性が高い文字列を格納する Java キーストアの作成」 に従って vault を作成した場合、エイリアスはvaultになります。
対話コンソールを終了します。
2を入力して対話コンソールを終了します。
設定ファイルとデプロイメントで使用するため、キーストアパスワードがマスキングされます。また、vault が完全設定され、すぐ使用できる状態になります。
7.4. パスワード vault を使用するよう JBoss EAP 6 を設定 リンクのコピーリンクがクリップボードにコピーされました!
設定ファイルにあるパスワードや機密性の高いその他の属性をマスキングする前に、これらを保存し復号化するパスワード vault を JBoss EAP 6 が認識するようにする必要があります。次の手順に従ってこの機能を有効にします。
手順7.2 パスワード vault の設定
コマンドの適切な値を決定します。
キーストアの作成に使用されるコマンドによって決定される以下のパラメーターの値を決定します。キーストア作成の詳細は「機密性が高い文字列を格納する Java キーストアの作成」および「キーストアパスワードのマスキングとパスワード vault の初期化」を参照してください。Expand Parameter 説明 KEYSTORE_URL ファイルシステムのパスまたはキーストアファイル。通常vault.keystoreのようになります。KEYSTORE_PASSWORD キーストアのアクセスに使用されるパスワード。この値はマスクされる必要があります。KEYSTORE_ALIAS キーストアエイリアスの名前。SALT キーストアの値を暗号化および復号化するために使用される salt。ITERATION_COUNT 暗号化アルゴリズムが実行される回数。ENC_FILE_DIR キーストアコマンドが実行されるディレクトリーへのパス。通常、パスワード vault が含まれるディレクトリーになります。host (管理対象ドメインのみ) 設定するホストの名前。管理 CLI を使用してパスワード vault を有効にします。
次のコマンドの 1 つを実行します。実行するコマンドは、管理対象ドメインまたはスタンドアロンサーバー設定のどちらを使用するかによって異なります。コマンドの値は、手順の最初で使用した値に置き換えます。注記
Microsoft Windows Server を使用する場合、CLI コマンドでは ディレクトリーパスにある\文字に\を追加してエスケープします。たとえば、C:\\data\\vault\\vault.keystoreのようになります。これは、単一の\文字は文字のエスケープに使用されるためです。管理対象ドメイン
/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")])/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")])Copy to Clipboard Copied! Toggle word wrap Toggle overflow スタンドアロンサーバー
/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")])Copy to Clipboard Copied! Toggle word wrap Toggle overflow
仮の値を用いたコマンドの例は次のとおりです。/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/")])/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/")])Copy to Clipboard Copied! Toggle word wrap Toggle overflow
パスワード vault を使用してマスキングされた文字列を復号化するよう JBoss EAP 6 が設定されます。vault に文字列を追加し、設定で使用する場合は「Java キーストアに暗号化された機密性の高い文字列の保存および読み出し」を参照してください。
7.5. パスワード Vault のカスタム実装を使用するよう JBoss EAP 6 を設定 リンクのコピーリンクがクリップボードにコピーされました!
独自の SecurityVault 実装を使用して、設定ファイルのパスワードや機密性の高いその他の属性をマスクできます。
手順7.3 パスワード vault のカスタム実装の使用
- インターフェース
SecurityVaultを実装するクラスを作成します。 - 前の手順のクラスが含まれるモジュールを作成し、インターフェースが
SecurityVaultであるorg.picketboxの依存関係を指定します。 - 以下の属性を用いて vault 要素を追加して、JBoss EAP サーバー設定でカスタムのパスワード vault を有効にします。
- code
SecurityVaultを実装するクラスの完全修飾名。- module
- カスタムクラスが含まれるモジュールの名前。
オプションでvault-optionsパラメーターを使用して、パスワード Vault のカスタムクラスを初期化できます。以下に例を示します。/core-service=vault:add(code="custom.vault.implementation.CustomSecurityVault", module="custom.vault.module", 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(code="custom.vault.implementation.CustomSecurityVault", module="custom.vault.module", 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")])Copy to Clipboard Copied! Toggle word wrap Toggle overflow
パスワード vault のカスタム実装を使用して、マスクされた文字列が復号化されるよう JBoss EAP 6 が設定されます。
7.6. Java キーストアに暗号化された機密性の高い文字列の保存および読み出し リンクのコピーリンクがクリップボードにコピーされました!
パスワードや、機密性の高いその他の文字列がプレーンテキストの設定ファイルに含まれるのはセキュアではありません。JBoss EAP 6 には、このような機密性の高い文字列をマスキングして暗号化されたキーストアに保存する機能や、設定ファイルでマスクされた値を使用する機能が含まれています。
要件
EAP_HOME/bin/vault.shアプリケーションはコマンドラインインターフェースからアクセスできなければなりません。
手順7.4 Java キーストアの設定
vault.shコマンドを実行します。EAP_HOME/bin/vault.shを実行します。0を入力して新しい対話セッションを開始します。暗号化されたファイルが保存されるディレクトリーを入力します。
「「機密性が高い文字列を格納する Java キーストアの作成」」に従ってキーストアを作成した場合、キーストアはEAP_HOME/vault/というディレクトリーにあります。ほとんどの場合、暗号化した情報をキーストアと同じ場所に保存することは適切です。このディレクトリーには機密性の高い情報が含まれるため、アクセスできるユーザーを制限する必要があります。最低でも、JBoss EAP を実行するユーザーアカウントには読み書き権限が必要です。注記
必ずディレクトリー名の最後にスラッシュが含まれるようにしてください。ご使用のオペレーティングシステムに応じて/または\を使用します。キーストアへのパスを入力します。
キーストアファイルへのフルパスを入力します。この例ではEAP_HOME/vault/vault.keystoreを使用します。キーストアパスワード、vault 名、ソルト、繰り返す回数を入力します。
入力を促されたら、キーストアパスワード、vault 名、ソルト、繰り返す回数を入力します。ハンドシェイクが実行されます。パスワードを保存するオプションを選択します。
オプション0を選択して、パスワードや機密性の高い他の文字列を保存します。値を入力します。
入力を促されたら、値を 2 回入力します。値が一致しない場合は再度入力するよう要求されます。vault ブロックを入力します。
同じリソースに関連する属性のコンテナである vault ブロックを入力します。属性名の例としてはds_ExampleDSなどが挙げられます。データソースまたは他のサービス定義で、暗号化された文字列への参照の一部を形成します。属性名を入力します。
保存する属性の名前を入力します。passwordが属性名の例の 1 つになります。結果以下のようなメッセージによって、属性が保存されたことが示されます。
Secured attribute value has been stored in vault.
Secured attribute value has been stored in vault.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 暗号化された文字列に関する情報を書き留めます。
メッセージは vault ブロック、属性名、共有キー、および設定で文字列を使用する場合のアドバイスを表示する標準出力を出力します。安全な場所にこの情報を書き留めておくようにしてください。出力例は次のとおりです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定で暗号化された文字列を使用します。
プレーンテキストの文字列の代わりに、前の設定手順の文字列を使用します。以下は、上記の暗号化されたパスワードを使用するデータソースになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 式が許可されるドメインまたはスタンドアロン設定ファイルであれば、どこでも暗号化された文字列を使用することができます。注記
特定のサブシステム内で式が許可されるかを確認するには、そのサブシステムに対して次の CLI コマンドを実行します。/host=master/core-service=management/security-realm=TestRealm:read-resource-description(recursive=true)
/host=master/core-service=management/security-realm=TestRealm:read-resource-description(recursive=true)Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドの出力で、expressions-allowedパラメーターの値を探します。値が true であればこのサブシステムの設定内で式を使用できます。文字列をキーストアに格納した後、次の構文を使用してクリアテキストの文字列を暗号化された文字列に置き換えます。${VAULT::VAULT_BLOCK::ATTRIBUTE_NAME::ENCRYPTED_VALUE}${VAULT::VAULT_BLOCK::ATTRIBUTE_NAME::ENCRYPTED_VALUE}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 実環境の値の例は次のとおりです。vault ブロックはds_ExampleDS、属性はpasswordです。<password>${VAULT::ds_ExampleDS::password::1}</password><password>${VAULT::ds_ExampleDS::password::1}</password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.7. アプリケーションでの機密性の高い文字列の保存および解決 リンクのコピーリンクがクリップボードにコピーされました!
JBoss EAP 6 の設定要素は、セキュリティー vault メカニズムを通じて Java キーストアに保存される値に対して暗号化された文字列を解決する機能をサポートしています。この機能に対するサポートを独自のアプリケーションに追加することができます。
この手順を実行する前に、vault ファイルを格納するディレクトリーが存在することを確認してください。JBoss EAP 6 を実行するユーザーが vault ファイルを読み書きできるパーミッションを持っていれば、vault ファイルの場所はどこでも構いません。この例では、vault/ ディレクトリーを /home/USER/vault/ ディレクトリーに置きます。vault 自体は vault/ ディレクトリーの中にある vault.keystore と呼ばれるファイルになります。
例7.2 vault へのパスワードの文字列の追加
EAP_HOME/bin/vault.sh コマンドを用いて文字列を vault へ追加します。次の画面出力にコマンドと応答がすべて含まれています。ユーザー入力の値は強調文字で表されています。出力の一部は書式上、削除されています。Microsoft Windows ではコマンド名は vault.bat になります。Microsoft Windows のファイルパスでは、ディレクトリーの分離記号として / ではなく \ が使用されることに注意してください。
VAULT で始まる行です。
例7.3 vault されたパスワードを使用するサーブレット
第8章 Web、HTTP コネクター、および HTTP クラスタリング リンクのコピーリンクがクリップボードにコピーされました!
8.1. mod_cluster ワーカーノードの設定 リンクのコピーリンクがクリップボードにコピーされました!
mod_cluster ワーカーノードは、負荷分散されたクラスターに参加するアプリケーションサーバーです。ユーザーからのリクエストは web サーバーが受信した後、mod_cluster ワーカーノードのプールへ転送します。ワーカーノードは、管理対象ドメインまたはスタンドアロンサーバーのサーバーグループの一部にすることができます。web サーバーの負荷分散については『管理および設定ガイド』の「HTTP コネクターの概要」を参照してください。
mod_cluster サブシステムより設定されます。mod_cluster サブシステムを設定する場合は『管理および設定ガイド』の「mod_cluster サブシステムの設定」を参照してください。
ワーカーノード設定
- スタンドアロンサーバーは
standalone-haまたはstandalone-full-haプロファイルで起動する必要があります。 - 管理対象ドメインのサーバーグループは、
haまたはfull-haプロファイルと、ha-socketsまたはfull-ha-socketsソケットバインディンググループを使用する必要があります。JBoss EAP 6 には、これらの要件を満たすother-server-groupという名前のクラスター対応サーバーグループが同梱されます。
注記
/profile=full-ha 部分を削除します。
手順8.1 ワーカーノードの設定
ネットワークインターフェースの設定
デフォルトでは、ネットワークインターフェースがすべて127.0.0.1に設定されます。スタンドアロンサーバーまたはサーバーグループ内の 1 つまたは複数のサーバーをホストする各物理ホストでは、インターフェースが他のサーバーが見つけることができるパブリック IP アドレスを使用するよう設定する必要があります。JBoss EAP 6 ホストの IP アドレスを変更するには、ホストをシャットダウンし、設定ファイルを直接編集する必要があります。これは、管理コンソールと管理 CLI を駆動する管理 API は固定管理アドレスに依存するためです。クラスター内の各サーバーの IP アドレスをマスターのパブリック IP アドレスに変更するには、次の手順を実行します。- 本トピックでこれまでに説明したプロファイルを使用して JBoss EAP サーバーを起動します。
EAP_HOME/bin/jboss-cli.shコマンド (Linux の場合) またはEAP_HOME\bin\jboss-cli.batコマンド (Microsoft Windows Server の場合) を使用して管理 CLI を起動します。connectと入力して localhost 上のドメインコントローラーに接続するか、connect IP_ADDRESSと入力してリモートサーバー上のドメインコントローラーに接続します。- 以下のコマンドを入力し、
management、public、およびunsecureインターフェースの外部 IP アドレスを編集します。必ずコマンドのEXTERNAL_IP_ADDRESSをホストの実際の外部 IP アドレスと置き換えてください。各コマンドに対して以下のような結果が表示されるはずです。/interface=management:write-attribute(name=inet-address,value="${jboss.bind.address.management:EXTERNAL_IP_ADDRESS}" /interface=public:write-attribute(name=inet-address,value="${jboss.bind.address.public:EXTERNAL_IP_ADDRESS}" /interface=unsecure:write-attribute(name=inet-address,value="${jboss.bind.address.unsecure:EXTERNAL_IP_ADDRESS}" :reload/interface=management:write-attribute(name=inet-address,value="${jboss.bind.address.management:EXTERNAL_IP_ADDRESS}" /interface=public:write-attribute(name=inet-address,value="${jboss.bind.address.public:EXTERNAL_IP_ADDRESS}" /interface=unsecure:write-attribute(name=inet-address,value="${jboss.bind.address.unsecure:EXTERNAL_IP_ADDRESS}" :reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow "outcome" => "success"
"outcome" => "success"Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 管理対象ドメインに参加するマスターでないホストの場合、ホスト名を
masterから一意の名前に変更する必要があります。この名前はスレーブ全体で一意となる必要があり、クラスターに対する識別のために使用されます。そのため、使用する名前を覚えておくようにしてください。- 以下の構文を使用して、JBoss EAP スレーブホストを起動します。例:
bin/domain.sh --host-config=HOST_SLAVE_XML_FILE_NAME
bin/domain.sh --host-config=HOST_SLAVE_XML_FILE_NAMECopy to Clipboard Copied! Toggle word wrap Toggle overflow bin/domain.sh --host-config=host-slave01.xml
bin/domain.sh --host-config=host-slave01.xmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 管理 CLI を起動します。
- 以下の構文を使用してホスト名を置き換えます。例:
/host=master:write-attribute(name="name",value=UNIQUE_HOST_SLAVE_NAME)
/host=master:write-attribute(name="name",value=UNIQUE_HOST_SLAVE_NAME)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の結果が表示されるはずです。/host=master:write-attribute(name="name",value="host-slave01")
/host=master:write-attribute(name="name",value="host-slave01")Copy to Clipboard Copied! Toggle word wrap Toggle overflow "outcome" => "success"
"outcome" => "success"Copy to Clipboard Copied! Toggle word wrap Toggle overflow これは、以下のようにhost-slave01.xmlファイルの XML を変更します。<host name="host-slave01" xmlns="urn:jboss:domain:1.6">
<host name="host-slave01" xmlns="urn:jboss:domain:1.6">Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 管理対象ドメインに参加する必要がある新たに設定されたホストの場合は、
local要素を削除し、ドメインコントローラーを示すhost属性のremote要素を追加する必要があります。この手順はスタンドアロンサーバーには適用されません。- 以下の構文を使用して、JBoss EAP スレーブホストを起動します。例:
bin/domain.sh --host-config=HOST_SLAVE_XML_FILE_NAME
bin/domain.sh --host-config=HOST_SLAVE_XML_FILE_NAMECopy to Clipboard Copied! Toggle word wrap Toggle overflow bin/domain.sh --host-config=host-slave01.xml
bin/domain.sh --host-config=host-slave01.xmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 管理 CLI を起動します。
- 次の構文を使用してドメインコントローラーを指定します。例:
/host=UNIQUE_HOST_SLAVE_NAME/:write-remote-domain-controller(host=DOMAIN_CONTROLLER_IP_ADDRESS,port=${jboss.domain.master.port:9999},security-realm="ManagementRealm")/host=UNIQUE_HOST_SLAVE_NAME/:write-remote-domain-controller(host=DOMAIN_CONTROLLER_IP_ADDRESS,port=${jboss.domain.master.port:9999},security-realm="ManagementRealm")Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の結果が表示されるはずです。/host=host-slave01/:write-remote-domain-controller(host="192.168.1.200",port=${jboss.domain.master.port:9999},security-realm="ManagementRealm")/host=host-slave01/:write-remote-domain-controller(host="192.168.1.200",port=${jboss.domain.master.port:9999},security-realm="ManagementRealm")Copy to Clipboard Copied! Toggle word wrap Toggle overflow "outcome" => "success"
"outcome" => "success"Copy to Clipboard Copied! Toggle word wrap Toggle overflow これは、以下のようにhost-slave01.xmlファイルの XML を変更します。<domain-controller> <remote host="192.168.1.200" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm"/> </domain-controller><domain-controller> <remote host="192.168.1.200" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm"/> </domain-controller>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
各スレーブサーバーの認証を設定します。
各スレーブサーバーでは、ドメインコントローラーまたはスタンドアロンマスターのManagementRealmで作成されたユーザー名とパスワードが必要です。ドメインコントローラーまたはスタンドアロンマスターで、EAP_HOME/bin/add-user.shコマンドを実行します。同じユーザー名を持つユーザーをスレーブとしてManagementRealmに追加します。このユーザーが外部 JBoss AS インスタンスに対して認証する必要があるかどうか尋ねられた場合は、yesと回答します。パスワードchangemeを使用した、slave1という名前のスレーブに対するコマンドの入出力例は以下のとおりです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow add-user.shの出力から Base64 でエンコードされた<secret>要素をコピーします。認証に Base64 でエンコードされたパスワード値を指定したい場合、add-user.shの出力の最終行より<secret>要素値をコピーします。次の手順でこの値が必要になります。新しい認証を使用するようスレーブホストのセキュリティーレルムを変更します。
以下の方法の 1 つを用いて秘密の値を指定できます。管理 CLI を使用して、サーバー設定ファイルに Base64 でエンコードされたパスワード値を指定します。
EAP_HOME/bin/jboss-cli.shコマンド (Linux の場合) またはEAP_HOME\bin\jboss-cli.batコマンド (Microsoft Windows Server の場合) を使用して管理 CLI を起動します。connectと入力して localhost 上のドメインコントローラーに接続するか、connect IP_ADDRESSと入力してリモートサーバー上のドメインコントローラーに接続します。- 以下のコマンドを入力して秘密の値を指定します。必ず
SECRET_VALUEを前の手順のadd-user出力から返された秘密の値に置き換えてください。各コマンドに対して以下のような結果が表示されるはずです。/core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="SECRET_VALUE") :reload
/core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="SECRET_VALUE") :reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow "outcome" => "success"
"outcome" => "success"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ホストを設定し、vault よりパスワードを取得します。
vault.shスクリプトを使用してマスクされたパスワードを生成します。次のような文字列が生成されます:VAULT::secret::password::ODVmYmJjNGMtZDU2ZC00YmNlLWE4ODMtZjQ1NWNmNDU4ZDc1TElORV9CUkVBS3ZhdWx0。vault に関する詳細は、「機密性の高い文字列のパスワード vault」の項にある 「パスワード valut システム」 を参照してください。EAP_HOME/bin/jboss-cli.shコマンド (Linux の場合) またはEAP_HOME\bin\jboss-cli.batコマンド (Microsoft Windows Server の場合) を使用して管理 CLI を起動します。connectと入力して localhost 上のドメインコントローラーに接続するか、connect IP_ADDRESSと入力してリモートサーバー上のドメインコントローラーに接続します。- 以下のコマンドを入力して秘密の値を指定します。必ず
SECRET_VALUEを前の手順で生成されたマスクされたパスワードに置き換えてください。各コマンドに対して以下のような結果が表示されるはずです。/core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="${VAULT::secret::password::SECRET_VALUE}") :reload/core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="${VAULT::secret::password::SECRET_VALUE}") :reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow "outcome" => "success"
"outcome" => "success"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記
vault でパスワードを作成する場合、Base64 エンコードではなくプレーンテキストで指定する必要があります。
システムプロパティーとしてパスワードを指定します。
次の例は、server.identity.passwordをパスワードのシステムプロパティー名として使用します。- 管理 CLI を使用してサーバー設定ファイルにパスワードのシステムプロパティーを指定します。
EAP_HOME/bin/jboss-cli.shコマンド (Linux の場合) またはEAP_HOME\bin\jboss-cli.batコマンド (Microsoft Windows Server の場合) を使用して管理 CLI を起動します。connectと入力して localhost 上のドメインコントローラーに接続するか、connect IP_ADDRESSと入力してリモートサーバー上のドメインコントローラーに接続します。- 以下のコマンドを入力し、システムプロパティーを使用する秘密のアイデンティティーを設定します。各コマンドに対して以下のような結果が表示されるはずです。
/core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="${server.identity.password}") :reload/core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="${server.identity.password}") :reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow "outcome" => "success"
"outcome" => "success"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- システムプロパティーとしてパスワードを指定する場合、次の方法のいずれかを用いてホストを設定できます。
- 次の例のように、プレーンテキストのパスワードをコマンドライン引数として入力し、サーバーを起動します。
-Dserver.identity.password=changeme
-Dserver.identity.password=changemeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記
パスワードはプレーンテキストで入力する必要があります。ps -efコマンドを実行すると、このパスワードを確認できます。 - パスワードをプロパティーファイルに格納し、プロパティーファイルの URL をコマンドライン引数として渡します。
- キーと値のペアをプロパティーファイルに追加します。例は次のとおりです。
server.identity.password=changeme
server.identity.password=changemeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - コマンドライン引数を用いてサーバーを起動します。.
--properties=URL_TO_PROPERTIES_FILE
--properties=URL_TO_PROPERTIES_FILECopy to Clipboard Copied! Toggle word wrap Toggle overflow
サーバーを再起動します。
ホスト名をユーザー名として使用し、暗号化された文字列をパスワードとして使用してスレーブがマスターに対して認証されます。
スタンドアロンサーバーまたは管理対象ドメインのサーバーグループ内のサーバーが mod_cluster ワーカーノードとして設定されます。クラスター化されたアプリケーションをデプロイする場合、セッションはフェイルオーバーのためにすべてのクラスターサーバーに複製され、外部の web サーバーまたはロードバランサーから要求を許可できます。クラスターの各ノードは、デフォルトで自動検出を使用して他のノードを検出します。自動検出と mod_cluster サブシステムの他の固有設定値を設定するには、『管理および設定ガイド』の「mod_cluster サブシステムの設定」を参照してください。Apache HTTP サーバーを設定するには、『管理および設定ガイド』の「外部 Web サーバーを JBoss EAP 6 アプリケーションの Web フロントエンドとして使用」を参照してください。
第9章 パッチインストール リンクのコピーリンクがクリップボードにコピーされました!
9.1. パッチおよびアップグレード リンクのコピーリンクがクリップボードにコピーされました!
9.2. パッチ適用の仕組み リンクのコピーリンクがクリップボードにコピーされました!
重要
- 非同期更新: 既存製品の通常の更新サイクル以外にリリースされる個別のパッチ。これらには、セキュリティーパッチや、Red Hat Global Support Services (GSS) が特定の問題を修正するために提供する他の個別パッチなどがあります。
- 計画更新: これらには、累積パッチと、既存製品のマイクロアップグレード、マイナーアップグレード、またはメジャーアップグレードなどがあります。累積パッチには、製品の該当バージョンに対してすでに開発された更新がすべて含まれます。
重要
EAP_HOME/modules/system/layers/base/.overlays/$PATCH_ID/$MODULE ディレクトリーから取得されることに注意してください。元のファイルは EAP_HOME/modules/system/layers/base/$MODULE に残ったままになります。セキュリティー上の理由のため、パッチ適用メカニズムにより元の jar ファイルが無効な状態になります。つまり、モジュールを更新するパッチを適用すると、元のモジュールの jar ファイルが変更され使用不可の状態になります。パッチがロールバックされると、元のファイルが使用可能な状態に戻ります。これは、適用されたどのパッチをロールバックするにも、適切なロールバック手順に従う必要があることを意味します。適切なロールバック手順については、「パッチ管理システムを使用して Zip 形式のパッチ適用をロールバックする」を参照してください。
9.3. パッチメーリングリストへのサブスクライブ リンクのコピーリンクがクリップボードにコピーされました!
Red Hat の JBoss チームは、Red Hat JBoss Middleware 製品のセキュリティーに関する情報をお知らせするメーリングリストを管理しています。ここでは、このリストをサブスクライブする方法について取り上げます。
要件
- なし
手順9.1 JBoss Watch List をサブスクライブする
- JBoss Watch メーリングリストのページへ移動します。このリンク をクリックしてください。
- Subscribing to Jboss-watch-list (Jboss-watch-list へのサブスクライブ) にメールアドレスを入力します。
- 名前を入力し、パスワードを選択することも可能です。名前とパスワードの指定は任意ですが推奨されます。
- (サブスクライブ) ボタンを押してサブスクリプションプロセスを開始します。
- メーリングリストのアーカイブは JBoss Watch Mailing List Archives で閲覧できます。
メールアドレスの確認後に、JBoss パッチメーリングリストへのサブスクライブが完了し、セキュリティー関連の通知を受け取るようになります。
9.4. zip 形式のパッチのインストール リンクのコピーリンクがクリップボードにコピーされました!
9.4.1. パッチ管理システム リンクのコピーリンクがクリップボードにコピーされました!
patch コマンドを使用するか、管理コンソールを使用してアクセスできます。パッチ管理システムは、管理ドメイン全体で JBoss EAP 6 サーバーインスタンスを自動的にパッチを適用するために使用できませんが、管理ドメインの各サーバーインスタンスにはパッチを個別に適用できます。
重要
注記
patch コマンドの引数とスイッチがリストされています。
| 引数またはスイッチ | 説明 |
|---|---|
apply | パッチを適用します。 |
--override-all | 競合がある場合に、パッチ操作によりユーザーの変更が上書きされます。 |
--override-modules | モジュールが変更された結果、競合が発生した場合、このスイッチにより、これらの変更がパッチ操作の内容で上書きされます。 |
--override=path(,path) | 指定されたその他のファイルの場合は、競合する変更済みファイルがパッチ操作のファイルで上書きされます。 |
--preserve=path(,path) | 指定されたその他のファイルの場合は、競合する変更済みファイルが保持されます。 |
--host=HOST_NAME | これはドメインモードで使用でき、パッチ操作を実行するホストを指定します。 |
info | 現在インストールされているパッチに関する情報を返します。 |
history | パッチ適用履歴に関する情報を返します。 |
rollback | パッチのアプリケーションがロールバックします。 |
--patch-id=PATCH_ID | ロールバックに必要です。ロールバックするパッチの ID を指定します。 |
--reset-configuration=TRUE|FALSE | ロールバックに必要です。ロールバック操作の一部としてサーバー設定ファイルを復元するかどうかを指定します。 |
--rollback-to | ロールバックするパッチが個別 (1 回だけ) のパッチである場合は、この引数を使用すると、ロールバック操作によって、指定されたパッチの上に適用された他のすべての 1 回だけのパッチもロールバックされます。 |
9.4.2. パッチ管理システムを使用した Zip 形式パッチのインストール リンクのコピーリンクがクリップボードにコピーされました!
zip 形式のパッチは、管理 CLI または管理コンソールから JBoss EAP 6 パッチ管理システムを使用してインストールできます。
重要
要件
- Red Hat カスタマーポータルへの有効なアクセスおよびサブスクリプション。
- zip 形式でインストールされた JBoss 製品の現在のサブスクリプション。
- JBoss EAP 6 サーバーを更新するには、管理 CLI または管理コンソールにアクセスします。『管理設定ガイド』の「管理 CLI の起動」または「管理コンソールへログイン」を参照してください。
警告
手順9.2 管理 CLI を使用して zip パッチを JBoss EAP 6 サーバーインスタンスに適用する
- カスタマーポータル ( https://access.redhat.com/downloads/) からパッチ zip ファイルをダウンロードします。
- 管理 CLI から、以下のコマンドでパッチファイルへの適切なパスを指定してパッチを適用します。
[standalone@localhost:9999 /] patch apply /path/to/downloaded-patch.zip
[standalone@localhost:9999 /] patch apply /path/to/downloaded-patch.zipCopy to Clipboard Copied! Toggle word wrap Toggle overflow パッチを適用するときに競合が発生した場合、patchツールは警告を発します。コマンドを再実行して競合を解決する場合に利用可能なpatchコマンドのスイッチについては、「パッチ管理システム」を参照してください。 - 以下のコマンドを実行して、パッチを適用するために JBoss EAP 6 サーバーを再起動します。
[standalone@localhost:9999 /] shutdown --restart=true
[standalone@localhost:9999 /] shutdown --restart=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手順9.3 管理コンソールを使用して zip パッチを JBoss EAP 6 サーバーインスタンスに適用する
- カスタマーポータル ( https://access.redhat.com/downloads/) からパッチ zip ファイルをダウンロードします。
- 管理コンソールで以下の操作を行います。
- スタンドアロンサーバーの場合: 画面の上部にある Runtime (ランタイム) タブをクリックし、次に Patch Management (パッチ管理) をクリックします。
- 管理ドメインの場合: 画面の上部にある Domain (ドメイン) タブをクリックし、Host (ホスト) ドロップダウンメニューからパッチを適用するホストを選択して、Patch Management (パッチ管理) をクリックします。
- (新規パッチの適用) をクリックします。
- 管理ドメインホストにパッチを適用する場合は、次の画面でホストのサーバーをシャットダウンするかどうかを選択し、 (次へ) をクリックします。
- (参照) ボタンをクリックし、適用するダウンロード済みパッチを選択して、 (次へ) をクリックします。
- パッチを適用する場合に競合がある場合は、警告が表示されます。View error details (エラー詳細の表示) をクリックして競合の詳細を表示します。競合がある場合は、操作をキャンセルするか、Override all conflicts (すべての競合のオーバーライド) チェックボックスを選択します。競合をオーバーライドすると、すべてのユーザーの変更がパッチの内容によって上書きされます。
- パッチが正常に適用されたら、パッチを有効にするために JBoss EAP 6 サーバーを再起動するかどうかを選択し、 (完了) をクリックします。
JBoss EAP 6 サーバーインスタンスに、最新のパッチが適用されます。
9.4.3. パッチ管理システムを使用して Zip 形式のパッチ適用をロールバックする リンクのコピーリンクがクリップボードにコピーされました!
JBoss EAP 6 パッチ管理システムは、以前に適用された zip パッチの適用を管理 CLI または管理コンソールを使用してロールバックするために使用できます。
警告
重要
要件
- JBoss EAP 6 パッチ管理システムを使用して以前に適用されたパッチ。
- JBoss EAP 6 サーバーの管理 CLI または管理コンソールにアクセスします。『管理設定ガイド』の「管理 CLI の起動」または「管理コンソールへログイン」を参照してください。
警告
Reset Configuration オプションの値を指定するときに注意してください。
TRUE に設定された場合、パッチロールバックプロセスにより JBoss EAP 6 サーバー設定ファイルがパッチ適用前の状態にロールバックされます。パッチの適用後に JBoss EAP 6 サーバー設定ファイルに行われたすべての変更は失われます。
FALSE に設定された場合、サーバー設定ファイルはロールバックされません。この状況では、ネームスペースなどの設定がパッチにより変更され (設定は有効でなくなり、手動で修正する必要があります)、ロールバック後にサーバーを起動できないことがあります。
手順9.4 管理 CLI を使用して JBoss EAP 6 サーバーインスタンスからパッチをロールバックする
- 管理 CLI から
patch infoコマンドを使用して、ロールバックするパッチの ID を見つけます。- 累積パッチの場合、パッチ ID は
patch info出力に表示された最初のcumulative-patch-idの値です。 - 個別セキュリティーまたはバグ修正 ID は、
patch info出力に表示された最初のpatchesの値としてリストされます (最も最近に適用された 個別パッチが最初にリストされます)。
- 管理 CLI から、以前の手順の適切なパッチ ID を持つパッチをロールバックします。
[standalone@localhost:9999 /] patch rollback --patch-id=PATCH_ID --reset-configuration=TRUE
[standalone@localhost:9999 /] patch rollback --patch-id=PATCH_ID --reset-configuration=TRUECopy to Clipboard Copied! Toggle word wrap Toggle overflow パッチをロールバックするときに競合が発生した場合、patchツールは警告を発します。コマンドを再実行して競合を解決する場合に利用可能なpatchコマンドのスイッチについては、「パッチ管理システム」を参照してください。 - パッチのロールバックを反映するために、JBoss EAP 6 サーバーを再起動します。
[standalone@localhost:9999 /] shutdown --restart=true
[standalone@localhost:9999 /] shutdown --restart=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手順9.5 管理コンソールを使用して JBoss EAP 6 サーバーインスタンスからパッチをロールバックする
- 管理コンソールで以下の操作を行います。
- スタンドアロンサーバーの場合: 画面の上部にある Runtime (ランタイム) タブをクリックし、次に Patch Management (パッチ管理) をクリックします。
- 管理ドメインの場合: 画面の上部にある Domain (ドメイン) タブをクリックし、Host (ホスト) ドロップダウンメニューから該当するホストを選択して、Patch Management (パッチ管理) をクリックします。
- Recent Patch History (最近のパッチ履歴) テーブルで、ロールバックするパッチを選択し、 (ロールバック) をクリックします。
- 管理ドメインホストの場合は、次の画面でホストのサーバーをシャットダウンするかどうかを選択し、 (次へ) をクリックします。
- ロールバックプロセスのオプションを選択し、 (次へ) をクリックします。
- オプションとロールバックするパッチを確認し、 (次へ) をクリックします。
- Override all (すべてのオーバーライド) オプションが選択されておらず、パッチをロールバックするときに競合がある場合は、警告が表示されます。View error details (エラー詳細の表示) をクリックして競合の詳細を表示します。競合がある場合は、操作をキャンセルするか、 (オプションの選択) をクリックし、Override all (すべてのオーバーライド) チェックボックスを選択した状態で操作を再試行します。競合をオーバーライドすると、すべてのユーザーの変更がロールバック操作によって上書きされます。
- パッチが正常にロールバックされたら、変更を反映するために JBoss EAP 6 サーバーを今すぐ再起動するかどうかを選択し、 (完了) をクリックします。
パッチ (およびオプションでサーバー設定ファイル) は、JBoss EAP 6 サーバーインスタンスでロールバックされます。
9.5. RPM インストールへのパッチ適用 リンクのコピーリンクがクリップボードにコピーされました!
JBoss パッチは、zip (全製品) と RPM (製品のサブセット) の 2 つの形式で配布されます。このタスクでは、RPM 形式でパッチをインストールするのに実行する必要がある手順を示します。
要件
- Red Hat Network への有効なサブスクリプション。
- RPM パッケージでインストールされた JBoss 製品の現在のサブスクリプション。
手順9.6 RPM 形式で JBoss 製品へパッチを適用する
yum を使用して、パッチをインストールすることが可能です。
警告
- JBoss watch メーリングリストにサブスクライブするか、JBoss watch メーリングリストのアーカイブを閲覧して、セキュリティーパッチに関する情報を入手します。
- エラータを読んでセキュリティーパッチに関する情報を取得し、使用環境の JBoss 製品に適用されることを確認します。
- セキュリティーパッチが使用環境の JBoss 製品に適用される場合は、リンク先よりエラータに含まれている更新済みの RPM パッケージをダウンロードします。
- パッチをインストールするには、以下のコマンドまたは同様のコマンドを実行します。
yum update
yum updateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要
RPM インストールを更新する場合、JBoss 製品は RPM でリリースされた修正で累積的に更新されます。
RPM 形式を使用して JBoss 製品に最新の更新が適用されます。
9.6. JBoss セキュリティーパッチの深刻度および影響度 リンクのコピーリンクがクリップボードにコピーされました!
| 深刻度 | 説明 |
|---|---|
| Critical (重大) |
非認証のリモート攻撃者が簡単に悪用でき、ユーザーとやりとりしなくてもシステムが危険にさらされる (任意コード実行) 欠陥にこの深刻度が適用されます。ワームによって悪用される脆弱性になります。認証されたリモートユーザー、ローカルユーザー、または想定外の設定を必要とする欠陥は重大な欠陥とは分類されません。
|
| Important (高) |
リソースの機密性、整合性、または可用性が簡単に危険にさらされる欠陥にこの深刻度が付けられます。ローカルユーザーが権限を取得できる場合、非認証のリモートユーザーが認証によって保護されるリソースを閲覧できる場合、認証されたリモートユーザーが任意コードを実行できる場合、あるいはサービス拒否がローカルまたはリモートユーザーによって引き起こされる場合、この脆弱性タイプになります。
|
| Moderate (中) |
悪用するのは比較的困難であっても、リソースの機密性、整合性、または可用性が一部危険にさらされる原因となる欠陥にこの深刻度が付けられます。重大または重要な影響を与える可能性はあっても、欠陥の技術評価を基にするとそれほど簡単には悪用できなかったり、想定外の設定に影響しない脆弱性のタイプになります。
|
| Low (低) |
セキュリティーに影響する問題で、前述の深刻度に該当しないものにこの深刻度が適用されます。想定外の状況でのみ悪用される可能性があるとみられる脆弱性や、悪用されても影響が最小限にとどまる脆弱性のタイプになります。
|
例9.1 CVSS v2 の影響スコア
C:N/I:P/A:C
C:N/I:P/A:C
9.7. JBoss EAP にデプロイされたアプリケーション内にバンドルされた依存関係のセキュリティー更新管理 リンクのコピーリンクがクリップボードにコピーされました!
ツールとデータソース
- JBoss パッチメーリングリスト
- JBoss パッチのメーリングリストをサブスクライブすると、JBoss 製品で修正されたセキュリティー上の欠陥について通知されるため、デプロイされたアプリケーションが脆弱性のあるバージョンのコンポーネントをバンドルするかどうかを確認できます。
- バンドルされたコンポーネントのセキュリティーアドバイザリーページ
- オープンソースコンポーネントの多くは、独自のセキュリティーアドバイザリーページを持っています。たとえば、既知のセキュリティー問題が多い Struts 2 は一般的に使用されるコンポーネントですが、JBoss EAP ディストリビューションの一部として提供されません。Struts 2 プロジェクトには、アップストリームのセキュリティーアドバイザリーページがあります。デプロイされたアプリケーションによって Struts 2 がバンドルされる場合は、このページを監視する必要があります。商用コンポーネントの多くも、セキュリティーアドバイザリーページがあります。
- 既知の脆弱性に対してデプロイされたアプリケーションを定期的にスキャンする
- これを行う商用ツールは複数あります。また、Red Hat の社員によって開発された Victims というオープンソースツールもありますが、このツールに対するサポートや保証はありません。Victims は複数のビルドおよび統合ツールにプラグインを提供し、既知の脆弱性がある依存関係のバンドルに対して自動的にアプリケーションをスキャンします。Maven、Ant、および Jenkins 用のプラグインがあります。Victims ツールの詳細は、https://victi.ms/about.html を参照してください。
関連トピック:
パート III. セキュアなアプリケーションの開発 リンクのコピーリンクがクリップボードにコピーされました!
第10章 セキュリティーの概要 リンクのコピーリンクがクリップボードにコピーされました!
10.1. アプリケーションセキュリティー リンクのコピーリンクがクリップボードにコピーされました!
10.2. 宣言型セキュリティー リンクのコピーリンクがクリップボードにコピーされました!
10.2.1. Java EE 宣言型セキュリティーの概要 リンクのコピーリンクがクリップボードにコピーされました!
ejb-jar.xml および web.xml デプロイメント記述子を使用して、エンタープライズアプリケーションの EJB および Web コンポーネントへのアクセスをセキュア化します。
10.2.2. セキュリティーの参照 リンクのコピーリンクがクリップボードにコピーされました!
図10.1 セキュリティーロール参照モデル
role-nameType 属性値を isCallerInRole(String) メソッドへの引数として使用することを宣言します。isCallerInRole メソッドを使用すると、コンポーネントは <security-role-ref> または <role-name> 要素で宣言されたロールに呼び出し元があるかどうかを検証できます。<role-name> 要素の値は、<role-link> 要素を介して <security-role> へリンクする必要があります。通常、isCallerInRole は、ロールベースの <method-permissions> 要素を使用して定義できないセキュリティーチェックを実行するために使用されます。
例10.1 ejb-jar.xml 記述子の一部
注記
例10.2 web.xml 記述子の一部
10.2.3. セキュリティーアイデンティティー (ID) リンクのコピーリンクがクリップボードにコピーされました!
図10.2 Java EE セキュリティーアイデンティティーデータモデル
EJBContext.getCallerPrincipal() メソッドのように呼び出し元の ID が変更されないことに注意してください。呼び出し元のセキュリティーロールは、<run-as> または <role-name> 要素値によって指定された単一のロールに設定されます。
anonymous という名前のプリンシパルがすべての発信呼び出しへ割り当てられます。別のプリンシパルを呼び出しに関連付けるには、<run-as-principal> を jboss-ejb3.xml ファイルの Bean に関連付けます。以下は、internal という名前のプリンシパルを前例の RunAsBean に関連付けます。
web.xml ファイルのサーブレット定義にもあります。以下の例は、InternalRole ロールをサーブレットに割り当てる方法を示しています。
principal に関連付けられます。run-as ロールに従う特定のプリンシパルを割り当てるため、<run-as-principal> 要素は jboss-web.xml ファイルにあります。以下は、internal という名前のプリンシパルを上記のサーブレットに関連付ける方法を示しています。
<servlet>
<servlet-name>AServlet</servlet-name>
<run-as-principal>internal</run-as-principal>
</servlet>
<servlet>
<servlet-name>AServlet</servlet-name>
<run-as-principal>internal</run-as-principal>
</servlet>
10.2.4. セキュリティーロール リンクのコピーリンクがクリップボードにコピーされました!
security-role-ref または security-identity 要素によって参照されるセキュリティーロール名は、アプリケーションの宣言済みロールの 1 つへマップする必要があります。アプリケーションアセンブラーは、security-role 要素を宣言して論理セキュリティーロールを定義します。role-name の値は、論理アプリケーションロール名になります (Administrator、Architect、SalesManager など)。
security-role 要素は security-role-ref/role-name の値をコンポーネントロールが参照する論理ロールへマップするためのみ使用されます。ユーザーの割り当てられたロールは、アプリケーションのセキュリティーマネージャーの動的関数です。JBoss では、メソッドパーミッションの宣言に security-role の定義は必要ありません。しかし、アプリケーションサーバーにまたがる移植性を維持し、デプロイメント記述子を保持するため、security-role 要素を指定することが推奨されます。
例10.3 security-role 要素の使用を示す ejb-jar.xml 記述子の一部
例10.4 security-role 要素の使用を示す web.xml 記述子の例 (一部)
10.2.5. EJB メソッドのパーミッション リンクのコピーリンクがクリップボードにコピーされました!
図10.3 Java EE メソッドパーミッション要素
method-permission 要素には、メソッド子要素によって特定された EJB メソッドへアクセスできる論理ロールを定義する 1 つ以上の role-name 子要素が含まれています。また、role-name 要素の代わりに unchecked 要素を指定して、認証されたすべてのユーザーがメソッド子要素によって特定されたメソッドにアクセスできることを宣言できます。さらに、exclude-list 要素があるメソッドにはアクセスできないことを宣言することも可能です。method-permission 要素を使用して、ロールによるアクセスが可能であると宣言されていないメソッドが EJB にある場合、EJB メソッドはデフォルトでは使用されません。これは、メソッドがデフォルトで exclude-list に含まれるようにすることと同じです。
図10.4 Java EE メソッド要素
<method> <ejb-name>EJBNAME</ejb-name> <method-name>*</method-name> </method>
<method>
<ejb-name>EJBNAME</ejb-name>
<method-name>*</method-name>
</method>
<method>
<ejb-name>EJBNAME</ejb-name>
<method-name>METHOD</method-name>
</method>
<method>
<ejb-name>EJBNAME</ejb-name>
<method-name>METHOD</method-name>
</method>
method-intf 要素は、エンタープライズ Bean のホームおよびリモートインターフェースの両方に定義された同じ名前やシグネチャーを持つメソッドを区別するために使用されます。
method-permission 要素の完全な使用例は、例10.5「method-permission 要素の使用を説明する ejb-jar.xml 記述子の一部」 を参照してください。
例10.5 method-permission 要素の使用を説明する ejb-jar.xml 記述子の一部
10.2.6. エンタープライズ Bean セキュリティーアノテーション リンクのコピーリンクがクリップボードにコピーされました!
@DeclareRoles- コードに宣言された各セキュリティーロールを宣言します。ロールの設定に関する詳細情報は、『Java EE 6 Tutorial』 の Specifying Authorized Users by Declaring Security Roles を参照してください。
@RolesAllowed、@PermitAll、および@DenyAll- アノテーションのメソッドパーミッションを指定します。アノテーションメソッドパーミッションの設定に関する詳細は、『Java EE 6 Tutorial』の Specifying Authorized Users by Declaring Security Roles を参照してください。
@RunAs- コンポーネントの伝播されたセキュリティーアイデンティティーを設定します。伝播されたセキュリティーアイデンティティーをアノテーションを使用して設定する方法については、『Java EE 6 Tutorial』の Propagating a Security Identity (Run-As) を参照してください。
10.2.7. Web コンテンツのセキュリティー制約 リンクのコピーリンクがクリップボードにコピーされました!
web.xml の security-constraint 要素を使用して宣言されます。
図10.5 Web コンテンツのセキュリティー制約
NONE、INTEGRAL、および CONFIDENTIAL になります。NONE を指定すると、アプリケーションはトランスポートの保証を必要としません。INTEGRAL の場合、アプリケーションはクライアントとサーバー間での送信中でデータが変更されない方法を必要とします。CONFIDENTIAL の場合、アプリケーションは送信中のデータが他のエンティティーによって見られないようにする方法を必要とします。ほとんどの場合で、INTEGRAL または CONFIDENTIAL フラグが存在すると SSL の使用が必要になります。
図10.6 Web ログインの設定
BASIC、DIGEST、FORM、SPNEGO、および CLIENT-CERT です。<realm-name> 子要素は、HTTP ベーシックおよびダイジェスト認証で使用されるレルム名を指定します。<form-login-config> 子要素は、フォームベースのログインで使用されるログインおよびエラーページを指定します。<auth-method> 値が FORM でない場合、form-login-config と子要素は無視されます。
/restricted パス下にある URL には /restricted ロールが必要であることを示しています。トランスポートの保証は必要なく、ユーザーアイデンティティーの取得に使用される認証メソッドは BASIC HTTP 認証です。
例10.6 web.xml 記述子の一部
10.2.8. フォームベース認証の有効化 リンクのコピーリンクがクリップボードにコピーされました!
web.xml の <login-config> 要素に <auth-method>FORM</auth-method> が含まれるようにします。ログインおよびエラーページも、以下のように <login-config> に定義されます。
FormAuthenticator を使用してユーザーを適切なページに移動します。JBoss EAP はセッションプールを保持するため、リクエストごとに認証情報が存在する必要はありません。FormAuthenticator がリクエストを受け取ると、既存のセッションに関して org.apache.catalina.session.Manager をクエリーします。セッションが存在しない場合、新しいセッションが作成されます。その後、FormAuthenticator がセッションのクレデンシャルを検証します。
注記
/dev/urandom (Linux の場合) より取得され、MD5 でハッシュ化されます。セッション ID は作成時にチェックされ、作成された ID が一意になるようにします。
JSESSIONID と呼ばれ、値はセッション ID の 16 進数列です。このクッキーは、非永続となるよう設定されます。そのため、ブラウザーを終了するとクライアント側でこのクッキーが削除されます。サーバー側では、30 分間活動がないとセッションが期限切れになり、セッションオブジェクトとそれらのクレデンシャルが削除されます。
FormAuthenticator によってリクエストがキャッシュされ、必要な場合は新しいセッションが作成されます。さらに、ユーザーは login-config に定義されたログインページへリダイレクトされます (前述のコード例では、ログインページは login.html になります)。その後、ユーザーは提供される HTML フォームにユーザー名とパスワードを入力します。ユーザー名とパスワードは、j_security_check フォームアクションを介して FormAuthenticator へ渡されます。
FormAuthenticator によって、ユーザー名とパスワードが Web アプリケーションコンテキストにアタッチされるレルムに対して認証されます。JBoss Enterprise Application Platform では、レルムは JBossWebRealm になります。認証に成功すると、FormAuthenticator によってキャッシュから保存されたリクエストが読み出され、ユーザーが元のリクエストへリダイレクトされます。
注記
/j_security_check で終わり、最低でも j_username および j_password パラメーターが存在する場合のみ、フォーム認証リクエストを認識します。
10.2.9. 宣言型セキュリティーの有効化 リンクのコピーリンクがクリップボードにコピーされました!
関連トピック:
第11章 アプリケーションのセキュリティー リンクのコピーリンクがクリップボードにコピーされました!
11.1. データソースセキュリティー リンクのコピーリンクがクリップボードにコピーされました!
11.1.1. データソースセキュリティー リンクのコピーリンクがクリップボードにコピーされました!
- セキュリティードメイン: 「セキュリティードメイン」
- パスワード vault: 「パスワード valut システム」
例11.1 セキュリティードメインの例
例11.2 パスワード vault の例
<security>
<user-name>admin</user-name>
<password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password>
</security>
<security>
<user-name>admin</user-name>
<password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password>
</security>
11.2. EJB アプリケーションセキュリティー リンクのコピーリンクがクリップボードにコピーされました!
11.2.1. セキュリティーアイデンティティー (ID) リンクのコピーリンクがクリップボードにコピーされました!
11.2.1.1. EJB のセキュリティーアイデンティティー リンクのコピーリンクがクリップボードにコピーされました!
11.2.1.2. EJB のセキュリティーアイデンティティーの設定 リンクのコピーリンクがクリップボードにコピーされました!
<security-identity> タグより設定されます。
<security-identity> タグが存在しないと、EJB の独自の呼び出し側アイデンティティーが使用されます。
例11.3 呼び出し側と同じになるように EJB のセキュリティーアイデンティティーを設定する
<security-identity> 要素の宣言を指定しない場合、この挙動がデフォルトになります。
例11.4 特定ロールに EJB のセキュリティーアイデンティティーを設定する
<security-identity> タグの中に <run-as> および <role-name> タグを使用します。
<run-as> を使用すると anonymous という名前のプリンシパルが発信呼び出しへ割り当てられます。違うプリンシパルを割り当てる場合は <run-as-principle> を使用します。
注記
<run-as> 要素と <run-as-principal> 要素を使用することもできます。
以下も参照してください。
11.2.2. EJB メソッドのパーミッション リンクのコピーリンクがクリップボードにコピーされました!
11.2.2.1. EJB メソッドパーミッション リンクのコピーリンクがクリップボードにコピーされました!
<method-permisison> 要素宣言は、EJB のインターフェースメソッドを呼び出しできるロールを指定します。以下の組み合わせのパーミッションを指定できます。
- 名前付き EJB のホームおよびコンポーネントインターフェースメソッド
- 名前付き EJB のホームあるいはコンポーネントインターフェースの指定メソッド
- オーバーロードした名前を持つメソッドセット内の指定メソッド
11.2.2.2. EJB メソッドパーミッションの使用 リンクのコピーリンクがクリップボードにコピーされました!
<method-permission> 要素は、<method> 要素によって定義される EJB メソッドへアクセスできる論理ロールを定義します。XML の構文を表す例は複数あります。メソッドパーミッションステートメントは複数存在することがあり、累積的な影響があります。<method-permission> 要素は <ejb-jar> 記述子の <assembly-descriptor> 要素の子要素です。
例11.5 ロールが EJB の全メソッドへのアクセスできるようにする
例11.6 EJB の特定メソッドへのみロールがアクセスできるようにし、パラメーターが渡すことができるメソッドを制限する
例11.7 認証された全ユーザーが EJB のメソッドにアクセスできるようにする
<unchecked/> 要素を使用すると、認証された全ユーザーが指定のメソッドを使用できます。
例11.8 特定の EJB メソッドを完全に除外して使用されないようにする
例11.9 複数の <method-permission> ブロックが含まれる完全な <assembly-descriptor>
11.2.3. EJB セキュリティーアノテーション リンクのコピーリンクがクリップボードにコピーされました!
11.2.3.1. EJB セキュリティーアノテーション リンクのコピーリンクがクリップボードにコピーされました!
javax.annotation.security アノテーションは JSR250 に定義されています。
- @DeclareRoles
- どのロールが利用可能か宣言します。
- @RunAs
- コンポーネントの伝搬されたセキュリティーアイデンティティーを設定します。
11.2.3.2. EJB セキュリティーアノテーションの使用 リンクのコピーリンクがクリップボードにコピーされました!
XML 記述子かアノテーションを使用して、どのセキュリティーロールが Enterprise JavaBean (EJB) でメソッドを呼び出しできるかを制御することができます。XML 記述子の使用については 「EJB メソッドパーミッションの使用」 を参照してください。
EJB のセキュリティーパーミッションを制御するアノテーション
- @DeclareRoles
- @DeclareRoles を使用して、どのセキュリティーロールに対してパーミッションをチェックするか定義します。@DeclareRoles が存在しない場合、@RolesAllowed アノテーションよりリストが自動的に構築されます。ロールの設定に関する詳細情報は、『Java EE 6 Tutorial』 の Specifying Authorized Users by Declaring Security Roles を参照してください。
- @RolesAllowed、@PermitAll、@DenyAll
@RolesAllowedを使用して、1 つまたは複数のメソッドへのアクセスが許可されるロールをリストします。@PermitAllまたは@DenyAllを使用して、すべてのロールが 1 つまたは複数のメソッドを使用することを許可または拒否します。アノテーションメソッドパーミッションの設定に関する詳細は、『Java EE 6 Tutorial』 の Specifying Authorized Users by Declaring Security Roles を参照してください。- @RunAs
@RunAsを使用して、アノテーション付けされたメソッドから呼び出しを行うときにメソッドが使用するロールを指定します。伝播されたセキュリティーアイデンティティーをアノテーションを使用して設定する方法については、『Java EE 6 Tutorial』 の Propagating a Security Identity (Run-As) を参照してください。
例11.10 セキュリティーアノテーションの例
WelcomeEveryone メソッドにアクセスできます。呼び出し時、GoodBye メソッドは tempemployee ロールを使用します。GoodbyeAdmin メソッドおよびセキュリティーアノテーションのない他のメソッドにアクセスできるのは admin ロールのみです。
11.2.4. EJB へのリモートアクセス リンクのコピーリンクがクリップボードにコピーされました!
11.2.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 になります。 - トランスポートはインボーカーレイヤーによって制御されます。
- 最も下のレイヤーにはデータ形式をワイヤー形式に変換するマーシャラーとアンマーシャラーが含まれています。
11.2.4.2. Remoting コールバック リンクのコピーリンクがクリップボードにコピーされました!
InvocationRequest をクライアントに送信します。コールバックが同期的または非同期的であるかに関わらず、サーバー側のコードは同様に動作します。クライアントのみが違いを認識する必要があります。サーバーの InvocationRequest は responseObject をクライアントに送信します。これはクライアントが要求したペイロードで、要求やイベント通知への直接応答になる場合があります。
m_listeners オブジェクトを使用してリスナーを追跡します。これにはサーバーハンドラーに追加された全リスナーのリストが含まれます。ServerInvocationHandler インターフェースにはこのリストを管理できるようにするメソッドが含まれます。
org.jboss.remoting.InvokerCallbackHandler の実装で、コールバックデータを処理します。コールバックハンドラーの実装後、プルコールバックのリスナーを追加するか、プッシュコールバックのコールバックサーバーを実装します。
プルコールバックでは、Client.addListener() メソッドを使用してクライアントがクライアント自体にサーバーのリスナーリストを追加します。その後、コールバックデータを同期的に配信するためにサーバーを周期的にプルします。ここでは Client.getCallbacks() を使用してプルが実行されます。
プッシュコールバックではクライアントアプリケーションが独自の InvocationHandler を実行する必要があります。これには、クライアント上で Remoting サービスを実行する必要があります。これは コールバックサーバーと呼ばれます。コールバックサーバーは受信する要求を非同期的に許可し、要求元 (この場合はサーバー) のために処理します。メインサーバーを用いてクライアントのコールバックサーバーを登録するには、コールバックサーバーの InvokerLocator を addListener への 2 番目の引数として渡します。
11.2.4.3. リモーティングサーバーの検出 リンクのコピーリンクがクリップボードにコピーされました!
11.2.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インターフェースです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow unsecureインターフェースのホストごとの定義はdomain.xmlまたはstandalone.xmlと同じディレクトリーにあるhost.xmlで定義されます。また、このインターフェースは複数の他のサブシステムによっても使用されます。変更する場合は十分注意してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - socket-binding
remotingサブシステムによって使用されるデフォルトの socket-binding は TCP ポート 4777 へバインドします。この設定を変更する必要がある場合はソケットバインディングとソケットバインディンググループに関するドキュメントを参照してください。- EJB の リモーティングコネクター参照
- EJB サブシステムにはリモートメソッド呼び出しに対するリモーティングコネクターへの参照が含まれています。デフォルト設定は次のとおりです。
<remote connector-ref="remoting-connector" thread-pool-name="default"/>
<remote connector-ref="remoting-connector" thread-pool-name="default"/>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - セキュアなトランスポート設定
- Remoting はクライアントの要求があれば StartTLS を使用して安全な接続 (HTTPS、Secure Servlet など) を使用します。安全な接続と安全でない接続の両方で同じソケットバインディング (ネットワークポート) が使用されるため、サーバー側に追加の設定をする必要はありません。クライアントは必要に応じて安全なトランスポートまたは安全でないトランスポートを要求します。EJB、ORB、JMS プロバイダーなどの Remoting を使用する JBoss EAP のコンポーネントはデフォルトで安全なインターフェースを使用します。
警告
ワーカースレッドプールは、Remoting コネクターからの作業を処理できるスレッドのグループのことです。単一の要素 <worker-thread-pool> で、複数の属性を取ります。ネットワークタイムアウトやスレッド不足が発生したり、メモリーの使用を制限する場合にこれらの属性を調節します。特定の推奨設定は状況によって異なります。詳細は Red Hat グローバルサポートサービスまでご連絡ください。
| 属性 | 説明 | 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 EAP 6 の複数のサブシステムによって使用されます。カスタムコネクターの要素や属性の設定はアプリケーションによって異なるため、詳細は Red Hat グローバルサポートサービスまでご連絡ください。
| 属性 | 説明 | CLI コマンド |
|---|---|---|
| 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 EAP 6 インストールで使用可能です。
| /profile=default/subsystem=remoting/connector=remoting-connector/:write-attribute(name=security-realm,value=ApplicationRealm)
|
| 属性 | 説明 | 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 属性を取り、認証に使用します。
| 属性 | 説明 | 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
/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 の保護品質 (QoP) 値が希望順に並ぶスペース区切りのリストである
value 属性が含まれます。
|
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=qop,value=["auth"])
|
| strength |
SASL の暗号強度の値が希望順に並ぶスペース区切りのリストである
value 属性が含まれます。
|
/profile=default/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-anonymous,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)
|
例11.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">
<connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/>
</subsystem>
文書化されていない設定内容
- JIDI および マルチキャスト自動検出
11.2.4.5. リモート EJB クライアントを用いたセキュリティーレルムの使用 リンクのコピーリンクがクリップボードにコピーされました!
- 新しいセキュリティーレルムをドメインコントローラーかスタンドアロンサーバーに追加します。
- 次のパラメーターをアプリケーションのクラスパスにある
jboss-ejb-client.propertiesファイルに追加します。この例では、ファイルの他のパラメーターは接続をdefaultとしてみなすことを前提とします。remote.connection.default.username=appuser remote.connection.default.password=apppassword
remote.connection.default.username=appuser remote.connection.default.password=apppasswordCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 新しいセキュリティーレルムを使用するドメインまたはスタンドアロンサーバー上にカスタム Remoting コネクターを作成します。
- カスタム Remoting コネクターを用いてプロファイルを使用するよう設定されているサーバーグループに EJB をデプロイします。管理対象ドメインを使用していない場合はスタンドアロンサーバーに EJB をデプロイします。
11.2.4.6. 新しいセキュリティーレルムの追加 リンクのコピーリンクがクリップボードにコピーされました!
管理 CLI を実行します。
jboss-cli.shまたはjboss-cli.batコマンドを開始し、サーバーに接続します。新しいセキュリティーレルムを作成します。
次のコマンドを実行し、ドメインコントローラーまたはスタンドアロンサーバー上でMyDomainRealmという名前の新しいセキュリティーレルムを作成します。ドメインインスタンスでは以下コマンドを使用します。/host=master/core-service=management/security-realm=MyDomainRealm:add()
/host=master/core-service=management/security-realm=MyDomainRealm:add()Copy to Clipboard Copied! Toggle word wrap Toggle overflow スタンドアロンインスタンスでは以下のコマンドを使用します。/core-service=management/security-realm=MyDomainRealm:add()
/core-service=management/security-realm=MyDomainRealm:add()Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいロールの情報を保存するプロパティーファイルへの参照を作成します。
次のコマンドを実行し、新しいロールに関連するプロパティーが含まれるmyfile.propertiesという名前のファイルのポインターを作成します。注記
新たに作成されたプロパティーファイルは、含まれるadd-user.shおよびadd-user.batスクリプトによって管理されません。そのため、外部で管理する必要があります。ドメインインスタンスでは以下コマンドを使用します。/host=master/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
/host=master/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)Copy to Clipboard Copied! Toggle word wrap Toggle overflow スタンドアロンインスタンスでは以下のコマンドを使用します。/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
新しいセキュリティーレルムが作成されます。新たに作成されたこのレルムにユーザーやロールを追加すると、デフォルトのセキュリティーレルムとは別のファイルに情報が保存されます。新規ファイルはご使用のアプリケーションやプロシージャーを使用して管理できます。
11.2.4.7. セキュリティーレルムへのユーザーの追加 リンクのコピーリンクがクリップボードにコピーされました!
add-user.shまたはadd-user.batコマンドを実行します。ターミナルを開き、EAP_HOME/bin/ディレクトリーへ移動します。Red Hat Enterprise Linux や他の UNIX 系のオペレーティングシステムを稼働している場合は、add-user.shを実行します。Microsoft Windows Server を稼働している場合はadd-user.batを実行します。管理ユーザーかアプリケーションユーザーのどちらを追加するか選択します。
この手順ではbを入力し、アプリケーションユーザーを追加します。ユーザーが追加されるレルムを選択します。
デフォルトでは、ApplicationRealmのみが選択可能です。カスタムレルムが追加されている場合はその名前を入力します。入力を促されたらユーザー名、パスワード、ロールを入力します。
入力を促されたら希望のユーザー名、パスワード、任意のロールを入力します。yesを入力して選択を確認するか、noを入力して変更をキャンセルします。変更はセキュリティーレルムの各プロパティーファイルに書き込まれます。
11.2.4.8. SSL による暗号化を使用したリモート EJB アクセス リンクのコピーリンクがクリップボードにコピーされました!
警告
11.3. JAX-RS アプリケーションセキュリティー リンクのコピーリンクがクリップボードにコピーされました!
11.3.1. RESTEasy JAX-RS Web サービスのロールベースのセキュリティーの有効化 リンクのコピーリンクがクリップボードにコピーされました!
RESTEasy は JAX-RS メソッドの @RolesAllowed、@PermitAll、@DenyAll アノテーションをサポートしますが、デフォルトではこれらのアノテーションを認識しません。次の手順に従って web.xml ファイルを設定し、ロールベースセキュリティーを有効にします。
警告
手順11.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><context-param> <param-name>resteasy.role.based.security</param-name> <param-value>true</param-value> </context-param>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - <security-role> タグを使用して RESTEasy JAX-RS WAR ファイル内で使用されるすべてのロールを宣言します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - すべてのロールに対して JAX-RS ランタイムが対応する全 URL へのアクセスを承認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ロールベースセキュリティーが定義されたロールのセットによりアプリケーション内で有効になります。
例11.12 ロールベースセキュリティーの設定例
11.3.2. アノテーションを使用した JAX-RS Web サービスのセキュア化 リンクのコピーリンクがクリップボードにコピーされました!
サポート対象のセキュリティーアノテーションを使用して JAX-RS Web サービスをセキュアにする手順を取り上げます。
手順11.2 サポート対象のセキュリティーアノテーションを使用した JAX-RS Web サービスのセキュア化
- ロールベースセキュリティーを有効にします。詳細は 「RESTEasy JAX-RS Web サービスのロールベースのセキュリティーの有効化」 を参照してください。
- JAX-RS Web サービスにセキュリティーアノテーションを追加します。RESTEasy は次のアノテーションをサポートします。
- @RolesAllowed
- メソッドにアクセスできるロールを定義します。ロールはすべて
web.xmlファイルに定義する必要があります。 - @PermitAll
web.xmlファイルに定義されている全ロールによるメソッドへのアクセスを許可します。- @DenyAll
- メソッドへのアクセスをすべて拒否します。
第12章 セキュリティーサブシステム リンクのコピーリンクがクリップボードにコピーされました!
12.1. セキュリティーサブシステム リンクのコピーリンクがクリップボードにコピーされました!
security サブシステムは、アプリケーションのセキュリティーインフラストラクチャーを提供します。サブシステムは、現在のリクエストに関連するセキュリティーコンテキストを使用して認証マネージャー、承認マネージャー、監査マネージャー、およびマッピングマネージャーの機能を関係するコンテナに提供します。
security サブシステムはデフォルトで事前設定されているため、セキュリティー要素を変更する必要はほとんどありません。変更が必要となる可能性がある唯一のセキュリティー要素は、deep-copy-subject-mode を使用するかどうかです。ほとんどの場合で、管理者はセキュリティードメインの設定に集中します。
ディープコピーサブジェクトモードの詳細は、「ディープコピーサブジェクトモード」を参照してください。
セキュリティードメインとは、認証、承認、監査、およびマッピングを制御するために単一または複数のアプリケーションが使用する Java Authentication and Authorization Service (JAAS) 宣言型セキュリティー設定のセットです。デフォルトでは、jboss-ejb-policy、jboss-web-policy、および other の 3 つのセキュリティードメインが含まれています。アプリケーションの要件に対応するため、必要な数のセキュリティードメインを作成できます。セキュリティードメインの詳細は、「アプリケーションでのセキュリティードメインの使用」を参照してください。
12.2. セキュリティーサブシステムの構造 リンクのコピーリンクがクリップボードにコピーされました!
例12.1 セキュリティーサブシステムの設定例
<security-management>、 <subject-factory>、および <security-properties> 要素はデフォルト設定では存在しません。<subject-factory> および <security-properties> 要素は JBoss EAP 6.1 およびそれ以降のバージョンで廃止になりました。
12.3. セキュリティーサブシステムの設定 リンクのコピーリンクがクリップボードにコピーされました!
12.3.1. セキュリティーサブシステムの設定 リンクのコピーリンクがクリップボードにコピーされました!
- <security-management>
- このセクションは、security サブシステムの高レベルの動作をオーバーライドします。スレッドの安全性を強化するため、セキュリティートークンへコピーまたはリンクするかどうかを指定するオプション設定
deep-copy-subject-modeが含まれます。 - <security-domains>
- 複数のセキュリティードメインを保持するコンテナ要素です。セキュリティードメインには認証、承認、マッピング、監査モジュール、JASPI 認証、および JSSE 設定の情報が含まれることがあります。アプリケーションはセキュリティードメインを指定してセキュリティー情報を管理します。
- <security-properties>
- java.security.Security クラスに設定されるプロパティーの名前と値が含まれます。
12.3.2. セキュリティー管理 リンクのコピーリンクがクリップボードにコピーされました!
12.3.2.1. ディープコピーサブジェクトモード リンクのコピーリンクがクリップボードにコピーされました!
12.3.2.2. ディープコピーサブジェクトモードの有効化 リンクのコピーリンクがクリップボードにコピーされました!
手順12.1 管理コンソールからディープコピーセキュリティーモードを有効化
管理コンソールへのログイン
手順の詳細は、カスタマーポータルの https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/ にある JBoss Enterprise Application Platform 6.x『管理および設定ガイド』の「管理コンソール」の章を参照してください。管理対象ドメイン: 適切なプロファイルを選択します。
管理対象ドメインではプロファイルごとにセキュリティーサブシステムが設定されているため、各プロファイルに対して個別にディープコピーセキュリティーモードを有効または無効にできます。プロファイルを選択するには、画面の上部にあるの右上にある Configuration をクリックし、左上にある Profile ドロップダウンボックスよりプロファイルを選択します。Security Subsystem 設定メニューを開きます。
Security メニューを展開し、Security Subsystem を選択します。Deep Copy Subject モードを有効にします。
をクリックします。Deep Copy Subjects の横にあるボックスにチェックを入れ、ディープコピーサブジェクトモードを有効にします。
管理 CLI を使用してこのオプションを有効にしたい場合、以下のコマンドの 1 つを使用します。
例12.2 管理対象ドメイン
/profile=full/subsystem=security/:write-attribute(name=deep-copy-subject-mode,value=TRUE)
/profile=full/subsystem=security/:write-attribute(name=deep-copy-subject-mode,value=TRUE)
例12.3 スタンドアロンサーバー
/subsystem=security/:write-attribute(name=deep-copy-subject-mode,value=TRUE)
/subsystem=security/:write-attribute(name=deep-copy-subject-mode,value=TRUE)
12.3.3. セキュリティードメイン リンクのコピーリンクがクリップボードにコピーされました!
12.3.3.1. セキュリティードメイン リンクのコピーリンクがクリップボードにコピーされました!
12.3.3.2. セキュリティードメインに関連する CLI 操作 リンクのコピーリンクがクリップボードにコピーされました!
例12.4 flush-cache
/subsystem=security/security-domain=other:read-operation-description(name=flush-cache)
/subsystem=security/security-domain=other:read-operation-description(name=flush-cache)
例12.5 list-cached-principals
/subsystem=security/security-domain=other:read-operation-description(name=list-cached-principals)
/subsystem=security/security-domain=other:read-operation-description(name=list-cached-principals)
第13章 認証および承認 リンクのコピーリンクがクリップボードにコピーされました!
13.1. Kerberos と SPNEGO の統合 リンクのコピーリンクがクリップボードにコピーされました!
13.1.1. Kerberos と SPNEGO の統合 リンクのコピーリンクがクリップボードにコピーされました!
通常の設定では、アクティブディレクトリードメインによって制御されるデスクトップにユーザーがログインします。ユーザーは Web ブラウザー (Firefox または Internet Explorer) を使用して、JBoss EAP 上でホストされる JBoss Negotiation を使用する Web アプリケーションへアクセスします。Web ブラウザーは、デスクトップのサインオン情報を Web アプリケーションへ転送します。JBoss EAP は、アクティブディレクトリーまたは Kerberos サーバーを用いてバックグラウンドの GSS メッセージを使用し、ユーザーを検証します。これにより、ユーザーは Web アプリケーションへのシームレスな SSO を実現できます。
13.1.2. SPNEGO を使用したデスクトップ SSO リンクのコピーリンクがクリップボードにコピーされました!
- セキュリティードメイン
- システムプロパティー
- Web アプリケーション
手順13.1 SPNEGO を使用するデスクトップ SSO の設定
セキュリティードメインの設定
セキュリティードメインを設定して、サーバーのアイデンティティーを表し、Web アプリケーションをセキュアにします。例13.1 セキュリティードメインの設定
Copy to Clipboard Copied! Toggle word wrap Toggle overflow システムプロパティーの設定
必要な場合は、システムプロパティーをドメインモデルに設定できます。例13.2 システムプロパティーの設定
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Web アプリケーションの設定
オーセンティケーターは上書きできませんが、NegotiationAuthenticatorをバルブとして jboss-web.xml 記述子に追加し、Web アプリケーションを設定できます。注記
セキュア化するリソースの決定に使用されるため、security-constraintおよびlogin-configが web.xml ファイルに定義されている必要があります。しかし、選択されたauth-methodはこのオーセンティケーターによって上書きされます。例13.3 Web アプリケーションの設定
Copy to Clipboard Copied! Toggle word wrap Toggle overflow また、JBoss Negotiation クラスの場所を特定できるようにするため、Web アプリケーションはMETA-INF/MANIFEST.MFに定義された依存関係を必要とします。例13.4
META-INF/MANIFEST.MFでの依存関係の定義Manifest-Version: 1.0 Build-Jdk: 1.6.0_24 Dependencies: org.jboss.security.negotiationManifest-Version: 1.0 Build-Jdk: 1.6.0_24 Dependencies: org.jboss.security.negotiationCopy to Clipboard Copied! Toggle word wrap Toggle overflow
13.1.3. Microsoft Windows ドメインでの JBoss Negotiation の設定 リンクのコピーリンクがクリップボードにコピーされました!
{hostname}、レルムは {realm}、ドメインは {domain}、JBoss EAP インスタンスをホストするサーバーは {machine_name} を使用します。
手順13.2 Microsoft Windows ドメインでの JBoss Negotiation の設定
既存のサービスプリンシパルマッピングの消去
Microsoft Windows ネットワークでは、一部のマッピングが自動作成されます。自動的に作成されたマッピングを削除し、ネゴシエーションが適切に行われるようにサーバーのアイデンティティーをサービスプリンシパルへマップします。マッピングにより、クライアントコンピューター上の Web ブラウザーがサーバーを信頼し、SPNEGO の実行を試みます。クライアントコンピューターは、HTTP{hostname}形式のマッピングに対し、ドメインコントローラーを検証します。既存のマッピングを削除する手順は次のとおりです。- コマンド
setspn -L {machine_name}を使用して、コンピューターに対してドメインに登録されたマッピングをリストします。 - コマンド
setspn -D HTTP/{hostname} {machine_name}およびsetspn -D host/{hostname} {machine_name}を使用して、既存のマッピングを削除します。
- ホストユーザーアカウントを作成します。
注記
ホストユーザー名には{machine_name}以外の名前を使用してください。これ以降では、ホストユーザー名として{user_name}を使用します。 {user_name}と{hostname}の間のマッピングを定義します。- コマンド
ktpass -princ HTTP/{hostname}@{realm} -pass * -mapuser {domain}\{user_name}を実行し、サービスプリンシパルマッピングを設定します。 - 入力を要求されたら、ユーザー名のパスワードを入力します。
注記
ユーザー名のパスワードをリセットします。これはキータブをエクスポートするために必要です。 - コマンド
setspn -L {user_name}を実行し、マッピングを検証します。
ユーザーのキータブを、JBoss EAP がインストールされているサーバーへエクスポートします。
コマンドktab -k service.keytab -a HTTP/{hostname}@{realm}を実行し、キータブをエクスポートします。注記
このコマンドは、HTTP/{hostname} プリンシパルのチケットを、JBoss 上でホストセキュリティードメインを設定するために使用されるキータブservice.keytabへエクスポートします。- セキュリティードメイン内のプリンシパルを次のように定義します。
<module-option name="principal">HTTP/{hostname}@{realm}</module-option><module-option name="principal">HTTP/{hostname}@{realm}</module-option>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.1.4. PicketLink IDP の Kerberos 認証 リンクのコピーリンクがクリップボードにコピーされました!
手順13.3 JBoss EAP 6 のインストールと Kerberos の設定
- JBoss EAP 6 をダウンロードし、インストールします。インストールガイド のインストール手順を参照してください。
- Oracle Java または IBM Java の使用に関わらず、無制限の JCE を使用する必要があります。無制限の JCE を使用しないと、JBoss サーバーが適切な SPNEGO メカニズムタイプでネゴシエートできません (
GSS_IAKERB_MECHANISMである 1.3.6.1.5.2.5 を使用)。 - 以下の例を使用して、希望の Java バージョンを使用するよう JBoss を設定します。
export JAVA_HOME=JDK/JRE_directory
export JAVA_HOME=JDK/JRE_directoryCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手順13.4 JBoss Negotiation Toolkit を使用した Kerberos 設定のテスト
- Github の JBoss Negotiation Toolkit を使用します。
- 設定ファイルを編集し、
mvn clean installコマンドを使用してプロジェクトを構築します。 - ファイル
jboss-negotiation-toolkit/target/jboss-negotiation-toolkit.warを$JBOSS_HOME/standalone/deployments/へコピーします。 - 3 つのセクションがすべて JBoss Negotiation Toolkit を通過することを検証します。
手順13.5 PicketLink IDP の設定
idp.war への変更
この例では、PicketLink Quickstarts リポジトリーにある idp.war および employee.war アーカイブを使用します。idp.war のファイルを以下のように変更します。
- IDP は JBoss Negotiation モジュールを使用するため、
org.jboss.security.negotiationモジュールを$JBOSS_HOME/standalone/deployments/idp.war/META-INF/jboss-deployment-structure.xmlに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - SPNEGO の追加バルブ
org.jboss.security.negotiation.NegotiationAuthenticatorを$JBOSS_HOME/standalone/deployments/idp.war/WEB-INF/jboss-web.xmlに追加します。 - 以下のとおり、
$JBOSS_HOME/standalone/deployments/idp.war/WEB-INF/jboss-web.xmlのsecurity-domainをidpからSPNEGOに変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Kerberos サーバー設定によってプリンシパルに追加されたセキュリティーロールを
$JBOSS_HOME/standalone/deployments/idp.war/WEB-INF/web.xmlに追加または変更します。 - 次のように、ファイル
$JBOSS_HOME/standalone/deployments/idp.war/WEB-INF/picketlink.xmlを変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow IdentityURLを変更し、IDP が実行されているサーバーのホスト名と同じになるようにします。Trustを変更し、アイデンティティープロバイダーが信頼するドメイン名が含まれるようにします。employee.warを変更します。Kerberos サーバー設定によってプリンシパルに追加されたセキュリティーロールを$JBOSS_HOME/standalone/deployments/employee.war/WEB-INF/web.xmlに追加または変更します。$JBOSS_HOME/standalone/configuration/standalone.xmlファイルのsecurity domain設定を編集します。ロールマッピング設定は、通常のセキュリティードメイン設定のものと同じです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
注記
jboss.security.disable.secdomain.option を true に設定する必要があります。詳細は「セキュリティードメインでの認証の設定」を参照してください。次のようにログインモジュールを更新します。
<login-module code="Kerberos" flag="required"> <module-option name="principal" value="HTTP/something.com@yourdomain.COM"/> <module-option name="credsType" value="acceptor"/> <module-option name="useKeytab" value="file:///root/keytab"/> </login-module>
<login-module code="Kerberos" flag="required">
<module-option name="principal" value="HTTP/something.com@yourdomain.COM"/>
<module-option name="credsType" value="acceptor"/>
<module-option name="useKeytab" value="file:///root/keytab"/>
</login-module>
手順13.6 PicketLink IDP の Kerberos 認証設定の検証
$JBOSS_HOME/bin/standalone.shを使用して JBoss EAP サーバーを起動します。- Kerberos を使用するようブラウザー (Firefox など) を設定します。次の手順に従ってください: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/sso-config-firefox.html
- 上記のとおりに設定された Firefox から
http://YOUR_DOMAIN:8080/employeeにアクセスできることを確認します。
13.1.5. PicketLink IDP での証明書を用いたログイン リンクのコピーリンクがクリップボードにコピーされました!
SSL をサポートするよう PicketLink IDP を設定できます。次の手順は、SSL クライアント認証をサポートする IDP として Web アプリケーションを設定する方法の例になります。ユーザーを認証するために IDP を設定する方法は 2 つあります。
- SSL が使用されている場合、サーバーはクライアントに対して証明書を要求し、その証明書を使用してユーザーを認証します。
- クライアントによって証明書が提供されなかった場合、フォームベース認証が実行されます。
13.1.5.1. JBoss EAP 6.3 での SSL 設定 リンクのコピーリンクがクリップボードにコピーされました!
手順13.7 サーバーの証明書、キーストア、およびトラストストアの作成
サーバーの証明書の作成
以下のコマンドを使用して、サーバーの証明書を作成します。追加情報を入力するよう要求され、これらの値を入力する必要があります。証明書の CN 名は DNS サーバー名と同じでなければなりません。たとえば、ローカルホストの場合では以下のコマンドを使用できます。keytool -genkey -alias server -keyalg RSA -keystore server.keystore -storepass change_it -validity 365
keytool -genkey -alias server -keyalg RSA -keystore server.keystore -storepass change_it -validity 365Copy to Clipboard Copied! Toggle word wrap Toggle overflow keytool -genkey -alias server -keystore server.keystore -storepass change_it -keypass password -dname "CN=localhost,OU=QE,O=example.com,L=Brno,C=CZ"
keytool -genkey -alias server -keystore server.keystore -storepass change_it -keypass password -dname "CN=localhost,OU=QE,O=example.com,L=Brno,C=CZ"Copy to Clipboard Copied! Toggle word wrap Toggle overflow クライアント証明書の作成
SSL を介してリソースにアクセスするときに、この証明書を使用してサーバーに対して認証を行います。keytool -genkey -alias client -keystore client.keystore -storepass change_it -validity 365 -keyalg RSA -keysize 2048 -storetype pkcs12
keytool -genkey -alias client -keystore client.keystore -storepass change_it -validity 365 -keyalg RSA -keysize 2048 -storetype pkcs12Copy to Clipboard Copied! Toggle word wrap Toggle overflow トラストストアの作成
クライアントの証明書をエクスポートし、この証明書をインポートしてトラストストアを作成します。keytool -exportcert -keystore client.keystore -storetype pkcs12 -storepass change_it -alias client -keypass change_it -file client.keystore keytool -import -file client.keystore -alias client -keystore client.truststore
keytool -exportcert -keystore client.keystore -storetype pkcs12 -storepass change_it -alias client -keypass change_it -file client.keystore keytool -import -file client.keystore -alias client -keystore client.truststoreCopy to Clipboard Copied! Toggle word wrap Toggle overflow JBoss EAP 6.3 サーバーインストールの変更による SSL の有効化
以下のコネクターを Web サブシステムに追加して、SSL を有効にします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow サーバーの再起動
サーバーを再起動し、https://localhost:8443 で応答することを確認します。証明書の信用
サーバー証明書を信用するよう要求されます。
アプリケーションにアクセスする前に、client.keystore をブラウザーにインポートする必要があります。このファイルにはクライアント証明書が含まれています。アプリケーションにアクセスすると、サーバーとの認証に使用する必要がある証明書を選択するよう要求されます。適切な証明書を選択します。
以下のセキュリティードメインをサーバーインストールに追加します。スタンドアロンモードを使用している場合は、JBOSS_HOME/standalone/configuration/standalone.xml に追加する必要があります。
正規表現ユーザー名ログインモジュールを証明書ログインモジュールの後に使用すると、LDAP からロールを取得するためにプリンシパル名からユーザー名、UID、またはその他のフィールドを取得できます。このモジュールには、regex というオプションがあります。このオプションはプリンシパル名に適用される正規表現を指定し、その結果は後続のログインモジュールへ渡されます。
UID=007, EMAILADDRESS=something@something, CN=James Bond, O=SpyAgency というプリンシパル名が入力されると、結果として UID=007 が出力されます。
例13.5 正規表現ユーザー名ログインモジュールの例
java.util.regex.Pattern クラスのドキュメントを参照してください。
13.2. 認証 リンクのコピーリンクがクリップボードにコピーされました!
13.2.1. 認証 リンクのコピーリンクがクリップボードにコピーされました!
13.2.2. セキュリティードメインでの認証の設定 リンクのコピーリンクがクリップボードにコピーされました!
手順13.8 セキュリティードメインの認証設定
セキュリティードメインの詳細ビューを開きます。
- 管理コンソールの上部にある Configuration ラベルをクリックします。
- プロファイルビューの左上にある Profile 選択ボックスから編集するプロファイルを選択します。
- Security メニューを展開し、Security Domains を選択します。
- 編集したいセキュリティードメインの View リンクをクリックします。
認証サブシステム設定に移動します。
ビューの上部にある Authentication ラベルを選択します (未選択である場合)。設定領域が Login Modules と Details の 2 つの領域に分割されます。ログインモジュールは、設定の基本単位です。セキュリティードメインには複数のログインモジュールを含めることができ、各ログインモジュールには複数の属性とオプションを含めることができます。認証モジュールを追加します。
Add をクリックして、JAAS 認証モジュールを追加します。モジュールの詳細を入力します。Code はモジュールのクラス名です。Flag 設定は、モジュールが同じセキュリティードメイン内で他の認証モジュールにどのように関係するかを制御します。フラグの説明Java Enterprise Edition 6 の仕様には、以下のようなセキュリティーモジュールの説明があります。次のリストは、http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA に記載されています。詳細については、そのドキュメントを参照してください。
Expand フラグ 説明 required LoginModule は成功する必要があります。成功または失敗すると、LoginModule リストを下方向に進み認証が続行されます。requisite LoginModule は成功する必要があります。成功すると、LoginModule リストの下方向に進み認証が続行されます。失敗すると、即座に制御がアプリケーションに戻されます (LoginModule リストの下方向に進まず、認証が続行されません)。sufficient LoginModule は成功する必要はありません。成功した場合は、即座に制御がアプリケーションに戻されます (LoginModule リストの下方向に進まず、認証が続行されません)。失敗すると、LoginModule リストの下方向に進み認証が続行されます。optional LoginModule は成功する必要がありません。成功または失敗した場合、LoginModule リストの下方向に進み認証が続行されます。認証設定を編集します。
モジュールを追加したら、画面の Details セクションで をクリックすることにより、Code または Flags を変更できます。Attributes タブが選択されていることを確認します。モジュールオプションを追加、編集、または削除します (任意)。
モジュールにオプションを追加する必要がある場合は、Login Modules リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。 ボタンをクリックし、オプションのキーと値を指定します。 ボタンを使用してオプションを削除します。
認証モジュールが、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。
jboss.security.security_domain モジュールのオプション
デフォルトでは、セキュリティードメインに定義された各ログインモジュールには jboss.security.security_domain モジュールオプションが自動的に追加されます。既知のオプションのみが定義されるようチェックを行うログインモジュールでは、このオプションによって問題が発生します。このようなログインモジュールの 1 つが IBM Kerberos ログインモジュールの com.ibm.security.auth.module.Krb5LoginModule です。
true に設定します。以下を起動パラメーターに追加します。
-Djboss.security.disable.secdomain.option=true
-Djboss.security.disable.secdomain.option=true
13.3. JAAS - Java Authentication and Authorization Service リンクのコピーリンクがクリップボードにコピーされました!
13.3.1. JAAS リンクのコピーリンクがクリップボードにコピーされました!
13.3.2. JAAS コアクラス リンクのコピーリンクがクリップボードにコピーされました!
Subject(javax.security.auth.Subject)
Configuration(javax.security.auth.login.Configuration)LoginContext(javax.security.auth.login.LoginContext)
Principal(java.security.Principal)Callback(javax.security.auth.callback.Callback)CallbackHandler(javax.security.auth.callback.CallbackHandler)LoginModule(javax.security.auth.spi.LoginModule)
13.3.3. サブジェクトおよびプリンシパルクラス リンクのコピーリンクがクリップボードにコピーされました!
Subject クラスは JAAS の中心クラスです。Subject は人やサービスなどの、単一エンティティーの情報を表します。これには、エンティティーのプリンシパル、パブリックのクレデンシャル、プライベートのクレデンシャルなどが含まれます。JAAS API は既存の Java 2 の java.security.Principal インターフェースを使用して、プリンシパルを表します。これは、基本的に入力された名前になります。
public Set getPrincipals() {...}
public Set getPrincipals(Class c) {...}
public Set getPrincipals() {...}
public Set getPrincipals(Class c) {...}
getPrincipals() はサブジェクトに含まれるすべてのプリンシパルを返します。getPrincipals(Class c) は、クラス c のインスタンスまたはそのサブクラスの 1 つであるプリンシパルのみを返します。サブジェクトに一致するプリンシパルがない場合は、空のセットが返されます。
java.security.acl.Group インターフェースは java.security.Principal のサブインターフェースであるため、プリンシパルのセットのインスタンスは、他のプリンシパルやプリンシパルグループの論理グループを表すことがあります。
13.3.4. サブジェクトの認証 リンクのコピーリンクがクリップボードにコピーされました!
- アプリケーションは
LoginContextをインスタンス化し、ログイン設定の名前とCallbackHandlerを渡して、設定LoginModuleが必要とするCallbackオブジェクトを追加します。 LoginContextは、名前付きログイン設定に含まれるすべてのLoginModulesをロードするためConfigurationを確認します。このような名前付き設定が存在しない場合は、other設定がデフォルトで使用されます。- アプリケーションによって、
LoginContext.loginメソッドが呼び出されます。 - ログインメソッドはロードされた各
LoginModuleを呼び出します。各LoginModuleはサブジェクトを認証するため、関連するLoginModuleでハンドルメソッドを呼び出し、認証プロセスに必要な情報を取得します。必要な情報は、Callbackオブジェクトのアレイの形式でハンドルメソッドに渡されます。認証に成功すると、LoginModuleは関連のプリンシパルとクレデンシャルをサブジェクトに関連付けします。 LoginContextは認証ステータスをアプリケーションに返します。ログインメソッドから返されると認証が成功したことになります。ログインメソッドによって LoginException が発生すると認証に失敗したことになります。- 認証に成功すると、アプリケーションは
LoginContext.getSubjectメソッドを使用して認証されたサブジェクトを取得します。 - サブジェクトの認証が完了した後に
LoginContext.logoutメソッドを呼び出すと、loginメソッドによりサブジェクトに関連付けられたすべてのプリンシパルおよび関連情報を削除できます。
LoginContext クラスは、サブジェクト認証の基本メソッドを提供し、基礎となる認証技術に依存しないアプリケーションを開発する方法を提供します。LoginContext は、特定のアプリケーション向けに設定された認証サービスを決定するため Configuration を確認します。LoginModule クラスは認証サービスを表します。そのため、アプリケーション自体を変更しなくても、異なるログインモジュールをアプリケーションにプラグ可能です。次のコードは、アプリケーションがサブジェクトを認証するために必要となる手順を示しています。
LoginModule インターフェースの実装を作成することで、認証技術を統合します。これにより、管理者は異なる認証技術を 1 つのアプリケーションにプラグできます。複数の LoginModule をチェーン化し、複数の認証技術を認証プロセスに加えることが可能です。たとえば、1 つの LoginModule がユーザー名およびパスワードベースの認証を行い、別の LoginModule をスマートカードリーダや生体認証などのハードウェアデバイスへ接続するインターフェースとすることが可能です。
LoginModule のライフサイクルは、クライアントがログインメソッドを作成し公開するLoginContext オブジェクトによって決定されます。このプロセスには 2 つのフェーズがあり、プロセスの手順は次のようになります。
LoginContextは引数のないパブリックコンストラクターを使用して、設定されたLoginModuleを作成します。- 各
LoginModuleは、初期化メソッドへの呼び出しによって初期化されます。Subject引数は null 以外になることが保証されます。初期化メソッドのシグネチャーはpublic void initialize(Subject subject, CallbackHandler callbackHandler, Map sharedState, Map options)です。 loginメソッドは、認証プロセスを開始するために呼び出されます。たとえば、あるメソッド実装はユーザーにユーザー名とパスワードの入力を求め、NIS や LDAP などのネーミングサービスに保存されたデータに対してこの情報を検証することがあります。別の実装は、スマートカードや生体認証デバイスにインターフェースとして接続したり、基礎となるオペレーティングシステムからユーザー情報を抽出したりすることがあります。各LoginModuleによるユーザーアイデンティティーの検証は、JAAS 認証のフェーズ 1 とみなされます。loginメソッドのシグネチャーはboolean login() throws LoginExceptionです。LoginExceptionは失敗を意味します。true の戻り値はメソッドが成功したことを示し、false の戻り値はログインモジュールが無視されることを示します。LoginContextの全体的な認証が成功すると、各LoginModuleでcommitが呼び出されます。フェーズ 1 がLoginModuleに対して成功すると、コミットメソッドはフェーズ 2 を続行し、関連するプリンシパル、パブリッククレデンシャル、プライベートクレデンシャルをサブジェクトに関連付けます。フェーズ 1 がLoginModuleに対して失敗すると、commitはユーザー名やパスワードなどの以前保存した認証状態をすべて削除します。commitメソッドのシグネチャーはboolean commit() throws LoginExceptionです。コミットフェーズの完了に失敗すると、LoginExceptionが発生します。true が返されるとメソッドが成功したことを示し、false が返されるとログインモジュールが無視されることを示します。LoginContextの全体的な認証が失敗すると、各LoginModuleでabortメソッドが呼び出されます。abortメソッドはログインまたは初期化メソッドによって作成されたすべての認証状態を削除または破棄します。abortメソッドのシグネチャーはboolean abort() throws LoginExceptionです。abortフェーズの完了に失敗するとLoginExceptionが発生します。true が返されるとメソッドが成功したことを示し、false が返されるとログインモジュールが無視されることを示します- ログイン成功後に認証状態を削除するため、アプリケーションは
LoginContextでlogoutを呼び出します。これにより、各LoginModuleでlogoutメソッドが呼び出されます。logoutメソッドは、commit操作中に当初サブジェクトに関連付けられていたプリンシパルとクレデンシャルを削除します。クレデンシャルは削除時に破棄されるはずです。logoutメソッドのシグネチャーはboolean logout() throws LoginExceptionです。ログアウトプロセスの完了に失敗すると、LoginExceptionが発生します。true が返されるとメソッドが成功したことを示し、false が返されるとログインモジュールが無視されることを示します。
LoginModule がユーザーと通信して認証情報を取得する必要がある場合、CallbackHandler オブジェクトを使用します。アプリケーションは、 CallbackHandler インターフェースを実装して LoginContext に渡し、基礎となるログインモジュールに直接認証情報を送信します。
CallbackHandler を使用して、パスワードやスマートカード PIN などのユーザー入力による情報を取得したり、ステータスなどの情報をユーザーに提供したりします。アプリケーションによる CallbackHandler の指定を可能にすることで、基礎となる LoginModule がアプリケーションとユーザーが対話するさまざまな方法に依存しないようにします。たとえば、GUI アプリケーションの CallbackHandler の実装は、ウィンドウを表示してユーザーの入力を求めることがあります。一方でアプリケーションサーバーなどの GUI でない環境の CallbackHandler 実装は、アプリケーションサーバー API を使用してクレデンシャル情報を取得することがあります。CallbackHandler インターフェースには実装するメソッドが 1 つあります。
void handle(Callback[] callbacks)
throws java.io.IOException,
UnsupportedCallbackException;
void handle(Callback[] callbacks)
throws java.io.IOException,
UnsupportedCallbackException;
Callback インターフェースです。これは複数のデフォルト実装が提供されているタグ付けインターフェースで、前述の例で使用した NameCallback と PasswordCallback が含まれます。LoginModule は Callback を使用し、認証メカニズムで必要となる情報を要求します。LoginModule は認証のログインフェーズの間に Callback のアレイを直接 CallbackHandler.handle メソッドに渡します。callbackhandler がハンドルメソッドに渡された Callback オブジェクトの使用方法が分からない場合は、UnsupportedCallbackException が発生し、ログイン呼び出しが中止されます。
13.4. JASPI (Java Authentication SPI for Containers) リンクのコピーリンクがクリップボードにコピーされました!
13.4.1. JASPI (Java Authentication SPI for Containers) のセキュリティー リンクのコピーリンクがクリップボードにコピーされました!
13.4.2. JASPI (Java Authentication SPI for Containers) のセキュリティーの設定 リンクのコピーリンクがクリップボードにコピーされました!
<authentication-jaspi> 要素をセキュリティードメインに追加します。設定は標準的な認証モジュールと似ていますが、ログインモジュール要素は <login-module-stack> 要素で囲まれています。設定の構成は次のとおりです。
例13.6 authentication-jaspi 要素の構成
EAP_HOME/domain/configuration/domain.xml または EAP_HOME/standalone/configuration/standalone.xml へ直接追加する必要があります。
13.5. 承認 リンクのコピーリンクがクリップボードにコピーされました!
13.5.1. 承認 リンクのコピーリンクがクリップボードにコピーされました!
13.5.2. セキュリティードメインにおける承認の設定 リンクのコピーリンクがクリップボードにコピーされました!
手順13.9 セキュリティードメインの承認設定
セキュリティードメインの詳細ビューを開きます。
- 管理コンソールの上部にある Configuration ラベルをクリックします。
- 管理対象ドメインでは、左上にある Profile ドロップダウンボックスで編集するプロファイルを選択します。
- Security メニューを展開し、Security Domains を選択します。
- 編集したいセキュリティードメインの View リンクをクリックします。
承認サブシステム設定に移動します。
画面の上部にある Authorization ラベルを選択します。設定領域が Policies と Details の 2 つの領域に分割されます。ログインモジュールは、設定の基本単位です。セキュリティードメインには複数の承認ポリシーを含めることができ、各ログインモジュールには複数の属性とオプションを含めることができます。ポリシーを追加します。
Add をクリックして、JAAS 承認ポリシーモジュールを追加します。モジュールの詳細を入力します。Code はモジュールのクラス名です。Flag は、モジュールが同じセキュリティードメイン内で他の承認ポリシーモジュールにどのように関係するかを制御します。フラグの説明Java Enterprise Edition 6 の仕様には、以下のようなセキュリティーモジュールの説明があります。次のリストは、http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA に記載されています。詳細については、そのドキュメントを参照してください。
Expand フラグ 説明 required LoginModule は成功する必要があります。成功または失敗すると、LoginModule リストを下方向に進み承認が続行されます。requisite LoginModule は成功する必要があります。成功すると、LoginModule リストの下方向に進み承認が続行されます。失敗すると、即座に制御がアプリケーションに戻されます (LoginModule リストの下方向に進まず、承認が続行されません)。sufficient LoginModule は成功する必要はありません。成功した場合は、即座に制御がアプリケーションに戻されます (LoginModule リストの下方向に進まず、承認が続行されません)。失敗すると、LoginModule リストの下方向に進み承認が続行されます。optional LoginModule は成功する必要がありません。成功または失敗した場合、LoginModule リストを下方向に進み承認が続行されます。承認設定を編集します。
モジュールを追加したら、画面の Details セクションで をクリックすることにより、Code または Flags を変更できます。Attributes タブが選択されていることを確認します。モジュールオプションを追加、編集、または削除します (任意)。
モジュールにオプションを追加する必要がある場合は、Policies リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。 をクリックし、オプションのキーと値を指定します。 ボタンを使用してオプションを削除します。
承認ポリシーモジュールが、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。
13.6. JACC (Java Authorization Contract for Containers) リンクのコピーリンクがクリップボードにコピーされました!
13.6.1. JACC (Java Authorization Contract for Containers) リンクのコピーリンクがクリップボードにコピーされました!
13.6.2. JACC (Java Authorization Contract for Containers) のセキュリティーの設定 リンクのコピーリンクがクリップボードにコピーされました!
jboss-web.xml を編集する必要があります。
セキュリティードメインに JACC サポートを追加するには、required フラグセットで JACC 承認ポリシーをセキュリティードメインの承認スタックへ追加します。以下は JACC サポートを持つセキュリティードメインの例になりますが、セキュリティードメインは直接 XML には設定されず、管理コンソールまたは管理 CLI で設定されます。
jboss-web.xml は デプロイメントの 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>
<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 で説明されています。
例13.7 EJB の JACC メソッドパーミッション例
<security> 子要素の jboss-ejb3.xml 記述子に宣言されます。セキュリティードメインの他に、EJB が実行されるプリンシパルを変更する run-as プリンシパル を指定することもできます。
例13.8 EJB におけるセキュリティードメイン宣言の例
13.6.3. XACML を使用した粒度の細かい承認 リンクのコピーリンクがクリップボードにコピーされました!
13.6.3.1. 粒度の細かい承認および XACML リンクのコピーリンクがクリップボードにコピーされました!
- PERMIT - アクセスは許可されます。
- DENY - アクセスは拒否されます。
- INDETERMINATE - PDP にエラーがあります。
- NOTAPPLICABLE - 要求に足りない属性があるか、一致するポリシーがありません。
- Oasis XACML v2.0 ライブラリー
- JAXB v2.0 ベースのオブジェクトモデル
- XACML ポリシーおよび属性を保存または読み出しするための ExistDB 統合。
13.6.3.2. 粒度の細かい承認向けの XACML の設定 リンクのコピーリンクがクリップボードにコピーされました!
手順13.10 XACML の設定
- 単一の jar ファイルであるライブラリーをダウンロードします。
XACML に対して 1 つ以上のポリシーファイルを作成します。
WEB-INF/classes下に、すべてのポリシーを保存するpoliciesを作成します。WEB-INF/classesディレクトリー下にpolicyConfig.xmlを作成します。定義できる 2 タイプのポリシーセットは次のとおりです。- RPS (ロールパーミッションポリシーセット)
- PPS (パーミッションポリシーセット)
例13.9 RPS (ロールパーミッションポリシーセット)
Employee (従業員)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Manager (マネージャー)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例13.10 PPS (パーミッションポリシーセット)
Employee (従業員)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Manager (マネージャー)Copy to Clipboard Copied! Toggle word wrap Toggle overflow XACML エンジンに対して設定ファイルを作成します。
設定ファイルは、ロケーターを設定し、ポリシーが保存されるディレクトリーを示すために作成されます。例13.11 設定ファイル
ポリシーファイルのディレクトリーのみを示す設定ファイルCopy to Clipboard Copied! Toggle word wrap Toggle overflow ポリシーセットを定義する設定ファイルCopy to Clipboard Copied! Toggle word wrap Toggle overflow - PDP (ポリシー決定ポイント) を作成し、設定ファイルに渡します。
- PEP (ポリシー強制ポイント) は、コンテキストを基に XACML 要求を作成します。XACML 要求を PDP へ渡し、以下のアクセス決定の 1 つを取得します。
- Permit
- Deny
- Indeterminate
- Not Applicable
例13.12 アクセス決定
許可の条件Copy to Clipboard Copied! Toggle word wrap Toggle overflow 許可の拒否Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.7. セキュリティーの監査 リンクのコピーリンクがクリップボードにコピーされました!
13.7.1. セキュリティー監査 リンクのコピーリンクがクリップボードにコピーされました!
13.7.2. セキュリティー監査の設定 リンクのコピーリンクがクリップボードにコピーされました!
手順13.11 セキュリティードメインのセキュリティー監査の設定
セキュリティードメインの詳細ビューを開きます。
- 画面の上部にある Configuration をクリックします。
- 管理対象ドメインでは、左上にある Profile 選択ボックスから編集するプロファイルを選択します。
- Security メニューを展開し、Security Domains を選択します。
- 編集したいセキュリティードメインの View リンクをクリックします。
監査サブシステム設定に移動します。
画面の上部にある Audit タブを選択します。設定領域が Provider Modules と Details の 2 つの領域に分割されます。プロバイダーモジュールは、設定の基本単位です。セキュリティードメインには複数のプロバイダーモジュールを含めることができ、各ログインモジュールには属性とオプションを含めることができます。プロバイダーモジュールを追加します。
Add をクリックします。Code セクションに、プロバイダーモジュールのクラス名を入力します。モジュールの挙動を確認します。
監査モジュールの目的は、セキュリティーサブシステムのイベントを監視する方法を提供することです。ログファイルの記述、メールによる通知、またはその他の監査メカニズムによって監視を行うことが可能です。たとえば、JBoss EAP 6 にはデフォルトでLogAuditProviderモジュールが含まれています。この監査モジュールを前述の手順に従って有効にすると、EAP_HOMEディレクトリー内のlogサブフォルダーにあるaudit.logファイルにセキュリティー通知を書き込みます。前述の手順がLogAuditProviderのコンテキスト内で動作するかを確認するには、通知が発生するようなアクションを実行した後、監査ログファイルをチェックします。含まれるセキュリティー監査プロバイダーモジュールの完全一覧は 「含まれるセキュリティー監査プロバイダーモジュール」 を参照してください。モジュールオプションを追加、編集、または削除します (任意)。
モジュールにオプションを追加する場合は、Policies リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。 をクリックし、オプションのキーと値を指定します。すでに存在するオプションを編集するには、 をクリックして削除し、 をクリックして正しいオプションで再度追加します。
セキュリティー監査モジュールは、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。
13.7.3. 新しいセキュリティープロパティー リンクのコピーリンクがクリップボードにコピーされました!
| 名前 | 説明 | 設定可能な値 | 挙動 | デフォルト |
|---|---|---|---|---|
org.jboss.security.web.audit | このプロパティーは Web リクエストのセキュリティー監査の細かさを制御します。 | off、headers、cookies、parameters、attributes | 指定されたコンポーネント (またはカンマ区切りのコンポーネントグループ) が Web リクエストから監査されます。 | headers,parameters |
org.jboss.security.web.audit.mask | このプロパティーを使用すると、Web リクエストのヘッダー、パラメーター、クッキーおよび属性に対して照合される文字列のリストを指定できます。指定されたマスクに一致する要素は、セキュリティー監査ロギングから除外されます。 | ヘッダー、パラメーター、クッキーおよび属性のキーを示すコンマ区切りの文字列。 | 現在、マスクの一致は厳格ではありません。たとえば、authorization のマスクは authorization というヘッダーと custom_authorization というパラメーターの両方をマスクします。厳格なマスクは今後のリリースで導入される予定です。 | j_password,authorization |
13.8. セキュリティーマッピング リンクのコピーリンクがクリップボードにコピーされました!
13.8.1. セキュリティーマッピング リンクのコピーリンクがクリップボードにコピーされました!
13.8.2. セキュリティードメインでのセキュリティーマッピングの設定 リンクのコピーリンクがクリップボードにコピーされました!
手順13.12 セキュリティードメインでのセキュリティーマッピングの設定
セキュリティードメインの詳細ビューを開きます。
- 管理コンソールの上部にある Configuration ラベルをクリックします。
- 管理対象ドメインでは、左上にある Profile 選択ボックスからプロファイルを選択します。
- Security メニューを展開し、Security Domains を選択します。
- 編集したいセキュリティードメインの View リンクをクリックします。
マッピングサブシステム設定に移動します。
画面の上部にある Mapping ラベルを選択します。設定領域が Modules と Details の 2 つの領域に分割されます。マッピングモジュールは、設定の基本単位です。セキュリティードメインには複数のマッピングモジュールを含めることができ、各ログインモジュールには複数の属性とオプションを含めることができます。セキュリティーマッピングモジュールを追加します。
Add をクリックします。モジュールの詳細を記入します。Code がモジュールのクラス名です。Type フィールドは、このモジュールが実行するマッピングのタイプを示します。許可される値は、principal、role、attribute、または credential です。セキュリティーマッピングモジュールを編集します。
モジュールを追加したら、Code または Type を変更できます。- Attributes タブを選択します。
- 画面の Details セクションにある をクリックします。
モジュールオプションを追加、編集、または削除します (任意)。
モジュールにオプションを追加する場合は、Policies リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。 をクリックし、オプションのキーと値を指定します。すでに存在するオプションを編集するには、Remove をクリックして削除し、新たな値で再度追加します。ボタンを使用して、オプションを削除します。
セキュリティーマッピングモジュールは、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。
13.9. アプリケーションでのセキュリティードメインの使用 リンクのコピーリンクがクリップボードにコピーされました!
アプリケーションでセキュリティードメインを使用するには、最初にサーバーの設定でセキュリティードメインを定義し、アプリケーションのデプロイメント記述子でアプリケーションに対して有効にする必要があります。その後、使用する EJB に必要なアノテーションを追加する必要があります。ここでは、アプリケーションでセキュリティードメインを使用するために必要な手順について取り上げます。
警告
手順13.13 セキュリティードメインを使用するようアプリケーションを設定
セキュリティードメインの定義
サーバーの設定ファイルでセキュリティードメインを定義した後、アプリケーションの記述子ファイルでアプリケーションに対して有効にする必要があります。サーバーの設定ファイルへセキュリティードメインを設定
セキュリティードメインは、サーバーの設定ファイルのsecurityサブシステムに設定されます。JBoss EAP 6 インスタンスが管理対象ドメインで実行されている場合、domain/configuration/domain.xmlファイルになります。JBoss EAP 6 インスタンスがスタンドアロンサーバーとして実行されている場合はstandalone/configuration/standalone.xmlファイルになります。other、jboss-web-policy、およびjboss-ejb-policyセキュリティードメインはデフォルトとして JBoss EAP 6 に提供されます。次の XML の例は、サーバーの設定ファイルのsecurityサブシステムよりコピーされました。セキュリティードメインのcache-type属性は、高速な認証チェックを行うためにキャッシュを指定します。簡単なマップをキャッシュとして使用するdefaultか、Infinispan キャッシュを使用するinfinispanを値として使用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 管理コンソールまたは CLI を使用して、追加のセキュリティードメインを必要に応じて設定できます。アプリケーションの記述子ファイルでのセキュリティードメインの有効化
セキュリティードメインはアプリケーションのWEB-INF/web.xmlファイルにある<jboss-web>要素の<security-domain>子要素に指定されます。次の例はmy-domainという名前のセキュリティードメインを設定します。<jboss-web> <security-domain>my-domain</security-domain> </jboss-web><jboss-web> <security-domain>my-domain</security-domain> </jboss-web>Copy to Clipboard Copied! Toggle word wrap Toggle overflow これがWEB-INF/jboss-web.xml記述子に指定できる多くの設定の 1 つになります。
EJB への必要なアノテーションの追加
@SecurityDomainおよび@RolesAllowedアノテーションを使用してセキュリティーを EJB に設定します。次の EJB コードの例は、guestロールのユーザーによるotherセキュリティードメインへのアクセスを制限します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow その他のコード例は、Red Hat カスタマーポータルより入手できる JBoss EAP 6 Quickstarts バンドルのejb-securityクイックスタートを参照してください。
第14章 シングルサインオン (SSO) リンクのコピーリンクがクリップボードにコピーされました!
14.1. Web アプリケーションのシングルサインオン (SSO) リンクのコピーリンクがクリップボードにコピーされました!
SSO (シングルサインオン) は 1 つのリソースへの認証を用いて他のリソースへのアクセスを暗黙的に承認できるようにします。
クラスター化されていない SSO は、アプリケーションの承認情報の共有を同じ仮想ホスト内に制限します。また、ホストの障害に対する耐性を持ちません。クラスター化された SSO データは複数の仮想ホストのアプリケーション間で共有することができ、フェイルオーバーに対する耐性を持ちます。さらに、クラスター化された SSO はロードバランサーからのリクエストを受信することができます。
リソースが保護されていない場合、ユーザーの認証は完全に無視されます。ユーザーが保護されたリソースにアクセスすると、ユーザーの認証が必要になります。
14.2. Web アプリケーションのクラスター化されたシングルサインオン (SSO) リンクのコピーリンクがクリップボードにコピーされました!
jboss-web.xml に設定されます。
- Apache Tomcat の ClusteredSingleSignOn
- Apache Tomcat の IDPWebBrowserSSOValve
- PicketLink によって提供される SPNEGO ベースの SSO
14.3. 適切な SSO 実装の選択 リンクのコピーリンクがクリップボードにコピーされました!
web.xml デプロイメント記述子で <distributable/> タグを使用します。クラスター化された SSO を使用すると、アプリケーションがクラスター化されているかどうかに関わらず、セキュリティーコンテキストやアイデンティティー情報のレプリケーションが可能になります。これらの技術は一緒に使用されることもありますが、概念は異なります。
Microsoft Active Directory など、Kerberos ベースの認証承認システムがすでに組織で使用されている場合は、同じシステムを使用して JBoss EAP 6 上で実行されているエンタープライズアプリケーションを透過的に認証することができます。
1 つのインスタンスで複数のアプリケーションを実行し、これらのアプリケーションに対して SSO セッションのレプリケーションを有効にする必要がある場合、クラスター化されていない SSO が要件に合います。
クラスター全体で単一または複数のアプリケーションを実行し、これらのアプリケーションに対して SSO セッションのレプリケーションを有効にする必要がある場合、クラスター化された SSO が要件に合います。
14.4. Web アプリケーションでのシングルサインオン (SSO) の使用 リンクのコピーリンクがクリップボードにコピーされました!
シングルサインオン (SSO) の機能は Web および Infinispan サブシステムによって提供されます。この手順に従って Web アプリケーションに SSO を設定します。
要件
- 認証と承認を処理する設定されたセキュリティードメイン。
infinispanサブシステム。管理対象ドメインの場合、このサブシステムはfull-haプロファイルにあります。スタンドアロンサーバーではstandalone-full-ha.xml設定を使用します。webcache-containerと SSO replicated-cache が存在する必要があります。最初の設定ファイルにはwebcache-container がすでに含まれており、一部の設定には SSO replicated-cache も含まれています。以下のコマンドを使用して SSO replicated-cache をチェックし、有効にします。これらのコマンドは管理対象ドメインのfullプロファイルを変更することに注意してください。コマンドを変更して、スタンドアロンサーバーで別のプロファイルを使用したり、コマンドの/profile=ha部分を削除することができます。例14.1
webcache-container の確認前述のプロファイルや設定には、デフォルトとしてwebcache-container が含まれています。次のコマンドを使用して、webcache-container の存在を確認します。異なるプロファイルを使用する場合は、haをその名前に置き換えます。/profile=ha/subsystem=infinispan/cache-container=web/:read-resource(recursive=false,proxies=false,include-runtime=false,include-defaults=true)
/profile=ha/subsystem=infinispan/cache-container=web/:read-resource(recursive=false,proxies=false,include-runtime=false,include-defaults=true)Copy to Clipboard Copied! Toggle word wrap Toggle overflow サブシステムが存在する場合、結果はsuccessになります。存在しない場合は追加する必要があります。例14.2
webcache-container の追加次の 3 つのコマンドを使用してwebcache-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:add(aliases=["standard-session-cache"],default-cache="repl",module="org.jboss.as.clustering.web.infinispan")Copy to Clipboard Copied! Toggle word wrap Toggle overflow /profile=ha/subsystem=infinispan/cache-container=web/transport=TRANSPORT:add(lock-timeout=60000)
/profile=ha/subsystem=infinispan/cache-container=web/transport=TRANSPORT:add(lock-timeout=60000)Copy to Clipboard Copied! Toggle word wrap Toggle overflow /profile=ha/subsystem=infinispan/cache-container=web/replicated-cache=repl:add(mode="ASYNC",batching=true)
/profile=ha/subsystem=infinispan/cache-container=web/replicated-cache=repl:add(mode="ASYNC",batching=true)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例14.3
SSOreplicated-cache の確認次の管理 CLI コマンドを実行します。/profile=ha/subsystem=infinispan/cache-container=web/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
/profile=ha/subsystem=infinispan/cache-container=web/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)Copy to Clipboard Copied! Toggle word wrap Toggle overflow "sso" => {のような出力を探します。このような出力が見つからない場合、設定に SSO replicated-cache は存在しません。例14.4
SSOreplicated-cache の追加/profile=ha/subsystem=infinispan/cache-container=web/replicated-cache=sso:add(mode="SYNC", batching=true)
/profile=ha/subsystem=infinispan/cache-container=web/replicated-cache=sso:add(mode="SYNC", batching=true)Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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")
/profile=ha/subsystem=web/virtual-server=default-host/sso=configuration:add(cache-container="web",cache-name="sso",reauthenticate="false",domain="domain.com")Copy to Clipboard Copied! Toggle word wrap Toggle overflow - SSO 情報を共有する各アプリケーションは、
jboss-web.xmlデプロイメント記述子にある同じ <security-domain> とweb.xml設定ファイルにある同じレルムを使用するよう設定されている必要があります。
サーバープロファイルの Web サブシステム下に sso を設定します。 cache-container 属性が存在する場合は ClusteredSingleSignOn バージョンが使用されます。それ以外の場合は標準の SingleSignOn クラスが使用されます。
例14.5 クラスター化された SSO 設定の例
/subsystem=web/virtual-server=default-host/sso=configuration:add(cache-container="web",cache-name="sso",reauthenticate="false",domain="domain.com")
/subsystem=web/virtual-server=default-host/sso=configuration:add(cache-container="web",cache-name="sso",reauthenticate="false",domain="domain.com")
例14.6 クラスター化されていない SSO 設定の例
/subsystem=web/virtual-server=default-host/sso=configuration:add(reauthenticate="false")
/subsystem=web/virtual-server=default-host/sso=configuration:add(reauthenticate="false")
アプリケーションはメソッド javax.servlet.http.HttpSession.invalidate() を呼び出し、プログラムを用いてセッションを無効化することができます。
14.5. Kerberos リンクのコピーリンクがクリップボードにコピーされました!
14.6. SPNEGO リンクのコピーリンクがクリップボードにコピーされました!
14.7. Microsoft Active Directory リンクのコピーリンクがクリップボードにコピーされました!
- ユーザー、コンピューター、パスワードなどのリソースの情報を保存する LDAP (Lightweight Directory Access Protocol) 。
- ネットワーク上でセキュアな認証を提供する Kerberos。
- IP アドレスやコンピューターのホスト名、ネットワーク上のその他のデバイス間でマッピングを提供する DNS (Domain Name Service)。
14.8. Web アプリケーションに対する Kerberos または Microsoft Active Directory のデスクトップ SSO の設定 リンクのコピーリンクがクリップボードにコピーされました!
Microsoft Active Directory など、組織における既存の Kerberos ベースの認証承認インフラストラクチャーを使用して Web アプリケーションや EJB アプリケーションを認証するため、JBoss EAP 6 に内蔵される JBoss Negotiation の機能を使用することが可能です。Web アプリケーションを適切に設定すれば、デスクトップまたはネットワークへのログインに成功するだけでWeb アプリケーションに対して透過的な認証を行えるため、追加のログインプロンプトは必要ありません。
JBoss EAP 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 に使用されるクラスとのマッピングを表しています。
| 単純名 | クラス名 | 目的 |
|---|---|---|
| Kerberos |
com.sun.security.auth.module.Krb5LoginModule
com.ibm.security.auth.module.Krb5LoginModule
|
Oracle JDK 使用時の Kerberos ログインモジュール
IBM JDK 使用時の 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 アプリケーションに対して設定することは難しいこともあるため、大変便利なツールと言えます。
手順14.1 Web または EJB アプリケーションへ SSO 認証を設定
サーバーのアイデンティティーを表すセキュリティードメインを 1 つ設定します。必要な場合はシステムプロパティーを設定します。
最初のセキュリティードメインは、コンテナ自体をディレクトリーサービスへ認証します。ユーザーではなくコンテナ自体の認証であるため、ある種の静的ログインメカニズムを受容するログインモジュールを使用する必要があります。この例では静的プリンシパルを使用し、クレデンシャルが含まれるキータブファイルを参照します。明確にするため、この例では XML コードが提供されていますが、管理コンソールまたは管理 CLI を使用してセキュリティードメインを設定するようにしてください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Web アプリケーションやアプリケーションをセキュアにするため、2 つ目のセキュリティードメインを設定します。必要な場合はシステムプロパティーを設定します。
2 つ目のセキュリティードメインは、個別のユーザーを Kerberos または SPNEGO 認証サーバーへ認証するために使用されます。ユーザーの認証に最低でも 1 つのログインモジュールが必要で、ユーザーに適用するロールを検索するために別のログインモジュールが必要となります。次の XML コードは SPNEGO セキュリティードメインの例を表しています。これには、ロールを個別のユーザーにマッピングする承認モジュールが含まれます。認証サーバー上でロールを検索するモジュールを使用することもできます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow web.xmlの security-constraint と login-config を指定します。web.xml記述子にはセキュリティー制約とログイン設定に関する情報が含まれています。セキュリティー制約とログイン情報の値の例は次のとおりです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow jboss-web.xml記述子にセキュリティードメインと他の設定を指定します。クライアント側のセキュリティードメイン (例の 2 番目のセキュリティードメイン) の名前をデプロイメントのjboss-web.xml記述子に指定し、アプリケーションがこのセキュリティードメインを使用するよう指示します。オーセンティケーターを直接上書きすることができなくなりましたが、必要な場合は NegotiationAuthenticator をバルブとしてjboss-web.xml記述子に追加することができます。<jacc-star-role-allow>は任意で、複数のロール名を一致させるためアスタリスク (*) の使用を許可します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow アプリケーションの
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
Manifest-Version: 1.0 Build-Jdk: 1.6.0_24 Dependencies: org.jboss.security.negotiationCopy to Clipboard Copied! Toggle word wrap Toggle overflow - この代わりに、
META-INF/jboss-deployment-structure.xmlファイルを編集して依存関係をアプリケーションに追加することもできます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Web アプリケーションが Kerberos、Microsoft Active Directory、またはその他の SPNEGO 対応のディレクトリーサービスに対してクレデンシャルを許可および認証します。ユーザーがすでにディレクトリーサービスにログインしているシステムよりアプリケーションを実行し、必要なロールがすでにユーザーに適用されている場合は、Web アプリケーションは認証を要求しないため、SSO の機能が実現されます。
14.9. フォーム認証への SPNEGO フォールバックの設定 リンクのコピーリンクがクリップボードにコピーされました!
手順14.2 フォーム認証へフォールバックする SPNEGO セキュリティー
SPNEGO の設定
web.xmlの編集login-config要素をアプリケーションへ追加し、web.xml でログインおよびエラーページを設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Web コンテンツの追加
login.htmlおよびerror.htmlの参照をweb.xmlへ追加します。これらのファイルは、Web アプリケーションアーカイブのform-login-config設定に指定された場所に追加されます。 詳細は、本書の「フォームベース認証の有効化」を参照してください。通常、login.htmlは次のようになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
注記
第15章 SAML を用いたシングルサインオン リンクのコピーリンクがクリップボードにコピーされました!
15.1. セキュリティートークンサービス (STS) リンクのコピーリンクがクリップボードにコピーされました!
- Issue や Renew などの要求タイプ。
- トークンのタイプ。
- 発行されたトークンのライフタイム。
- トークンを要求したサービスプロバイダーに関する情報。
- 生成されたトークンを暗号化するために使用される情報。
注記
provider 属性を使用すると、EAP のセキュリティーレルムは PKCS#11 キーおよびトラストストアの定義を許可できます。このパラメーターに指定された値は、関連する KeyStore.getInstance("PKCS11") 呼び出しへ渡され、キーとトラストストアが初期化されます。
java.security ポリシーファイルに必要なエントリーに関する正しい知識が必要になります。Oracle の 『Java PKCs#11 Reference Guide』 にこの情報が記載されています。
RequestSecurityToken 要素で囲まれます。要求の例には、この要求が Issue 要求であることを指定する RequestType と、発行するトークンのタイプを指定する TokenType の 2 つの WS-Trust 要素も含まれています。
例15.1 WS-Trust セキュリティートークン要求メッセージ
例15.2 セキュリティートークン応答メッセージ
TokenType 要素は発行されたトークンのタイプを指定し、RequestedSecurityToken 要素にはトークン自体が含まれています。トークンの形式は、トークンのタイプによって異なります。Lifetime 要素は、いつトークンが作成され、期限切れになるかを指定します。
セキュリティートークン要求の処理手順は次のとおりです。
- クライアントがセキュリティートークン要求を
PicketLinkSTSに送信します。
PicketLinkSTSが要求メッセージを解析し、JAXB オブジェクトモデルを生成します。
- 必要な場合、
PicketLinkSTSは設定ファイルを読み取り、STSConfigurationオブジェクトを作成します。その後、WSTrustRequestHandlerへの参照を設定から取得し、要求の処理をハンドラーインスタンスへ委譲します。
- 要求ハンドラーは必要な場合に
STSConfigurationを使用してデフォルト値を設定します (要求がトークンのライフタイム値を指定しない場合など)。
WSTrustRequestHandlerはWSTrustRequestContextを作成し、PicketLinkSTSより受信したJAXB要求オブジェクトおよび呼び出し元プリンシパルを設定します。
WSTrustRequestHandlerはSTSConfigurationを使用して、要求されたトークンのタイプを基に要求の処理に使用する必要があるSecurityTokenProviderを取得します。その後、プロバイダーを呼び出し、構築されたWSTrustRequestContextをパラメーターとして渡します。
SecurityTokenProviderインスタンスはトークン要求を処理し、発行されたトークンを要求コンテキストに保存します。
WSTrustRequestHandlerはトークンをコンテキストから取得し、必要な場合は暗号化します。また、セキュリティートークンが含まれる WS-Trust 応答オブジェクトを構築します。
PicketLinkSTSは要求ハンドラーによって生成される応答を書き取り、クライアントへ返します。
15.2. セキュリティートークンサービス (STS) の設定 リンクのコピーリンクがクリップボードにコピーされました!
WEB-INF ディレクトリーにある picketlink.xml ファイルで指定されます。picketlink.xml ファイルで設定できる要素は次のとおりです。
注記
PicketLinkSTS: ルート要素です。STS 管理者が以下のデフォルト値を設定できるよう、一部のプロパティーを定義します。STSName: セキュリティートークンサービスの名前を表す文字列。指定がない場合は、デフォルト値のPicketLinkSTSが使用されます。TokenTimeout: 秒単位のトークンライフタイム値。指定のない場合は、デフォルト値の 3600 (1 時間) が使用されます。EncryptToken: 発行されたトークンが暗号化されるかどうかを指定するブール値。デフォルト値は false です。
KeyProvider: トークンを署名および暗号化するために PicketLink STS によって使用されるキーストアを設定するため、この要素とすべてのサブ要素が使用されます。キーストアの場所、そのパスワード、エイリアスおよびパスワードの署名 (秘密鍵) などのプロパティーは、すべてこのセクションに設定されます。RequestHandler: この要素は、使用されるWSTrustRequestHandler実装の完全修飾名を指定します。指定がない場合、デフォルトのorg.picketlink.identity.federation.core.wstrust.StandardRequestHandlerが使用されます。TokenProvider: このセクションは、各タイプのセキュリティートークンに対応するために使用する必要があるTokenProvider実装を指定します。例には、SpecialTokenタイプのトークンに対応するプロバイダーと、SAMLV2.0タイプのトークンに対応するプロバイダーの 2 つのプロバイダーがあります。WSTrustRequestHandlerは、STSConfigurationのgetProviderForTokenType(文字列タイプ) メソッドを呼び出し、適切なTokenProviderへの参照を取得します。TokenTimeout: WS-Trust 要求にライフタイムが指定されていない場合に、WSTrustRequestHandlerによって使用されます。作成時間が現在の時間で、指定の秒数後に期限切れとなるライフタイムインスタンスを作成します。ServiceProviders: 各サービスプロバイダー (セキュリティートークンを必要とする Web サービス) に使用しなければならないトークンタイプを指定します。WS-Trust 要求にトークンタイプが含まれていない場合、WSTrustRequestHandlerはサービスプロバイダーエンドポイントを使用して、発行する必要があるトークンのタイプを確認する必要があります。EncryptToken: 発行されたトークンを暗号化する必要があるかどうかを決定するために、WSTrustRequestHandlerによって使用されます。true の場合、サービスプロバイダーの公開鍵証明書 (PKC) を使用してトークンが暗号化されます。
例15.3 STS 設定
15.3. PicketLink STS ログインモジュール リンクのコピーリンクがクリップボードにコピーされました!
STS ログインモジュールのタイプは次のとおりです。
STSIssuingLoginModule
- 設定された STS を呼び出し、セキュリティートークンを要求します。
RequestedSecurityTokenを正常に受け取った後、認証の成功を示します。 - 通常、STS への呼び出しには認証が必要です。このログインモジュールは、以下のソースの 1 つよりクレデンシャルを使用します。
useOptionsCredentialsモジュールオプションがtrueに設定されている場合は、プロパティーファイルを使用します。password-stackingモジュールオプションがuseFirstPassに設定されている場合は、以前のログインモジュールクレデンシャルを使用します。- 名前およびパスワードコールバックを提供し、設定された
CallbackHandlerよりクレデンシャルを使用します。
- 認証に成功した後、同じアサーションを持つものがすでに存在しない場合は
SamlCredentialがサブジェクトの公開クレデンシャルに挿入されます。
STSValidatingLoginModule
- 設定された STS を呼び出し、利用可能なセキュリティートークンを検証します。
- 通常、STS への呼び出しには認証が必要です。このログインモジュールは、以下のソースの 1 つよりクレデンシャルを使用します。
useOptionsCredentialsモジュールオプションがtrueに設定されている場合は、プロパティーファイルを使用します。password-stackingモジュールオプションがuseFirstPassに設定されている場合は、以前のログインモジュールクレデンシャルを使用します。- 名前およびパスワードコールバックを提供し、設定された
CallbackHandlerよりクレデンシャルを使用します。
- 認証に成功した後、同じアサーションを持つものがすでに存在しない場合は
SamlCredentialがサブジェクトの公開クレデンシャルに挿入されます。
SAML2STSLoginModule
- このログインモジュールは、
ObjectCallbackを設定されたCallbackHandlerに提供し、SamlCredentialオブジェクトが返されることを想定します。アサーションは、設定された STS に対して検証されます。 - ユーザー ID および SAML トークンが共有されている場合、正常に認証された別のログインモジュールの上にスタックされると、このログインモジュールは検証を省略します。
- 認証に成功した後、ユーザーの ID として設定される
SamlCredentialと、ユーザーのロールとして設定される複数値のロール属性に対してSamlCredentialが確認されます。
SAML2LoginModule
- このログインモジュールは、SAML 認証の他のコンポーネントと一緒に使用され、このログインモジュール自体は認証を行いません。
SPRedirectFormAuthenticatorは、SAML v2 HTTP リダイレクトプロファイルの PicketLink の実装でこのログインモジュールを使用します。- Tomcat オーセンティケーターバルブは、アイデンティティープロバイダーへリダイレクトし、SAML アサーションを取得して、認証を実行します。
- このログインモジュールは、JAAS サブジェクトに入力されるユーザー ID およびロールを JBoss セキュリティーフレームワークへ渡すために使用されます。
15.4. STSIssuingLoginModule の設定 リンクのコピーリンクがクリップボードにコピーされました!
STSIssuingLoginModule は、ユーザー名とパスワードを使用し、トークンを読み出してユーザーを STS に対して認証します。
例15.4 STSIssuingLoginModule の設定
- 宣言されたセキュリティードメインの変更。
- Principal マッピングプロバイダーの指定。
- RoleGroup マッピングプロバイダーの指定。
15.5. STSValidatingLoginModule の設定 リンクのコピーリンクがクリップボードにコピーされました!
例15.5 STSValidatingLoginModule の設定
15.6. STS クライアントのプーリング リンクのコピーリンクがクリップボードにコピーされました!
- org.picketlink.identity.federation.core.wstrust.auth.STSIssuingLoginModule
- org.picketlink.identity.federation.core.wstrust.auth.STSValidatingLoginModule
- org.picketlink.trust.jbossws.jaas.JBWSTokenIssuingLoginModule
initialNumberOfClients ログインモジュールオプションから設定します。
org.picketlink.identity.federation.bindings.stspool.STSClientPoolFactory は、クライアントプール機能をアプリケーションに提供します。
STSClientPoolFactory の使用
final STSClientPool pool = STSClientPoolFactory.getPoolInstance(); pool.createPool(20, stsClientConfig); final STSClient client = pool.getClient(stsClientConfig);
final STSClientPool pool = STSClientPoolFactory.getPoolInstance();
pool.createPool(20, stsClientConfig);
final STSClient client = pool.getClient(stsClientConfig);
pool.returnClient();
pool.returnClient();
if (! pool.configExists(stsClientConfig) {
pool.createPool(stsClientConfig);
}
if (! pool.configExists(stsClientConfig) {
pool.createPool(stsClientConfig);
}
pool.destroyPool(stsClientConfig);
pool.destroyPool(stsClientConfig);
15.7. SAML Web ブラウザーベースの SSO リンクのコピーリンクがクリップボードにコピーされました!
15.7.1. SAML Web ブラウザーベースの SSO リンクのコピーリンクがクリップボードにコピーされました!
重要
15.7.2. SAML v2 ベースの Web SSO の設定 リンクのコピーリンクがクリップボードにコピーされました!
- アイデンティティープロバイダー: アイデンティティープロバイダーは、エンドユーザーを認証し、そのユーザーのアイデンティティーを信頼されたパートナーにアサートする権限のあるエンティティーです。
- サービスプロバイダー: サービスプロバイダーはアイデンティティープロバイダーに依存し、ユーザーの電子クレデンシャルよりユーザーに関する情報をアサートするため、サービスプロバイダーはユーザークレデンシャルの信頼されたアサーションのセットを基にアクセス制御および伝播を管理します。
15.7.3. アイデンティティープロバイダーの設定 リンクのコピーリンクがクリップボードにコピーされました!
手順15.1 アイデンティティープロバイダー (IDP) の設定
IDP の Web アプリケーションセキュリティーの設定
Web アプリケーションをアイデンティティープロバイダーとして設定します。注記
ログインページをカスタマイズできるため、FORM ベースの Web アプリケーションセキュリティーを使用することが推奨されます。web.xmlの設定例は次のとおりです。例15.6 IDP の
web.xml設定Copy to Clipboard Copied! Toggle word wrap Toggle overflow IDP のセキュリティードメインの作成
IDP に対して定義された認証および承認メカニズムを用いてセキュリティードメインを作成します。詳細は「アプリケーションでのセキュリティードメインの使用」を参照してください。IDP バルブの設定
IDP Web アプリケーションのWEB-INFディレクトリーでjboss-web.xmlファイルを作成し、IDP のバルブを設定します。以下にjboss-web.xmlファイルの例を示します。例15.7 IDP バルブの
jboss-web.xmlファイル設定Copy to Clipboard Copied! Toggle word wrap Toggle overflow PicketLink 設定ファイル (
picketlink.xml) の設定以下はpicketlink.xml設定の例になります。この設定ファイルで、サービスプロバイダーおよび IDP へ送信される SAML2 アサーションに発行者として追加される URL を指定します。例15.8
picketlink.xml設定Copy to Clipboard Copied! Toggle word wrap Toggle overflow デフォルトでは、picketlink.xmlは IDP Web アプリケーションのWEB-INFディレクトリーにありますが、アプリケーションの外部にあるpicketlink.xmlへのカスタムパスを設定できます。任意設定:
picketlink.xmlへのカスタムパスの設定アプリケーションのWEB-INF/jboss-web.xmlでバルブ要素に、configFileとtimerIntervalの 2 つのパラメーターを追加します。configFileはpicketlink.xmlへのパスを指定し、timerIntervalは設定を再ロードする間隔をミリ秒単位で指定します。例を以下に示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
PicketLink モジュール (
META-INF/MANIFEST.MFまたはjboss-deployment-structure.xml) での依存関係の宣言PicketLink クラスの場所を特定できるようにするため、Web アプリケーションにはMETA-INF/MANIFEST.MFまたはjboss-deployment-structure.xmlに定義される依存関係が必要です。例15.9
META-INF/MANIFEST.MFでの依存関係の定義Manifest-Version: 1.0 Build-Jdk: 1.6.0_24 Dependencies: org.picketlinkManifest-Version: 1.0 Build-Jdk: 1.6.0_24 Dependencies: org.picketlinkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例15.10
META-INF/jboss-deployment-structure.xmlでの依存関係の定義Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.7.4. HTTP/REDIRECT バインディングを使用したサービスプロバイダーの設定 リンクのコピーリンクがクリップボードにコピーされました!
手順15.2 サービスプロバイダー (SP) の設定
SP の Web アプリケーションセキュリティーの設定
SP として設定する Web アプリケーションのweb.xmlファイルで、FORM ベースのセキュリティーを有効にする必要があります。例15.11 SP の
web.xml設定Copy to Clipboard Copied! Toggle word wrap Toggle overflow SP のセキュリティードメインの作成
SAML2LoginModuleを使用するセキュリティードメインを作成します。以下に設定例を示します。<security-domain name="sp" cache-type="default"> <authentication> <login-module code="org.picketlink.identity.federation.bindings.jboss.auth.SAML2LoginModule" flag="required"/> </authentication> </security-domain><security-domain name="sp" cache-type="default"> <authentication> <login-module code="org.picketlink.identity.federation.bindings.jboss.auth.SAML2LoginModule" flag="required"/> </authentication> </security-domain>Copy to Clipboard Copied! Toggle word wrap Toggle overflow SP バルブの設定
SP のバルブを設定するには、SP Web アプリケーションのWEB-INFディレクトリーにjboss-web.xmlを作成します。例15.12 SP バルブの
jboss-web.xmlファイル設定Copy to Clipboard Copied! Toggle word wrap Toggle overflow PicketLink 設定ファイル (
picketlink.xml) の設定以下は SP のpicketlink.xml設定の例になります。この設定ファイルで、対応する SP のハンドラーを用いて SP および IDP の URL を指定します。例15.13
picketlink.xml設定Copy to Clipboard Copied! Toggle word wrap Toggle overflow デフォルトでは、picketlink.xmlはアプリケーションのWEB-INFディレクトリーにありますが、アプリケーションの外部にあるpicketlink.xmlへのカスタムパスを設定できます。任意設定:
picketlink.xmlへのカスタムパスの設定アプリケーションのWEB-INF/jboss-web.xmlでバルブ要素に、configFileとtimerIntervalの 2 つのパラメーターを追加します。configFileはpicketlink.xmlへのパスを指定し、timerIntervalは設定を再ロードする間隔をミリ秒単位で指定します。例を以下に示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
PicketLink モジュール (
META-INF/MANIFEST.MFまたはjboss-deployment-structure.xml) での依存関係の宣言PicketLink クラスの場所を特定できるようにするため、Web アプリケーションにはMETA-INF/MANIFEST.MFまたはjboss-deployment-structure.xmlに定義される依存関係が必要です。例15.14
META-INF/MANIFEST.MFでの依存関係の定義Manifest-Version: 1.0 Build-Jdk: 1.6.0_24 Dependencies: org.picketlinkManifest-Version: 1.0 Build-Jdk: 1.6.0_24 Dependencies: org.picketlinkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例15.15
META-INF/jboss-deployment-structure.xmlでの依存関係の定義Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.7.5. HTTP/POST バインディングを使用した SAML v2 ベースの Web SSO の設定 リンクのコピーリンクがクリップボードにコピーされました!
手順15.3 HTTP/POST バインディングを使用した SAML v2 ベースの Web SSO の設定
アイデンティティープロバイダー (IDP) を設定します。
HTTP/POST バインディング向けに IDP を設定する手順は、HTTP/リダイレクトバインディング向けに IDP を設定する手順と同じです。IDP 設定の詳細は、「SAML v2 ベースの Web SSO の設定」を参照してください。サービスプロバイダー (SP) の設定
HTTP/POST バインディング向けに SP を設定する手順は、HTTP/リダイレクトバインディング向けに SP を設定する手順と同じですが、SP のpicketlink.xmlファイルに違いが 1 つあります。BindingType="REDIRECT"をBindingType="POST"に変更します。SP 設定の詳細は、「HTTP/REDIRECT バインディングを使用したサービスプロバイダーの設定」を参照してください。
15.7.6. サービスプロバイダーにおける動的 Account Chooser (アカウントチューザー) の設定 リンクのコピーリンクがクリップボードにコピーされました!
手順15.4 サービスプロバイダーにおける動的 Account Chooser (アカウントチューザー) の設定
- SP Web アプリケーションの
WEB-INFディレクトリーにあるjboss-web.xmlで Account Chooser (アカウントチューザー) バルブを設定します。例15.16 SP アカウントチューザーの
jboss-web.xmlファイル設定Copy to Clipboard Copied! Toggle word wrap Toggle overflow AccountChooserValveには以下の設定可能なオプションがあります。- DomainName
- ユーザーのブラウザーへ送信されるクッキーに使用されるドメイン名。
- CookieExpiry
- クッキーの有効期限 (秒単位)。デフォルトは
-1で、ブラウザーが閉じられたときにクッキーの有効期限が切れることを意味します。 - AccountIDPMapProvider
- IDP マッピングの実装の完全修飾名。デフォルトは、SP Web アプリケーションの
WEB-INFディレクトリーにあるidpmap.propertiesプロパティーファイルです。この実装は、org.picketlink.identity.federation.bindings.tomcat.sp.AbstractAccountChooserValve.AccountIDPMapProviderを実装する必要があります。 - AccountChooserPage
- 異なる IDP アカウントをリストする HTML/JSP ページの名前。デフォルトは
/accountChooser.htmlです。
- IDP のマッピングを定義します。デフォルトは、SP Web アプリケーションの
WEB-INFディレクトリーにあるidpmap.propertiesプロパティーファイルです。例15.17
idpmap.properties設定DomainA=http://localhost:8080/idp1/ DomainB=http://localhost:8080/idp2/
DomainA=http://localhost:8080/idp1/ DomainB=http://localhost:8080/idp2/Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ユーザーが IDP を選択するための HTML ページを SP Web アプリケーションで作成します。デフォルトでは、このファイルは
accountChooser.htmlになります。各 IDP への URL には、idpmap.propertiesにリストされた IDP の名前を指定するidpパラメーターが必要です。例15.18
accountChooser.html設定Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.7.7. IDP-initiated SSO の設定 リンクのコピーリンクがクリップボードにコピーされました!
順序
- ユーザーが IDP にアクセスします。
- IDP は SAML リクエストや応答がないことを確認し、IDP が初めて SAML を使用することを想定します。
- IDP がユーザーに認証を要求します。
- 認証後、すべての SP アプリケーションへリンクするページをユーザーが取得する、ホストされたセクションを IDP が表示します。
- ユーザーが SP アプリケーションを選択します。
- クエリーパラメーターの SAML 応答に SAML アサーションを持つサービスプロバイダーへ IDP がユーザーをリダイレクトします。
- SP は SAML アサーションをチェックし、アクセスを提供します。
非要請応答をサポートするには特別な設定は必要ありません。IDP と SP を通常どおり設定できます。IDP と SP の設定方法に関する詳細は以下を参照してください。
ユーザーの認証後、IDP はすべてのサービスプロバイダーアプリケーションへのリンクが含まれるページを表示します。通常、リンクは以下のようになります。
<a href="http://localhost:8080/idp?SAML_VERSION=2.0&TARGET=http://localhost:8080/sales-post/">Sales</a>
<a href="http://localhost:8080/idp?SAML_VERSION=2.0&TARGET=http://localhost:8080/sales-post/">Sales</a>
15.8. SAML グローバルログアウトプロファイルの設定 リンクのコピーリンクがクリップボードにコピーされました!
注記
手順15.5 グローバルログアウトの設定
picketlink-handlers.xml の設定
picketlink-handlers.xml にSAML2LogOutHandlerを追加します。サービスプロバイダー Web ページの設定
サービスプロバイダーの Web ページの最後にあるリンクにGLO=trueを追加します。例15.19 グローバルログアウトへのリンク
<a href="?GLO=true">Click to Globally LogOut</a>
<a href="?GLO=true">Click to Globally LogOut</a>Copy to Clipboard Copied! Toggle word wrap Toggle overflow logout.jspページの作成ログアウトプロセスの一部として、PicketLink はユーザーをサービスプロバイダーアプリケーションのルートディレクトリーにあるlogout.jspページへリダイレクトします。必ずこのページを作成してください。
第16章 ログインモジュール リンクのコピーリンクがクリップボードにコピーされました!
16.1. モジュールの使用 リンクのコピーリンクがクリップボードにコピーされました!
16.1.1. パスワードスタッキング リンクのコピーリンクがクリップボードにコピーされました!
password-stacking 属性を useFirstPass に設定する必要があります。パスワードスタッキング用に設定された以前のモジュールがユーザーを認証した場合、他のすべてのスタッキングモジュールはユーザーが認証されたとみなし、承認手順のロールのみを提供しようとします。
password-stacking オプションが useFirstPass に設定されている場合、このモジュールは最初にログインモジュールの共有状態マップにて、プロパティー名 javax.security.auth.login.name 配下の共有ユーザー名とjavax.security.auth.login.password 配下のパスワードを探します。
注記
例16.1 パスワードスタッキングの例
16.1.2. パスワードのハッシュ化 リンクのコピーリンクがクリップボードにコピーされました!
重要
例16.2 パスワードのハッシュ化
usersb64.properties ファイルに含まれ、認証されていないユーザーにプリンシパル名 nobody を割り当てるログインモジュールの設定になります。usersb64.properties ファイルはデプロイメントクラスパスの一部になります。
- hashAlgorithm
- パスワードをハッシュ化するために使用される
java.security.MessageDigestアルゴリズムの名前。デフォルトはないため、ハッシュ化を有効にするにはこのオプションを指定する必要があります。一般的な値はSHA-256、SHA-1、およびMD5です。 - hashEncoding
- 3 つのエンコーディング形式 (
base64、hex、またはrfc2617) の 1 つを指定する文字列です。デフォルトはbase64です。 - hashCharset
- クリアテキストのパスワードをバイトアレイに変換するために使用されるエンコーディング文字。デフォルトはプラットフォームのデフォルトエンコーディングです。
- hashUserPassword
- ユーザーが送信するパスワードに適用されるハッシュアルゴリズムを指定します。ハッシュ化されたユーザーパスワードは、パスワードのハッシュであることが想定されるログインモジュールの値と比較されます。デフォルトは
trueです。 - hashStorePassword
- サーバー側に保存されるパスワードに適用されるハッシュアルゴリズムを指定します。これは、ユーザーがユーザーパスワードのハッシュとサーバーからのリクエスト固有のトークンを送信して比較するダイジェスト認証に使用されます。サーバー側のハッシュを算出するために、ハッシュアルゴリズム (ダイジェスト認証の場合は
rfc2617) が使用されます。サーバー側のハッシュは、クライアントから送信されたハッシュ化された値と一致する必要があります。
org.jboss.security.auth.spi.Util クラスによって提供されます。以下の例は、base64 でエンコードされ MD5 でハッシュ化されたパスワードを生成します。
String hashedPassword = Util.createPasswordHash("SHA-256",
Util.BASE64_ENCODING, null, null, "password");
String hashedPassword = Util.createPasswordHash("SHA-256",
Util.BASE64_ENCODING, null, null, "password");
password が OpenSSL のダイジェスト関数へパイプ処理された後、base64 でエンコードされた形式に変換するために別の OpenSSL 関数へパイプ処理されます。
echo -n password | openssl dgst -sha256 -binary | openssl base64
echo -n password | openssl dgst -sha256 -binary | openssl base64
XohImNooBHFR0OVvjcYpJ3NgPQ1qq73WKhHvch0VQtg= で、両方の場合で同じになります。上記の例では、この値はセキュリティードメインで指定されたユーザーのプロパティーファイル usersb64.properties に保存される必要があります。
16.1.3. 非認証のアイデンティティー リンクのコピーリンクがクリップボードにコピーされました!
unauthenticatedIdentity は、関連する認証情報がない状態で作成されたリクエストへ特定のアイデンティティー (guest など) を割り当てるログインモジュール設定オプションです。このオプションを使用すると、保護されていないサーブレットは特定のロールを必要としない EJB 上でメソッドを呼び出しできます。このようなプリンシパルには関連するロールがなく、セキュアでない EJB やチェックされないパーミッション制約に関連する EJB メソッドへのみアクセスできます。
- unauthenticatedIdentity: 認証情報が含まれないリクエストへ割り当てられるプリンシパル名を定義します。
16.1.4. Ldap ログインモジュール リンクのコピーリンクがクリップボードにコピーされました!
Ldap ログインモジュールは LDAP (Lightweight Directory Access Protocol) サーバーに対して認証を行う LoginModule 実装です。JNDI (Java Naming and Directory Interface) LDAP プロバイダーを使用してアクセス可能な LDAP サーバーにユーザー名とクレデンシャルが保存される場合は、Ldap ログインモジュールを使用してください。
注記
AdvancedLdap ログインモジュールまたは AdvancedLdap ログインモジュールのみの使用を考慮してください。
- 識別名 (DN)
- LDAP (Lightweight Directory Access Protocol) では、識別名によってディレクトリーでオブジェクトが一意に識別されます。各識別名には他のオブジェクトとは異なる一意な名前と場所が必要で、これには属性と値のペア (AVP) を使用します。AVP は共通名や組織単位などの情報を定義します。これらの値を組み合わせることで、LDAP が必要とする一意な文字列が作成されます。
注記
- java.naming.factory.initial
InitialContextFactory実装クラス名。デフォルトは Sun LDAP プロバイダー実装com.sun.jndi.ldap.LdapCtxFactoryです。- java.naming.provider.url
- LDAP サーバーの LDAP URL。
- java.naming.security.authentication
- 使用するセキュリティープロトコルレベルです。使用可能な値は
none、simple、strongなどです。プロパティーが定義されていないと、挙動はサービスプロバイダーによって決定されます。 - java.naming.security.protocol
- セキュリティーアクセスに使用されるトランスポートプロトコル。この設定オプションをサービスプロバイダーのタイプ (例: SSL) に設定します。プロパティーが定義されてされていないと、挙動はサービスプロバイダーによって決定されます。
- java.naming.security.principal
- サービスに対する呼び出し元を認証するプリンシパルのアイデンティティーを指定します。これは、以下に示された他のプロパティーから構築されます。
- java.naming.security.credentials
- サービスに対する呼び出し元を認証するプリンシパルのクレデンシャルを指定します。クレデンシャルの可能な形式はハッシュ化されたパスワード、クリアテキストのパスワード、キー、または証明書です。プロパティーが定義されていないと、挙動はサービスプロバイダーによって決定されます。
注記
true に設定する必要があります。
InitialLdapContext を作成します。
InitialLdapContext インスタンスが作成されます)、roleAttributeName および uidAttributeName オプションの値に設定された検索属性で rolesCtxDN の場所を検索し、ユーザーのロールがクエリーされます。ロール名は、検索結果セットのロール属性で toString メソッドを呼び出して取得されます。
例16.3 LDAP ログインモジュールのセキュリティードメイン
java.naming.factory.initial、java.naming.factory.url、および java.naming.security オプションは以下の条件を示します。
- Sun LDAP JNDI プロバイダー実装が使用されます。
- LDAP サーバーは、ポート 1389 のホスト
ldaphost.jboss.orgにあります。 - LDAP サーバーへの接続には LDAP の単純な認証メソッドが使用されます。
jsmith が uid=jsmith,ou=People,dc=jboss,dc=org へマップされます。
注記
userPassword 属性 (この例では theduke) を使用して LDAP サーバーがユーザーを認証することを想定します。ほとんどの LDAP サーバーはこのように動作しますが、ご使用の LDAP サーバーの認証処理がこれとは異なる場合は、本番環境の要件に従って LDAP を設定する必要があります。
rolesCtxDN のサブツリー検索が実行され、承認の基になるロールが読み出されます。matchOnUserDN が true の場合、ユーザーの完全な DN を基に検索が実行されます。true でない場合は、入力された実際のユーザー名を基にして検索が実行されます。この例では、ou=Roles,dc=jboss,dc=org 配下の uid=jsmith,ou=People,dc=jboss,dc=org と等しい member 属性を持つエントリーに対して検索が行われ、ロールエントリー配下の cn=JBossAdmin が見つかります。
cn になります。返される値は JBossAdmin で、ユーザー jsmith が JBossAdmin ロールに割り当てられます。
- LDAP データ変換形式 (LDIF)
- LDAP ディレクトリーの内容や更新リクエストを表すために使用されるプレーンテキストのデータ変換形式です。ディレクトリーの内容は 各オブジェクトまたは更新リクエストが 1 つのレコードとして示されます。内容は追加、変更、削除、および名前変更リクエストで構成されます。
例16.4 LDIF ファイルの例
16.1.5. LdapExtended ログインモジュール リンクのコピーリンクがクリップボードにコピーされました!
- 識別名 (DN)
- LDAP (Lightweight Directory Access Protocol) では、識別名によってディレクトリーでオブジェクトが一意に識別されます。各識別名には他のオブジェクトとは異なる一意な名前と場所が必要で、これには属性と値のペア (AVP) を使用します。AVP は共通名や組織単位などの情報を定義します。これらの値を組み合わせることで、LDAP が必要とする一意な文字列が作成されます。
org.jboss.security.auth.spi.LdapExtLoginModule) はバインドするユーザーと関連するロールを検索します。ロールクエリーは再帰的に DN をたどり、階層的なロール構成を移動します。
- Context.INITIAL_CONTEXT_FACTORY = "java.naming.factory.initial"
- Context.SECURITY_PROTOCOL = "java.naming.security.protocol"
- Context.PROVIDER_URL = "java.naming.provider.url"
- Context.SECURITY_AUTHENTICATION = "java.naming.security.authentication"
- Context.REFERRAL = "java.naming.referral"
- 初期の LDAP サーバーのバインドは bindDN および bindCredential プロパティーを使用して認証されます。bindDN は、ユーザーとロールの baseCtxDN および rolesCtxDN ツリーを検索する権限を持つユーザーです。認証する user DN は、baseFilter プロパティーによって指定されたフィルターを使用してクエリーされます。
- 結果となる userDN は、InitialLdapContext 環境 Context.SECURITY_PRINCIPAL として userDN を使用して LDAP サーバーにバインドすることで認証されます。Context.SECURITY_CREDENTIALS プロパティーは、コールバックハンドラーにより取得された文字列パスワードに設定されます。
- これに成功すると、rolesCtxDN、roleAttributeID、roleAttributeIsDN、roleNameAttributeID、および roleFilter オプションを使用して関連するユーザーロールがクエリーされます。
図16.1 LDAP 構成の例
例16.5 LDAP 設定例 2
例16.6 LDAP 設定例 3
例16.7 LDAP 設定例 4
例16.8 デフォルトの Active Directory 設定
例16.9 再帰的なロールの Active Directory 設定
16.1.6. UsersRoles ログインモジュール リンクのコピーリンクがクリップボードにコピーされました!
UsersRoles ログインモジュールは、Java プロパティーファイルからロードされた複数のユーザーおよびユーザーロールをサポートする簡単なログインモジュールです。デフォルトのユーザー名対パスワードマッピングのファイル名は users.properties で、デフォルトのユーザー名対ロールマッピングのファイル名は roles.properties です。
WAR アーカイブの WEB-INF/classes フォルダー内) やサーバークラスパスのディレクトリー内に置くことができます。このログインモジュールの主な目的は、アプリケーションでデプロイされたプロパティーファイルを使用して複数のユーザーやロールのセキュリティー設定を簡単にテストすることです。
例16.10 UserRoles ログインモジュール
ejb3-sampleapp-users.properties ファイルは各ユーザーエントリーが個別の行で示される username=password 形式を使用します。
username1=password1 username2=password2 ...
username1=password1
username2=password2
...
ejb3-sampleapp-roles.properties ファイルは、グループ名の値を任意で用いて username=role1,role2, というパターンを使用します。例を以下に示します。
username1=role1,role2,... username1.RoleGroup1=role3,role4,... username2=role1,role3,...
username1=role1,role2,...
username1.RoleGroup1=role3,role4,...
username2=role1,role3,...
ejb3-sampleapp-roles.properties の user name.XXX というプロパティー名のパターンは、ユーザー名ロールをロールの特定の名前を持つグループへ割り当てるために使用されます。プロパティー名の XXX 部分はグループ名になります。user name=... は user name.Roles=... の省略形です。Roles グループ名は JBossAuthorizationManager が想定する、ユーザーの権限を定義するロールが含まれる標準名です。
jduke と同等の定義になります。
jduke=TheDuke,AnimatedCharacter jduke.Roles=TheDuke,AnimatedCharacter
jduke=TheDuke,AnimatedCharacter
jduke.Roles=TheDuke,AnimatedCharacter
16.1.7. Database ログインモジュール リンクのコピーリンクがクリップボードにコピーされました!
Database ログインモジュールは、認証とロールマッピングをサポートする JDBC (Java Database Connectivity) ベースのログインモジュールです。ユーザー名、パスワード、およびロールの情報がリレーショナルデータベースに保存される場合は、このログインモジュールを使用します。
注記
Database ログインモジュールは、以下の 2 つの論理テーブルを基にします。
Table Principals(PrincipalID text, Password text) Table Roles(PrincipalID text, Role text, RoleGroup text)
Table Principals(PrincipalID text, Password text)
Table Roles(PrincipalID text, Role text, RoleGroup text)
Principals テーブルは、ユーザーの PrincipalID を有効なパスワードに関連付けます。Roles テーブルは、ユーザーの PrincipalID をロールセットに関連付けます。ユーザー権限に使用されるロールは、RoleGroup 列の値が Roles である行に含まれる必要があります。
java.sql.ResultSet の論理構成が前述の Principals および Roles テーブルと同じであることです。結果は列インデックスを基にアクセスされるため、テーブルおよび列の実際の名前は関係ありません。
Principals と Roles の 2 つのテーブルを持つデータベースについて考えてみてください。以下のステートメントは以下のデータをテーブルに追加します。
Principalsテーブル内のPasswordがechomanのPrincipalIDjavaRolesテーブル内のRolesRoleGroupにあるEchoという名前のロールを持つPrincipalIDjavaRolesテーブル内のCallerPrincipalRoleGroupにあるcaller_javaという名前のロールを持つPrincipalIDjava
INSERT INTO Principals VALUES('java', 'echoman')
INSERT INTO Roles VALUES('java', 'Echo', 'Roles')
INSERT INTO Roles VALUES('java', 'caller_java', 'CallerPrincipal')
INSERT INTO Principals VALUES('java', 'echoman')
INSERT INTO Roles VALUES('java', 'Echo', 'Roles')
INSERT INTO Roles VALUES('java', 'caller_java', 'CallerPrincipal')
Database login module ログインモジュールの設定例は、次のように構築できます。
CREATE TABLE Users(username VARCHAR(64) PRIMARY KEY, passwd VARCHAR(64)) CREATE TABLE UserRoles(username VARCHAR(64), role VARCHAR(32))
CREATE TABLE Users(username VARCHAR(64) PRIMARY KEY, passwd VARCHAR(64))
CREATE TABLE UserRoles(username VARCHAR(64), role VARCHAR(32))
16.1.8. Certificate ログインモジュール リンクのコピーリンクがクリップボードにコピーされました!
Certificate ログインモジュールは X509 証明書を基にユーザーを認証します。このログインモジュールの典型的なユースケースが Web 層の CLIENT-CERT 認証です。
CertRolesLoginModule および DatabaseCertLoginModule は、動作を拡張してプロパティーファイルまたはデータベースから承認ロールを取得します。
Certificate ログインモジュールオプションの詳細は「含まれる認証モジュール」を参照してください。
Certificate ログインモジュールは、ユーザーの検証に KeyStore を必要とします。これは、以下の設定 (一部分) が示すとおり、リンクされたセキュリティードメインの JSSE 設定から取得されます。
手順16.1 証明書およびロールベース承認を用いた Web アプリケーションのセキュア化
user-app.war などの Web アプリケーションをセキュアにする方法を説明します。この例では、認証と承認に CertificateRoles ログインモジュールが使用されます。trusted-clients.keystore および app-roles.properties には、クライアント証明書に関連するプリンシパルへマップするエントリーが必要になります。
リソースおよびロールの宣言
web.xmlを変更し、認証および承認に使用される許可されたロールおよびセキュリティードメインとともにセキュア化されるリソースを宣言します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow セキュリティードメインの指定
jboss-web.xmlファイルで、必要なセキュリティードメインを指定します。<jboss-web> <security-domain>app-sec-domain</security-domain> </jboss-web>
<jboss-web> <security-domain>app-sec-domain</security-domain> </jboss-web>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ログインモジュールの設定
管理 CLI を使用して、指定したapp-sec-domainドメインのログインモジュール設定を定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
例16.11 証明書の例
trusted-clients.keystore は、例16.11「証明書の例」 の証明書が CN=valid-client, OU=Security QE, OU=JBoss, O=Red Hat, C=CZ のエイリアスと保存されることを要件とすることがあります。app-roles.properties には同じエントリーが存在する必要があります。DN には通常は区切り文字として使用される文字が含まれているため、以下のようにバックスラッシュ (\) を使用して区切り文字をエスケープする必要があります。
# A sample app-roles.properties file CN\=valid-client,\ OU\=Security\ QE,\ OU\=JBoss,\ O\=Red\ Hat,\ C\=CZ
# A sample app-roles.properties file
CN\=valid-client,\ OU\=Security\ QE,\ OU\=JBoss,\ O\=Red\ Hat,\ C\=CZ
16.1.9. Identity ログインモジュール リンクのコピーリンクがクリップボードにコピーされました!
Identity ログインモジュールは、ハードコードされたユーザー名をモジュールに対して認証されたサブジェクトに関連付ける簡単なログインモジュールです。このモジュールは、principal オプションによって指定された名前を使用して SimplePrincipal インスタンスを作成します。
注記
jduke という名前のプリンシパルとして認証し、TheDuke および AnimatedCharacter というロール名を割り当てます。
16.1.10. RunAs ログインモジュール リンクのコピーリンクがクリップボードにコピーされました!
RunAs ログインモジュールはヘルパーモジュールで、認証のログイン段階の間に run as ロールをスタックへプッシュし、コミットまたはアボート段階で run as ロールをスタックからポップします。
RunAs ロールを必要とするログインモジュールを確立する前に RunAs ログインモジュールを設定する必要があります。
16.1.10.1. RunAsIdentity の作成 リンクのコピーリンクがクリップボードにコピーされました!
javax.security.auth.Subject インスタンスまたは org.jboss.security.RunAsIdentity インスタンスのいずれかによって示されます。これらのクラスは、アイデンティティーとアイデンティティーが持つロールのリストを示す 1 つ以上のプリンシパルを保存します。javax.security.auth.Subject の場合は、クレデンシャルのリストも保存されます。
ejb-jar.xml デプロイメント記述子の <assembly-descriptor> セクションには、ユーザーがさまざまな EJB メソッドへアクセスするために必要な 1 つ以上のロールを指定します。これらのリストを比較すると、EJB メソッドへアクセスするために必要なロールの 1 つをユーザーが持っているかどうかが分かります。
例16.12 org.jboss.security.RunAsIdentity の作成
ejb-jar.xml ファイルには、<session> 要素の子として定義された <run-as> ロールを持つ <security-identity> 要素を指定します。
Admin の RunAsIdentity ロールを作成する必要があることを意味します。
Admin ロールのプリンシパルに名前と付けるには、jboss-ejb3.xml ファイルで <run-as-principal> 要素を定義します。
ejb-jar.xml ファイルの <security-identity> 要素と jboss-ejb3.xml ファイルの <security> 要素はデプロイメント時点で解析されます。<run-as> ロール名および <run-as-principal> 名は org.jboss.metadata.ejb.spec.SecurityIdentityMetaData クラスに保存されます。
例16.13 RunAsIdentity への複数ロールの割り当て
jboss-ejb3.xml デプロイメント記述子の <assembly-descriptor> 要素グループでロールをプリンシパルへマップすると、追加のロールを RunAsIdentity へ割り当てできます。
John の <run-as-principal> が作成されました。この例の設定は、Support ロールを追加して Admin ロールを拡張します。新しいロールには、追加のプリンシパルと最初に定義されたプリンシパル John が含まれます。
ejb-jar.xml および jboss-ejb3.xml ファイルの <security-role> 要素はデプロイ時に解析されます。<role-name> および <principal-name> データは org.jboss.metadata.ejb.spec.SecurityIdentityMetaData クラスに保存されます。
16.1.11. Client ログインモジュール リンクのコピーリンクがクリップボードにコピーされました!
Client ログインモジュール (org.jboss.security.ClientLoginModule) は、呼び出し側のアイデンティティーとクレデンシャルを確立するときに JBoss クライアントによって使用される LoginModule の実装です。このモジュールは、新しい SecurityContext を作成してプリンシパルとクレデンシャルを割り当て、SecurityContext を ThreadLocal セキュリティーコンテキストに設定します。
Client ログインモジュールは、クライアントが現在のスレッドの呼び出し側を確立するために唯一サポートされるメカニズムです。スタンドアロンクライアントアプリケーションとサーバー環境 (EAP セキュリティーサブシステムを透過的に使用するよう設定されていないセキュリティー環境で JBoss EJB クライアントとして動作する) の両方は Client ログインモジュールを使用する必要があります。
Client ログインモジュールの他に別のログインモジュールを設定する必要があります。
16.1.12. SPNEGO ログインモジュール リンクのコピーリンクがクリップボードにコピーされました!
SPNEGO ログインモジュール (org.jboss.security.negotiation.spnego.SPNEGOLoginModule) は、KDC を用いて呼び出し側のアイデンティティーとクレデンシャルを確立する LoginModule の実装です。モジュールは JBoss Negotiation プロジェクトの一部で、SPNEGO (Simple and Protected GSSAPI Negotiation メカニズム) を実装します。AdvancedLdap ログインモジュールを用いてチェーンされた設定でこの認証を使用すると、LDAP サーバーとの連携を可能にできます。
SPNEGO または AdvancedLdap ログインモジュールを使用するには、META-INF/jboss-deployment-structure.xml デプロイメント記述子ファイルを編集し、手作業で依存関係を追加する必要があります。
例16.14 JBoss Negotiation モジュールを依存関係として追加
16.1.13. RoleMapping ログインモジュール リンクのコピーリンクがクリップボードにコピーされました!
RoleMapping ログインモジュールは、認証プロセスの最終結果であるロールを 1 つ以上の宣言的ロールへマップすることをサポートします。たとえば、ユーザー「A」は「ldapAdmin」および「testAdmin」ロールを持ち、アクセスのために web.xml または ejb-jar.xml ファイルに定義された宣言的ロールは admin であると認証プロセスによって判断された場合、このモジュールは admin ロールをユーザー A にマップします。
RoleMapping ログインモジュールオプションの詳細は「含まれる認証モジュール」を参照してください。
RoleMapping ログインモジュールはログインモジュール設定の任意のモジュールであると定義する必要があります。これにより、以前マップされたロールのマッピングが変更されます。
例16.15 マップされたロールの定義
例16.16 マップされたロールを定義する推奨方法
例16.17 RoleMappingLoginModule によって使用されるプロパティーファイル
ldapAdmin=admin, testAdmin
ldapAdmin=admin, testAdmin
ldapAdmin ロールが含まれている場合、replaceRole プロパティーの値に応じて admin および testAdmin ロールが認証されたサブジェクトに追加されるか、認証されたサブジェクトの代替となります。
16.1.14. bindCredential モジュールオプション リンクのコピーリンクがクリップボードにコピーされました!
bindCredential モジュールオプションは、DN のクレデンシャルを保存するために使用され、複数のログインおよびマッピングモジュールによって使用されます。パスワードを取得する方法は複数あります。
- 管理 CLI コマンドのプレーンテキスト。
bindCredentialモジュールのパスワードは、("bindCredential"=>"secret1")のように管理 CLI コマンドにてプレーンテキストで提供されることがあります。セキュリティー上の理由で、このパスワードは JBoss EAP の vault メカニズムを使用して暗号化する必要があります。- 外部コマンドの使用。
- 外部コマンドの出力からパスワードを入手するには、
{EXT}...形式を使用します (...は外部コマンドに置き換えます)。コマンド出力の最初の行がパスワードとして使用されます。パフォーマンスを改善するため、{EXTC[:expiration_in_millis]}の亜種は指定のミリ秒の間パスワードをキャッシュします。デフォルトでは、キャッシュされたパスワードは失効しません。0(ゼロ) が値として指定された場合、キャッシュされたクレデンシャルは失効しません。EXTCの亜種はLdapExtendedログインモジュールのみによってサポートされます。
例16.18 外部コマンドからのパスワードの取得
{EXT}cat /mysecretpasswordfile
{EXT}cat /mysecretpasswordfile
例16.19 外部ファイルからパスワードを取得し、500 ミリ秒間キャッシュする
{EXTC:500}cat /mysecretpasswordfile
{EXTC:500}cat /mysecretpasswordfile
16.2. カスタムモジュール リンクのコピーリンクがクリップボードにコピーされました!
AuthenticationManager は Subject プリンシパルセットの特定の使用パターンを必要とします。AuthenticationManager と動作するログインモジュールを書くには、JAAS サブジェクトクラスの情報ストレージ機能と、これらの機能の想定される使用方法を理解する必要があります。
LoginModule 実装を紹介します。
Subject に関連するセキュリティー情報を取得できます。
Subject アイデンティティーおよびロールに対し、EAP は getPrincipals() および getPrincipals(java.lang.Class) から取得したプリンシパルセットを選択します。使用パターンは次のとおりです。
- ユーザーアイデンティティー (例: ユーザー名、従業員 ID など) は
java.security.PrincipalオブジェクトとしてSubjectPrincipalsセットに保存されます。ユーザーアイデンティティーを示すPrincipal実装は、プリンシパルの名前に基づいた比較および等価が必要になります。適切な実装はorg.jboss.security.SimplePrincipalクラスとして使用可能です。必要な場合は、他のPrincipalインスタンスをSubjectPrincipalsに追加できます。 - 割り当てられたユーザーロールも
Principalsセットに保存され、java.security.acl.Groupインスタンスを使用して名前付きロールセットにグループ化されます。Groupインターフェースはjava.security.Principalのサブインスタンスで、PrincipalやGroupのコレクションを定義します。 - 任意の数のロールセットを
Subjectに割り当てできます。
- EAP セキュリティーフレームワークは、
RolesおよびCallerPrincipalという名前の 2 つのロールセットを使用します。Rolesグループは、Subjectが認証されたアプリケーションドメインで知られる名前付きロールのPrincipalのコレクションです。このロールセットは、現在の呼び出し側が名前付きアプリケーションドメインロールに属するかどうかを確認するために EJB が使用できるEJBContext.isCallerInRole(String)などのメソッドによって使用されます。メソッドパーミッションチェックを実行するセキュリティーインターセプターロジックもこのロールセットを使用します。CallerPrincipalGroupは、アプリケーションドメインのユーザーに割り当てられた単一のPrincipalアイデンティティーで構成されます。EJBContext.getCallerPrincipal()メソッドはCallerPrincipalを使用して、アプリケーションドメインが操作環境アイデンティティーからアプリケーションに適したユーザーアイデンティティーへマップできるようにします。SubjectにCallerPrincipalGroupがない場合、アプリケーションアイデンティティーは操作環境アイデンティティーと同じになります。
16.2.1. サブジェクト使用パターンのサポート リンクのコピーリンクがクリップボードにコピーされました!
Subject 使用パターンを正しく簡単に実装するため、適切に Subject を使用できるようにするテンプレートパターンを認証された Subject に追加するログインモジュールが EAP に含まれています。
2 つのログインモジュールでより汎用的なのが org.jboss.security.auth.spi.AbstractServerLoginModule クラスです。
javax.security.auth.spi.LoginModule の実装を提供し、操作環境セキュリティーインフラストラクチャー固有の主要タスクに対して抽象メソッドを提供します。このクラスの主な詳細は、例16.20「AbstractServerLoginModule クラスの一部」を参照してください。JavaDoc のコメントでサブクラスの役割が説明されています。
重要
loginOk インスタンス変数が極めて重要になります。ログインに成功した場合はこれを true に設定する必要があります。ログインに失敗した場合は、ログインメソッドをオーバーライドするサブクラスによって false に設定する必要があります。この変数が適切に設定されないと、コミットメソッドは適切にサブジェクトを更新しません。
例16.20 AbstractServerLoginModule クラスの一部
カスタムログインモジュールに適している 2 つ目の抽象ベースログインモジュールは org.jboss.security.auth.spi.UsernamePasswordLoginModule です。
char[] パスワードを認証クレデンシャルとすることで、カスタムログインモジュールの実装をさらに簡素化します。また、このログインモジュールは、匿名ユーザー (null のユーザー名とパスワードによって示される) をロールを持たないプリンシパルへマップすることをサポートします。クラスの主な詳細は以下を参照してください。JavaDoc のコメントでサブクラスの役割が説明されています。
例16.21 UsernamePasswordLoginModule クラスの一部
文字別ベースのユーザー名とクレデンシャルが、作成中のカスタムログインモジュールの認証技術で使用できるかどうかを基に AbstractServerLoginModule と UsernamePasswordLoginModule のどちらをサブクラス化するかを決定します。文字別ベースのセマンティックが有効な場合は UsernamePasswordLoginModule をサブクラス化し、その他の場合は AbstractServerLoginModule をサブクラスします。
カスタムログインモジュールが実行する手順は、選択するベースログインモジュールクラスによって異なります。セキュリティーインフラストラクチャーと統合するカスタムログインモジュールを作成する場合は、EAP セキュリティーマネージャーが想定する形式の認証された Principal 情報がログインモジュールによって提供されるようにするため、最初に AbstractServerLoginModule または UsernamePasswordLoginModule をサブクラス化します。
AbstractServerLoginModule をサブクラス化する場合は、以下をオーバーライドする必要があります。
void initialize(Subject, CallbackHandler, Map, Map): 解析するカスタムオプションがある場合。boolean login(): 認証を行うため。ログインに成功した場合は必ずloginOkインスタンス変数を true に設定します。失敗した場合は false に設定します。Principal getIdentity():log()手順によって認証されたユーザーのPrincipalオブジェクトを返します。Group[] getRoleSets(): 最低でも、login()の間に認証されたPrincipalへ割り当てられたロールが含まれるRolesという名前のGroupを返します。次に一般的なGroupの名前はCallerPrincipalで、セキュリティードメインアイデンティティーではなくユーザーのアプリケーションアイデンティティーを提供します。
UsernamePasswordLoginModule をサブクラス化する場合は、以下をオーバーライドする必要があります。
void initialize(Subject, CallbackHandler, Map, Map): 解析するカスタムオプションがある場合。Group[] getRoleSets(): 最低でも、login()の間に認証されたPrincipalへ割り当てられたロールが含まれるRolesという名前のGroupを返します。次に一般的なGroupの名前はCallerPrincipalで、セキュリティードメインアイデンティティーではなくユーザーのアプリケーションアイデンティティーを提供します。String getUsersPassword():getUsername()メソッドより使用可能な現在のユーザー名の想定されるパスワードを返します。callbackhandlerがユーザー名と候補のパスワードを返した後、getUsersPassword()メソッドはlogin()内から呼び出されます。
16.2.2. カスタム LoginModule の例 リンクのコピーリンクがクリップボードにコピーされました!
UsernamePasswordLoginModule を拡張し、JNDI ルックアップからユーザーのパスワードとロール名を取得するカスタムログインモジュールの例を作成するのに役立ちます。
password/<username> 形式 (<username> は認証中の現ユーザー) の名前を使用してコンテキストでルックアップを実行するとユーザーのパスワードが返されるカスタムの JNDI コンテキストログインモジュールが作成されます。同様に、roles/<username> 形式のルックアップは要求されたユーザーのロールを返します。JndiUserAndPassLoginModule カスタムログインモジュールのソースコードは 例16.22「JndiUserAndPassLoginModule カスタムログインモジュール」 を参照してください。
UsernamePasswordLoginModule が拡張されるため、JndiUserAndPassLoginModule はユーザーのパスワードとロールを JNDI ストアから取得することに注意してください。JndiUserAndPassLoginModule は JAAS LoginModule 操作とやりとりしません。
例16.22 JndiUserAndPassLoginModule カスタムログインモジュール
例16.23 新規されたカスタムログインモジュールが含まれる security-ex2 セキュリティードメインの定義
JndiUserAndPassLoginModule カスタムログインモジュールを使用することは、セキュリティードメイン例のログイン設定によって判断されます。EJB JAR META-INF/jboss-ejb3.xml 記述子はセキュリティードメインを設定します。Web アプリケーションでは、これは WEB-INF/jboss-web.xml ファイルの一部になります。
例16.24 jboss-ejb3.xml の例
例16.25 jboss-web.xml example
<?xml version="1.0"?>
<jboss-web>
<security-domain>security-ex2</security-domain>
</jboss-web>
<?xml version="1.0"?>
<jboss-web>
<security-domain>security-ex2</security-domain>
</jboss-web>
第17章 アプリケーションのロールベースセキュリティー リンクのコピーリンクがクリップボードにコピーされました!
17.1. Java Authentication and Authorization Service (JAAS) リンクのコピーリンクがクリップボードにコピーされました!
17.2. Java Authentication and Authorization Service (JAAS) リンクのコピーリンクがクリップボードにコピーされました!
サーバーグループ (管理対象ドメイン内) とサーバー (スタンドアローンサーバー内) にはセキュリティードメインの設定が含まれます。セキュリティードメインには、認証、承認、マッピング、監査のモジュールの組み合わせと設定詳細に関する情報が含まれています。アプリケーションは必要なセキュリティードメインを名前で jboss-web.xml に指定します。
アプリケーション固有の設定は次の 4 つのファイルの 1 つ以上に設定されます。
| File | 説明 |
|---|---|
| ejb-jar.xml |
アーカイブの
META-INF ディレクトリーにある Enterprise JavaBean (EJB) アプリケーションのデプロイメント記述子です。ejb-jar.xml を使用してロールを指定し、アプリケーションレベルでプリンシパルへマッピングします。また、特定のメソッドやクラスを特定のロールへ制限することも可能です。セキュリティーに関係しない他の EJB 固有の設定に対しても使用できます。
|
| web.xml |
Java Enterprise Edition (EE) の Web アプリケーションのデプロイメント記述子です。
web.xml を使用して、アプリケーションのリソースおよびトランスポートの制約を宣言します (許可される HTTP リクエストタイプの制限など)。このファイルに簡単な Web ベースの認証を設定することもできます。セキュリティーに関係しない他のアプリケーション固有の設定に使用することもできます。アプリケーションが認証および承認に使用するセキュリティードメインは、jboss-web.xml に定義されます。
|
| 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 固有の拡張を提供します。
17.3. アプリケーションでのセキュリティードメインの使用 リンクのコピーリンクがクリップボードにコピーされました!
アプリケーションでセキュリティードメインを使用するには、最初にサーバーの設定でセキュリティードメインを定義し、アプリケーションのデプロイメント記述子でアプリケーションに対して有効にする必要があります。その後、使用する EJB に必要なアノテーションを追加する必要があります。ここでは、アプリケーションでセキュリティードメインを使用するために必要な手順について取り上げます。
警告
手順17.1 セキュリティードメインを使用するようアプリケーションを設定
セキュリティードメインの定義
サーバーの設定ファイルでセキュリティードメインを定義した後、アプリケーションの記述子ファイルでアプリケーションに対して有効にする必要があります。サーバーの設定ファイルへセキュリティードメインを設定
セキュリティードメインは、サーバーの設定ファイルのsecurityサブシステムに設定されます。JBoss EAP 6 インスタンスが管理対象ドメインで実行されている場合、domain/configuration/domain.xmlファイルになります。JBoss EAP 6 インスタンスがスタンドアロンサーバーとして実行されている場合はstandalone/configuration/standalone.xmlファイルになります。other、jboss-web-policy、およびjboss-ejb-policyセキュリティードメインはデフォルトとして JBoss EAP 6 に提供されます。次の XML の例は、サーバーの設定ファイルのsecurityサブシステムよりコピーされました。セキュリティードメインのcache-type属性は、高速な認証チェックを行うためにキャッシュを指定します。簡単なマップをキャッシュとして使用するdefaultか、Infinispan キャッシュを使用するinfinispanを値として使用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 管理コンソールまたは CLI を使用して、追加のセキュリティードメインを必要に応じて設定できます。アプリケーションの記述子ファイルでのセキュリティードメインの有効化
セキュリティードメインはアプリケーションのWEB-INF/web.xmlファイルにある<jboss-web>要素の<security-domain>子要素に指定されます。次の例はmy-domainという名前のセキュリティードメインを設定します。<jboss-web> <security-domain>my-domain</security-domain> </jboss-web><jboss-web> <security-domain>my-domain</security-domain> </jboss-web>Copy to Clipboard Copied! Toggle word wrap Toggle overflow これがWEB-INF/jboss-web.xml記述子に指定できる多くの設定の 1 つになります。
EJB への必要なアノテーションの追加
@SecurityDomainおよび@RolesAllowedアノテーションを使用してセキュリティーを EJB に設定します。次の EJB コードの例は、guestロールのユーザーによるotherセキュリティードメインへのアクセスを制限します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow その他のコード例は、Red Hat カスタマーポータルより入手できる JBoss EAP 6 Quickstarts バンドルのejb-securityクイックスタートを参照してください。
17.4. サーブレットでのロールベースセキュリティーの使用 リンクのコピーリンクがクリップボードにコピーされました!
jboss-web.xml に指定されたセキュリティードメインによって処理されます。
サーブレットで ロールベースセキュリティーを使用する前に、アクセスの認証と承認に使用されるセキュリティードメインを JBoss EAP 6 のコンテナーに設定する必要があります。
手順17.2 ロールベースセキュリティーのサーブレットへの追加
サーブレットと URL パターンの間にマッピングを追加します。
web.xmlの<servlet-mapping>要素を使用して各サーブレットを URL パターンへマッピングします。次の例はDisplayOpResultと呼ばれるサーブレットを URL パターン/DisplayOpResultにマッピングします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow URL パターンにセキュリティー制約を追加します。
URL パターンをセキュリティー制約へマッピングするには、<security-constraint>を使用します。次の例は、URL パターン/DisplayOpResultのアクセスを、ロールeap_adminを持つプリンシパルのみに許可します。セキュリティードメインにロールが存在していなければなりません。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 認証メソッドを指定する必要があります。BASIC、FORM、DIGEST、CLIENT-CERT、SPNEGOのいずれかを指定できます。この例ではBASIC認証を使用します。WAR の
jboss-web.xmlにセキュリティードメインを指定します。セキュリティードメインにサーブレットを接続するため、WAR のjboss-web.xmlにセキュリティードメインを追加します。セキュリティードメインにはセキュリティー制約に対してプリンシパルを認証および承認する方法が設定されています。次の例はacme_domainというセキュリティードメインを使用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
例17.1 ロールベースセキュリティーが設定された web.xml の例
17.5. アプリケーションにおけるサードパーティー認証システムの使用 リンクのコピーリンクがクリップボードにコピーされました!
注記
context.xml デプロイメント記述子には設定されないようになりました。バルブは直接 jboss-web.xml 記述子に設定されます。context.xml は無視されるようになりました。
例17.2 基本的な認証バルブ
<jboss-web>
<valve>
<class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name>
</valve>
</jboss-web>
<jboss-web>
<valve>
<class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name>
</valve>
</jboss-web>
例17.3 ヘッダー属性セットを持つカスタムバルブ
独自のオーセンティケーターの作成については本書の範囲外となりますが、次の Java コードを例として提供します。
例17.4 GenericHeaderAuthenticator.java
第18章 マイグレーション リンクのコピーリンクがクリップボードにコピーされました!
18.1. アプリケーションセキュリティーの変更設定 リンクのコピーリンクがクリップボードにコピーされました!
以前のバージョンの JBoss EAP では、EAP_HOME/server/SERVER_NAME/conf/ ディレクトリーに置かれたプロパティーファイルはクラスパス上にあり、UsersRolesLoginModule によって簡単に見つかりました。JBoss EAP 6 ではディレクトリー構造が変更されたため、プロパティーファイルをアプリケーション内でパッケージ化し、クラスパスで使用できるようにする必要があります。
重要
security-domains 下の新しいセキュリティードメインを standalone/configuration/standalone.xml または domain/configuration/domain.xml サーバー設定ファイルに追加します。
${jboss.server.config.dir} は EAP_HOME/standalone/configuration/ ディレクトリーを参照します。インスタンスが管理対象ドメインで実行されている場合、 ${jboss.server.config.dir} は EAP_HOME/domain/configuration/ ディレクトリーを参照します。
JBoss EAP 6 では、セキュリティードメインの名前に接頭辞 java:/jaas/ を使用しません。
- Web アプリケーションの場合は、
jboss-web.xmlのセキュリティードメイン設定からこの接頭辞を削除する必要があります。 - エンタープライズアプリケーションの場合は、
jboss-ejb3.xmlファイルのセキュリティードメイン設定からこの接頭辞を削除する必要があります。JBoss EAP 6 では、jboss.xmlはこのファイルに置き換えられました。
付録A 参考資料 リンクのコピーリンクがクリップボードにコピーされました!
A.1. 含まれる認証モジュール リンクのコピーリンクがクリップボードにコピーされました!
Role という単語が Code 名に含まれます。
Code 値またはフルネーム (パッケージ修飾) 使用します。
認証モジュール
| コード | RealmDirect
|
| クラス | org.jboss.as.security.RealmDirectLoginModule
|
| 説明 |
セキュリティーレルムと直接インターフェースで接続するログインモジュール実装。このログインモジュールは、バッキングストアとのやりとりがすべてレルムへ委譲されるようにするため、定義の重複や同期化が必要なくなります。リモーティング呼び出しや管理インターフェースに対して使用されます。
|
| オプション | タイプ | デフォルト | 説明 |
|---|---|---|---|
realm |
文字列
| ApplicationRealm
|
指定するレルムの名前。
|
| コード | Client
|
| クラス | org.jboss.security.ClientLoginModule
|
| 説明 |
このログインモジュールは、JBoss EAP 6 がクライアントとして動作するときに呼び出し元 ID とクレデンシャルを確立するよう設定されています。サーバー認証に使用されるセキュリティードメインの一部として使用しないでください。
|
| オプション | タイプ | デフォルト | 説明 |
|---|---|---|---|
multi-threaded | true または false
| false
|
各スレッドが独自のプリンシパルとクレデンシャルストレージを持つ場合は、true に設定します。VM 内のすべてのスレッドが同じ ID とクレデンシャルを共有するよう指定する場合は false に設定します。
|
password-stacking
| useFirstPass または false
| false
|
このログインモジュールが ID として使用する
LoginContext に格納された情報を探すよう指定する場合は、LoginContext に設定します。このオプションは、他のログインモジュールをスタックする場合に使用できます。
|
restore-login-identity
| true または false
| false
| login() メソッドの先頭に示された ID とクレデンシャルを logout() メソッドの呼び出し後に復元する必要がある場合は true に設定します。
|
| コード | Remoting
|
| クラス | org.jboss.as.security.remoting.RemotingLoginModule
|
| 説明 |
このログインモジュールは、現在認証中の要求が Remoting 接続上で受信された要求であるかどうかを確認するために使用されます。Remoting 接続上で受信された要求である場合、Remoting 認証処理中に作成された ID が使用され、現在の要求に関連付けされます。要求が Remoting 接続上で受信されなかった場合は、このモジュールは何もせず、JAAS ベースのログインは次のモジュールへ続行されます。
|
| オプション | タイプ | デフォルト | 説明 |
|---|---|---|---|
password-stacking | useFirstPass または false
| false
|
このログインモジュールが ID を見つけるため
LoginContext に格納された情報を最初に探すことを示す useFirstPass の値。このオプションは、他のログインモジュールをこのモジュールとスタックする場合に使用できます。
|
principalClass
|
完全修飾クラス名
|
なし
|
プリンシパル名に String 引数を取るコンストラクターを含む
Principal 実装クラス。
|
unauthenticatedIdentity
|
プリンシパル名。
|
なし
|
認証情報を含まない要求に割り当てられるプリンシパル名を定義します。これにより、保護されていないサーブレットは特定のロールを必要としない EJB でメソッドを呼び出すことができるようになります。このようなプリンシパルには関連付けられたロールがなく、セキュアでない JEB または
unchecked permission 制約に関連付けられた EJB メソッドのみにアクセスできます。
|
| コード | Certificate
|
| クラス | org.jboss.security.auth.spi.BaseCertLoginModule
|
| 説明 |
このログインモジュールは、
X509 Certificates に基づいてユーザーを認証するよう設計されています。この使用例は、Web アプリケーションの CLIENT-CERT 認証です。
|
| オプション | タイプ | デフォルト | 説明 |
|---|---|---|---|
securityDomain
| 文字列 | other
|
信頼済み証明書を保持するトラストストア用 JSSE 設定を持つセキュリティードメインの名前。
|
verifier
| class |
なし
|
ログイン証明書の検証に使用する
org.jboss.security.auth.certs.X509CertificateVerifier のクラス名。
|
| コード | CertificateRoles
|
| クラス | org.jboss.security.auth.spi.CertRolesLoginModule
|
| 説明 |
このログインモジュールは、Certificate ログインモジュールを拡張して、プロパティーファイルからロールマッピング機能を追加します。同じすべてのオプションを Certificate ログインモジュールとして取得し、次のオプションを追加します。
|
| オプション | タイプ | デフォルト | 説明 |
|---|---|---|---|
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
|
defaultRolesProperties
| 文字列 | defaultRoles.properties
| rolesProperties ファイルが見つからない場合に使用するリソースまたはファイルの名前。
|
roleGroupSeparator
| 単一の文字。 | . (ピリオド 1 つ)
| rolesProperties ファイルでどの文字をロールグループセパレーターとして使用するか。
|
| コード | Database |
| クラス | org.jboss.security.auth.spi.DatabaseServerLoginModule
|
| 説明 |
認証とロールマッピングをサポートする JDBC ベースのログインモジュール。これは、次の定義を使用して、2 つの論理テーブルに基づきます。
|
| オプション | タイプ | デフォルト | 説明 |
|---|---|---|---|
digestCallback
| 完全修飾クラス名 |
なし
|
入力パスワードをハッシュ化するソルト値などのプレまたはポストダイジェストコンテンツを含む
DigestCallback 実装のクラス名。hashAlgorithm が指定された場合にのみ使用されます。
|
dsJndiName
| JNDI リソース | java:/DefaultDS
|
認証情報を保持する JNDI リソースの名前。このオプションは必須です。
|
hashAlgorithm
| String |
プレーンパスワードを使用
|
パスワードをハッシュ化するのに使用されるメッセージダイジェストアルゴリズム。サポートされるアルゴリズムは Java セキュリティープロバイダーに依存しますが、
MD5、SHA-1、および SHA-256 がサポートされます。
|
hashCharset
| String |
プラットフォームのデフォルトのエンコーディング
|
パスワードの文字列をバイトアレイに変換するときに使用する文字セット/エンコーディングの名前。これにはサポートされるすべての Java 文字セット名が含まれます。
|
hashEncoding
| String |
Base64
|
使用する文字列エンコーディング形式。
|
ignorePasswordCase
| boolean |
false
|
パスワードの比較で大文字と小文字の区別を無視するかどうかを示すフラグ。
|
inputValidator
| 完全修飾クラス名 |
なし
|
クライアントによって提供されるユーザー名およびパスワードを検証するために使用される InputValidator 実装のインスタンス。
|
principalsQuery
| 準備済み SQL ステートメント | select Password from Principals where PrincipalID=?
|
プリンシパルに関する情報を取得するための準備済み SQL クエリー。
|
rolesQuery
| 準備済み SQL ステートメント |
なし
|
ロールの情報を取得するための準備済み SQL クエリー。
select Role, RoleGroup from Roles where PrincipalID=? と同等である必要があります。ここで、Role はロール名で、RoleGroup 列の値は常に R が大文字である Roles または CallerPrincipal である必要があります。
|
storeDigestCallback
| 完全修飾クラス名 |
なし
|
ストア/予想されるパスワードをハッシュ化するソルト値などのプレまたはポストダイジェストコンテンツを含む
DigestCallback 実装のクラス名。hashStorePassword または hashUserPassword が true で、hashAlgorithm が指定された場合のみ使用されます。
|
suspendResume
| boolean |
true
|
データベース操作中に既存の JTA トランザクションを一時停止するかどうか。
|
throwValidatorError
| boolean |
false
|
検証エラーがクライアントへ公開されるべきかどうかを示すフラグ。
|
transactionManagerJndiName
| JNDI リソース |
java:/TransactionManager
|
ログインモジュールによって使用されるトランザクションマネージャーの JNDI 名。
|
| コード | DatabaseCertificate
|
| クラス | org.jboss.security.auth.spi.DatabaseCertLoginModule
|
| 説明 |
このログインモジュールは、Certificate ログインモジュールを拡張して、データベーステーブルからロールマッピング機能を追加します。同じオプションと次の追加オプションが存在します。
|
| オプション | タイプ | デフォルト | 説明 |
|---|---|---|---|
dsJndiName
| JNDI リソース | java:/DefaultDS
|
認証情報を保持する 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 トランザクションを一時停止するかどうか。
|
| コード | Identity
|
| クラス | org.jboss.security.auth.spi.IdentityLoginModule
|
| 説明 |
モジュールオプションで指定されたプリンシパルをモジュールに対して認証されたサブジェクトと関連付けます。使用される Principal クラスのタイプは
org.jboss.security.SimplePrincipal です。プリンシパルオプションが指定されない場合は、名前が guest のプリンシパルが使用されます。
|
| オプション | タイプ | デフォルト | 説明 |
|---|---|---|---|
principal
| String | guest
|
プリンシパルに使用する名前。
|
roles
| カンマ区切りの文字列リスト |
なし
|
サブジェクトに割り当てられるロールのカンマ区切りリスト。
|
| コード | Ldap
|
| クラス | org.jboss.security.auth.spi.LdapLoginModule
|
| 説明 |
ユーザー名とパスワードが、JNDI LDAP プロバイダーを使用してアクセスできる LDAP サーバーに格納された場合に、LDAP サーバーに対して認証します。多くのオプションは、LDAP プロバイダーまたは環境によって決定されるため、必須ではありません。
|
| オプション | タイプ | デフォルト | 説明 |
|---|---|---|---|
java.naming.factory.initial
| クラス名 | com.sun.jndi.ldap.LdapCtxFactory
| InitialContextFactory 実装クラス名。
|
java.naming.provider.url
| ldap:// URL
| java.naming.security.protocol の値が SSL の場合は ldap://localhost:636 で、その他の場合は ldap://localhost:389。
|
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 タイプを使用した不透明なオブジェクトとしてクレデンシャルを取得するかどうか。これにより、char[] クレデンシャル情報を LDAP サーバーに渡すことができます。
|
rolesCtxDN
| 完全修飾 DN |
なし
|
ユーザーロールを検索するコンテキストの完全修飾 DN。
|
userRolesCtxDNAttributeName
|
属性
|
なし
|
ユーザーロールを検索するコンテキストの DN を含むユーザーオブジェクトの属性。これは、
rolesCtxDN と異なるため、ユーザーのロールを検索するコンテキストは各ユーザーに対して一意になることがあります。
|
roleAttributeID
| 属性 | roles
|
ユーザーロールを含む属性の名前。
|
roleAttributeIsDN
| true または false
| false
| roleAttributeID にロールオブジェクトの完全修飾 DN が含まれるかどうか。false の場合は、コンテキスト名の roleNameAttributeId 属性の値からロール名が取得されます。Microsoft Active Directory などの特定のディレクトリースキーマでは、この属性を true に設定する必要があります。
|
roleNameAttributeID
| 属性 | name
|
ロール名を含む
roleCtxDN コンテキスト内の属性の名前。roleAttributeIsDN プロパティーが true に設定された場合、このプロパティーはロールオブジェクトの名前属性を見つけるために使用されます。
|
uidAttributeID
| 属性 | uid
|
ユーザー ID に対応する
UserRolesAttributeDN の属性の名前。これは、ユーザーロールを見つけるために使用されます。
|
matchOnUserDN
| true または false
| false
|
ユーザーロールの検索でユーザーの完全識別 DN またはユーザー名のみに一致するかどうか。
true の場合、完全 userDN は一致する値として使用されます。false の場合は、ユーザー名のみが uidAttributeName 属性に対して一致する値として使用されます。
|
allowEmptyPasswords
| true または false
| false
|
空白のパスワードを許可するかどうか。ほとんどの LDAP サーバーでは、空白のパスワードが匿名ログイン試行として扱われます。空のパスワードを拒否するには、これを
false に設定します。
|
| コード | LdapExtended
|
| クラス | org.jboss.security.auth.spi.LdapExtLoginModule
|
| 説明 |
検索を使用してバインドユーザーと関連するロールを見つける別の LDAP ログインモジュール実装。ロールクエリーは再帰的に DN に従い、階層ロール構造をナビゲートします。同じ
java.naming オプションを Ldap モジュールとして使用し、Ldap モジュールの他のオプションの代わりに次のオプションを使用します。
認証は 2 つの手順で行われます。
|
| オプション | タイプ | デフォルト | 説明 |
|---|---|---|---|
baseCtxDN
| 完全修飾 DN |
なし
|
ユーザー検索を開始する最上位コンテキストの固定 DN。
|
bindCredential
| 文字列、オプションで暗号化 |
なし
|
詳細は「bindCredential モジュールオプション」を参照してください。
|
bindDN
| 完全修飾 DN |
なし
|
ユーザーおよびロールクエリーのために LDAP サーバーに対してバインドするために使用される DN。この DN は
baseCtxDN および rolesCtxDN の値に対する読み取りおよび検索パーミッションを必要とします。
|
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
| 属性 | name
|
ロール名を含む
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
| false
|
空白のパスワードを許可するかどうか。ほとんどの LDAP サーバーでは、空白のパスワードが匿名ログイン試行として扱われます。空のパスワードを拒否するには、これを false に設定します。
|
referralUserAttributeIDToCheck
|
属性
|
なし
|
リファーラル (referral) を使用しない場合はこのオプションを無視してもかまいません。リファーラルを使用し、ロールオブジェクトがリファーラル内部にある場合、このオプションは特定のロール (例:
member) に対して定義されたユーザーが含まれる属性名を示します。ユーザーはこの属性名の内容に対してチェックされます。このオプションが設定されていないとチェックは常に失敗するため、ロールオブジェクトはリファーラルツリーに保存できません。
|
| コード | RoleMapping
|
| クラス | org.jboss.security.auth.spi.RoleMappingLoginModule
|
| 説明 |
認証プロセスの結果であるロールを宣言ロールに対してマップします。このモジュールは、セキュリティードメインに追加する場合に
optional とフラグ付けする必要があります。
|
| オプション | タイプ | デフォルト | 説明 |
|---|---|---|---|
rolesProperties
| プロパティーファイルまたはリソースの完全修飾ファイルパスまたは完全修飾ファイル名。 | none
|
ロールを置換ロールに対してマップするプロパティーファイルまたはリソースの完全修飾ファイルパスまたはファイル名。形式は
original_role=role1,role2,role3 になります。
|
replaceRole
| true または false
| false
|
現在のロールを追加するか、現在のロールをマップされたロールに置き換えるか。
true に設定された場合は、置き換えられます。
|
注記
rolesProperties モジュールオプションは RoleMapping に必要です。
| コード | RunAs
|
| クラス | org.jboss.security.auth.spi.RunAsLoginModule
|
| 説明 | run as ロールを、認証のログイン段階の間スタックにプッシュし、コミットまたはアボート段階でスタックから run as ロールをポップするヘルパーモジュール。このログインモジュールは、セキュアな EJB にアクセスするログインモジュールなどの、認証を実行するためにセキュアなリソースにアクセスする必要がある他のログインモジュール用ロールを提供します。run as ロールを確立する必要があるログインモジュールの前に、RunAsLoginModule を設定する必要があります。
|
| オプション | タイプ | デフォルト | 説明 |
|---|---|---|---|
roleName
| ロール名 | nobody
|
ログイン段階で
run as ロールとして使用するロールの名前。
|
principalName
| プリンシパル名 | nobody
|
ログインフェーズ中に
run as プリンシパルとして使用するプリンシパルの名前。指定がない場合、デフォルトの nobody が使用されます。
|
principalClass
| 完全修飾クラス名 |
なし
|
プリンシパル名に String 引数を取るコンストラクターを含む
Principal 実装クラス。
|
| コード | Simple
|
| クラス | org.jboss.security.auth.spi.SimpleServerLoginModule
|
| 説明 |
テスト目的でセキュリティーを素早くセットアップするモジュール。次の単純なアルゴリズムが実装されます。
|
Simple モジュールオプション
Simpleモジュールにはオプションがありません。
| コード | ConfiguredIdentity
|
| クラス | org.picketbox.datasource.security.ConfiguredIdentityLoginModule
|
| 説明 |
モジュールオプションで指定されたプリンシパルをモジュールに対して認証されたサブジェクトに関連付けます。使用される Principal クラスのタイプは
org.jboss.security.SimplePrincipal です。
|
| オプション | タイプ | デフォルト | 説明 |
|---|---|---|---|
username
| 文字列 | なし | 認証のユーザー名 |
password
| 暗号化文字列 | "" |
認証に使用するパスワード。パスワードを暗号化するには、コマンドラインで直接モジュールを使用します。
java org.picketbox.datasource.security.SecureIdentityLoginModule password_to_encrypt
このコマンドの結果をモジュールオプションの値フィールドに貼り付けます。デフォルトの値は空の文字列です。
|
principal
| プリンシパルの名前 | none
|
モジュールに対して認証されるサブジェクトに関連付けられるプリンシパル。
|
| コード | SecureIdentity
|
| クラス | org.picketbox.datasource.security.SecureIdentityLoginModule
|
| 説明 |
このモジュールは、レガシー対応のために提供されます。このモジュールを使用すると、パスワードを暗号化し、暗号化されたパスワードを最適なプリンシパルで使用します。アプリケーションが
SecureIdentity を使用する場合は、パスワード vault メカニズムを代わりに使用することを検討してください。
|
| オプション | タイプ | デフォルト | 説明 |
|---|---|---|---|
username
| 文字列 | なし | 認証のユーザー名 |
password
| 暗号化文字列 | "" |
認証に使用するパスワード。パスワードを暗号化するには、コマンドラインで直接モジュールを使用します。
java org.picketbox.datasource.security.SecureIdentityLoginModule password_to_encrypt
このコマンドの結果をモジュールオプションの値フィールドに貼り付けます。デフォルトの値は空の文字列です。
|
managedConnectionFactoryName
| JCA リソース | なし |
データソースの JCA 接続ファクトリーの名前。
|
| コード | PropertiesUsers
|
| クラス | org.jboss.security.auth.spi.PropertiesUsersLoginModule
|
| 説明 |
認証用ユーザー名およびパスワードを格納するプロパティーファイルを使用します。認証 (ロールマッピング) は提供されません。このモジュールは、テスト向けのみに限定されます。
|
| コード | SimpleUsers
|
| クラス | org.jboss.security.auth.spi.SimpleUsersLoginModule
|
| 説明 |
このログインモジュールは
module-option を使用してユーザー名とクリアテキストパスワードを保存します。module-option の name および value 属性はユーザー名とパスワードを指定します。テストの目的でのみ含まれているため、本番環境
|
| コード | LdapUsers
|
| クラス | org.jboss.security.auth.spi.LdapUsersLoginModule
|
| 説明 | LdapUsers モジュールは ExtendedLDAP および AdvancedLdap モジュールが導入されたため廃止になりました。
|
| コード | Kerberos
|
| クラス | com.sun.security.auth.module.Krb5LoginModule。IBM JDK でのクラス名は com.ibm.security.auth.module.Krb5LoginModule。
|
| 説明 |
GSSAPI を使用して Kerberos ログイン認証を実行します。このモジュールは、Sun Microsystems により提供された API のセキュリティーフレームワークの一部です。詳細については、http://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html を参照してください。このモジュールは、認証とロールのマッピングを処理する別のモジュールと組み合わせる必要があります。
|
| オプション | タイプ | デフォルト | 説明 |
|---|---|---|---|
storekey
| true または false
| false | KerberosKey をサブジェクトのプライベートクレデンシャルに追加するかどうか。
|
doNotPrompt
| true または false
| false | true に設定された場合、ユーザーはパスワードを要求されません。
|
useTicketCache
| true または false のブール値
| false | true の場合、TGT はチケットキャッシュから取得されます。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 に設定して、認証段階が完了した後に共有状態からユーザー名とパスワードを削除します。
|
| コード | SPNEGO
|
| クラス | org.jboss.security.negotiation.spnego.SPNEGOLoginModule
|
| 説明 |
Microsoft Active Directory サーバーまたは SPNEGO をサポートする他の環境に対して SPNEGO 認証を許可します。SPNEGO は Kerberos クレデンシャルを持つこともできます。このモジュールは、認証とロールのマッピングを処理する別のモジュールと組み合わせる必要があります。
|
| オプション | タイプ | デフォルト | 説明 |
|---|---|---|---|
serverSecurityDomain
| string
| null
|
Kerberos ログインモジュールを介してサーバーサービスの ID を読み出すために使用されるドメインを定義します。このプロパティーは必ず設定する必要があります。
|
removeRealmFromPrincipal
| boolean
| false
|
処理を続行する前に Kerberos レルムをプリンシパルから削除する必要があることを指定します。
|
usernamePasswordDomain
| string
| null
|
Kerberos が失敗したときにフェールオーバーログインとして使用する必要がある設定内の別のセキュリティードメインを指定します。
|
| コード | AdvancedLdap |
| クラス | org.jboss.security.negotiation.AdvancedLdapLoginModule
|
| 説明 |
SASL や JAAS セキュリティードメインの使用など、追加機能を提供するモジュール。
|
| オプション | タイプ | デフォルト | 説明 |
|---|---|---|---|
bindAuthentication
|
文字列
|
なし
|
ディレクトリーサーバーへのバインディングに使用する SASL 認証のタイプ。
|
java.naming.provider.url
| string
| java.naming.security.protocol の値が SSL の場合は ldap://localhost:686 で、その他の場合は ldap://localhost:389。
|
ディレクトリーサーバーの URI。
|
baseCtxDN
|
完全修飾 DN
|
なし
|
検索の基盤として使用する識別名。
|
baseFilter
|
LDAP 検索フィルターを表す文字列。
|
なし
|
検索結果を絞り込むために使用するフィルター。
|
roleAttributeID
|
LDAP 属性を表す文字列値。
|
なし
|
承認ロールの名前が含まれる LDAP 属性。
|
roleAttributeIsDN
| true または false
| false
|
ロール属性が識別名 (DN) であるかどうか。
|
roleNameAttributeID
|
LDAP 属性を表す文字列。
|
なし
|
実際のロール属性が含まれる
RoleAttributeId 内に格納された属性。
|
recurseRoles
| true または false
| false
|
ロールに対して
RoleAttributeId を再帰的に検索するかどうか。
|
referralUserAttributeIDToCheck
|
属性
|
なし
|
リファーラル (referral) を使用しない場合はこのオプションを無視してもかまいません。リファーラルを使用し、ロールオブジェクトがリファーラル内部にある場合、このオプションは特定のロール (例:
member) に対して定義されたユーザーが含まれる属性名を示します。ユーザーはこの属性名の内容に対してチェックされます。このオプションが設定されていないとチェックは常に失敗するため、ロールオブジェクトはリファーラルツリーに保存できません。
|
| コード | AdvancedADLdap |
| クラス | org.jboss.security.negotiation.AdvancedADLoginModule
|
| 説明 |
このモジュールは
AdvancedLdap ログインモジュールを拡張し、Microsoft Active Directory に関連する追加パラメーターを追加します。
|
| コード | UsersRoles |
| クラス | org.jboss.security.auth.spi.UsersRolesLoginModul
|
| 説明 |
2 つの異なるプロパティーファイルに格納された複数のユーザーおよびユーザーロールをサポートする簡単なログインモジュール。
|
| オプション | タイプ | デフォルト | 説明 |
|---|---|---|---|
usersProperties
|
ファイルまたはリソースへのパス。
| users.properties
|
ユーザーからパスワードへのマッピングが含まれるファイルまたはリソース。ファイルの形式は
username=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 メソッドにのみアクセスできます。
|
認証モジュールは、javax.security.auth.spi.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.web.WebAuthorizationModule |
| JACC | org.jboss.security.authorization.modules.JACCAuthorizationModule |
| XACML | org.jboss.security.authorization.modules.XACMLAuthorizationModule |
認証リクエストを常に拒否する単純な承認モジュールです。設定オプションはありません。
認証リクエストを常に許可する単純な承認モジュールです。設定オプションはありません。
意思決定を設定済みの delegate へ移譲するデフォルトの認証モジュールです。
デフォルトの Tomcat 承認ロジック (permit all) を持つデフォルトの Web 認証モジュールです。
このモジュールは 2 つの delegate を使用して JACC セマンティックを強制します (Web コンテナ承認リクエストの WebJACCPolicyModuleDelegate と、EJB コンテナリクエストの EJBJACCPolicyModuleDelegate)。設定オプションはありません。
このモジュールは Web コンテナと EJB コンテナの 2 つの delegate を使用して (WebXACMLPolicyModuleDelegate および EJBXACMLPolicyModuleDelegate) XACML 承認を強制します。このモジュールは登録されたポリシーを基に PDP オブジェクトを作成し、それに対して Web または EJB リクエストを評価します。
これはオーバーライドされる必要があるベースの承認モジュールで、他の承認モジュールへ委譲するためのファシリティーを提供します。
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 |
| LdapAttributes | org.jboss.security.mapping.providers.attribute.LdapAttributeMappingProvider |
jboss-web.xml および jboss-app.xml デプロイメント記述子で可能なプリンシパルからロールへのマッピングを考慮するロールマッピングモジュール。
例A.1 例
jboss-web.xml および jboss-app.xml デプロイメント記述子で指定できるプリンシパルからロールへのマッピングを考慮するロールツーロール (Role to Roles) マッピングモジュールです。この場合、principal-name は他のロールをマップするロールを示します。
例A.2 例
オプションからロールを選び、渡されたグループの前に追加するロールマッピングプロバイダー。ロール (値) のカンマ区切りリストが含まれるロール名 (キー) のプロパティースタイルマッピングを取ります。
SimplePrincipal を取り、異なるプリンシパル名で SimplePrincipal を変換するプリンシパルマッピングプロバイダー。
データベースからロールを読み取る MappingProvider。
dsJndiName: ロールをユーザーにマップするために使用されるデータソースの JNDI 名。rolesQuery: このオプションは「select RoleName from Roles where User=?」と同等の準備済みステートメントです。「?」は現在のプリンシパル名に置き換えられます。suspendResume: ブール値 - ロールの検索の実行中に、現在のスレッドに関連するトランザクションを停止し、その後再開します。transactionManagerJndiName: トランザクションマネージャーの JNDI 名 (デフォルトは java:/TransactionManager)。
ロールを検索するため LDAP サーバーを使用してロールを割り当てるマッピングプロバイダー。
bindDN: ユーザーおよびロールクエリーのために LDAP サーバーに対してバインドするために使用される DN。この DN は baseCtxDN および rolesCtxDN の値では読み取りおよび検索パーミッションが必要です。bindCredential: bindDN のパスワード。これは、jaasSecurityDomain が指定された場合に暗号化できます。rolesCtxDN: ユーザーロールを検索するコンテキストの固定 DN。これは、実際のロールが存在する DN ではなく、ユーザーロールを含むオブジェクトが存在する DN です。たとえば、Microsoft Active Directory サーバーでは、これは、ユーザーアカウントが存在する DN です。roleAttributeID: 承認ロールの名前が含まれる LDAP 属性。roleAttributeIsDN:roleAttributeIDにロールオブジェクトの完全修飾 DN が含まれるかどうか。false の場合は、コンテキスト名のroleNameAttributeId属性の値からロール名が取得されます。Microsoft Active Directory などの特定のディレクトリースキーマでは、この属性をtrueに設定する必要があります。roleNameAttributeID: ロール名を含むroleCtxDNコンテキスト内の属性の名前。roleAttributeIsDNプロパティーがtrueに設定された場合、このプロパティーはロールオブジェクトの名前属性を見つけるために使用されます。parseRoleNameFromDN: クエリーによって返された DN に roleNameAttributeID が含まれるかどうかを示すフラグ。trueに設定された場合、DN は roleNameATtributeID に対してチェックされます。falseに設定された場合、DN は roleNameATtributeID に対してチェックされません。このフラグは LDAP クエリーのパフォーマンスを向上できます。roleFilter: 認証済みユーザーと関連付けられたロールを検索するために使用される検索フィルター。入力ユーザー名またはログインモジュールコールバックから取得されたuserDNが{0}式が使用されたフィルターに置換されます。認証済みuserDNは、{1}が使用されたフィルターに置換されます。入力ユーザー名に一致する検索フィルター例は、(member={0})です。認証済みuserDNに一致する他の例は(member={1})です。roleRecursion: ロール検索が一致するコンテキストで行われる再帰のレベル数。再帰を無効にするには、これを0に設定します。searchTimeLimit: ユーザー/ロール検索のタイムアウト (ミリ秒単位)。デフォルトは 10000 (10 秒) です。searchScope: 使用する検索範囲。
「username=role1,role2,...」という形式でプロパティーファイルからロールを読み取る MappingProvider。
rolesProperties: プロパティーでフォーマットされるファイル名。JBoss 変数の拡張は${jboss.variable}という形式で使用されます。
オプションマップからロールを読み取る簡単な MappingProvider。オプションの属性名はロールを割り当てるプリンシパルの名前で、 属性値はプリンシパルに割り当てるロール名のカンマ区切りリストです。
例A.3 例
<module-option name="JavaDuke" value="JBossAdmin,Admin"/> <module-option name="joe" value="Users"/>
<module-option name="JavaDuke" value="JBossAdmin,Admin"/>
<module-option name="joe" value="Users"/>
モジュールをチェックし、マッピングコンテキストからプリンシパル名を見つけ、principalName + ".email" という名前のモジュールオプションから属性電子メールアドレスを作成し、それを指定のプリンシパルへマップします。
属性を LDAP からサブジェクトへマップします。オプションには、ご使用の LDAP JNDI プロバイダーがサポートするオプションがすべて含まれます。
例A.4 標準のプロパティー名の例
Context.INITIAL_CONTEXT_FACTORY = "java.naming.factory.initial" Context.SECURITY_PROTOCOL = "java.naming.security.protocol" Context.PROVIDER_URL = "java.naming.provider.url" Context.SECURITY_AUTHENTICATION = "java.naming.security.authentication"
Context.INITIAL_CONTEXT_FACTORY = "java.naming.factory.initial"
Context.SECURITY_PROTOCOL = "java.naming.security.protocol"
Context.PROVIDER_URL = "java.naming.provider.url"
Context.SECURITY_AUTHENTICATION = "java.naming.security.authentication"
bindDN: ユーザーおよびロールクエリーのために LDAP サーバーに対してバインドするために使用される DN。この DN は baseCtxDN および rolesCtxDN の値では読み取りおよび検索パーミッションが必要です。bindCredential: bindDN のパスワード。これは、jaasSecurityDomain が指定された場合に暗号化できます。baseCtxDN: ユーザー検索を開始するコンテキストの固定 DN。baseFilter: 認証するユーザーのコンテキストを見つけるために使用される検索フィルター。入力ユーザー名またはログインモジュールコールバックから取得されたuserDNが、{0}式が使用されたフィルターに置換されます。この置換の挙動は標準の__DirContext.search(Name, String, Object[], SearchControls cons)__メソッドからになります。一般的な検索フィルターの例は(uid={0})です。searchTimeLimit: ユーザー/ロール検索のタイムアウト (ミリ秒単位)。デフォルトは 10000 (10 秒) です。attributeList: ユーザーの属性のカンマ区切りリスト (例: mail,cn,sn,employeeType,employeeNumber)。jaasSecurityDomain:java.naming.security.principalの復号化に使用する JaasSecurityDomain。パスワードの暗号化された形式はJaasSecurityDomain#encrypt64(byte[])によって返されます。org.jboss.security.plugins.PBEUtilsを使用して暗号化された形式を生成することもできます。
A.4. 含まれるセキュリティー監査プロバイダーモジュール リンクのコピーリンクがクリップボードにコピーされました!
| コード | クラス |
|---|---|
| LogAuditProvider | org.jboss.security.audit.providers.LogAuditProvider |
A.5. jboss-web.xml の設定に関する参考資料 リンクのコピーリンクがクリップボードにコピーされました!
jboss-web.xml はデプロイメントの WEB-INF ディレクトリー内にあるファイルです。このファイルには、JBoss Web コンテナが Servlet 3.0 仕様に追加する機能に関する設定情報が含まれています。Servlet 3.0 仕様は web.xml の同じディレクトリーに格納されます。
jboss-web.xml ファイルのトップレベル要素は <jboss-web> 要素です。
使用可能な設定の多くは、アプリケーションの web.xml に設定される要件をローカルリソースへマッピングします。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 に対する要求を満たします。
| 属性 | 説明 |
|---|---|
| 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 EAP 6 に新規導入された要素です。 |
| disable-audit | Web 監査を有効にする場合はこのブール値要素を false に設定し、無効にする場合は true に設定します。Web セキュリティー監査は Java EE 仕様の一部ではありません。この要素は JBoss EAP 6 に初めて導入された要素です。 |
| disable-cross-context | false の場合、アプリケーションは他のアプリケーションコンテキストを呼び出すことができます。デフォルトは true です。 |
アプリケーションによって使用されるアノテーションを記述します。下表は <annotation> の子要素の一覧になります。
| 属性 | 説明 |
|---|---|
| class-name |
アノテーションのクラスの名前。
|
| servlet-security |
サーブレットのセキュリティーを表す
@ServletSecurity などの要素。
|
| run-as |
run-as の情報を表す
@RunAs などの要素。
|
| multipart-config |
multipart-config 情報を表す
@MultiPart などの要素。
|
リスナーを記述します。下表は <listener> の子要素の一覧になります。
| 属性 | 説明 |
|---|---|
| class-name |
リスナーのクラスの名前。
|
| listener-type |
アプリケーションのコンテキストにどのようなリスナーを追加するかを示す
condition 要素の一覧です。以下を選択することが可能です。
|
| module |
リスナークラスが含まれるモジュールの名前。
|
| param |
パラメーター。
<param-name> と <param-value> の 2 つの子要素が含まれます。
|
アプリケーションのバルブを記述します。<listener> に似ており、class-name、module および param 要素を持ちます。
A.6. 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.5 セキュリティー ID の例
<session> の中でのみ利用可能です。
付録B 改訂履歴 リンクのコピーリンクがクリップボードにコピーされました!
| 改訂履歴 | |||
|---|---|---|---|
| 改訂 6.3.0-50.1 | Mon Feb 11 2019 | ||
| |||
| 改訂 6.3.0-50 | Tuesday November 18 2014 | ||
| |||
| 改訂 6.3.0-43 | Friday August 8 2014 | ||
| |||
| 改訂 6.3.0-42 | Wednesday, July 30 2014 | ||
| |||