セキュリティーガイド
Red Hat JBoss Enterprise Application Platform 6 向け
Red Hat Customer Content Services
概要
パート 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
-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"
例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"
例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"
例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"
ドメインサーバーを起動します。
ドメインまたはサーバーを通常どおり起動します。
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
を実行します。場所は異なることがあります。
ポリシーを作成します。
ポリシーを作成するには、Add Policy Entry を選択します。必要なパラメーターを追加し、Done をクリックします。既存のポリシーを編集します。
既存のポリシーのリストからポリシーを選択し、Edit Policy Entry ボタンを選択します。必要に応じて、パラメーターを編集します。既存のポリシーを削除します。
既存のポリシーのリストからポリシーを選択し、Remove Policy Entry ボタンを選択します。
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
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"
Windows
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()
スタンドアロンインスタンスでは以下のコマンドを使用します。/core-service=management/security-realm=MyDomainRealm:add()
新しいロールの情報を保存するプロパティーファイルへの参照を作成します。
次のコマンドを実行し、新しいロールに関連するプロパティーが含まれるmyfile.properties
という名前のファイルのポインターを作成します。注記
新たに作成されたプロパティーファイルは、含まれるadd-user.sh
およびadd-user.bat
スクリプトによって管理されません。そのため、外部で管理する必要があります。ドメインインスタンスでは以下コマンドを使用します。/host=master/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
スタンドアロンインスタンスでは以下のコマンドを使用します。/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
新しいセキュリティーレルムが作成されます。新たに作成されたこのレルムにユーザーやロールを追加すると、デフォルトのセキュリティーレルムとは別のファイルに情報が保存されます。新規ファイルはご使用のアプリケーションやプロシージャーを使用して管理できます。
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
例4.2 管理インターフェースの指定
EAP_HOME/bin/domain.sh -bmanagement=10.1.1.1
例4.3 各インターフェースへの異なるアドレスの指定
EAP_HOME/bin/domain.sh -bmanagement=127.0.0.1 -b 10.1.1.1
例4.4 すべてのネットワークインターフェースへのパブリックインターフェースのバインド
EAP_HOME/bin/domain.sh -b 0.0.0.0
-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 キーを使用して Customize ボタンに移動し、ENTER キーを押します。Trusted Services 画面が表示されます。
- どの値も変更せずに、TAB キーを使用して Forward ボタンに移動し、ENTER を押して次の画面に進みます。Other Ports 画面が表示されます。
- TAB キーを使用して <Add> ボタンに移動し、ENTER を押します。Port and Protocol 画面が表示されます。
- Port / Port Range フィールドに
5445
と入力し、TAB キーを使用して Protocol フィールドに移動し、tcp
と入力します。TAB キーを使用して OK ボタンに移動し、ENTER を押します。 - TAB キーを使用して、Forward ボタンに移動し、Port Forwarding 画面にアクセスします。
- TAB キーを使用して <Add> ボタンに移動し、ENTER キーを押します。
- 以下の値を入力してポート
5445
のポート転送を設定します。- 送信元インターフェース:
eth1
- プロトコル:
tcp
- ポート/ポート範囲:
5445
- 宛先 IP アドレス:
10.1.1.2
- ポート/ポート範囲:
5445
TAB キーを使用して OK ボタンに移動し、ENTER を押します。 - TAB キーを使用して Close ボタンに移動し、ENTER を押します。
- TAB キーを使用して OK ボタンに移動し、ENTER を押します。変更内容を適用するには、警告を読み、Yes をクリックします。
JBoss 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"'
- ポート 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"'
手順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
注記
UDP マルチキャストをアドバタイズする mod_cluster バランサーのデフォルトアドレスおよびポートは 224.0.1.105:23364 です。
4.3. JBoss EAP 6 により使用されるネットワークポート
- サーバーグループがデフォルトのソケットバインディンググループのいずれかを使用するか、またはカスタムグループを使用するかどうか。
- 個別デプロイメントの要件。
注記
8080
で、サーバーは 100
のポートオフセットを使用する場合、その HTTP ポートは 8180
になります。
デフォルトのソケットバインディンググループ
full-ha-sockets
full-sockets
ha-sockets
standard-sockets
表4.1 デフォルトのソケットバインディングの参照
名前 | ポート | マルチキャストポート | 説明 | full-ha-sockets | full-sockets | ha-socket | standard-socket |
---|---|---|---|---|---|---|---|
ajp | 8009 | Apache JServ プロトコル。HTTP クラスタリングおよび負荷分散に使用します。 | ○ | ○ | ○ | ○ | |
http | 8080 | デプロイされた Web アプリケーションのデフォルトポート。 | ○ | ○ | ○ | ○ | |
https | 8443 | デプロイされた Web アプリケーションとクライアント間の SSL 暗号化接続。 | ○ | ○ | ○ | ○ | |
jacorb | 3528 | JTS トランザクションおよび他の ORB 依存サービス用の CORBA サービス。 | ○ | ○ | × | × | |
jacorb-ssl | 3529 | SSL 暗号化 CORBA サービス。 | ○ | ○ | × | × | |
jgroups-diagnostics | 7500 | マルチキャスト。HA クラスターでのピアの検出に使用されます。管理インターフェースを使用しても設定できません。 | ○ | × | ○ | × | |
jgroups-mping | 45700 | マルチキャスト。HA クラスターでの初期メンバーシップの検出に使用されます。 | ○ | × | ○ | × | |
jgroups-tcp | 7600 | TCP を使用した、HA クラスター内でのユニキャストピア検出。 | ○ | × | ○ | × | |
jgroups-tcp-fd | 57600 | TCP を介した HA 障害検出に使用されます。 | ○ | × | ○ | × | |
jgroups-udp | 55200 | 45688 | UDP を使用した、HA クラスター内でのマルチキャストピア検出。 | ○ | × | ○ | × |
jgroups-udp-fd | 54200 | UDP を介した HA 障害検出に使用されます。 | ○ | × | ○ | × | |
messaging | 5445 | JMS サービス。 | ○ | ○ | × | × | |
messaging-group | HornetQ JMS ブロードキャストと検出グループにより参照されます。 | ○ | ○ | × | × | ||
messaging-throughput | 5455 | JMS Remoting により使用されます。 | ○ | ○ | × | × | |
mod_cluster | 23364 | JBoss 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 ベンダーのドキュメントを確認してください。
表4.2 推奨される暗号プリミティブ
2048 ビットキーと OAEP を使用する RSA |
CBC モードの AES-128 |
SHA-256 |
HMAC-SHA-256 |
HMAC-SHA-1 |
表4.3 その他の暗号プリミティブ
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)
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)
プロトコルを
TLSv1
に設定します。/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=protocol,value=TLSv1)
アプリケーションをデプロイします。
設定したプロファイルを使用するサーバーグループにアプリケーションをデプロイします。スタンドアロンサーバーを使用する場合、アプリケーションをサーバーにデプロイします。アプリケーションに対する 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 -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 コマンドで使用されるパラメーターの説明は次のとおりです。Parameter 説明 -genkeypair
keytool
コマンドは公開鍵と秘密鍵が含まれるキーペアを生成します。-alias
キーストアのエイリアス。この値は任意ですが、エイリアス jboss
はデフォルトで JBoss Web サーバーによって使用されます。-keyalg
キーペア生成のアルゴリズム。この例では RSA
になります。-keystore
キーストアファイルの名前と場所。デフォルトの場所はカレントディレクトリーです。選択する名前は任意です。この例では、ファイルの名前は server.keystore
になります。-storepass
このパスワードは、キーの読み取りを可能にするためキーストアに対して認証を行うために使用されます。パスワードは 6 文字以上である必要があり、キーストアがアクセスされた時に提供しなければなりません。この例では、 mykeystorepass
が使用されています。このパラメーターを省略すると、コマンドの実行時に入力するよう要求されます。-keypass
実際の鍵のパスワードです。注記
実装の制限により、ストアと同じパスワードを使用する必要があります。--dname
キーの識別名を記述する引用符で囲まれた文字列 (例: "CN=jsmith,OU=Engineering,O=mycompany.com,L=Raleigh,C=US")。以下のコンポーネントが連結された文字列になります。 CN
- 共通名またはホスト名。ホスト名が jsmith.mycompany.com の場合、CN
は jsmith になります。OU
- 組織単位 (例: Engineering)。O
- 組織名 (例: mycompany.com)。L
- 地域 (例: Raleigh または London)。S
- 州 (例: NC)。このパラメーターの使用は任意です。C
- 2 文字の国コード (例: US または UK)。
上記のコマンドを実行すると、次の情報が要求されます。- コマンドラインで
-storepass
パラメーターを使用しなかった場合、キーストアのパスワードを入力するよう要求されます。次に要求されたら新しいパスワードを再入力します。 - コマンドラインで
-keypass
パラメーターを使用しなかった場合、キーのパスワードを入力するよう要求されます。Enter を押し、キーストアのパスワードと同じ値を設定します。
コマンドが終了すると、ファイルserver.keystore
にエイリアスjboss
を持つ単一のキーが含まれるようになります。キーを検証します。
以下のコマンドを使用して、キーが正常に動作することを検証します。keytool -list -keystore server.keystore
キーストアのパスワードを入力するよう求められます。キーストアの内容 (この場合はjboss
という名前の単一キー) が表示されます。jboss
キーの種類がPrivateKeyEntry
であることに注意してください。これは、キーストアにこのキーのパブリックおよびプライベートエントリが含まれることを示します。証明書署名要求を生成します。
次のコマンドを実行し、手順 1 で作成したキーストアより公開鍵を使用して証明書署名要求を生成します。keytool -certreq -keyalg RSA -alias jboss -keystore server.keystore -file certreq.csr
キーストアに対する認証を行うために、パスワードを入力するよう求められます。keytool
コマンドにより、現在の作業ディレクトリーにcertreq.csr
という名前の証明書署名要求が新規作成されます。新しく生成された証明書署名要求をテストします。
以下のコマンドを使用して証明書の内容をテストします。openssl req -in certreq.csr -noout -text
証明書の詳細が表示されます。オプション: 証明書署名要求を認証局 (CA) に送信します。
認証局 (CA) は、証明書を認証できます。この結果、証明書は、サードパーティークライアントが信用できると見なされます。CA により、署名済み証明書が提供されます。また、オプションで 1 つまたは複数の中間証明書が提供されます。オプション: キーストアからの自己署名証明書のエクスポート
テストまたは内部使用のためにのみ証明書が必要な場合は、自己署名証明書を使用できます。次のように、手順 1 で作成したキーストアからエクスポートします。keytool -export -alias jboss -keystore server.keystore -file server.crt
キーストアに対して認証するためパスワードの入力が求められます。server.crt
という名前の自己署名証明書が現在の作業ディレクトリーに作成されます。署名済み証明書を中間証明書とともにインポートします。
CA で指示された順序で各証明書をインポートします。各証明書をインポートするには、intermediate.ca
またはserver.crt
を実際のファイル名に置き換えます。証明書が別のファイルとして提供されない場合は、各証明書に対して個別のファイルを作成し、その内容をファイルに貼り付けます。注記
署名済み証明書および証明書キーは機密情報です。サーバー間での転送方法に注意してください。keytool -import -keystore server.keystore -alias intermediateCA -file intermediate.ca
keytool -importcert -alias jboss -keystore server.keystore -file server.crt
証明書が正常にインポートされたことをテストします。
以下のコマンドを実行し、要求された場合にキーストアパスワードを入力します。キーストアの内容が表示され、証明書がリストの一部になります。keytool -list -keystore server.keystore
署名済み証明書はキーストアに含まれ、HTTPS Web サーバー通信を含む SSL 接続を暗号化するために使用できます。
4.8. SSL コネクターリファレンス
default
を使用した管理対象ドメイン向けに設計されています。プロファイル名を、管理対象ドメインに対して設定する名前に変更するか、コマンドの /profile=default
部分を省略します (スタンドアロンサーバーの場合)。
表4.4 SSL コネクター属性
属性 | 説明 | 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
FIPS プロバイダー情報の確認
standalone.conf
または domain.conf
に -Djavax.net.debug=true
を追加して、debug レベルのロギングを有効にします。FIPS プロバイダーの情報は server.log
に記録されます。例を以下に示します。
04:22:45,685 INFO [stdout] (http-/127.0.0.1:8443-1) JsseJCE: Using MessageDigest SHA from provider IBMJCEFIPS version 1.7 04:22:45,689 INFO [stdout] (http-/127.0.0.1:8443-1) DHCrypt: DH KeyPairGenerator from provider from init IBMJCEFIPS version 1.7 04:22:45,754 INFO [stdout] (http-/127.0.0.1:8443-1) JsseJCE: Using KeyFactory DiffieHellman from provider IBMJCEFIPS version 1.7 04:22:45,754 INFO [stdout] (http-/127.0.0.1:8443-1) JsseJCE: Using KeyAgreement DiffieHellman from provider IBMJCEFIPS version 1.7 04:22:45,754 INFO [stdout] (http-/127.0.0.1:8443-1) DHCrypt: DH KeyAgreement from provider IBMJCEFIPS version 1.7 04:22:45,754 INFO [stdout] (http-/127.0.0.1:8443-1) DHCrypt: DH KeyAgreement from provider from initIBMJCEFIPS version 1.7
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
NSS 設定ファイルの作成
次の内容が含まれるnss_pkcsll_fips.cfg
という名前の新しいテキストファイルを/usr/share/jboss-as
ディレクトリーに作成します。name = nss-fips nssLibraryDirectory=/usr/lib64 nssSecmodDirectory=/usr/share/jboss-as/nssdb nssModule = fips
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
この行に指定されている設定ファイルは手順 2 で作成されたファイルであることに注意してください。このプロバイダーを優先するため、このファイルにある他のsecurity.provider.X
行の値 (X) に 1 を足す必要があります。NSS ライブラリーに対して FIPS モードを有効にする
次のようにmodutil
コマンドを実行し、FIPS モードを有効にします。modutil -fips true -dbdir /usr/share/jboss-as/nssdb
ここで指定するディレクトリーは手順 1 で作成したものであることに注意してください。この時点で、セキュリティーライブラリーエラーが発生し、NSS 共有オブジェクトの一部に対してライブラリー署名の再生成が必要になることがあります。FIPS トークンのパスワードの変更
次のコマンドを使用して FIPS トークンのパスワードを設定します。トークンの名前はNSS FIPS 140-2 Certificate DB
でなければならないことに注意してください。modutil -changepw "
NSS FIPS 140-2 Certificate DB
" -dbdir /usr/share/jboss-as/nssdbFIPS トークンに使用されるパスワードは 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
PKCS11 キーストアを使用するよう HTTPS コネクターを設定する
JBoss CLI ツールで次のコマンドを使用し、HTTPS コネクターを追加します。/subsystem=web/connector=https/:add(socket-binding=https,scheme=https,protocol=HTTP/1.1,secure=true)
次に、以下のコマンドを使用して SSL 設定を追加します。PASSWORD を 手順 5 の FIPS 準拠のパスワードに置き換えます。/subsystem=web/connector=https/ssl=configuration:add(name=https,password=PASSWORD,keystore-type=PKCS11, cipher-suite="SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_anon_WITH_AES_128_CBC_SHA, TLS_ECDH_anon_WITH_AES_256_CBC_SHA")
検証
次のコマンドを実行し、JVM が PKCS11 キーストアから公開鍵を読み取れることを検証します。keytool -list -storetype pkcs11
例4.5 FIPS 140-2 に準拠した HTTPS コネクターの XML 設定
<connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true"> <ssl name="https" password="****" cipher-suite="SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_anon_WITH_AES_128_CBC_SHA, TLS_ECDH_anon_WITH_AES_256_CBC_SHA" keystore-type="PKCS11"/> </connector>
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)
例5.1 HTTP インターフェースの設定の読み込み
/host=master/core-service=management/management-interface=http-interface/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
{
"outcome" => "success",
"result" => {
"console-enabled" => true,
"interface" => "management",
"port" => expression "${jboss.management.http.port:9990}",
"secure-port" => undefined,
"security-realm" => "ManagementRealm"
}
}
例5.2 HTTP インターフェースの削除
/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)
5.4. デフォルトセキュリティーレルムからのサイレント認証の削除
JBoss EAP 6 には、ローカル管理 CLI ユーザーに対するサイレント認証方法が含まれます。これにより、ローカルユーザーは、ユーザー名またはパスワード認証なしで管理 CLI にアクセスできるようになります。この機能は、利便性のために有効であり、ローカルユーザーが認証なしで管理 CLI スクリプトを実行する場合に役に立ちます。この機能は、ローカル設定へのアクセスにより、ユーザーが独自のユーザー詳細を追加できる (または、セキュリティーチェックを無効にする) ため、役に立つ機能です。
security-realm
セクション内で local
要素を削除することにより、実現できます。これは、スタンドアロンサーバーインスタンス用の standalone.xml
と管理対象ドメイン用の host.xml
の両方に適用されます。特定のサーバー設定への影響について理解している場合のみ、local
要素の削除を考慮するようにしてください。
local
要素を直接削除することです。
例5.4 security-realm
の local
要素の例
<security-realms> <security-realm name="ManagementRealm"> <authentication> <local default-user="$local"/> <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/> </authentication> </security-realm> <security-realm name="ApplicationRealm"> <authentication> <local default-user="$local" allowed-users="*"/> <properties path="application-users.properties" relative-to="jboss.server.config.dir"/> </authentication> <authorization> <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/> </authorization> </security-realm> </security-realms>
要件
- JBoss EAP 6 インスタンスを起動します。
- 管理 CLI を起動します。
手順5.1 デフォルトセキュリティーレルムからのサイレント認証の削除
管理 CLI でのサイレント認証の削除
必要に応じて、管理レルムとアプリケーションレルムからlocal
要素を削除します。- 管理レルムから
local
要素を削除します。スタンドアロンの場合
/core-service=management/security-realm=ManagementRealm/authentication=local:remove
管理対象ドメインの場合
/host=HOST_NAME/core-service=management/security-realm=ManagementRealm/authentication=local:remove
- アプリケーションレルムから
local
要素を削除します。スタンドアロンの場合
/core-service=management/security-realm=ApplicationRealm/authentication=local:remove
管理対象ドメインの場合
/host=HOST_NAME/core-service=management/security-realm=ApplicationRealm/authentication=local:remove
サイレント認証モードが、ManagementRealm
と ApplicationRealm
から削除されます。
5.5. JMX サブシステムへのリモートアクセスの無効化
/profile=default
接頭辞を削除してください。
注記
例5.5 JMX サブシステムからのリモートコネクターの削除
/profile=default/subsystem=jmx/remoting-connector=jmx/:remove
例5.6 JMX サブシステムの削除
/profile=default/subsystem=jmx/:remove
5.6. 管理インターフェースのセキュリティーレルムの設定
デフォルトでは、管理インターフェースは ManagementRealm
セキュリティーレルムを使用するよう設定されています。ManagementRealm はユーザーとパスワードの組み合わせを mgmt-users.properties
ファイルに格納します。
例5.7 デフォルトの ManagementRealm
/host=master/core-service=management/security-realm=ManagementRealm/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
{
"outcome" => "success",
"result" => {
"authorization" => undefined,
"server-identity" => undefined,
"authentication" => {"properties" => {
"path" => "mgmt-users.properties",
"plain-text" => false,
"relative-to" => "jboss.domain.config.dir"
}}
}
}
以下のコマンドは TestRealm
というセキュリティーレルムを作成し、関連するプロパティーファイルのディレクトリーを設定します。
例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)
セキュリティードメインを使用して管理インターフェースに対して認証を行うには、以下の手順に従います。
security-realm
属性の値として指定します。
例5.9 HTTP 管理インターフェースに使用するセキュリティーレルムの指定
/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管理コンソールが 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:undefine-attribute(name=socket-binding)
これらのコマンド実行後、以下のような出力が表示されるはずです。{"outcome" => "success"}
注記
この時点で、JBoss EAP のログに以下のようなエラーメッセージが表示されることがありますが、この時点では SSL の設定が完了していないため表示されます。JBAS015103: A secure port has been specified for the HTTP interface but no SSL configuration in the realm.
ドメインモード
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)
注記
この時点で、JBoss EAP のログに以下のようなエラーメッセージが表示されることがありますが、この時点では SSL の設定が完了していないため表示されます。JBAS015103: A secure port has been specified for the HTTP interface but no SSL configuration in the realm.
任意設定: カスタム 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}"/>
セキュリティーレルムを新たに作成します。
以下のコマンドを実行し、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/management-interface=http-interface/:write-attribute(name=security-realm,value=ManagementRealmHTTPS)
キーストアを使用するよう管理コンソールを設定します。
以下の管理 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)このコマンド実行後、以下のような出力が表示されるはずです。{ "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } }
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
注記
5.8. 管理インターフェースへの HTTP および HTTPS 接続に異なるインターフェースを使用
interface
属性によって指定されたインターフェースとは異なるインターフェースを使用する場合、secure-interface
属性が HTTPS 管理通信のホストのソケットを開くネットワークインターフェースを指定します。この属性を指定しないと、interface
属性によって指定されたインターフェースが使用されます。
secure-port
属性が設定されていなくても secure-interface
属性には影響はありません。
secure-interface
属性が設定されている EAP_HOME/domain/configuration/host.xml
の設定例は次のとおりです。
<?xml version='1.0' encoding='UTF-8'?> <host name="master" xmlns="urn:jboss:domain:3.0"> <management> <security-realms> <security-realm name="ManagementRealm"> <authentication> <local default-user="$local" /> <properties path="mgmt-users.properties" relative-to="jboss.domain.config.dir"/> </authentication> </security-realm> </security-realms> <management-interfaces> <native-interface security-realm="ManagementRealm"> <socket interface="management" port="${jboss.management.native.port:9999}"/> </native-interface> <http-interface security-realm="ManagementRealm"> <socket interface="management" port="${jboss.management.http.port:9990}" secure-port="${jboss.management.https.port:9943}" secure-interface="secure-management"/> </http-interface> </management-interfaces> </management> <domain-controller> <local/> <!-- Alternative remote domain controller configuration with a host and port --> <!-- <remote host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm"/> --> </domain-controller> <interfaces> <interface name="management"> <inet-address value="${jboss.bind.address.management:127.0.0.1}"/> </interface> <interface name="secure-management"> <inet-address value="${jboss.bind.address:10.10.64.1}"/> </interface> </interfaces> </host>
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 HOST2_alias -keyalg RSA -keysize 1024 -validity 365 -keystore host2.keystore.jks -dname "CA_HOST2" -keypass secret -storepass secret
- 証明書をエクスポートします。
keytool -exportcert -keystore HOST1.keystore.jks -alias HOST1_alias -keypass secret -storepass secret -file HOST1.cer
keytool -exportcert -keystore HOST2.keystore.jks -alias HOST2_alias -keypass secret -storepass secret -file HOST2.cer
- 証明書を反対のトラストストアにインポートします。
keytool -importcert -keystore HOST1.truststore.jks -storepass secret -alias HOST2_alias -trustcacerts -file HOST2.cer
keytool -importcert -keystore HOST2.truststore.jks -storepass secret -alias HOST1_alias -trustcacerts -file HOST1.cer
- インストールの設定に CertificateRealm を定義し (
host.xml
またはstandalone.xml
)、インターフェースがそれを示すようにします。これを行うには、設定ファイルを手作業で編集するか (非推奨)、以下のコマンドを使用します。/core-service=management/security-realm=CertificateRealm:add()
/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/authentication=truststore:add(keystore-path=/path/to/HOST1.truststore.jks,keystore-password=secret)
重要
これらのコマンドはスタンドアロンモードのみに提供されます。ドメインモードでは各コマンドの前に/host=master
を追加します。 - ネイティブインターフェースの
security-realm
を新しい証明書レルムに変更します。/host=master/core-service=management/management-interface=native-interface:write-attribute(name=security-realm,value=CertificateRealm)
EAP_HOME/bin/jboss-cli.xml
を設定ファイルとして使用する CLI の SSL 設定を追加します。パスワード vault を使用してキーストアおよびトラストストアのパスワードを保存するか (推奨方法)、プレーンテキストで保存します。- パスワード vault でキーストアおよびトラストストアのパスワードを保存する方法
EAP_HOME/bin/jboss-cli.xml
を編集し、SSL 設定を追加します (変数に適切な値を使用します)。また、vault の設定を追加します (各値をご使用の vault の値に置き換えます)。<ssl> <vault> <vault-option name="KEYSTORE_URL" value="path-to/vault/vault.keystore"/> <vault-option name="KEYSTORE_PASSWORD" value="MASK-5WNXs8oEbrs"/> <vault-option name="KEYSTORE_ALIAS" value="vault"/> <vault-option name="SALT" value="12345678"/> <vault-option name="ITERATION_COUNT" value="50"/> <vault-option name="ENC_FILE_DIR" value="path-to/jboss-eap/vault/"/> </vault> <alias>$HOST2alias</alias> <key-store>/path/to/HOST2.keystore.jks</key-store> <key-store-password>VAULT::VB::cli_pass::1</key-store-password> <key-password>VAULT::VB::cli_pass::1</key-password> <trust-store>/path/to/HOST2.truststore.jks</trust-store> <trust-store-password>VAULT::VB::cli_pass::1</trust-store-password> <modify-trust-store>true</modify-trust-store> </ssl>
- プレーンテキストでキーストアおよびトラストストアのパスワードを保存する方法
EAP_HOME/bin/jboss-cli.xml
を編集し、SSL 設定を追加します (変数に適切な値を使用します)。<ssl> <alias>$HOST2alias</alias> <key-store>/path/to/HOST2.keystore.jks</key-store> <key-store-password>secret</key-store-password> <trust-store>/path/to/HOST2.truststore.jks</trust-store> <trust-store-password>secret</trust-store-password> <modify-trust-store>true</modify-trust-store> </ssl>
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()
/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)
5.11. LDAP
5.11.1. LDAP
5.11.2. 管理インターフェースに対する LDAP を使用した認証
- LDAP サーバーへの送信接続を作成します。
- LDAP 対応のセキュリティーレルムを作成します。
- 管理インターフェースの新規セキュリティードメインを参照します。
LDAP 送信接続には、以下の属性を使用することができます。
表5.1 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/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))
例5.11 LDAP 対応のセキュリティーレルムを示す XML
- connection -
ldap_connection
- base-dn -
cn=users,dc=acme,dc=com
. - username-filter -
attribute="sambaAccountName"
<security-realm name="ldap_security_realm"> <authentication> <ldap connection="ldap_connection" base-dn="cn=users,dc=acme,dc=com"> <username-filter attribute="sambaAccountName" /> </ldap> </authentication> </security-realm>
警告
例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")
セキュリティーレルムの作成が完了したら、管理インターフェースの設定でそのドメインを参照する必要があります。管理インターフェースは、HTTP ダイジェスト認証用のセキュリティーレルムを使用します。
例5.13 HTTP インターフェースへのセキュリティーレルムの適用
/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)
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")
- 「管理インターフェースに対する 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. ロールパーミッション
表6.1 ロールパーミッション
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)
[standalone@localhost:9999 /] /core-service=management/access=authorization:write-attribute(name=provider, value=rbac) { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } [standalone@localhost:9999 /] /:reload { "outcome" => "success", "result" => undefined }
手順6.2 RBAC の無効化
- 管理 CLI で RBAC を無効にするには、アクセス承認リソースの
write-attribute
操作を使用して、プロバイダー属性をsimple
に設定します。/core-service=management/access=authorization:write-attribute(name=provider, value=simple)
[standalone@localhost:9999 /] /core-service=management/access=authorization:write-attribute(name=provider, value=simple) { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } [standalone@localhost:9999 /] /:reload { "outcome" => "success", "result" => undefined }
access-control
要素にある provider
属性を編集します。有効にする場合は値を rbac
に設定し、無効にする場合は simple
に設定します。
<management> <access-control provider="rbac"> <role-mapping> <role name="SuperUser"> <include> <user name="$local"/> </include> </role> </role-mapping> </access-control> </management>
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)
有効なポリシー名は 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]
permission-combination-policy
属性を編集します。
<access-control provider="rbac" permission-combination-policy="rejecting"> <role-mapping> <role name="SuperUser"> <include> <user name="$local"/> </include> </role> </role-mapping> </access-control>
6.9. ロールの管理
6.9.1. ロールメンバーシップ
- ユーザーが以下のいずれかである場合。
- ロールに含まれるユーザーとしてリストに記載されている。
- ロールに含まれるとリストに記載されたグループのメンバーである。
- ユーザーが以下のいずれかに該当しない場合。
- ロールから除外されるユーザーとしてリストに記載されている。
- ロールから除外されるとリストに記載されたグループのメンバーである。
6.9.2. ユーザーロール割り当ての設定
SuperUser
または Administrator
ロールのユーザーのみです。
- 管理コンソールへログインします。
- Administration タブをクリックします。
- Access Control メニューを展開し、Role Assignment を選択します。
- USERS タブを選択します。
手順6.4 ユーザーの新しいロール割り当ての作成
- 管理コンソールへログインします。
- Role Assignment セクションの Users タブに移動します。
- ユーザーリストの右上にある Add ボタンをクリックします。Add User ダイアログが表示されます。
図6.1 Add User ダイアログ
- ユーザー名を指定し、任意でレルムを指定します。
- Type メニューを include または exclude に設定します。
- include または exclude するロールのチェックボックスをクリックします。Control キー (OSX では Command キー) を押しながらクリックすると、複数のチェックボックスを選択できます。
- Save をクリックして終了します。正常に保存されると、Add User ダイアログが閉じられます。ユーザーのリストが更新され、変更内容が反映されます。正常に保存されなかった場合は、
Failed to save role assignment
というメッセージが表示されます。
手順6.5 ユーザーロール割り当ての更新
- 管理コンソールへログインします。
- Role Assignment セクションの Users タブに移動します。
- リストよりユーザーを選択します。
- Edit をクリックします。選択パネルが編集モードになります。
図6.2 Selection Edit ビュー
ここで、ユーザーに割り当てられたロールや除外されたロールを追加および削除できます。- 割り当てられたロールを追加するには、左側の使用可能なロールのリストからロールを選択し、割り当てられたロールリストの横にある、右矢印のボタンをクリックします。ロールが、使用可能なロールのリストから割り当てられたロールのリストに移動します。
- 割り当てられたロールを削除するには、割り当てられたロールのリストからロールを選択し、割り当てられたロールリストの横にある左矢印のボタンをクリックします。ロールが、割り当てられたロールのリストから使用可能なロールのリストへ移動します。
- 除外されたロールを追加するには、左側の使用可能なロールのリストからロールを選択し、除外されたロールリストの横にある、右矢印のボタンをクリックします。ロールが、使用可能なロールのリストから除外されたロールのリストに移動します。
- 除外されたロールを削除するには、除外されたロールのリストからロールを選択し、除外されたロールリストの横にある左矢印のボタンをクリックします。ロールが、除外されたロールのリストから使用可能なロールのリストへ移動します。
- Save をクリックして終了します。正常に保存されると、編集ビューが閉じられます。ユーザーのリストが更新され、変更内容が反映されます。正常に保存されなかった場合は、
Failed to save role assignment
というメッセージが表示されます。
手順6.6 ユーザーのロール割り当ての削除
- 管理コンソールへログインします。
- Role Assignment セクションの Users タブへ移動します。
- リストよりユーザーを選択します。
- Remove をクリックします。Remove Role Assignment 確認プロンプトが表示されます。
- Confirm をクリックします。正しく削除されると、ユーザーロール割り当てのリストにユーザーが表示されなくなります。
重要
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
手順6.7 ロール割り当て設定の表示
- :read-children-names 操作を使用して、設定されたロールの完全リストを取得します。
/core-service=management/access=authorization:read-children-names(child-type=role-mapping)
[standalone@localhost:9999 access=authorization] :read-children-names(child-type=role-mapping) { "outcome" => "success", "result" => [ "Administrator", "Deployer", "Maintainer", "Monitor", "Operator", "SuperUser" ] }
- 指定されたロールマッピングの
read-resource
操作を使用して、特定ロールの完全詳細を取得します。/core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)
[standalone@localhost:9999 access=authorization] ./role-mapping=Administrator:read-resource(recursive=true) { "outcome" => "success", "result" => { "include-all" => false, "exclude" => undefined, "include" => { "user-theboss" => { "name" => "theboss", "realm" => undefined, "type" => "USER" }, "user-harold" => { "name" => "harold", "realm" => undefined, "type" => "USER" }, "group-SysOps" => { "name" => "SysOps", "realm" => undefined, "type" => "GROUP" } } } } [standalone@localhost:9999 access=authorization]
手順6.8 新規ロールの追加
add
操作を使用して、新しいロール設定を追加します。/core-service=management/access=authorization/role-mapping=ROLENAME:add
ROLENAME は新しいマッピングに対するロール名です。[standalone@localhost:9999 access=authorization] ./role-mapping=Auditor:add {"outcome" => "success"} [standalone@localhost:9999 access=authorization]
手順6.9 ロールに include されるユーザーの追加
add
操作を使用して、ユーザーエントリーをロールの include リストに追加します。/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=USERNAME, type=USER)
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]
手順6.10 ロールに exclude されるユーザーの追加
add
操作を使用して、ユーザーエントリーをロールの exclude リストに追加します。/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=USERNAME, type=USER)
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]
手順6.11 ユーザーロールの include 設定の削除
remove
操作を使用してエントリーを削除します。/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
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]
include リストからユーザーを削除しても、ユーザーはシステムから削除されず、ロールがユーザーに割り当てられなくなる保証はありません。ロールはグループメンバーシップを基に割り当てられる可能性があります。
手順6.12 ユーザーロールの exclude 設定の削除
remove
操作を使用してエントリーを削除します。/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
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]
exclude リストからユーザーを削除しても、ユーザーはシステムから削除されず、ロールがユーザーに割り当てられる保証はありません。ロールはグループメンバーシップを基に除外される可能性があります。
6.9.4. ロールとユーザーグループ
mgmt-users.properties
ファイルまたは LDAP サーバーを使用して認証されるユーザーはユーザーグループのメンバーである可能性があります。ユーザーグループは、1 名以上のユーザーに割り当てできる任意のラベルです。
mgmt-users.properties
ファイルを使用する場合、グループ情報は mgmt-groups.properties
ファイルに保存されます。LDAP を使用する場合、グループ情報は LDAP サーバーに保存され、LDAP サーバーの管理者によって維持されます。
6.9.5. グループロール割り当ての設定
SuperUser
または Administrator
ロールのユーザーのみです。
- 管理コンソールへログインします。
- Administration タブをクリックします。
- Access Control メニューを展開し、Role Assignment を選択します。
- GROUPS タブを選択します。
手順6.13 グループの新しいロール割り当ての作成
- 管理コンソールへログインします。
- Role Assignment セクションの GROUPS タブに移動します。
- ユーザーリストの右上にある Add ボタンをクリックします。Add Group ダイアログが表示されます。
図6.3 Add Group ダイアログ
- グループ名を指定し、任意でレルムを指定します。
- Type メニューを include または exclude に設定します。
- include または exclude するロールのチェックボックスをクリックします。Control キー (OSX では Command キー) を押しながらクリックすると、複数のチェックボックスを選択できます。
- Save をクリックして終了します。正常に保存されると、Add Group ダイアログが閉じられます。グループのリストが更新され、変更内容が反映されます。正常に保存されなかった場合は、
Failed to save role assignment
というメッセージが表示されます。
手順6.14 グループロール割り当ての更新
- 管理コンソールへログインします。
- Role Assignment セクションの GROUPS タブへ移動します。
- リストよりグループを選択します。
- Edit をクリックします。Selection ビューが編集モードになります。
図6.4 Selection ビュー編集モード
ここで、グループに割り当てられたロールや除外されたロールを追加および削除できます。- 割り当てられたロールを追加するには、左側の使用可能なロールのリストからロールを選択し、割り当てられたロールリストの横にある、右矢印のボタンをクリックします。ロールが、使用可能なロールのリストから割り当てられたロールのリストに移動します。
- 割り当てられたロールを削除するには、割り当てられたロールのリストからロールを選択し、割り当てられたロールリストの横にある左矢印のボタンをクリックします。ロールが、割り当てられたロールのリストから使用可能なロールのリストへ移動します。
- 除外されたロールを追加するには、左側の使用可能なロールのリストからロールを選択し、除外されたロールリストの横にある、右矢印のボタンをクリックします。ロールが、使用可能なロールのリストから除外されたロールのリストに移動します。
- 除外されたロールを削除するには、除外されたロールのリストからロールを選択し、除外されたロールリストの横にある左矢印のボタンをクリックします。ロールが、除外されたロールのリストから使用可能なロールのリストへ移動します。
- Save をクリックして終了します。正常に保存されると、編集ビューが閉じられます。グループのリストが更新され、変更内容が反映されます。正常に保存されなかった場合は、Failed to save role assignment というメッセージが表示されます。
手順6.15 グループのロール割り当ての削除
- 管理コンソールへログインします。
- Role Assignment セクションの GROUPS タブへ移動します。
- リストよりグループを選択します。
- Remove をクリックします。Remove Role Assignment 確認プロンプトが表示されます。
- Confirm をクリックします。正しく削除されると、グループロール割り当てのリストにロールが表示されなくなります。ロール割り当てのリストからグループを削除しても、ユーザーグループはシステムから削除されず、そのグループのメンバーにロールが割り当てられなくなる保証はありません。各グループメンバーに直接ロールが割り当てられる可能性があります。
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
手順6.16 グループロール割り当て設定の表示
read-children-names
操作を使用して、設定されたロールの完全リストを取得します。/core-service=management/access=authorization:read-children-names(child-type=role-mapping)
[standalone@localhost:9999 access=authorization] :read-children-names(child-type=role-mapping) { "outcome" => "success", "result" => [ "Administrator", "Deployer", "Maintainer", "Monitor", "Operator", "SuperUser" ] }
- 指定されたロールマッピングの
read-resource
操作を使用して、特定ロールの完全詳細を取得します。/core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)
[standalone@localhost:9999 access=authorization] ./role-mapping=Administrator:read-resource(recursive=true) { "outcome" => "success", "result" => { "include-all" => false, "exclude" => undefined, "include" => { "user-theboss" => { "name" => "theboss", "realm" => undefined, "type" => "USER" }, "user-harold" => { "name" => "harold", "realm" => undefined, "type" => "USER" }, "group-SysOps" => { "name" => "SysOps", "realm" => undefined, "type" => "GROUP" } } } } [standalone@localhost:9999 access=authorization]
手順6.17 新規ロールの追加
add
操作を使用して、新しいロール設定を追加します。/core-service=management/access=authorization/role-mapping=ROLENAME:add
[standalone@localhost:9999 access=authorization] ./role-mapping=Auditor:add {"outcome" => "success"} [standalone@localhost:9999 access=authorization]
手順6.18 グループに include されるユーザーの追加
add
操作を使用して、グループエントリーをロールの include リストに追加します。/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=GROUPNAME, type=GROUP)
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]
手順6.19 ロールに exclude されるグループの追加
add
操作を使用して、グループエントリーをロールの exclude リストに追加します。/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=GROUPNAME, type=GROUP)
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]
手順6.20 グループーロールの include 設定の削除
remove
操作を使用してエントリーを削除します。/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
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]
include リストからグループを削除しても、グループはシステムから削除されず、このグループのユーザーにロールが割り当てられなくなる保証はありません。ロールは、グループのユーザーへ個別に割り当てられる可能性があります。
手順6.21 ユーザーグループの exclude エントリーの削除
remove
操作を使用してエントリーを削除します。/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
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]
exclude リストからグループを削除しても、グループはシステムから削除されず、ロールがグループのメンバーに割り当てられる保証はありません。ロールはグループメンバーシップを基に除外される可能性があります。
6.9.7. LDAP での承認とグループローディング
memberOf
属性を用いてユーザーエンティティーがユーザーが属するグループをマップしたり、 uniqueMember
属性を用いてグループエンティティーが属するユーザーをマップしたりすることがあります。また、両方のマッピングが LDAP サーバーによって維持されることもあります。
force
が false に設定されている場合は承認クエリー中に再使用されます。force
が true の場合は、承認中 (グループのロード中) に検索が再実行されます。通常、これは認証と承認が異なるサーバーによって実行される場合に行われます。
<authorization> <ldap connection="..."> <!-- OPTIONAL --> <username-to-dn force="true"> <!-- Only one of the following. --> <username-is-dn /> <username-filter base-dn="..." recursive="..." user-dn-attribute="..." attribute="..." /> <advanced-filter base-dn="..." recursive="..." user-dn-attribute="..." filter="..." /> </username-to-dn> <group-search group-name="..." iterative="..." group-dn-attribute="..." group-name-attribute="..." > <!-- One of the following --> <group-to-principal base-dn="..." recursive="..." search-by="..."> <membership-filter principal-attribute="..." /> </group-to-principal> <principal-to-group group-attribute="..." /> </group-search> </ldap> </authorization>
重要
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>
これは 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>
設定可能な属性は次のとおりです。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-filter の例と同じ属性は、意味とデフォルト値も同じです。新たな属性は以下の 1 つのみです。filter
: ユーザー名が{0}
プレースホルダーで置き換えられる、ユーザーのエントリーの検索に使用されるカスタムフィルター。
重要
フィルターの定義後も XML が有効である必要があるため、&
などの特殊文字が使用される場合は、適切な形式が使用されるようにしてください。たとえば、&
文字には&
を使用します。
グループ検索
例6.1 LDIF の例: プリンシパルからグループ
TestUserOne
は GroupOne
のメンバーで、 GroupOne
は GroupFive
のメンバーです。グループメンバーシップは、memberOf
属性を使用して表されます。memberOf
属性は、ユーザー (またはグループ) がメンバーであるグループの識別名に設定されます。
memberOf
属性を設定することも可能です (ユーザーが直接メンバーであるグループごとに 1 つ)。
dn: uid=TestUserOne,ou=users,dc=principal-to-group,dc=example,dc=org objectClass: extensibleObject objectClass: top objectClass: groupMember objectClass: inetOrgPerson objectClass: uidObject objectClass: person objectClass: organizationalPerson cn: Test User One sn: Test User One uid: TestUserOne distinguishedName: uid=TestUserOne,ou=users,dc=principal-to-group,dc=example,dc=org memberOf: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org memberOf: uid=Slashy/Group,ou=groups,dc=principal-to-group,dc=example,dc=org userPassword:: e1NTSEF9WFpURzhLVjc4WVZBQUJNbEI3Ym96UVAva0RTNlFNWUpLOTdTMUE9PQ== dn: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org objectClass: extensibleObject objectClass: top objectClass: groupMember objectClass: group objectClass: uidObject uid: GroupOne distinguishedName: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org memberOf: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org dn: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org objectClass: extensibleObject objectClass: top objectClass: groupMember objectClass: group objectClass: uidObject uid: GroupFive distinguishedName: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org
例6.2 LDIF の例: グループからプリンシパル
TestUserOne
は GroupOne
のメンバーで、 GroupOne
は GroupFive
のメンバーですが、相互参照にはグループからユーザーへ属性 uniqueMember
が使用されます。
dn: uid=TestUserOne,ou=users,dc=group-to-principal,dc=example,dc=org objectClass: top objectClass: inetOrgPerson objectClass: uidObject objectClass: person objectClass: organizationalPerson cn: Test User One sn: Test User One uid: TestUserOne userPassword:: e1NTSEF9SjR0OTRDR1ltaHc1VVZQOEJvbXhUYjl1dkFVd1lQTmRLSEdzaWc9PQ== dn: uid=GroupOne,ou=groups,dc=group-to-principal,dc=example,dc=org objectClass: top objectClass: groupOfUniqueNames objectClass: uidObject cn: Group One uid: GroupOne uniqueMember: uid=TestUserOne,ou=users,dc=group-to-principal,dc=example,dc=org dn: uid=GroupFive,ou=subgroups,ou=groups,dc=group-to-principal,dc=example,dc=org objectClass: top objectClass: groupOfUniqueNames objectClass: uidObject cn: Group Five uid: GroupFive uniqueMember: uid=TestUserFive,ou=users,dc=group-to-principal,dc=example,dc=org uniqueMember: uid=GroupOne,ou=groups,dc=group-to-principal,dc=example,dc=org
一般的なグループ検索
<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
属性です。
<authorization> <ldap connection="LocalLdap"> <username-to-dn> <username-filter base-dn="ou=users,dc=principal-to-group,dc=example,dc=org" recursive="false" attribute="uid" user-dn-attribute="dn" /> </username-to-dn> <group-search group-name="SIMPLE" iterative="true" group-dn-attribute="dn" group-name-attribute="uid"> <principal-to-group group-attribute="memberOf" /> </group-search> </ldap> </authorization>
principal-to-group
要素が単一の属性で追加されていることです。
group-attribute
: ユーザーがメンバーであるグループの識別名と一致する、ユーザーエントリー上の属性名。デフォルトはmemberOf
です。
例6.4 グループからプリンシパルへの設定例
<authorization> <ldap connection="LocalLdap"> <username-to-dn> <username-filter base-dn="ou=users,dc=group-to-principal,dc=example,dc=org" recursive="false" attribute="uid" user-dn-attribute="dn" /> </username-to-dn> <group-search group-name="SIMPLE" iterative="true" group-dn-attribute="dn" group-name-attribute="uid"> <group-to-principal base-dn="ou=groups,dc=group-to-principal,dc=example,dc=org" recursive="true" search-by="DISTINGUISHED_NAME"> <membership-filter principal-attribute="uniqueMember" /> </group-to-principal> </group-search> </ldap> </authorization>
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
ロールのユーザーのみです。
- 管理コンソールへログインします。
- Administration タブをクリックします。
- Access Control メニューを展開し、Role Assignment を選択します。
- ROLES タブを選択し、そのタブ内にある Scoped Roles タブを選択します。
手順6.22 新しいスコープ指定ロールの追加
- 管理コンソールへログインします。
- Roles タブの Scoped Roles エリアに移動します。
- Add をクリックします。Add Scoped Role ダイアログが表示されます。
- 次の詳細を指定します。
- Name: 新しいスコープ指定ロールの一意名。
- Base Role: このロールのパーミッションがベースとなるロール。
- Type: このロールがホストまたはサーバーグループに制限されるかどうか。
- Scope: ロールが制限されるホストまたはサーバーグループのリスト。複数のエントリーを選択できます。
- Include All: このロールにすべてのユーザーが自動的に含まれるかどうか。デフォルトは no です。
- Save ボタンをクリックすると、ダイアログが閉じられ、新規作成されたロールがテーブルに表示されます。
手順6.23 スコープ指定ロールの編集
- 管理コンソールへログインします。
- Roles タブの Scoped Roles エリアに移動します。
- テーブル上で編集するスコープ指定ロールをクリックします。ロールの詳細がテーブルの下の Selection パネルに表示されます。
- Selection パネルの Edit をクリックします。Selection パネルが編集モードになります。
- 変更する必要がある詳細を変更し、Save ボタンをクリックします。Selection パネルが以前の状態に戻ります。Selection パネルとテーブルの両方に、新たに更新された詳細が表示されます。
手順6.24 スコープ指定ロールメンバーの表示
- 管理コンソールへログインします。
- Roles タブの Scoped Roles エリアに移動します。
- テーブル上で、Members を表示したいスコープ指定ロールをクリックし、Members をクリックします。Members of role ダイアログが表示されます。このダイアログには、ロールに含まれるまたは除外されるユーザーとグループが表示されます。
- 情報を確認した後、Done ボタンをクリックします。
手順6.25 スコープ指定ロールの削除
重要
- 管理コンソールへログインします。
- Roles タブの Scoped Roles エリアに移動します。
- テーブル上で、削除するスコープ指定ロールを選択します。
- Remove ボタンをクリックします。Remove Scoped Role ダイアログが表示されます。
- Confirm ボタンをクリックします。ダイアログが閉じられ、ロールが削除されます。
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 読み取りシステムプロパティーを機密操作にする
[domain@localhost:9999 /] cd /core-service=management/access=authorization/constraint=sensitivity-classification/type=core/classification=system-property [domain@localhost:9999 classification=system-property] :write-attribute(name=configured-requires-read, value=true) { "outcome" => "success", "result" => undefined, "server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => {"outcome" => "success"}}, "server-two" => {"response" => {"outcome" => "success"}} }}}} } [domain@localhost:9999 classification=system-property] :read-resource { "outcome" => "success", "result" => { "configured-requires-addressable" => undefined, "configured-requires-read" => true, "configured-requires-write" => undefined, "default-requires-addressable" => false, "default-requires-read" => false, "default-requires-write" => true, "applies-to" => { "/host=master/system-property=*" => undefined, "/host=master/core-service=platform-mbean/type=runtime" => undefined, "/server-group=*/system-property=*" => undefined, "/host=master/server-config=*/system-property=*" => undefined, "/host=master" => undefined, "/system-property=*" => undefined, "/" => undefined } } } [domain@localhost:9999 classification=system-property]
表6.2 機密性制約の設定結果
値 | 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 アプリケーションリソースの分類を有効にする
[domain@localhost:9999 /] cd /core-service=management/access=authorization/constraint=application-classification/type=logging/classification=logging-profile [domain@localhost:9999 classification=logging-profile] :write-attribute(name=configured-application, value=true) { "outcome" => "success", "result" => undefined, "server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => {"outcome" => "success"}}, "server-two" => {"response" => {"outcome" => "success"}} }}}} } [domain@localhost:9999 classification=logging-profile] :read-resource { "outcome" => "success", "result" => { "configured-application" => true, "default-application" => false, "applies-to" => {"/profile=*/subsystem=logging/logging-profile=*" => undefined} } } [domain@localhost:9999 classification=logging-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 式への書き込みを非機密操作にする
[domain@localhost:9999 /] cd /core-service=management/access=authorization/constraint=vault-expression [domain@localhost:9999 constraint=vault-expression] :write-attribute(name=configured-requires-write, value=false) { "outcome" => "success", "result" => undefined, "server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => {"outcome" => "success"}}, "server-two" => {"response" => {"outcome" => "success"}} }}}} } [domain@localhost:9999 constraint=vault-expression] :read-resource { "outcome" => "success", "result" => { "configured-requires-read" => undefined, "configured-requires-write" => false, "default-requires-read" => true, "default-requires-write" => true } } [domain@localhost:9999 constraint=vault-expression]
表6.3 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
手順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
コマンドの入出力例$ keytool -genseckey -alias vault -storetype jceks -keyalg AES -keysize 128 -storepass vault22 -keypass vault22 -validity 730 -keystore
EAP_HOME/vault/
vault.keystore Enter keystore password: vault22 Re-enter new password:vault22 What is your first and last name? [Unknown]:Accounting Administrator
What is the name of your organizational unit? [Unknown]:AccountingServices
What is the name of your organization? [Unknown]:MyOrganization
What is the name of your City or Locality? [Unknown]:Raleigh
What is the name of your State or Province? [Unknown]:NC
What is the two-letter country code for this unit? [Unknown]:US
Is CN=Accounting Administrator, OU=AccountingServices, O=MyOrganization, L=Raleigh, ST=NC, C=US correct? [no]:yes
Enter key password for <vault> (RETURN if same as keystore password):
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 の初期化」を参照してください。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")])
スタンドアロンサーバー
/core-service=vault:add(vault-options=[("KEYSTORE_URL" => "PATH_TO_KEYSTORE"), ("KEYSTORE_PASSWORD" => "MASKED_PASSWORD"), ("KEYSTORE_ALIAS" => "ALIAS"), ("SALT" => "SALT"),("ITERATION_COUNT" => "ITERATION_COUNT"), ("ENC_FILE_DIR" => "ENC_FILE_DIR")])
仮の値を用いたコマンドの例は次のとおりです。/core-service=vault:add(vault-options=[("KEYSTORE_URL" => "/home/user/vault/vault.keystore"), ("KEYSTORE_PASSWORD" => "MASK-3y28rCZlcKR"), ("KEYSTORE_ALIAS" => "vault"), ("SALT" => "12438567"),("ITERATION_COUNT" => "50"), ("ENC_FILE_DIR" => "/home/user/vault/")])
パスワード vault を使用してマスキングされた文字列を復号化するよう JBoss 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")])
パスワード 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.
暗号化された文字列に関する情報を書き留めます。
メッセージは vault ブロック、属性名、共有キー、および設定で文字列を使用する場合のアドバイスを表示する標準出力を出力します。安全な場所にこの情報を書き留めておくようにしてください。出力例は次のとおりです。******************************************** Vault Block:ds_ExampleDS Attribute Name:password Configuration should be done as follows: VAULT::ds_ExampleDS::password::1 ********************************************
設定で暗号化された文字列を使用します。
プレーンテキストの文字列の代わりに、前の設定手順の文字列を使用します。以下は、上記の暗号化されたパスワードを使用するデータソースになります。... <subsystem xmlns="urn:jboss:domain:datasources:1.0"> <datasources> <datasource jndi-name="java:jboss/datasources/ExampleDS" enabled="true" use-java-context="true" pool-name="H2DS"> <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url> <driver>h2</driver> <pool></pool> <security> <user-name>sa</user-name> <password>${VAULT::ds_ExampleDS::password::1}</password> </security> </datasource> <drivers> <driver name="h2" module="com.h2database.h2"> <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class> </driver> </drivers> </datasources> </subsystem> ...
式が許可されるドメインまたはスタンドアロン設定ファイルであれば、どこでも暗号化された文字列を使用することができます。注記
特定のサブシステム内で式が許可されるかを確認するには、そのサブシステムに対して次の CLI コマンドを実行します。/host=master/core-service=management/security-realm=TestRealm:read-resource-description(recursive=true)
このコマンドの出力で、expressions-allowed
パラメーターの値を探します。値が true であればこのサブシステムの設定内で式を使用できます。文字列をキーストアに格納した後、次の構文を使用してクリアテキストの文字列を暗号化された文字列に置き換えます。${VAULT::VAULT_BLOCK::ATTRIBUTE_NAME::ENCRYPTED_VALUE}
実環境の値の例は次のとおりです。vault ブロックはds_ExampleDS
、属性はpassword
です。<password>${VAULT::ds_ExampleDS::password::1}</password>
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 のファイルパスでは、ディレクトリーの分離記号として /
ではなく \
が使用されることに注意してください。
[user@host bin]$ ./vault.sh ********************************** **** JBoss Vault ******** ********************************** Please enter a Digit:: 0: Start Interactive Session 1: Remove Interactive Session 2: Exit0
Starting an interactive session Enter directory to store encrypted files:/home/user/vault/
Enter Keystore URL:/home/user/vault/vault.keystore
Enter Keystore password:...
Enter Keystore password again:...
Values match Enter 8 character salt:12345678
Enter iteration count as a number (Eg: 44):25
Enter Keystore Alias:vault
Vault is initialized and ready for use Handshake with Vault complete Please enter a Digit:: 0: Store a password 1: Check whether password exists 2: Exit0
Task: Store a password Please enter attribute value:sa
Please enter attribute value again:sa
Values match Enter Vault Block:DS
Enter Attribute Name:thePass
Secured attribute value has been stored in vault. Please make note of the following: ******************************************** Vault Block:DS Attribute Name:thePass Configuration should be done as follows: VAULT::DS::thePass::1 ******************************************** Please enter a Digit:: 0: Store a password 1: Check whether password exists 2: Exit2
VAULT
で始まる行です。
例7.3 vault されたパスワードを使用するサーブレット
package vaulterror.web; import java.io.IOException; import java.io.Writer; import javax.annotation.Resource; import javax.annotation.sql.DataSourceDefinition; import javax.servlet.ServletException; import javax.servlet.annotation.WebServlet; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.sql.DataSource; /*@DataSourceDefinition( name = "java:jboss/datasources/LoginDS", user = "sa", password = "sa", className = "org.h2.jdbcx.JdbcDataSource", url = "jdbc:h2:tcp://localhost/mem:test" )*/ @DataSourceDefinition( name = "java:jboss/datasources/LoginDS", user = "sa", password = "VAULT::DS::thePass::1", className = "org.h2.jdbcx.JdbcDataSource", url = "jdbc:h2:tcp://localhost/mem:test" ) @WebServlet(name = "MyTestServlet", urlPatterns = { "/my/" }, loadOnStartup = 1) public class MyTestServlet extends HttpServlet { private static final long serialVersionUID = 1L; @Resource(lookup = "java:jboss/datasources/LoginDS") private DataSource ds; @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { Writer writer = resp.getWriter(); writer.write((ds != null) + ""); } }
第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
"outcome" => "success"
- 管理対象ドメインに参加するマスターでないホストの場合、ホスト名を
master
から一意の名前に変更する必要があります。この名前はスレーブ全体で一意となる必要があり、クラスターに対する識別のために使用されます。そのため、使用する名前を覚えておくようにしてください。- 以下の構文を使用して、JBoss EAP スレーブホストを起動します。
例:bin/domain.sh --host-config=HOST_SLAVE_XML_FILE_NAME
bin/domain.sh --host-config=host-slave01.xml
- 管理 CLI を起動します。
- 以下の構文を使用してホスト名を置き換えます。
例:/host=master:write-attribute(name="name",value=UNIQUE_HOST_SLAVE_NAME)
次の結果が表示されるはずです。/host=master:write-attribute(name="name",value="host-slave01")
"outcome" => "success"
これは、以下のようにhost-slave01.xml
ファイルの XML を変更します。<host name="host-slave01" xmlns="urn:jboss:domain:1.6">
- 管理対象ドメインに参加する必要がある新たに設定されたホストの場合は、
local
要素を削除し、ドメインコントローラーを示すhost
属性のremote
要素を追加する必要があります。この手順はスタンドアロンサーバーには適用されません。- 以下の構文を使用して、JBoss EAP スレーブホストを起動します。
例:bin/domain.sh --host-config=HOST_SLAVE_XML_FILE_NAME
bin/domain.sh --host-config=host-slave01.xml
- 管理 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=host-slave01/:write-remote-domain-controller(host="192.168.1.200",port=${jboss.domain.master.port:9999},security-realm="ManagementRealm")
"outcome" => "success"
これは、以下のようにhost-slave01.xml
ファイルの XML を変更します。<domain-controller> <remote host="192.168.1.200" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm"/> </domain-controller>
各スレーブサーバーの認証を設定します。
各スレーブサーバーでは、ドメインコントローラーまたはスタンドアロンマスターのManagementRealm
で作成されたユーザー名とパスワードが必要です。ドメインコントローラーまたはスタンドアロンマスターで、EAP_HOME/bin/add-user.sh
コマンドを実行します。同じユーザー名を持つユーザーをスレーブとしてManagementRealm
に追加します。このユーザーが外部 JBoss AS インスタンスに対して認証する必要があるかどうか尋ねられた場合は、yes
と回答します。パスワードchangeme
を使用した、slave1
という名前のスレーブに対するコマンドの入出力例は以下のとおりです。user:bin user$ ./add-user.sh What type of user do you wish to add? a) Management User (mgmt-users.properties) b) Application User (application-users.properties) (a):
a
Enter the details of the new user to add. Realm (ManagementRealm) : Username :slave1
Password :changeme
Re-enter Password :changeme
About to add user 'slave1' for realm 'ManagementRealm' Is this correct yes/no?yes
Added user 'slave1' to file '/home/user/jboss-eap-6.0/standalone/configuration/mgmt-users.properties' Added user 'slave1' to file '/home/user/jboss-eap-6.0/domain/configuration/mgmt-users.properties' Is this new user going to be used for one AS process to connect to another AS process e.g. slave domain controller? yes/no? yes To represent the user add the following to the server-identities definition <secret value="Y2hhbmdlbWU=" />add-user.sh
の出力から Base64 でエンコードされた<secret>
要素をコピーします。認証に Base64 でエンコードされたパスワード値を指定したい場合、add-user.sh
の出力の最終行より<secret>
要素値をコピーします。次の手順でこの値が必要になります。新しい認証を使用するようスレーブホストのセキュリティーレルムを変更します。
以下の方法の 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
"outcome" => "success"
ホストを設定し、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
"outcome" => "success"
注記
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
"outcome" => "success"
- システムプロパティーとしてパスワードを指定する場合、次の方法のいずれかを用いてホストを設定できます。
- 次の例のように、プレーンテキストのパスワードをコマンドライン引数として入力し、サーバーを起動します。
-Dserver.identity.password=changeme
注記
パスワードはプレーンテキストで入力する必要があります。ps -ef
コマンドを実行すると、このパスワードを確認できます。 - パスワードをプロパティーファイルに格納し、プロパティーファイルの URL をコマンドライン引数として渡します。
- キーと値のペアをプロパティーファイルに追加します。例は次のとおりです。
server.identity.password=changeme
- コマンドライン引数を用いてサーバーを起動します。
--properties=URL_TO_PROPERTIES_FILE
.
サーバーを再起動します。
ホスト名をユーザー名として使用し、暗号化された文字列をパスワードとして使用してスレーブがマスターに対して認証されます。
スタンドアロンサーバーまたは管理対象ドメインのサーバーグループ内のサーバーが 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 へのサブスクライブ) にメールアドレスを入力します。
- 名前を入力し、パスワードを選択することも可能です。名前とパスワードの指定は任意ですが推奨されます。
- Subscribe (サブスクライブ) ボタンを押してサブスクリプションプロセスを開始します。
- メーリングリストのアーカイブは JBoss Watch Mailing List Archives で閲覧できます。
メールアドレスの確認後に、JBoss パッチメーリングリストへのサブスクライブが完了し、セキュリティー関連の通知を受け取るようになります。
9.4. zip 形式のパッチのインストール
9.4.1. パッチ管理システム
patch
コマンドを使用するか、管理コンソールを使用してアクセスできます。パッチ管理システムは、管理ドメイン全体で JBoss EAP 6 サーバーインスタンスを自動的にパッチを適用するために使用できませんが、管理ドメインの各サーバーインスタンスにはパッチを個別に適用できます。
重要
注記
patch
コマンドの引数とスイッチがリストされています。
表9.1 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
パッチを適用するときに競合が発生した場合、patch
ツールは警告を発します。コマンドを再実行して競合を解決する場合に利用可能なpatch
コマンドのスイッチについては、「パッチ管理システム」を参照してください。 - 以下のコマンドを実行して、パッチを適用するために JBoss EAP 6 サーバーを再起動します。
[standalone@localhost:9999 /]
shutdown --restart=true
手順9.3 管理コンソールを使用して zip パッチを JBoss EAP 6 サーバーインスタンスに適用する
- カスタマーポータル ( https://access.redhat.com/downloads/) からパッチ zip ファイルをダウンロードします。
- 管理コンソールで以下の操作を行います。
- スタンドアロンサーバーの場合: 画面の上部にある Runtime (ランタイム) タブをクリックし、次に Patch Management (パッチ管理) をクリックします。
- 管理ドメインの場合: 画面の上部にある Domain (ドメイン) タブをクリックし、Host (ホスト) ドロップダウンメニューからパッチを適用するホストを選択して、Patch Management (パッチ管理) をクリックします。
- Apply a New Patch (新規パッチの適用) をクリックします。
- 管理ドメインホストにパッチを適用する場合は、次の画面でホストのサーバーをシャットダウンするかどうかを選択し、Next (次へ) をクリックします。
- Browse (参照) ボタンをクリックし、適用するダウンロード済みパッチを選択して、Next (次へ) をクリックします。
- パッチを適用する場合に競合がある場合は、警告が表示されます。View error details (エラー詳細の表示) をクリックして競合の詳細を表示します。競合がある場合は、操作をキャンセルするか、Override all conflicts (すべての競合のオーバーライド) チェックボックスを選択します。競合をオーバーライドすると、すべてのユーザーの変更がパッチの内容によって上書きされます。
- パッチが正常に適用されたら、パッチを有効にするために JBoss EAP 6 サーバーを再起動するかどうかを選択し、Finish (完了) をクリックします。
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
パッチをロールバックするときに競合が発生した場合、patch
ツールは警告を発します。コマンドを再実行して競合を解決する場合に利用可能なpatch
コマンドのスイッチについては、「パッチ管理システム」を参照してください。 - パッチのロールバックを反映するために、JBoss EAP 6 サーバーを再起動します。
[standalone@localhost:9999 /]
shutdown --restart=true
手順9.5 管理コンソールを使用して JBoss EAP 6 サーバーインスタンスからパッチをロールバックする
- 管理コンソールで以下の操作を行います。
- スタンドアロンサーバーの場合: 画面の上部にある Runtime (ランタイム) タブをクリックし、次に Patch Management (パッチ管理) をクリックします。
- 管理ドメインの場合: 画面の上部にある Domain (ドメイン) タブをクリックし、Host (ホスト) ドロップダウンメニューから該当するホストを選択して、Patch Management (パッチ管理) をクリックします。
- Recent Patch History (最近のパッチ履歴) テーブルで、ロールバックするパッチを選択し、Rollback (ロールバック) をクリックします。
- 管理ドメインホストの場合は、次の画面でホストのサーバーをシャットダウンするかどうかを選択し、Next (次へ) をクリックします。
- ロールバックプロセスのオプションを選択し、Next (次へ) をクリックします。
- オプションとロールバックするパッチを確認し、Next (次へ) をクリックします。
- Override all (すべてのオーバーライド) オプションが選択されておらず、パッチをロールバックするときに競合がある場合は、警告が表示されます。View error details (エラー詳細の表示) をクリックして競合の詳細を表示します。競合がある場合は、操作をキャンセルするか、Choose Options (オプションの選択) をクリックし、Override all (すべてのオーバーライド) チェックボックスを選択した状態で操作を再試行します。競合をオーバーライドすると、すべてのユーザーの変更がロールバック操作によって上書きされます。
- パッチが正常にロールバックされたら、変更を反映するために JBoss EAP 6 サーバーを今すぐ再起動するかどうかを選択し、Finish (完了) をクリックします。
パッチ (およびオプションでサーバー設定ファイル) は、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
重要
RPM インストールを更新する場合、JBoss 製品は RPM でリリースされた修正で累積的に更新されます。
RPM 形式を使用して JBoss 製品に最新の更新が適用されます。
9.6. JBoss セキュリティーパッチの深刻度および影響度
表9.2 JBoss セキュリティーパッチの深刻度
深刻度 | 説明 |
---|---|
Critical (重大) |
非認証のリモート攻撃者が簡単に悪用でき、ユーザーとやりとりしなくてもシステムが危険にさらされる (任意コード実行) 欠陥にこの深刻度が適用されます。ワームによって悪用される脆弱性になります。認証されたリモートユーザー、ローカルユーザー、または想定外の設定を必要とする欠陥は重大な欠陥とは分類されません。
|
Important (高) |
リソースの機密性、整合性、または可用性が簡単に危険にさらされる欠陥にこの深刻度が付けられます。ローカルユーザーが権限を取得できる場合、非認証のリモートユーザーが認証によって保護されるリソースを閲覧できる場合、認証されたリモートユーザーが任意コードを実行できる場合、あるいはサービス拒否がローカルまたはリモートユーザーによって引き起こされる場合、この脆弱性タイプになります。
|
Moderate (中) |
悪用するのは比較的困難であっても、リソースの機密性、整合性、または可用性が一部危険にさらされる原因となる欠陥にこの深刻度が付けられます。重大または重要な影響を与える可能性はあっても、欠陥の技術評価を基にするとそれほど簡単には悪用できなかったり、想定外の設定に影響しない脆弱性のタイプになります。
|
Low (低) |
セキュリティーに影響する問題で、前述の深刻度に該当しないものにこの深刻度が適用されます。想定外の状況でのみ悪用される可能性があるとみられる脆弱性や、悪用されても影響が最小限にとどまる脆弱性のタイプになります。
|
例9.1 CVSS v2 の影響スコア
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 記述子の一部
<!-- A sample ejb-jar.xml fragment --> <ejb-jar> <enterprise-beans> <session> <ejb-name>ASessionBean</ejb-name> ... <security-role-ref> <role-name>TheRoleICheck<role-name> <role-link>TheApplicationRole</role-link> </security-role-ref> </session> </enterprise-beans> ... </ejb-jar>
注記
例10.2 web.xml 記述子の一部
<web-app> <servlet> <servlet-name>AServlet</servlet-name> ... <security-role-ref> <role-name>TheServletRole</role-name> <role-link>TheApplicationRole</role-link> </security-role-ref> </servlet> ... </web-app>
10.2.3. セキュリティーアイデンティティー (ID)

図10.2 Java EE セキュリティーアイデンティティーデータモデル
EJBContext.getCallerPrincipal()
メソッドのように呼び出し元の ID が変更されないことに注意してください。呼び出し元のセキュリティーロールは、<run-as> または <role-name> 要素値によって指定された単一のロールに設定されます。
<ejb-jar> <enterprise-beans> <session> <ejb-name>ASessionBean</ejb-name> <!-- ... --> <security-identity> <use-caller-identity/> </security-identity> </session> <session> <ejb-name>RunAsBean</ejb-name> <!-- ... --> <security-identity> <run-as> <description>A private internal role</description> <role-name>InternalRole</role-name> </run-as> </security-identity> </session> </enterprise-beans> <!-- ... --> </ejb-jar>
anonymous
という名前のプリンシパルがすべての発信呼び出しへ割り当てられます。別のプリンシパルを呼び出しに関連付けるには、<run-as-principal> を jboss-ejb3.xml
ファイルの Bean に関連付けます。以下は、internal
という名前のプリンシパルを前例の RunAsBean
に関連付けます。
<session> <ejb-name>RunAsBean</ejb-name> <security-identity> <run-as-principal>internal</run-as-principal> </security-identity> </session>
web.xml
ファイルのサーブレット定義にもあります。以下の例は、InternalRole
ロールをサーブレットに割り当てる方法を示しています。
<servlet> <servlet-name>AServlet</servlet-name> <!-- ... --> <run-as> <role-name>InternalRole</role-name> </run-as> </servlet>
principal
に関連付けられます。run-as
ロールに従う特定のプリンシパルを割り当てるため、<run-as-principal> 要素は jboss-web.xml
ファイルにあります。以下は、internal
という名前のプリンシパルを上記のサーブレットに関連付ける方法を示しています。
<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 記述子の一部
<!-- A sample ejb-jar.xml fragment --> <ejb-jar> <assembly-descriptor> <security-role> <description>The single application role</description> <role-name>TheApplicationRole</role-name> </security-role> </assembly-descriptor> </ejb-jar>
例10.4 security-role 要素の使用を示す web.xml 記述子の例 (一部)
<!-- A sample web.xml fragment --> <web-app> <security-role> <description>The single application role</description> <role-name>TheApplicationRole</role-name> </security-role> </web-app>
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</method-name> </method>
<method> <ejb-name>EJBNAME</ejb-name> <method-name>METHOD</method-name> <method-params> <method-param>PARAMETER_1</method-param> <!-- ... --> <method-param>PARAMETER_N</method-param> </method-params> </method>
method-intf
要素は、エンタープライズ Bean のホームおよびリモートインターフェースの両方に定義された同じ名前やシグネチャーを持つメソッドを区別するために使用されます。
method-permission
要素の完全な使用例は、例10.5「method-permission 要素の使用を説明する ejb-jar.xml 記述子の一部」 を参照してください。
例10.5 method-permission 要素の使用を説明する ejb-jar.xml 記述子の一部
<ejb-jar> <assembly-descriptor> <method-permission> <description>The employee and temp-employee roles may access any method of the EmployeeService bean </description> <role-name>employee</role-name> <role-name>temp-employee</role-name> <method> <ejb-name>EmployeeService</ejb-name> <method-name>*</method-name> </method> </method-permission> <method-permission> <description>The employee role may access the findByPrimaryKey, getEmployeeInfo, and the updateEmployeeInfo(String) method of the AardvarkPayroll bean </description> <role-name>employee</role-name> <method> <ejb-name>AardvarkPayroll</ejb-name> <method-name>findByPrimaryKey</method-name> </method> <method> <ejb-name>AardvarkPayroll</ejb-name> <method-name>getEmployeeInfo</method-name> </method> <method> <ejb-name>AardvarkPayroll</ejb-name> <method-name>updateEmployeeInfo</method-name> <method-params> <method-param>java.lang.String</method-param> </method-params> </method> </method-permission> <method-permission> <description>The admin role may access any method of the EmployeeServiceAdmin bean </description> <role-name>admin</role-name> <method> <ejb-name>EmployeeServiceAdmin</ejb-name> <method-name>*</method-name> </method> </method-permission> <method-permission> <description>Any authenticated user may access any method of the EmployeeServiceHelp bean</description> <unchecked/> <method> <ejb-name>EmployeeServiceHelp</ejb-name> <method-name>*</method-name> </method> </method-permission> <exclude-list> <description>No fireTheCTO methods of the EmployeeFiring bean may be used in this deployment</description> <method> <ejb-name>EmployeeFiring</ejb-name> <method-name>fireTheCTO</method-name> </method> </exclude-list> </assembly-descriptor> </ejb-jar>
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 記述子の一部
<web-app> <security-constraint> <web-resource-collection> <web-resource-name>Secure Content</web-resource-name> <url-pattern>/restricted/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>AuthorizedUser</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <!-- ... --> <login-config> <auth-method>BASIC</auth-method> <realm-name>The Restricted Zone</realm-name> </login-config> <!-- ... --> <security-role> <description>The role required to access restricted content </description> <role-name>AuthorizedUser</role-name> </security-role> </web-app>
10.2.8. フォームベース認証の有効化
web.xml
の <login-config> 要素に <auth-method>FORM</auth-method>
が含まれるようにします。ログインおよびエラーページも、以下のように <login-config> に定義されます。
<login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/login.html</form-login-page> <form-error-page>/error.html</form-error-page> </form-login-config> </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 セキュリティードメインの例
<security-domain name="DsRealm" cache-type="default"> <authentication> <login-module code="ConfiguredIdentity" flag="required"> <module-option name="userName" value="sa"/> <module-option name="principal" value="sa"/> <module-option name="password" value="sa"/> </login-module> </authentication> </security-domain>
<datasources> <datasource jndi-name="java:jboss/datasources/securityDs" pool-name="securityDs"> <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url> <driver>h2</driver> <new-connection-sql>select current_user()</new-connection-sql> <security> <security-domain>DsRealm</security-domain> </security> </datasource> </datasources>
例11.2 パスワード vault の例
<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>
要素の宣言を指定しない場合、この挙動がデフォルトになります。
<ejb-jar> <enterprise-beans> <session> <ejb-name>ASessionBean</ejb-name> <!-- ... --> <security-identity> <use-caller-identity/> </security-identity> </session> <!-- ... --> </enterprise-beans> </ejb-jar>
例11.4 特定ロールに EJB のセキュリティーアイデンティティーを設定する
<security-identity>
タグの中に <run-as>
および <role-name>
タグを使用します。
<ejb-jar> <enterprise-beans> <session> <ejb-name>RunAsBean</ejb-name> <!-- ... --> <security-identity> <run-as> <description>A private internal role</description> <role-name>InternalRole</role-name> </run-as> </security-identity> </session> </enterprise-beans> <!-- ... --> </ejb-jar>
<run-as>
を使用すると anonymous
という名前のプリンシパルが発信呼び出しへ割り当てられます。違うプリンシパルを割り当てる場合は <run-as-principle>
を使用します。
<session> <ejb-name>RunAsBean</ejb-name> <security-identity> <run-as-principal>internal</run-as-principal> </security-identity> </session>
注記
<run-as>
要素と <run-as-principal>
要素を使用することもできます。
以下も参照してください。
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 の全メソッドへのアクセスできるようにする
<method-permission> <description>The employee and temp-employee roles may access any method of the EmployeeService bean </description> <role-name>employee</role-name> <role-name>temp-employee</role-name> <method> <ejb-name>EmployeeService</ejb-name> <method-name>*</method-name> </method> </method-permission>
例11.6 EJB の特定メソッドへのみロールがアクセスできるようにし、パラメーターが渡すことができるメソッドを制限する
<method-permission> <description>The employee role may access the findByPrimaryKey, getEmployeeInfo, and the updateEmployeeInfo(String) method of the AcmePayroll bean </description> <role-name>employee</role-name> <method> <ejb-name>AcmePayroll</ejb-name> <method-name>findByPrimaryKey</method-name> </method> <method> <ejb-name>AcmePayroll</ejb-name> <method-name>getEmployeeInfo</method-name> </method> <method> <ejb-name>AcmePayroll</ejb-name> <method-name>updateEmployeeInfo</method-name> <method-params> <method-param>java.lang.String</method-param> </method-params> </method> </method-permission>
例11.7 認証された全ユーザーが EJB のメソッドにアクセスできるようにする
<unchecked/>
要素を使用すると、認証された全ユーザーが指定のメソッドを使用できます。
<method-permission> <description>Any authenticated user may access any method of the EmployeeServiceHelp bean</description> <unchecked/> <method> <ejb-name>EmployeeServiceHelp</ejb-name> <method-name>*</method-name> </method> </method-permission>
例11.8 特定の EJB メソッドを完全に除外して使用されないようにする
<exclude-list> <description>No fireTheCTO methods of the EmployeeFiring bean may be used in this deployment</description> <method> <ejb-name>EmployeeFiring</ejb-name> <method-name>fireTheCTO</method-name> </method> </exclude-list>
例11.9 複数の <method-permission>
ブロックが含まれる完全な <assembly-descriptor>
<ejb-jar> <assembly-descriptor> <method-permission> <description>The employee and temp-employee roles may access any method of the EmployeeService bean </description> <role-name>employee</role-name> <role-name>temp-employee</role-name> <method> <ejb-name>EmployeeService</ejb-name> <method-name>*</method-name> </method> </method-permission> <method-permission> <description>The employee role may access the findByPrimaryKey, getEmployeeInfo, and the updateEmployeeInfo(String) method of the AcmePayroll bean </description> <role-name>employee</role-name> <method> <ejb-name>AcmePayroll</ejb-name> <method-name>findByPrimaryKey</method-name> </method> <method> <ejb-name>AcmePayroll</ejb-name> <method-name>getEmployeeInfo</method-name> </method> <method> <ejb-name>AcmePayroll</ejb-name> <method-name>updateEmployeeInfo</method-name> <method-params> <method-param>java.lang.String</method-param> </method-params> </method> </method-permission> <method-permission> <description>The admin role may access any method of the EmployeeServiceAdmin bean </description> <role-name>admin</role-name> <method> <ejb-name>EmployeeServiceAdmin</ejb-name> <method-name>*</method-name> </method> </method-permission> <method-permission> <description>Any authenticated user may access any method of the EmployeeServiceHelp bean</description> <unchecked/> <method> <ejb-name>EmployeeServiceHelp</ejb-name> <method-name>*</method-name> </method> </method-permission> <exclude-list> <description>No fireTheCTO methods of the EmployeeFiring bean may be used in this deployment</description> <method> <ejb-name>EmployeeFiring</ejb-name> <method-name>fireTheCTO</method-name> </method> </exclude-list> </assembly-descriptor> </ejb-jar>
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 セキュリティーアノテーションの例
@Stateless @RolesAllowed({"admin"}) @SecurityDomain("other") public class WelcomeEJB implements Welcome { @PermitAll public String WelcomeEveryone(String msg) { return "Welcome to " + msg; } @RunAs("tempemployee") public String GoodBye(String msg) { return "Goodbye, " + msg; } public String GoodbyeAdmin(String msg) { return "See you later, " + msg; } }
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
インターフェースです。<interfaces> <interface name="management"/> <interface name="public"/> <interface name="unsecure"/> </interfaces>
unsecure
インターフェースのホストごとの定義はdomain.xml
またはstandalone.xml
と同じディレクトリーにあるhost.xml
で定義されます。また、このインターフェースは複数の他のサブシステムによっても使用されます。変更する場合は十分注意してください。<interfaces> <interface name="management"> <inet-address value="${jboss.bind.address.management:127.0.0.1}"/> </interface> <interface name="public"> <inet-address value="${jboss.bind.address:127.0.0.1}"/> </interface> <interface name="unsecure"> <!-- Used for IIOP sockets in the standard configuration. To secure JacORB you need to setup SSL --> <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/> </interface> </interfaces>
- socket-binding
remoting
サブシステムによって使用されるデフォルトの socket-binding は TCP ポート 4777 へバインドします。この設定を変更する必要がある場合はソケットバインディングとソケットバインディンググループに関するドキュメントを参照してください。- EJB の リモーティングコネクター参照
- EJB サブシステムにはリモートメソッド呼び出しに対するリモーティングコネクターへの参照が含まれています。デフォルト設定は次のとおりです。
<remote connector-ref="remoting-connector" thread-pool-name="default"/>
- セキュアなトランスポート設定
- Remoting はクライアントの要求があれば StartTLS を使用して安全な接続 (HTTPS、Secure Servlet など) を使用します。安全な接続と安全でない接続の両方で同じソケットバインディング (ネットワークポート) が使用されるため、サーバー側に追加の設定をする必要はありません。クライアントは必要に応じて安全なトランスポートまたは安全でないトランスポートを要求します。EJB、ORB、JMS プロバイダーなどの Remoting を使用する JBoss EAP のコンポーネントはデフォルトで安全なインターフェースを使用します。
警告
ワーカースレッドプールは、Remoting コネクターからの作業を処理できるスレッドのグループのことです。単一の要素 <worker-thread-pool>
で、複数の属性を取ります。ネットワークタイムアウトやスレッド不足が発生したり、メモリーの使用を制限する場合にこれらの属性を調節します。特定の推奨設定は状況によって異なります。詳細は Red Hat グローバルサポートサービスまでご連絡ください。
表11.1 ワーカースレッドプールの属性
属性 | 説明 | CLI コマンド |
---|---|---|
read-threads |
リモーティングワーカーに対して作成する読み取りスレッドの数。デフォルトは
1 です。
| /profile=default/subsystem=remoting/:write-attribute(name=worker-read-threads,value=1)
|
write-threads |
リモーティングワーカーに対して作成する書き込みスレッドの数。デフォルトは
1 です。
| /profile=default/subsystem=remoting/:write-attribute(name=worker-write-threads,value=1)
|
task-keepalive |
コアでないリモーティングワーカーのタスクスレッドを生存させておく期間 (ミリ秒単位) です。デフォルトは
60 です。
| /profile=default/subsystem=remoting/:write-attribute(name=worker-task-keepalive,value=60)
|
task-max-threads |
リモーティングワーカーのタスクスレッドプールに対するスレッドの最大数です。デフォルトは
16 です。
| /profile=default/subsystem=remoting/:write-attribute(name=worker-task-max-threads,value=16)
|
task-core-threads |
リモーティングワーカーのタスクスレッドプールに対するコアスレッドの数です。デフォルトは
4 です。
| /profile=default/subsystem=remoting/:write-attribute(name=worker-task-core-threads,value=4)
|
task-limit |
拒否する前に許可されるリモーティングワーカータスクの最大数です。デフォルトは
16384 です。
| /profile=default/subsystem=remoting/:write-attribute(name=worker-task-limit,value=16384)
|
コネクターは主な Remoting 設定要素です。複数のコネクターを設定できます。各コネクターは、サブ要素を持つ <connector>
要素より構成され、複数の属性が含まれることもあります。デフォルトのコネクターは JBoss EAP 6 の複数のサブシステムによって使用されます。カスタムコネクターの要素や属性の設定はアプリケーションによって異なるため、詳細は Red Hat グローバルサポートサービスまでご連絡ください。
表11.2 コネクターの属性
属性 | 説明 | 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)
|
表11.3 コネクター要素
属性 | 説明 | CLI コマンド |
---|---|---|
sasl |
SASL (Simple Authentication and Security Layer) 認証メカニズムのエンクロージング要素です。
| N/A
|
properties |
1 つ以上の
<property> 要素が含まれ、各要素には name 属性と任意の value 属性が含まれます。
| /profile=default/subsystem=remoting/connector=remoting-connector/property=myProp/:add(value=myPropValue)
|
3 つのタイプの送信接続を指定することができます。
- URI への送信接続
- ローカルの送信接続 – ソケットなどのローカルリソースへ接続します。
- リモートの送信接続 – リモートリソースへ接続し、セキュリティーレルムを使用して認証を行います。
<outbound-connections>
要素で囲まれます。各接続タイプは outbound-socket-binding-ref
属性を取ります。送信接続は uri
属性を取ります。リモートの送信接続は任意の username
属性と security-realm
属性を取り、認証に使用します。
表11.4 送信接続要素
属性 | 説明 | CLI コマンド |
---|---|---|
outbound-connection | 汎用の送信接続。 | /profile=default/subsystem=remoting/outbound-connection=my-connection/:add(uri=http://my-connection)
|
local-outbound-connection | 暗黙の local:// URI スキームを持つ送信接続。 | /profile=default/subsystem=remoting/local-outbound-connection=my-connection/:add(outbound-socket-binding-ref=remoting2)
|
remote-outbound-connection |
セキュリティーレルムを用いた基本またはダイジェスト認証を使用する remote:// URI スキームの送信接続です。
| /profile=default/subsystem=remoting/remote-outbound-connection=my-connection/:add(outbound-socket-binding-ref=remoting,username=myUser,security-realm=ApplicationRealm)
|
SASL 子要素を定義する前に初期 SASL 要素を作成する必要があります。次のコマンドを使用します。
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:add
属性 | 説明 | CLI コマンド |
---|---|---|
include-mechanisms |
SASL メカニズムのスペース区切りのリストである
value 属性が含まれています。
|
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=include-mechanisms,value=["DIGEST","PLAIN","GSSAPI"]) |
qop |
SASL の保護品質 (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"> <worker-thread-pool read-threads="1" task-keepalive="60" task-max-threads="16" task-core-thread="4" task-limit="16384" write-threads="1" /> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"> <sasl> <include-mechanisms value="GSSAPI PLAIN DIGEST-MD5" /> <qop value="auth" /> <strength value="medium" /> <reuse-session value="false" /> <server-auth value="false" /> <policy> <forward-secrecy value="true" /> <no-active value="false" /> <no-anonymous value="false" /> <no-dictionary value="true" /> <no-plain-text value="false" /> <pass-credentials value="true" /> </policy> <properties> <property name="myprop1" value="1" /> <property name="myprop2" value="2" /> </properties> </sasl> <authentication-provider name="myprovider" /> <properties> <property name="myprop3" value="propValue" /> </properties> </connector> <outbound-connections> <outbound-connection name="my-outbound-connection" uri="http://myhost:7777/"/> <remote-outbound-connection name="my-remote-connection" outbound-socket-binding-ref="my-remote-socket" username="myUser" security-realm="ApplicationRealm"/> <local-outbound-connection name="myLocalConnection" outbound-socket-binding-ref="my-outbound-socket"/> </outbound-connections> </subsystem>
文書化されていない設定内容
- JIDI および マルチキャスト自動検出
11.2.4.5. リモート EJB クライアントを用いたセキュリティーレルムの使用
- 新しいセキュリティーレルムをドメインコントローラーかスタンドアロンサーバーに追加します。
- 次のパラメーターをアプリケーションのクラスパスにある
jboss-ejb-client.properties
ファイルに追加します。この例では、ファイルの他のパラメーターは接続をdefault
としてみなすことを前提とします。remote.connection.default.username=appuser remote.connection.default.password=apppassword
- 新しいセキュリティーレルムを使用するドメインまたはスタンドアロンサーバー上にカスタム 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()
スタンドアロンインスタンスでは以下のコマンドを使用します。/core-service=management/security-realm=MyDomainRealm:add()
新しいロールの情報を保存するプロパティーファイルへの参照を作成します。
次のコマンドを実行し、新しいロールに関連するプロパティーが含まれるmyfile.properties
という名前のファイルのポインターを作成します。注記
新たに作成されたプロパティーファイルは、含まれるadd-user.sh
およびadd-user.bat
スクリプトによって管理されません。そのため、外部で管理する必要があります。ドメインインスタンスでは以下コマンドを使用します。/host=master/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
スタンドアロンインスタンスでは以下のコマンドを使用します。/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
新しいセキュリティーレルムが作成されます。新たに作成されたこのレルムにユーザーやロールを追加すると、デフォルトのセキュリティーレルムとは別のファイルに情報が保存されます。新規ファイルはご使用のアプリケーションやプロシージャーを使用して管理できます。
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>
- <security-role> タグを使用して RESTEasy JAX-RS WAR ファイル内で使用されるすべてのロールを宣言します。
<security-role> <role-name>ROLE_NAME</role-name> </security-role> <security-role> <role-name>ROLE_NAME</role-name> </security-role>
- すべてのロールに対して JAX-RS ランタイムが対応する全 URL へのアクセスを承認します。
<security-constraint> <web-resource-collection> <web-resource-name>Resteasy</web-resource-name> <url-pattern>/PATH</url-pattern> </web-resource-collection> <auth-constraint> <role-name>ROLE_NAME</role-name> <role-name>ROLE_NAME</role-name> </auth-constraint> </security-constraint>
ロールベースセキュリティーが定義されたロールのセットによりアプリケーション内で有効になります。
例11.12 ロールベースセキュリティーの設定例
<web-app> <context-param> <param-name>resteasy.role.based.security</param-name> <param-value>true</param-value> </context-param> <servlet-mapping> <servlet-name>Resteasy</servlet-name> <url-pattern>/*</url-pattern> </servlet-mapping> <security-constraint> <web-resource-collection> <web-resource-name>Resteasy</web-resource-name> <url-pattern>/security</url-pattern> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> <role-name>user</role-name> </auth-constraint> </security-constraint> <security-role> <role-name>admin</role-name> </security-role> <security-role> <role-name>user</role-name> </security-role> </web-app>
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 セキュリティーサブシステムの設定例
<subsystem xmlns="urn:jboss:domain:security:1.2"> <security-management> ... </security-management> <security-domains> <security-domain name="other" cache-type="default"> <authentication> <login-module code="Remoting" flag="optional"> <module-option name="password-stacking" value="useFirstPass"/> </login-module> <login-module code="RealmUsersRoles" flag="required"> <module-option name="usersProperties" value="${jboss.domain.config.dir}/application-users.properties"/> <module-option name="rolesProperties" value="${jboss.domain.config.dir}/application-roles.properties"/> <module-option name="realm" value="ApplicationRealm"/> <module-option name="password-stacking" value="useFirstPass"/> </login-module> </authentication> </security-domain> <security-domain name="jboss-web-policy" cache-type="default"> <authorization> <policy-module code="Delegating" flag="required"/> </authorization> </security-domain> <security-domain name="jboss-ejb-policy" cache-type="default"> <authorization> <policy-module code="Delegating" flag="required"/> </authorization> </security-domain> </security-domains> <vault> ... </vault> </subsystem>
<security-management>
、 <subject-factory>
、および <security-properties>
要素はデフォルト設定では存在しません。<subject-factory>
および <security-properties>
要素は JBoss 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 モードを有効にします。
Edit をクリックします。Deep Copy Subjects の横にあるボックスにチェックを入れ、ディープコピーサブジェクトモードを有効にします。
管理 CLI を使用してこのオプションを有効にしたい場合、以下のコマンドの 1 つを使用します。
例12.2 管理対象ドメイン
/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)
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)
例12.5 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 セキュリティードメインの設定
<security-domains> <security-domain name="host" cache-type="default"> <authentication> <login-module code="Kerberos" flag="required"> <module-option name="storeKey" value="true"/> <module-option name="useKeyTab" value="true"/> <module-option name="principal" value="host/testserver@MY_REALM"/> <module-option name="keyTab" value="/home/username/service.keytab"/> <module-option name="doNotPrompt" value="true"/> <module-option name="debug" value="false"/> </login-module> </authentication> </security-domain> <security-domain name="SPNEGO" cache-type="default"> <authentication> <login-module code="SPNEGO" flag="requisite"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="serverSecurityDomain" value="host"/> </login-module> <!-- Login Module For Roles Search --> </security-domain>
システムプロパティーの設定
必要な場合は、システムプロパティーをドメインモデルに設定できます。例13.2 システムプロパティーの設定
<system-properties> <property name="java.security.krb5.kdc" value="mykdc.mydomain"/> <property name="java.security.krb5.realm" value="MY_REALM"/> </system-properties>
Web アプリケーションの設定
オーセンティケーターは上書きできませんが、NegotiationAuthenticator
をバルブとして jboss-web.xml 記述子に追加し、Web アプリケーションを設定できます。注記
セキュア化するリソースの決定に使用されるため、security-constraint
およびlogin-config
が web.xml ファイルに定義されている必要があります。しかし、選択されたauth-method
はこのオーセンティケーターによって上書きされます。例13.3 Web アプリケーションの設定
<!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 2.4//EN" "http://www.jboss.org/j2ee/dtd/jboss-web_4_0.dtd"> <jboss-web> <security-domain>SPNEGO</security-domain> <valve> <class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name> </valve> </jboss-web>
また、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.negotiation
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>
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
手順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
に追加します。<jboss-deployment-structure> <deployment> <!-- Add picketlink module dependency --> <dependencies> <module name="org.picketlink" /> <module name="org.jboss.security.negotiation" /> </dependencies> </deployment> </jboss-deployment-structure>
- 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
に変更します。<jboss-web> <security-domain>SPNEGO</security-domain> <context-root>idp</context-root> <valve> <class-name>org.picketlink.identity.federation.bindings.tomcat.idp.IDPWebBrowserSSOValve</class-name> <param> <param-name>passUserPrincipalToAttributeManager</param-name> <param-value>true</param-value> </param> </valve> <valve> <class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name> </valve> </jboss-web>
- Kerberos サーバー設定によってプリンシパルに追加されたセキュリティーロールを
$JBOSS_HOME/standalone/deployments/idp.war/WEB-INF/web.xml
に追加または変更します。 - 次のように、ファイル
$JBOSS_HOME/standalone/deployments/idp.war/WEB-INF/picketlink.xml
を変更します。<PicketLink xmlns="urn:picketlink:identity-federation:config:2.1"> <PicketLinkIDP xmlns="urn:picketlink:identity-federation:config:2.1"> <IdentityURL>${idp.url::http://localhost:8080/idp/}</IdentityURL> <Trust> <Domains>redhat.com,localhost,amazonaws.com</Domains> </Trust> </PicketLinkIDP> <Handlers xmlns="urn:picketlink:identity-federation:handler:config:2.1"> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2IssuerTrustHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2LogOutHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler" /> </Handlers> <!-- The configuration bellow defines a token timeout and a clock skew. Both configurations will be used during the SAML Assertion creation. This configuration is optional. It is defined only to show you how to set the token timeout and clock skew configuration. --> <PicketLinkSTS xmlns="urn:picketlink:identity-federation:config:1.0" TokenTimeout="5000" ClockSkew="0"> <TokenProviders> <TokenProvider ProviderClass="org.picketlink.identity.federation.core.saml.v1.providers.SAML11AssertionTokenProvider" TokenType="urn:oasis:names:tc:SAML:1.0:assertion" TokenElement="Assertion" TokenElementNS="urn:oasis:names:tc:SAML:1.0:assertion" /> <TokenProvider ProviderClass="org.picketlink.identity.federation.core.saml.v2.providers.SAML20AssertionTokenProvider" TokenType="urn:oasis:names:tc:SAML:2.0:assertion" TokenElement="Assertion" TokenElementNS="urn:oasis:names:tc:SAML:2.0:assertion" /> </TokenProviders> </PicketLinkSTS> </PicketLink>
IdentityURL
を変更し、IDP が実行されているサーバーのホスト名と同じになるようにします。Trust
を変更し、アイデンティティープロバイダーが信頼するドメイン名が含まれるようにします。employee.war
を変更します。Kerberos サーバー設定によってプリンシパルに追加されたセキュリティーロールを$JBOSS_HOME/standalone/deployments/employee.war/WEB-INF/web.xml
に追加または変更します。$JBOSS_HOME/standalone/configuration/standalone.xml
ファイルのsecurity domain
設定を編集します。ロールマッピング設定は、通常のセキュリティードメイン設定のものと同じです。<security-domain name="host" cache-type="default"> <authentication> <login-module code="Kerberos" flag="required"> <module-option name="principal" value="HTTP/something.com@yourdomain.COM"/> <module-option name="storeKey" value="true"/> <module-option name="useKeyTab" value="true"/> <module-option name="doNotPrompt" value="true"/> <module-option name="keyTab" value="/root/keytab"/> </login-module> </authentication> </security-domain> <security-domain name="SPNEGO" cache-type="default"> <authentication> <login-module code="SPNEGO" flag="required"> <module-option name="serverSecurityDomain" value="host"/> </login-module> </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>
注記
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>
手順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 サーバーの証明書、キーストア、およびトラストストアの作成
サーバーの証明書の作成
以下のコマンドを使用して、サーバーの証明書を作成します。keytool -genkey -alias server -keyalg RSA -keystore server.keystore -storepass change_it -validity 365
追加情報を入力するよう要求され、これらの値を入力する必要があります。証明書の CN 名は DNS サーバー名と同じでなければなりません。たとえば、ローカルホストの場合では以下のコマンドを使用できます。keytool -genkey -alias server -keystore server.keystore -storepass change_it -keypass password -dname "CN=localhost,OU=QE,O=example.com,L=Brno,C=CZ"
クライアント証明書の作成
SSL を介してリソースにアクセスするときに、この証明書を使用してサーバーに対して認証を行います。keytool -genkey -alias client -keystore client.keystore -storepass change_it -validity 365 -keyalg RSA -keysize 2048 -storetype pkcs12
トラストストアの作成
クライアントの証明書をエクスポートし、この証明書をインポートしてトラストストアを作成します。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
JBoss EAP 6.3 サーバーインストールの変更による SSL の有効化
以下のコネクターを Web サブシステムに追加して、SSL を有効にします。<connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" enable-lookups="false" secure="true"> <ssl name="localhost-ssl" key-alias="server" password="change_it" certificate-key-file="${jboss.server.config.dir}/server.keystore" protocol="TLSv1" verify-client="want" ca-certificate-file="${jboss.server.config.dir}/client.truststore"/> </connector>
サーバーの再起動
サーバーを再起動し、https://localhost:8443 で応答することを確認します。証明書の信用
サーバー証明書を信用するよう要求されます。
アプリケーションにアクセスする前に、client.keystore
をブラウザーにインポートする必要があります。このファイルにはクライアント証明書が含まれています。アプリケーションにアクセスすると、サーバーとの認証に使用する必要がある証明書を選択するよう要求されます。適切な証明書を選択します。
以下のセキュリティードメインをサーバーインストールに追加します。スタンドアロンモードを使用している場合は、JBOSS_HOME/standalone/configuration/standalone.xml
に追加する必要があります。
<security-domain name="idp" cache-type="default"> <authentication> <login-module code="CertificateRoles" flag="optional"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="securityDomain" value="idp"/> <module-option name="verifier" value="org.jboss.security.auth.certs.AnyCertVerifier"/> </login-module> <login-module code="org.picketlink.identity.federation.bindings.jboss.auth.RegExUserNameLoginModule" flag="optional"> <module-option name="regex" value="CN=(.*?),"/> </login-module> <login-module code="UsersRoles" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="usersProperties" value="users.properties"/> <module-option name="rolesProperties" value="roles.properties"/> </login-module> </authentication> <jsse keystore-password="change_it" keystore-url="${jboss.server.config.dir}" truststore-password="change_it" truststore-url="${jboss.server.config.dir}" client-auth="true"/> </security-domain>上記の設定例は、提供された証明書を検証します。証明書が提供されなかったり、認証に失敗したりした場合は、手順はユーザー/パスワードベースの認証にフォールバックします。
正規表現ユーザー名ログインモジュールを証明書ログインモジュールの後に使用すると、LDAP からロールを取得するためにプリンシパル名からユーザー名、UID、またはその他のフィールドを取得できます。このモジュールには、regex
というオプションがあります。このオプションはプリンシパル名に適用される正規表現を指定し、その結果は後続のログインモジュールへ渡されます。
UID=007, EMAILADDRESS=something@something, CN=James Bond, O=SpyAgency
というプリンシパル名が入力されると、結果として UID=007
が出力されます。
例13.5 正規表現ユーザー名ログインモジュールの例
<login-module code="org.picketlink.identity.federation.bindings.jboss.auth.RegExUserNameLoginModule" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="regex" value="UID=(.*?),"/> </login-module>
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 に記載されています。詳細については、そのドキュメントを参照してください。
フラグ 説明 required LoginModule は成功する必要があります。成功または失敗すると、LoginModule リストを下方向に進み認証が続行されます。requisite LoginModule は成功する必要があります。成功すると、LoginModule リストの下方向に進み認証が続行されます。失敗すると、即座に制御がアプリケーションに戻されます (LoginModule リストの下方向に進まず、認証が続行されません)。sufficient LoginModule は成功する必要はありません。成功した場合は、即座に制御がアプリケーションに戻されます (LoginModule リストの下方向に進まず、認証が続行されません)。失敗すると、LoginModule リストの下方向に進み認証が続行されます。optional LoginModule は成功する必要がありません。成功または失敗した場合、LoginModule リストの下方向に進み認証が続行されます。認証設定を編集します。
モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code または Flags を変更できます。Attributes タブが選択されていることを確認します。モジュールオプションを追加、編集、または削除します (任意)。
モジュールにオプションを追加する必要がある場合は、Login Modules リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add ボタンをクリックし、オプションのキーと値を指定します。Remove ボタンを使用してオプションを削除します。
認証モジュールが、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。
jboss.security.security_domain
モジュールのオプション
デフォルトでは、セキュリティードメインに定義された各ログインモジュールには jboss.security.security_domain
モジュールオプションが自動的に追加されます。既知のオプションのみが定義されるようチェックを行うログインモジュールでは、このオプションによって問題が発生します。このようなログインモジュールの 1 つが IBM Kerberos ログインモジュールの com.ibm.security.auth.module.Krb5LoginModule
です。
true
に設定します。以下を起動パラメーターに追加します。
-Djboss.security.disable.secdomain.option=true
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) {...}
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
クラスは認証サービスを表します。そのため、アプリケーション自体を変更しなくても、異なるログインモジュールをアプリケーションにプラグ可能です。次のコードは、アプリケーションがサブジェクトを認証するために必要となる手順を示しています。
CallbackHandler handler = new MyHandler(); LoginContext lc = new LoginContext("some-config", handler); try { lc.login(); Subject subject = lc.getSubject(); } catch(LoginException e) { System.out.println("authentication failed"); e.printStackTrace(); } // Perform work as authenticated Subject // ... // Scope of work complete, logout to remove authentication info try { lc.logout(); } catch(LoginException e) { System.out.println("logout failed"); e.printStackTrace(); } // A sample MyHandler class class MyHandler implements CallbackHandler { public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException { for (int i = 0; i < callbacks.length; i++) { if (callbacks[i] instanceof NameCallback) { NameCallback nc = (NameCallback)callbacks[i]; nc.setName(username); } else if (callbacks[i] instanceof PasswordCallback) { PasswordCallback pc = (PasswordCallback)callbacks[i]; pc.setPassword(password); } else { throw new UnsupportedCallbackException(callbacks[i], "Unrecognized Callback"); } } } }
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;
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
要素の構成
<authentication-jaspi> <login-module-stack name="..."> <login-module code="..." flag="..."> <module-option name="..." value="..."/> </login-module> </login-module-stack> <auth-module code="..." login-module-stack-ref="..."> <module-option name="..." value="..."/> </auth-module> </authentication-jaspi>
EAP_HOME/domain/configuration/domain.xml
または EAP_HOME/standalone/configuration/standalone.xml
へ直接追加する必要があります。
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 に記載されています。詳細については、そのドキュメントを参照してください。
フラグ 説明 required LoginModule は成功する必要があります。成功または失敗すると、LoginModule リストを下方向に進み承認が続行されます。requisite LoginModule は成功する必要があります。成功すると、LoginModule リストの下方向に進み承認が続行されます。失敗すると、即座に制御がアプリケーションに戻されます (LoginModule リストの下方向に進まず、承認が続行されません)。sufficient LoginModule は成功する必要はありません。成功した場合は、即座に制御がアプリケーションに戻されます (LoginModule リストの下方向に進まず、承認が続行されません)。失敗すると、LoginModule リストの下方向に進み承認が続行されます。optional LoginModule は成功する必要がありません。成功または失敗した場合、LoginModule リストを下方向に進み承認が続行されます。承認設定を編集します。
モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code または Flags を変更できます。Attributes タブが選択されていることを確認します。モジュールオプションを追加、編集、または削除します (任意)。
モジュールにオプションを追加する必要がある場合は、Policies リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add をクリックし、オプションのキーと値を指定します。Remove ボタンを使用してオプションを削除します。
承認ポリシーモジュールが、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。
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 で設定されます。
<security-domain name="jacc" cache-type="default"> <authentication> <login-module code="UsersRoles" flag="required"> </login-module> </authentication> <authorization> <policy-module code="JACC" flag="required"/> </authorization> </security-domain>
jboss-web.xml
は デプロイメントの WEB-INF/
ディレクトリーに存在し、Web コンテナに対する追加の JBoss 固有の設定を格納し、上書きします。JACC が有効になっているセキュリティードメインを使用するには、<security-domain>
要素が含まれるようにし、 さらに <use-jboss-authorization>
要素を true
に設定する必要があります。以下は、上記の JACC セキュリティードメインを使用するよう適切に設定されているアプリケーションになります。
<jboss-web> <security-domain>jacc</security-domain> <use-jboss-authorization>true</use-jboss-authorization> </jboss-web>
セキュリティードメインと JACC を使用するよう EJB を設定する方法は Web アプリケーションの場合とは異なります。EJB の場合、ejb-jar.xml
記述子にてメソッドまたはメソッドのグループ上でメソッドパーミッションを宣言できます。<ejb-jar>
要素内では、<method-permission>
要素のすべての子に JACC ロールに関する情報が含まれます。詳細は設定例を参照してください。EJBMethodPermission
クラスは Java Enterprise Edition 6 API の一部で、http://docs.oracle.com/javaee/6/api/javax/security/jacc/EJBMethodPermission.html で説明されています。
例13.7 EJB の JACC メソッドパーミッション例
<ejb-jar> <assembly-descriptor> <method-permission> <description>The employee and temp-employee roles may access any method of the EmployeeService bean </description> <role-name>employee</role-name> <role-name>temp-employee</role-name> <method> <ejb-name>EmployeeService</ejb-name> <method-name>*</method-name> </method> </method-permission> </assembly-descriptor> </ejb-jar>
<security>
子要素の jboss-ejb3.xml
記述子に宣言されます。セキュリティードメインの他に、EJB が実行されるプリンシパルを変更する run-as プリンシパル を指定することもできます。
例13.8 EJB におけるセキュリティードメイン宣言の例
<ejb-jar> <assembly-descriptor> <security> <ejb-name>*</ejb-name> <security-domain>myDomain</security-domain> <run-as-principal>myPrincipal</run-as-principal> </security> </assembly-descriptor> </ejb-jar>
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 (従業員)<PolicySet xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os" PolicySetId="RPS:employee:role" PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:permit-overrides"> <Target> <Subjects> <Subject> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">employee</AttributeValue> <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#anyURI"/> </SubjectMatch> </Subject> </Subjects> </Target> <!-- Use permissions associated with the employee role --> <PolicySetIdReference>PPS:employee:role</PolicySetIdReference> </PolicySet>
Manager (マネージャー)<PolicySet xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os" PolicySetId="RPS:manager:role" PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:permit-overrides"> <Target> <Subjects> <Subject> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">manager</AttributeValue> <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#anyURI"/> </SubjectMatch> </Subject> </Subjects> </Target> <!-- Use permissions associated with the manager role --> <PolicySetIdReference>PPS:manager:role</PolicySetIdReference> </PolicySet>
例13.10 PPS (パーミッションポリシーセット)
Employee (従業員)<PolicySet xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os" PolicySetId="PPS:employee:role" PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:permit-overrides"> <Target /> <!-- Permissions specifically for the employee role --> <Policy PolicyId="Permissions:specifically:for:the:employee:role" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides"> <Target /> <!-- Permission to create a purchase order --> <Rule RuleId="Permission:to:create:a:purchase:order" Effect="Permit"> <Target> <Resources> <Resource> <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">purchase order </AttributeValue> <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string" /> </ResourceMatch> </Resource> </Resources> <Actions> <Action> <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">create</AttributeValue> <ActionAttributeDesignator AttributeId="urn:action-id" DataType="http://www.w3.org/2001/XMLSchema#string" /> </ActionMatch> </Action> </Actions> </Target> </Rule> </Policy> <!-- HasPrivilegesOfRole Policy for employee role --> <Policy PolicyId="Permission:to:have:employee:role:permissions" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides"> <Target /> <!-- Permission to have employee role permissions --> <Rule RuleId="Permission:to:have:employee:permissions" Effect="Permit"> <Condition> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:and"> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:anyURI-is-in"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">employee</AttributeValue> <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#anyURI" /> </Apply> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:anyURI-is-in"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">urn:oasis:names:tc:xacml:2.0:actions:hasPrivilegesOfRole </AttributeValue> <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#anyURI" /> </Apply> </Apply> </Condition> </Rule> </Policy> </PolicySet>
Manager (マネージャー)<PolicySet xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os" PolicySetId="PPS:manager:role" PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:permit-overrides"> <Target /> <!-- Permissions specifically for the manager role --> <Policy PolicyId="Permissions:specifically:for:the:manager:role" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides"> <Target /> <!-- Permission to sign a purchase order --> <Rule RuleId="Permission:to:sign:a:purchase:order" Effect="Permit"> <Target> <Resources> <Resource> <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">purchase order </AttributeValue> <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string" /> </ResourceMatch> </Resource> </Resources> <Actions> <Action> <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">sign</AttributeValue> <ActionAttributeDesignator AttributeId="urn:action-id" DataType="http://www.w3.org/2001/XMLSchema#string" /> </ActionMatch> </Action> </Actions> </Target> </Rule> </Policy> <!-- HasPrivilegesOfRole Policy for manager role --> <Policy PolicyId="Permission:to:have:manager:role:permissions" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides"> <Target /> <!-- Permission to have manager role permissions --> <Rule RuleId="Permission:to:have:manager:permissions" Effect="Permit"> <Condition> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:and"> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:anyURI-is-in"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">manager</AttributeValue> <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#anyURI" /> </Apply> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:anyURI-is-in"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">urn:oasis:names:tc:xacml:2.0:actions:hasPrivilegesOfRole </AttributeValue> <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#anyURI" /> </Apply> </Apply> </Condition> </Rule> </Policy> <!-- Include permissions associated with employee role --> <PolicySetIdReference>PPS:employee:role</PolicySetIdReference> </PolicySet>
XACML エンジンに対して設定ファイルを作成します。
設定ファイルは、ロケーターを設定し、ポリシーが保存されるディレクトリーを示すために作成されます。例13.11 設定ファイル
ポリシーファイルのディレクトリーのみを示す設定ファイル<ns:jbosspdp xmlns:ns="urn:jboss:xacml:2.0"> <ns:Policies> <ns:PolicySet> <ns:Location>test/policies/rbac/</ns:Location> </ns:PolicySet> </ns:Policies> <ns:Locators> <ns:Locator Name="org.jboss.security.xacml.locators.JBossRBACPolicySetLocator"/> </ns:Locators> </ns:jbosspdp>
ポリシーセットを定義する設定ファイル<ns:jbosspdp xmlns:ns="urn:jboss:xacml:2.0"> <ns:Policies> <ns:PolicySet> <ns:Location>test/policies/rbac/employee-PPS-policyset.xml</ns:Location> </ns:PolicySet> <ns:PolicySet> <ns:Location>test/policies/rbac/manager-PPS-policyset.xml</ns:Location> </ns:PolicySet> <ns:PolicySet> <ns:Location>test/policies/rbac/employee-RPS-policyset.xml</ns:Location> </ns:PolicySet> <ns:PolicySet> <ns:Location>test/policies/rbac/manager-RPS-policyset.xml</ns:Location> </ns:PolicySet> </ns:Policies> <ns:Locators> <ns:Locator Name="org.jboss.security.xacml.locators.JBossRBACPolicySetLocator"/> </ns:Locators> </ns:jbosspdp>
- PDP (ポリシー決定ポイント) を作成し、設定ファイルに渡します。
- PEP (ポリシー強制ポイント) は、コンテキストを基に XACML 要求を作成します。XACML 要求を PDP へ渡し、以下のアクセス決定の 1 つを取得します。
- Permit
- Deny
- Indeterminate
- Not Applicable
例13.12 アクセス決定
許可の条件<Request xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:context:schema:os access_control-xacml-2.0-context-schema-os.xsd"> <Subject> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#string"> <AttributeValue>Anne</AttributeValue> </Attribute> <Attribute AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#anyURI"> <AttributeValue>manager</AttributeValue> </Attribute> </Subject> <Resource> <Attribute AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#anyURI"> <AttributeValue>manager</AttributeValue> </Attribute> </Resource> <Action> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#anyURI"> <AttributeValue>urn:oasis:names:tc:xacml:2.0:actions:hasPrivilegesOfRole</AttributeValue> </Attribute> </Action> </Request>
許可の拒否<Request xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:context:schema:os access_control-xacml-2.0-context-schema-os.xsd"> <Subject> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#string"> <AttributeValue>Anne</AttributeValue> </Attribute> <Attribute AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#anyURI"> <AttributeValue>manager</AttributeValue> </Attribute> </Subject> <Resource> <Attribute AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#anyURI"> <AttributeValue>manager</AttributeValue> </Attribute> </Resource> <Action> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#anyURI"> <AttributeValue>urn:nobody</AttributeValue> </Attribute> </Action> </Request>
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 タブを選択します。Add をクリックし、オプションのキーと値を指定します。すでに存在するオプションを編集するには、Remove をクリックして削除し、Add をクリックして正しいオプションで再度追加します。
セキュリティー監査モジュールは、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。
13.7.3. 新しいセキュリティープロパティー
表13.1 新しいセキュリティープロパティー
名前 | 説明 | 設定可能な値 | 挙動 | デフォルト |
---|---|---|---|---|
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 セクションにある Edit をクリックします。
モジュールオプションを追加、編集、または削除します (任意)。
モジュールにオプションを追加する場合は、Policies リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add をクリックし、オプションのキーと値を指定します。すでに存在するオプションを編集するには、Remove をクリックして削除し、新たな値で再度追加します。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
を値として使用できます。<subsystem xmlns="urn:jboss:domain:security:1.2"> <security-domains> <security-domain name="other" cache-type="default"> <authentication> <login-module code="Remoting" flag="optional"> <module-option name="password-stacking" value="useFirstPass"/> </login-module> <login-module code="RealmDirect" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> </login-module> </authentication> </security-domain> <security-domain name="jboss-web-policy" cache-type="default"> <authorization> <policy-module code="Delegating" flag="required"/> </authorization> </security-domain> <security-domain name="jboss-ejb-policy" cache-type="default"> <authorization> <policy-module code="Delegating" flag="required"/> </authorization> </security-domain> </security-domains> </subsystem>
管理コンソールまたは CLI を使用して、追加のセキュリティードメインを必要に応じて設定できます。アプリケーションの記述子ファイルでのセキュリティードメインの有効化
セキュリティードメインはアプリケーションのWEB-INF/web.xml
ファイルにある<jboss-web>
要素の<security-domain>
子要素に指定されます。次の例はmy-domain
という名前のセキュリティードメインを設定します。<jboss-web> <security-domain>my-domain</security-domain> </jboss-web>
これがWEB-INF/jboss-web.xml
記述子に指定できる多くの設定の 1 つになります。
EJB への必要なアノテーションの追加
@SecurityDomain
および@RolesAllowed
アノテーションを使用してセキュリティーを EJB に設定します。次の EJB コードの例は、guest
ロールのユーザーによるother
セキュリティードメインへのアクセスを制限します。package example.ejb3; import java.security.Principal; import javax.annotation.Resource; import javax.annotation.security.RolesAllowed; import javax.ejb.SessionContext; import javax.ejb.Stateless; import org.jboss.ejb3.annotation.SecurityDomain; /** * Simple secured EJB using EJB security annotations * Allow access to "other" security domain by users in a "guest" role. */ @Stateless @RolesAllowed({ "guest" }) @SecurityDomain("other") public class SecuredEJB { // Inject the Session Context @Resource private SessionContext ctx; /** * Secured EJB method using security annotations */ public String getSecurityInfo() { // Session context injected using the resource annotation Principal principal = ctx.getCallerPrincipal(); return principal.toString(); } }
その他のコード例は、Red Hat カスタマーポータルより入手できる JBoss 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
設定を使用します。web
cache-container
と SSO replicated-cache が存在する必要があります。最初の設定ファイルにはweb
cache-container がすでに含まれており、一部の設定には SSO replicated-cache も含まれています。以下のコマンドを使用して SSO replicated-cache をチェックし、有効にします。これらのコマンドは管理対象ドメインのfull
プロファイルを変更することに注意してください。コマンドを変更して、スタンドアロンサーバーで別のプロファイルを使用したり、コマンドの/profile=ha
部分を削除することができます。例14.1
web
cache-container の確認前述のプロファイルや設定には、デフォルトとしてweb
cache-container が含まれています。次のコマンドを使用して、web
cache-container の存在を確認します。異なるプロファイルを使用する場合は、ha
をその名前に置き換えます。/profile=ha/subsystem=infinispan/cache-container=web/:read-resource(recursive=false,proxies=false,include-runtime=false,include-defaults=true)
サブシステムが存在する場合、結果はsuccess
になります。存在しない場合は追加する必要があります。例14.2
web
cache-container の追加次の 3 つのコマンドを使用してweb
cache-container を設定に対して有効にします。必要に応じてプロファイルの名前やその他のパラメーターを変更します。以下のパラメーターはデフォルト設定で使用されるパラメーターになります。/profile=ha/subsystem=infinispan/cache-container=web:add(aliases=["standard-session-cache"],default-cache="repl",module="org.jboss.as.clustering.web.infinispan")
/profile=ha/subsystem=infinispan/cache-container=web/transport=TRANSPORT:add(lock-timeout=60000)
/profile=ha/subsystem=infinispan/cache-container=web/replicated-cache=repl:add(mode="ASYNC",batching=true)
例14.3
SSO
replicated-cache の確認次の管理 CLI コマンドを実行します。/profile=ha/subsystem=infinispan/cache-container=web/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
"sso" => {
のような出力を探します。このような出力が見つからない場合、設定に SSO replicated-cache は存在しません。例14.4
SSO
replicated-cache の追加/profile=ha/subsystem=infinispan/cache-container=web/replicated-cache=sso:add(mode="SYNC", batching=true)
- SSO を使用するよう
web
サブシステムを設定する必要があります。次のコマンドは、default-host
という仮想サーバー上と、クッキードメインdomain.com
で SSO を有効にします。キャッシュ名はsso
で、再認証は無効になっています。/profile=ha/subsystem=web/virtual-server=default-host/sso=configuration:add(cache-container="web",cache-name="sso",reauthenticate="false",domain="domain.com")
- SSO 情報を共有する各アプリケーションは、
jboss-web.xml
デプロイメント記述子にある同じ <security-domain> とweb.xml
設定ファイルにある同じレルムを使用するよう設定されている必要があります。
サーバープロファイルの 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")
例14.6 クラスター化されていない SSO 設定の例
/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 に使用されるクラスとのマッピングを表しています。
表14.1 ログインモジュールコードとクラス名
単純名 | クラス名 | 目的 |
---|---|---|
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 を使用してセキュリティードメインを設定するようにしてください。<security-domain name="host" cache-type="default"> <authentication> <login-module code="Kerberos" flag="required"> <module-option name="storeKey" value="true"/> <module-option name="useKeyTab" value="true"/> <module-option name="principal" value="host/testserver@MY_REALM"/> <module-option name="keyTab" value="/home/username/service.keytab"/> <module-option name="doNotPrompt" value="true"/> <module-option name="debug" value="false"/> </login-module> </authentication> </security-domain>
Web アプリケーションやアプリケーションをセキュアにするため、2 つ目のセキュリティードメインを設定します。必要な場合はシステムプロパティーを設定します。
2 つ目のセキュリティードメインは、個別のユーザーを Kerberos または SPNEGO 認証サーバーへ認証するために使用されます。ユーザーの認証に最低でも 1 つのログインモジュールが必要で、ユーザーに適用するロールを検索するために別のログインモジュールが必要となります。次の XML コードは SPNEGO セキュリティードメインの例を表しています。これには、ロールを個別のユーザーにマッピングする承認モジュールが含まれます。認証サーバー上でロールを検索するモジュールを使用することもできます。<security-domain name="SPNEGO" cache-type="default"> <authentication> <!-- Check the username and password --> <login-module code="SPNEGO" flag="requisite"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="serverSecurityDomain" value="host"/> </login-module> <!-- Search for roles --> <login-module code="UsersRoles" flag="required"> <module-option name="password-stacking" value="useFirstPass" /> <module-option name="usersProperties" value="spnego-users.properties" /> <module-option name="rolesProperties" value="spnego-roles.properties" /> </login-module> </authentication> </security-domain>
web.xml
の security-constraint と login-config を指定します。web.xml
記述子にはセキュリティー制約とログイン設定に関する情報が含まれています。セキュリティー制約とログイン情報の値の例は次のとおりです。<security-constraint> <display-name>Security Constraint on Conversation</display-name> <web-resource-collection> <web-resource-name>examplesWebApp</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>RequiredRole</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>SPNEGO</auth-method> <realm-name>SPNEGO</realm-name> </login-config> <security-role> <description> role required to log in to the Application</description> <role-name>RequiredRole</role-name> </security-role>
jboss-web.xml
記述子にセキュリティードメインと他の設定を指定します。クライアント側のセキュリティードメイン (例の 2 番目のセキュリティードメイン) の名前をデプロイメントのjboss-web.xml
記述子に指定し、アプリケーションがこのセキュリティードメインを使用するよう指示します。オーセンティケーターを直接上書きすることができなくなりましたが、必要な場合は NegotiationAuthenticator をバルブとしてjboss-web.xml
記述子に追加することができます。<jacc-star-role-allow>
は任意で、複数のロール名を一致させるためアスタリスク (*) の使用を許可します。<jboss-web> <security-domain>SPNEGO</security-domain> <valve> <class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name> </valve> <jacc-star-role-allow>true</jacc-star-role-allow> </jboss-web>
アプリケーションの
MANIFEST.MF
に依存関係を追加し、Negotiation クラスを見つけます。Web アプリケーションによる JBoss Negotiation クラスの検索を可能にするには、org.jboss.security.negotiation
上の依存関係をデプロイメントのMETA-INF/MANIFEST.MF
マニフェストに追加する必要があります。適切にフォーマットされたエントリーは次のとおりです。Manifest-Version: 1.0 Build-Jdk: 1.6.0_24 Dependencies: org.jboss.security.negotiation
- この代わりに、
META-INF/jboss-deployment-structure.xml
ファイルを編集して依存関係をアプリケーションに追加することもできます。<?xml version="1.0" encoding="UTF-8"?> <jboss-deployment-structure> <deployment> <dependencies> <module name='org.jboss.security.negotiation'/> </dependencies> </deployment> </jboss-deployment-structure>
Web アプリケーションが Kerberos、Microsoft Active Directory、またはその他の SPNEGO 対応のディレクトリーサービスに対してクレデンシャルを許可および認証します。ユーザーがすでにディレクトリーサービスにログインしているシステムよりアプリケーションを実行し、必要なロールがすでにユーザーに適用されている場合は、Web アプリケーションは認証を要求しないため、SSO の機能が実現されます。
14.9. フォーム認証への SPNEGO フォールバックの設定
手順14.2 フォーム認証へフォールバックする SPNEGO セキュリティー
SPNEGO の設定
web.xml
の編集login-config
要素をアプリケーションへ追加し、web.xml でログインおよびエラーページを設定します。<login-config> <auth-method>SPNEGO</auth-method> <realm-name>SPNEGO</realm-name> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/error.jsp</form-error-page> </form-login-config> </login-config>
Web コンテンツの追加
login.html
およびerror.html
の参照をweb.xml
へ追加します。これらのファイルは、Web アプリケーションアーカイブのform-login-config
設定に指定された場所に追加されます。 詳細は、本書の「フォームベース認証の有効化」を参照してください。通常、login.html
は次のようになります。<html> <head> <title>Vault Form Authentication</title> </head> <body> <h1>Vault Login Page</h1> <p> <form method="post" action="j_security_check"> <table> <tr> <td>Username</td><td>-</td> <td><input type="text" name="j_username"></td> </tr> <tr> <td>Password</td><td>-</td> <td><input type="password" name="j_password"></td> </tr> <tr> <td colspan="2"><input type="submit"></td> </tr> </table> </form> </p> <hr> </body> </html>
注記
第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 セキュリティートークン要求メッセージ
<S11:Envelope xmlns:S11=".." xmlns:wsu=".." xmlns:wst=".."> <S11:Header> ... </S11:Header> <S11:Body wsu:Id="body"> <wst:RequestSecurityToken Context="context"> <wst:TokenType>http://www.tokens.org/SpecialToken</wst:TokenType> <wst:RequestType> http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue </wst:RequestType> </wst:RequestSecurityToken> </S11:Body> </S11:Envelope>
例15.2 セキュリティートークン応答メッセージ
<wst:RequestSecurityTokenResponse Context="context" xmlns:wst=".." xmlns:wsu=".."> <wst:TokenType>http://www.tokens.org/SpecialToken</wst:TokenType> <wst:RequestedSecurityToken> <token:SpecialToken xmlns:token="..."> ARhjefhE2FEjneovi&@FHfeoveq3 </token:SpecialToken> </wst:RequestedSecurityToken> <wst:Lifetime> <wsu:Created>...</wsu:Created> <wsu:Expires>...</wsu:Expires> </wst:Lifetime> </wst:RequestSecurityTokenResponse>
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) を使用してトークンが暗号化されます。