セキュリティーガイド

JBoss Enterprise Application Platform 6.3

Red Hat JBoss Enterprise Application Platform 6 向け

Red Hat Customer Content Services

概要

本書は、Red Hat JBoss Enterprise Application Platform 6 およびそのパッチリリースをセキュアにするためのガイドです。

パート I. Red Hat JBoss Enterprise Application Platform 6 のセキュリティー

第1章 はじめに

1.1. Red Hat JBoss Enterprise Application Platform 6

Red Hat JBoss Enterprise Application Platform 6 (JBoss EAP 6) は、オープンな標準に基いて構築され、Java Enterprise Edition 6 の仕様に準拠するミドルウェアプラットフォームです。高可用性クラスタリング、メッセージング、分散キャッシングなどの技術が JBoss Application Server 7 と統合されます。
JBoss EAP 6 には、必要な場合にだけサービスを有効にできる新しいモジュール構造が含まれます (サービスの起動時間が短縮されます)。
管理コンソールと管理コマンドラインインターフェースにより、XML 設定ファイルの編集が不必要になり、タスクをスクリプト化および自動化する機能が追加されました。
また、JBoss EAP 6 には、セキュアでスケーラブルな Java EE アプリケーションの迅速な開発を可能にする API と開発フレームワークが含まれます。

1.2. JBoss EAP 6 のセキュア化

コンピューターセキュリティーとは、デジタル化の時代に仮想環境をセキュアにする情報技術の分野全体を表す言葉です。コンピューターセキュリティーには、データの保護や整合性、アプリケーションセキュリティー、リスクと脆弱化の評価、認証および承認プロトコルなどが含まれます。
コンピューターのデータは組織の重要な資産です。データの保護はビジネスの中核を形成する不可欠な要素です。JBoss EAP はマルチレイヤーのセキュリティーを提供し、すべての段階でデータを保護します。
本当にセキュアなシステムとは、主機能としてセキュリティーを基盤から設計したシステムのことです。このようなシステムは SBD (Security by Design) の原理を使用します。SBD を使用するシステムでは、悪質な攻撃や侵入は通常のセキュリティーの一部として許可され、それらの攻撃や侵入を回避するよう設計されています。
セキュリティーはオペレーティングシステム、ミドルウェア、およびアプリケーションのレベルで適用できます。RHEL に適用されるオペレーティングシステムレベルのセキュリティーに関する詳細は、Red Hat Enterprise Linux の『セキュリティーガイド』を参照してください。
次章以降では、JBoss EAP 6 内でのセキュリティーレベルおよびレイヤーについて取り上げます。これらのレイヤーが、プラットフォーム内の全セキュリティー機能に対するインフラストラクチャーを提供します。

パート II. プラットフォームのセキュア化

第2章 Java セキュリティーマネージャー

2.1. Java Security Manager

Java Security Manager
Java Security Manager は、Java 仮想マシン (JVM) サンドボックスの外部境界を管理するクラスで、JVM 内で実行するコードが JVM 外のリソースと対話する方法を制御します。Java Security Manager が有効な場合、Java API は安全でない可能性のある操作を行う前に Security Manager が承認するか確認します。
Java Security Manager は、セキュリティーポリシーを使用して該当するアクションを許可または拒否するかどうかを決定します。

2.2. Java Security Manager のポリシー

Security Policy
コードの異なるクラスに対する定義済みのパーミッション。Java Security Manager はアプリケーションがリクエストしたアクションとセキュリティポリシーを比較します。ポリシーによってアクションが許可される場合、Java Security Manager はアクションの実行を許可します。ポリシーによってアクションが許可されない場合は、Java Security Manager はこのアクションを拒否します。セキュリティポリシーは、コードの場所、コードの署名、またはサブジェクトのプリンシパルを基にパーミッションを定義できます。
使用する Java Security Manager やセキュリティーポリシーは、Java 仮想マシンのオプション java.security.managerjava.security.policy を使用して設定されます。
基本情報

セキュリティーポリシーのエントリーは、policytool に関係のある以下の設定要素から構成されます。

CodeBase
コードの元の URL の場所 (ホストとドメインの情報以外)。オプションのパラメーターです。
SignedBy
コードを署名するためにプライベートキーが使用された署名者を参照するキーストアで使用されたエイリアス。これは、単一値またはカンマ区切りの値リストになります。オプションのパラメーターです。省略された場合は、署名の有無に関わらず Java Security Manager に影響はありません。
Principal
principal_typeprincipal_name のペアのリスト。これは、実行スレッドのプリンシパルセット内に存在する必要があります。Principals エントリーは任意です。このエントリーを省略すると、実行スレッドのプリンシパルによる Java Security Manager への影響はありません。
Permission
permission は、コードに与えられるアクセス権です。多くのパーミッションは、Java Enterprise Edition 6 (Java EE 6) 仕様の一部として提供されます。

2.3. Java Security Manager 内での JBoss EAP 6 の実行

Java Security Manager ポリシーを指定するには、ブートストラッププロセス中にドメインまたはサーバーインスタンスに渡す Java オプションを編集する必要があります。このため、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 向けのセキュリティーマネージャーの設定

  1. 設定ファイルを開きます。

    編集のために設定ファイルを開きます。このファイルの場所は、管理対象ドメインとスタンドアロンサーバーのどちらを使用しているかによって異なります。このファイルは、サーバーまたはドメインを起動するために使用される実行可能ファイルではありません。
    • 管理対象ドメイン

      • 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
  2. ファイルに Java オプションを追加します。

    確実に Java オプションが使用されるようにするため、以下で始まるコードブロックに Java オプションを追加します。
    if [ "x$JAVA_OPTS" = "x" ]; then
    -Djava.security.policy の値を編集して、セキュリティーポリシーの場所を指定できます。改行を入れずに 1 行で指定する必要があります。-Djava.security.policy プロパティーを設定するときに == を使用して指定すると、セキュリティーマネージャーは指定されたポリシーファイルのみを使用します。= を使用して指定すると、セキュリティーマネージャーは指定されたポリシーと JAVA_HOME/lib/security/java.securitypolicy.url セクションに指定されたポリシーを一緒に使用します。

    重要

    JBoss Enterprise Application Platform 6.2.2 およびそれ以降のリリースでは、システムプロパティー jboss.modules.policy-permissionstrue に設定する必要があります。

    例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"
  3. ドメインサーバーを起動します。

    ドメインまたはサーバーを通常どおり起動します。

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 ポリシーの設定

  1. policytool を起動します。

    policytool ツールを次のいずれかの方法で起動します。
    • Red Hat Enterprise Linux

      GUI またはコマンドプロンプトで、/usr/bin/policytool を実行します。
    • Microsoft Windows Server

      スタートメニューまたは Java インストールの bin\ から、policytool.exe を実行します。場所は異なることがあります。
  2. ポリシーを作成します。

    ポリシーを作成するには、Add Policy Entry を選択します。必要なパラメーターを追加し、Done をクリックします。
  3. 既存のポリシーを編集します。

    既存のポリシーのリストからポリシーを選択し、Edit Policy Entry ボタンを選択します。必要に応じて、パラメーターを編集します。
  4. 既存のポリシーを削除します。

    既存のポリシーのリストからポリシーを選択し、Remove Policy Entry ボタンを選択します。

2.5. IBM JRE および Java Security Manager

IBM JRE は JBoss Enterprise Application Platform のセキュリティーポリシーとは適切に動作しないデフォルトのポリシープロバイダーを使用します。IBM JRE を使用して Java Security Manager が有効な状態で JBoss Enterprise Application Platform をホストする場合は、JRE 設定が標準のポリシープロバイダーを使用するよう変更する必要があります。
IBM JRE の JRE 設定を設定するには、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. セキュリティーレルム

セキュリティーレルム はユーザーとパスワード間、およびユーザーとロール間のマッピングです。セキュリティーレルムは EJB や Web アプリケーションに認証や承認を追加するメカニズムです。JBoss EAP 6 はデフォルトで次の 2 つのセキュリティーレルムを提供します。
  • ManagementRealm は、管理 CLI や Web ベースの管理コンソールに機能を提供する管理 API の認証情報を保存します。これは、JBoss EAP 6 を管理するための認証システムを提供します。管理 API に使用する同じビジネスルールでアプリケーションを認証する必要がある場合には、ManagementRealm を使用することもできます。
  • ApplicationRealm は Web アプリケーションと EJB のユーザー、パスワード、およびロール情報を保存します。
各レルムはファイシステム上の複数のファイルに保存されます。
  • REALM-users.properties はユーザー名とハッシュ化されたパスワードを保存します。
  • REALM-roles.properties はユーザー対ロールのマッピングを保存します。
  • mgmt-groups.propertiesManagementRealm のユーザー対グループのマッピングを保存します。ロールベースアクセス制御 (RBAC: Role-based Access Control) が有効な場合のみ使用されます。
プロパティーファイルは domain/configuration/ および standalone/configuration/ ディレクトリーに保存されます。ファイルは add-user.shadd-user.bat コマンドによって同時に書き込まれます。コマンドの実行時、新しいユーザーをどのレルムに追加するかを最初に決定します。

3.2. 新しいセキュリティーレルムの追加

  1. 管理 CLI を実行します。

    jboss-cli.sh または jboss-cli.bat コマンドを開始し、サーバーに接続します。
  2. 新しいセキュリティーレルムを作成します。

    次のコマンドを実行し、ドメインコントローラーまたはスタンドアロンサーバー上で MyDomainRealm という名前の新しいセキュリティーレルムを作成します。
    ドメインインスタンスでは以下コマンドを使用します。
    /host=master/core-service=management/security-realm=MyDomainRealm:add()
    スタンドアロンインスタンスでは以下のコマンドを使用します。
    /core-service=management/security-realm=MyDomainRealm:add()
  3. 新しいロールの情報を保存するプロパティーファイルへの参照を作成します。

    次のコマンドを実行し、新しいロールに関連するプロパティーが含まれる 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. セキュリティーレルムへのユーザーの追加

  1. add-user.sh または add-user.bat コマンドを実行します。

    ターミナルを開き、EAP_HOME/bin/ ディレクトリーへ移動します。Red Hat Enterprise Linux や他の UNIX 系のオペレーティングシステムを稼働している場合は、add-user.sh を実行します。Microsoft Windows Server を稼働している場合は add-user.bat を実行します。
  2. 管理ユーザーかアプリケーションユーザーのどちらを追加するか選択します。

    この手順では b を入力し、アプリケーションユーザーを追加します。
  3. ユーザーが追加されるレルムを選択します。

    デフォルトでは、ApplicationRealm のみが選択可能です。カスタムレルムが追加されている場合はその名前を入力します。
  4. 入力を促されたらユーザー名、パスワード、ロールを入力します。

    入力を促されたら希望のユーザー名、パスワード、任意のロールを入力します。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 を使用する場合) を使用します。
管理インターフェース、パブリックインターフェース、またはその両方の IP アドレスを変更できます。

警告

リモートホストからアクセス可能な他のネットワークインターフェースに管理インターフェースを公開する場合は、セキュリティーの問題に注意してください。ほとんどの場合、管理インターフェースにリモートアクセスを提供することはお勧めしません。
  1. JBoss EAP 6 を停止します。

    オペレーティングシステムに適切な方法で割り込みを送信して JBoss EAP 6 を停止します。JBoss EAP 6 をフォアグラウンドアプリケーションとして実行している場合、通常は Ctrl+C を押してこれを行います。
  2. バインドアドレスを指定して 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
XML 設定ファイルを直接編集してデフォルトのバインドアドレスを変更できますが、これを行うと -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 が連携するための管理

  1. 管理コンソールへのログイン

    管理コンソールにログインします。デフォルトでは、http://localhost:9990/console/ で実行されます。
  2. ソケットバインディンググループが使用するソケットバインディングを決定します。

    1. 管理コンソールの上部にある Configuration ラベルをクリックします。
    2. General Configuration メニューを展開します。Socket Binding を選択します。
    3. Socket Binding Declarations 画面が表示されます。最初に、standard-sockets グループが表示されます。他のグループを選択する場合は、右側のコンボボックスから選択します。

    注記

    スタンドアロンサーバーを使用する場合は、1 つのソケットバインディンググループのみが存在します。
    ソケット名とポートのリストが表示されます (1 ページあたり 8 つの値)。テーブルの矢印ナビゲーションを使用してページを移動できます。
  3. 開く必要があるポートを判断します。

    特定ポートの機能および環境の要件によっては、一部のポートをファイアウォール上で開く必要がある場合があります。
  4. JBoss EAP 6 にトラフィックを転送するようファイアウォールを設定します。

    以下の手順を実行して、必要なポートでトラフィックを許可するようネットワークファイアウォールを設定します。
    1. root ユーザーとしてファイアウォールマシンにログインし、コマンドプロンプトにアクセスします。
    2. system-config-firewall コマンドを実行してファイアウォール設定ユーティリティーを起動します。ファイアウォールシステムにログインした方法に応じて、GUI またはコマンドラインユーティリティーが起動します。このタスクでは、SSH 経由でコマンドラインインターフェースを使用してログインしていることを前提とします。
    3. キーボードで TAB キーを使用して Customize ボタンに移動し、ENTER キーを押します。Trusted Services 画面が表示されます。
    4. どの値も変更せずに、TAB キーを使用して Forward ボタンに移動し、ENTER を押して次の画面に進みます。Other Ports 画面が表示されます。
    5. TAB キーを使用して <Add> ボタンに移動し、ENTER を押します。Port and Protocol 画面が表示されます。
    6. Port / Port Range フィールドに 5445 と入力し、TAB キーを使用して Protocol フィールドに移動し、tcp と入力します。TAB キーを使用して OK ボタンに移動し、ENTER を押します。
    7. TAB キーを使用して、Forward ボタンに移動し、Port Forwarding 画面にアクセスします。
    8. TAB キーを使用して <Add> ボタンに移動し、ENTER キーを押します。
    9. 以下の値を入力してポート 5445 のポート転送を設定します。
      • 送信元インターフェース: eth1
      • プロトコル: tcp
      • ポート/ポート範囲: 5445
      • 宛先 IP アドレス: 10.1.1.2
      • ポート/ポート範囲: 5445
      TAB キーを使用して OK ボタンに移動し、ENTER を押します。
    10. TAB キーを使用して Close ボタンに移動し、ENTER を押します。
    11. TAB キーを使用して OK ボタンに移動し、ENTER を押します。変更内容を適用するには、警告を読み、Yes をクリックします。
  5. 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 上でのファイアウォールの設定

  1. デバッグの目的でファイアウォールを停止し、現在のネットワークの挙動がファイアウォールの設定と関係しているかどうかを判断します。
    Start-Process "$psHome\powershell.exe" -Verb Runas -ArgumentList '-command "NetSh Advfirewall set allprofiles state off"'
  2. ポート 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 により使用されるネットワークポート

JBoss EAP 6 のデフォルト設定で使用されるポートは、次の複数の要因によって異なります。
  • サーバーグループがデフォルトのソケットバインディンググループのいずれかを使用するか、またはカスタムグループを使用するかどうか。
  • 個別デプロイメントの要件。

注記

数値ポートオフセットは、同じ物理サーバーで複数のサーバーを実行する場合にポートの競合を緩和するために設定できます。サーバーが数値のポートオフセットを使用する場合は、サーバーグループのソケットバインディンググループに対するデフォルトのポート番号にオフセットを追加します。たとえば、ソケットバインディンググループの HTTP ポートが 8080 で、サーバーは 100 のポートオフセットを使用する場合、その HTTP ポートは 8180 になります。
特に指定がない限り、ポートは TCP プロトコルを使用します。

デフォルトのソケットバインディンググループ

  • full-ha-sockets
  • full-sockets
  • ha-sockets
  • standard-sockets

表4.1 デフォルトのソケットバインディングの参照

名前ポートマルチキャストポート説明full-ha-socketsfull-socketsha-socketstandard-socket
ajp8009 Apache JServ プロトコル。HTTP クラスタリングおよび負荷分散に使用します。
http8080 デプロイされた Web アプリケーションのデフォルトポート。
https8443 デプロイされた Web アプリケーションとクライアント間の SSL 暗号化接続。
jacorb3528 JTS トランザクションおよび他の ORB 依存サービス用の CORBA サービス。××
jacorb-ssl3529 SSL 暗号化 CORBA サービス。××
jgroups-diagnostics 7500マルチキャスト。HA クラスターでのピアの検出に使用されます。管理インターフェースを使用しても設定できません。××
jgroups-mping 45700マルチキャスト。HA クラスターでの初期メンバーシップの検出に使用されます。××
jgroups-tcp7600 TCP を使用した、HA クラスター内でのユニキャストピア検出。××
jgroups-tcp-fd57600 TCP を介した HA 障害検出に使用されます。××
jgroups-udp5520045688UDP を使用した、HA クラスター内でのマルチキャストピア検出。××
jgroups-udp-fd54200 UDP を介した HA 障害検出に使用されます。××
messaging5445 JMS サービス。××
messaging-group HornetQ JMS ブロードキャストと検出グループにより参照されます。××
messaging-throughput5455 JMS Remoting により使用されます。××
mod_cluster 23364JBoss EAP 6 と HTTP ロードバランサー間の通信に対するマルチキャストポート。××
osgi-http8090 OSGi サブシステムを使用する内部コンポーネントにより使用されます。管理インターフェースを使用して設定できません。
remoting4447 リモート EJB の呼び出しに使用されます。
txn-recovery-environment4712 JTA トランザクションリカバリーマネージャー。
txn-status-manager4713 JTA / JTS トランザクションマネージャー。
管理ポート

ソケットバインディンググループの他に、各ホストコントローラーによって 2 つのポートが管理目的で開かれます。

  • 9990 - Web 管理コンソールポート
  • 9999 - 管理コンソールと管理 API によって使用されるポート
さらに、管理コンソールに対して HTTPS が有効になっている場合、9443 もデフォルトポートとして開かれます。

4.4. 暗号化

暗号化とは、数学的なアルゴリズムを適用して機密情報を分かりにくくすることを言います。暗号化はデータの侵害やシステム機能の停止などのリスクからインフラストラクチャーを保護する基盤の 1 つとなります。
暗号化はパスワードなどの簡単な文字列データへ適用することができます。また、データ通信のストリームへ適用することも可能です。たとえば、HTTPS プロトコルはデータを転送する前にすべてのデータを暗号化します。セキュアシェル (SSH) プロトコルを使用して 1 つのサーバーから別のサーバーへ接続する場合、すべての通信が暗号化されたトンネルで送信されます。

4.5. SSL 暗号化

SSL (セキュアソケットレイヤー) は、2 つのシステム間のネットワークトラフィックを暗号化します。接続のハンドシェーク フェーズで生成され、2 つのシステムのみが認識する共通鍵を使用して 2 つのシステム間のトラフィックを暗号化します。
共通鍵をセキュアに交換するために、SSL は PKI (Public Key Infrastructure、公開鍵基盤) を利用します。PKI とは、キーペア を使った暗号化の方法です。キーペア は公開鍵と秘密鍵の 2 つの一致する暗号化キーで構成されます。公開鍵は共有され、データを暗号化するために使用されます。秘密鍵は公開されず公開鍵で暗号化されたデータを復号化するために使用されます。
クライアントが安全な接続を要求した場合、安全な通信が開始される前にハンドシェイクフェーズが実行されます。SSL のハンドシェイク中にサーバーは公開鍵を証明書としてクライアントに渡します。この証明書にはサーバーの ID (サーバーの URL)、サーバーの公開鍵、証明書を認証するデジタル署名が含まれています。その後、クライアントは証明書を検証し、この証明書が信頼できるものであるかを判断します。この証明書を信頼する場合、クライアントは共通鍵を SSL 接続に対して生成し、サーバーの公開鍵を使用して暗号化してからサーバーに戻します。サーバーは秘密鍵を使用して、共通鍵を復号化します。その後、同じ接続でこれらの 2 つのマシンが行う通信はこの共通鍵を使い暗号化されます。

警告

Red Hat は、影響するすべてのパッケージで TLSv1.1 または TLSv1.2 を利用するために SSL を明示的に無効化することを推奨しています。

4.6. JBoss EAP 6 Web サーバーでの SSL 暗号化の実装

はじめに

多くの Web アプリケーションでは、クライアントとサーバー間で SSL 暗号化接続 (HTTPS 接続とも呼ばれます) が必要です。以下の手順を使用すると、サーバーまたはサーバーグループで HTTPS を有効にできます。

警告

Red Hat は、影響するすべてのパッケージで TLSv1.1 または TLSv1.2 を利用するために SSL を明示的に無効化することを推奨しています。

要件

  • SSL 暗号化キーセットと SSL 暗号化証明書。これらは、証明書署名認証局から購入したり、コマンドラインユーティリティーを使用して生成したりできます。Red Hat Enterprise Linux のユーティリティーを使用して暗号化キーを生成するには、「SSL 暗号化キーおよび証明書の生成」を参照してください。
  • 特定の環境と設定に関する以下の詳細。
    • 証明書ファイルが保存されている完全なディレクトリー名。
    • 暗号化キーの暗号化パスワード。
  • ドメインコントローラーまたはスタンドアロンサーバーに接続する稼働中の管理 CLI。
  • 適切な暗号化スイートを選択します。
暗号化スイート

暗号化スイートを構成するために使用される暗号プリミティブは複数あります。推奨される暗号プリミティブは最初の表に記載されています。2 つ目の表には、既存のソフトウェアとの互換性を維持するために使用できる 可能性がある 暗号プリミティブが記載されていますが、推奨されるプリミティブよりも安全性が低くなります。

警告

Red Hat は、厳選された強力な暗号を 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
コネクターの SSL プロパティーに設定できるパラメーターの完全リストは、「SSL コネクターリファレンス」を参照してください。

注記

この手順では、管理対象ドメインを使用する JBoss EAP 6 設定に適切なコマンドを使用します。スタンドアロンサーバーを使用する場合は、管理 CLI コマンドの先頭から /profile=default を削除して管理 CLI コマンドを変更します。

警告

Red Hat は、影響するすべてのパッケージで TLSv1.1 または TLSv1.2 を利用するために SSL を明示的に無効化することを推奨しています。

手順4.4 JBoss Web Server が HTTPS を使用するよう設定

  1. 新しい HTTPS コネクターを追加します。

    https スキームと https ソケットバインディング (デフォルトは 8443) を使用し、セキュアとして設定される HTTPS という名前のセキュアなコネクターを作成します。
    /profile=default/subsystem=web/connector=HTTPS/:add(socket-binding=https,scheme=https,protocol=HTTP/1.1,secure=true)
  2. 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)
  3. プロトコルを TLSv1 に設定します。

    /profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=protocol,value=TLSv1)
  4. アプリケーションをデプロイします。

    設定したプロファイルを使用するサーバーグループにアプリケーションをデプロイします。スタンドアロンサーバーを使用する場合、アプリケーションをサーバーにデプロイします。アプリケーションに対する HTTPS 要求は新しい SSL 暗号化接続を使用します。

4.7. SSL 暗号化キーおよび証明書の生成

SSL で暗号化された HTTP 接続 (HTTPS) や、他のタイプの SSL で暗号化された通信を使用するには、署名された暗号化証明書が必要です。証明書を認証局 (CA) から購入したり、自己署名証明書を使用したりできます。自己署名証明書を信頼できるとみなすサードパーティーは少数ですが、内部テストを目的とした使用には適しています。
この手順を実行すると、Red Hat Enterprise Linux で利用可能なユーティリティーを使用して自己署名証明書を作成できます。

要件

  • Java Development Kit 実装で提供される keytool ユーティリティーが必要です。このコマンドは、Red Hat Enterprise Linux 上の OpenJDK により /usr/bin/keytool にインストールされます。
  • keytool コマンドの構文およびパラメーターについて理解してください。この手順では、非常に一般的な手順を実行します。本書では、SSL 証明書または keytool コマンドに特有の説明は範囲外となります。

手順4.5 SSL 暗号化キーおよび証明書の生成

  1. パブリックキーおよびプライベートキーとともにキーストアを生成します。

    以下のコマンドを実行し、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説明
    -genkeypairkeytool コマンドは公開鍵と秘密鍵が含まれるキーペアを生成します。
    -aliasキーストアのエイリアス。この値は任意ですが、エイリアス jboss はデフォルトで JBoss Web サーバーによって使用されます。
    -keyalgキーペア生成のアルゴリズム。この例では RSA になります。
    -keystoreキーストアファイルの名前と場所。デフォルトの場所はカレントディレクトリーです。選択する名前は任意です。この例では、ファイルの名前は server.keystore になります。
    -storepassこのパスワードは、キーの読み取りを可能にするためキーストアに対して認証を行うために使用されます。パスワードは 6 文字以上である必要があり、キーストアがアクセスされた時に提供しなければなりません。この例では、mykeystorepass が使用されています。このパラメーターを省略すると、コマンドの実行時に入力するよう要求されます。
    -keypass
    実際の鍵のパスワードです。

    注記

    実装の制限により、ストアと同じパスワードを使用する必要があります。
    --dnameキーの識別名を記述する引用符で囲まれた文字列 (例: "CN=jsmith,OU=Engineering,O=mycompany.com,L=Raleigh,C=US")。以下のコンポーネントが連結された文字列になります。
    • CN - 共通名またはホスト名。ホスト名が jsmith.mycompany.com の場合、CN は jsmith になります。
    • OU - 組織単位 (例: Engineering)。
    • O - 組織名 (例: mycompany.com)。
    • L - 地域 (例: Raleigh または London)。
    • S - 州 (例: NC)。このパラメーターの使用は任意です。
    • C - 2 文字の国コード (例: US または UK)。
    上記のコマンドを実行すると、次の情報が要求されます。
    • コマンドラインで -storepass パラメーターを使用しなかった場合、キーストアのパスワードを入力するよう要求されます。次に要求されたら新しいパスワードを再入力します。
    • コマンドラインで -keypass パラメーターを使用しなかった場合、キーのパスワードを入力するよう要求されます。Enter を押し、キーストアのパスワードと同じ値を設定します。
    コマンドが終了すると、ファイル server.keystore にエイリアス jboss を持つ単一のキーが含まれるようになります。
  2. キーを検証します。

    以下のコマンドを使用して、キーが正常に動作することを検証します。
    keytool -list -keystore server.keystore
    キーストアのパスワードを入力するよう求められます。キーストアの内容 (この場合は jboss という名前の単一キー) が表示されます。jboss キーの種類が PrivateKeyEntry であることに注意してください。これは、キーストアにこのキーのパブリックおよびプライベートエントリが含まれることを示します。
  3. 証明書署名要求を生成します。

    次のコマンドを実行し、手順 1 で作成したキーストアより公開鍵を使用して証明書署名要求を生成します。
    keytool -certreq -keyalg RSA -alias jboss -keystore server.keystore -file certreq.csr
    キーストアに対する認証を行うために、パスワードを入力するよう求められます。keytool コマンドにより、現在の作業ディレクトリーに certreq.csr という名前の証明書署名要求が新規作成されます。
  4. 新しく生成された証明書署名要求をテストします。

    以下のコマンドを使用して証明書の内容をテストします。
    openssl req -in certreq.csr -noout -text
    証明書の詳細が表示されます。
  5. オプション: 証明書署名要求を認証局 (CA) に送信します。

    認証局 (CA) は、証明書を認証できます。この結果、証明書は、サードパーティークライアントが信用できると見なされます。CA により、署名済み証明書が提供されます。また、オプションで 1 つまたは複数の中間証明書が提供されます。
  6. オプション: キーストアからの自己署名証明書のエクスポート

    テストまたは内部使用のためにのみ証明書が必要な場合は、自己署名証明書を使用できます。次のように、手順 1 で作成したキーストアからエクスポートします。
    keytool -export -alias jboss -keystore server.keystore -file server.crt
    キーストアに対して認証するためパスワードの入力が求められます。server.crt という名前の自己署名証明書が現在の作業ディレクトリーに作成されます。
  7. 署名済み証明書を中間証明書とともにインポートします。

    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
  8. 証明書が正常にインポートされたことをテストします。

    以下のコマンドを実行し、要求された場合にキーストアパスワードを入力します。キーストアの内容が表示され、証明書がリストの一部になります。
    keytool -list -keystore server.keystore
結果

署名済み証明書はキーストアに含まれ、HTTPS Web サーバー通信を含む SSL 接続を暗号化するために使用できます。

4.8. SSL コネクターリファレンス

JBoss Web コネクターには、次の SSL 設定属性を含めることができます。提供された CLI コマンドは、プロファイル default を使用した管理対象ドメイン向けに設計されています。プロファイル名を、管理対象ドメインに対して設定する名前に変更するか、コマンドの /profile=default 部分を省略します (スタンドアロンサーバーの場合)。

表4.4 SSL コネクター属性

属性説明CLI コマンド
name
SSL コネクターの表示名。
属性 name は読み取り専用です。
verify-client
HTTP/HTTPS コネクターまたはネイティブ APR コネクターが使用されるかによって、verify-client の可能な値は異なります。
HTTP/HTTPS コネクター

可能な値は truefalse、または want です。接続を受け入れる前にクライアントから有効な証明書チェーンが必要な場合は、true に設定します。SSL スタックでクライアント証明書を要求し、クライアント証明書が提示されない場合でもエラーが発生しないようにするには、want に設定します。CLIENT-CERT 認証を使用するセキュリティー制約によって保護されたリソースをクライアントが要求する場合を除き、証明書チェーンを必要としないときは false (デフォルト値) に設定します。

ネイティブ APR コネクター

可能な値は optionalrequireoptionalNoCA、および none (または none と同様の他の文字列) です。これらの値は、証明が任意、必須、認証局なしの任意、または不要であるかどうかを決定します。デフォルトは none で、クライアントは証明書を提出する機会がありません。

最初のコマンド例は 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 を参照してください。 @SECLEVELSUITEB128SUITEB128ONLY、および 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 の準拠

連邦情報処理標準 (FIPS: Federal Information Processing Standard) 140-2 は、アメリカ政府による、暗号化ソフトウェアモジュール認定のためのコンピューターセキュリティー標準です。多くの場合で、FIPS 140-2 へ準拠することが政府機関や民間企業が使用するソフトウェアシステムの要件となります。
JBoss EAP 6 は外部モジュールによる暗号化を使用します。また、FIPS 140-2 に準拠する暗号化モジュールを使用するよう設定できます。

4.9.2. IBM JDK での FIPS 140-2 準拠の暗号

IBM JDK では、IBM® JCE (Java™ Cryptographic Extension) IBMJCEFIPS プロバイダーおよびマルチプラットフォーム用 IBM JSSE (Java Secure Sockets Extension) FIPS 140-2 Cryptographic Module (IBMJSSEFIPS) が FIPS 140-2 に準拠する暗号化を提供します。
IBMJCEFIPS の詳細は IBM JCEFIPS に関する IBM のドキュメントと、NIST IBMJCEFIPS – Security Policy を参照してください。

鍵の格納

IBM JCE はキーストアを提供しないことに注意してください。鍵はコンピューターに格納され、その物理的境界を残しません。コンピューターの間で鍵を移動する場合は、鍵を暗号化する必要があります。
FIPS 準拠モードで keytool を実行するには、以下のように各コマンドで -providerClass オプションを使用します。
keytool -list -storetype JCEKS -keystore mystore.jck -storepass mystorepass -providerClass com.ibm.crypto.fips.provider.IBMJCEFIPS

FIPS プロバイダー情報の確認

サーバーによって使用される IBMJCEFIPS に関する情報を確認するには、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 準拠のパスワード

FIPS 準拠のパスワードは以下の条件を満たす必要があります。
  1. 7 文字以上であること。
  2. 以下の文字クラスのうち、3 クラス以上の文字が含まれること。
    • ASCII 数字
    • 小文字の ASCII
    • 大文字の ASCII
    • 英数字以外の ASCII
    • ASCII 以外の文字
パスワードの最初の文字が大文字の ASCII である場合、2. にある大文字の ASCII として見なされません。
パスワードの最後の文字が ASCII 数字である場合、制限 2 の ASCII 数字とは見なされません。

4.9.4. Red Hat Enterprise Linux 6 にて SSL の FIPS 140-2 準拠の暗号を有効化

ここでは、JBoss EAP 6 の Web コンテナ (JBoss Web) を SSL に対する FIPS 140-2 準拠の暗号化に設定する方法を説明します。ここでは Red Hat Enterprise Linux 6 での手順のみを取り上げます。
このタスクでは、FIPS モードの Mozilla NSS ライブラリーを使用します。

要件

手順4.6 SSL に対して FIPS 140-2 準拠の暗号化を有効にする

  1. データベースの作成

    jboss ユーザーが所有するディレクトリーに NSS データベースを作成します。
    $ mkdir -p  /usr/share/jboss-as/nssdb
    $ chown jboss /usr/share/jboss-as/nssdb 
    $ modutil -create -dbdir /usr/share/jboss-as/nssdb
  2. 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/libnssLibraryDirectory に設定します。
  3. 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 を足す必要があります。
  4. NSS ライブラリーに対して FIPS モードを有効にする

    次のように modutil コマンドを実行し、FIPS モードを有効にします。
    modutil -fips true -dbdir /usr/share/jboss-as/nssdb
    ここで指定するディレクトリーは手順 1 で作成したものであることに注意してください。
    この時点で、セキュリティーライブラリーエラーが発生し、NSS 共有オブジェクトの一部に対してライブラリー署名の再生成が必要になることがあります。
  5. FIPS トークンのパスワードの変更

    次のコマンドを使用して FIPS トークンのパスワードを設定します。トークンの名前は NSS FIPS 140-2 Certificate DB でなければならないことに注意してください。
    modutil -changepw "NSS FIPS 140-2 Certificate DB" -dbdir /usr/share/jboss-as/nssdb
    FIPS トークンに使用されるパスワードは FIPS 準拠のパスワードでなければなりません。
  6. 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
  7. 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")
  8. 検証

    次のコマンドを実行し、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章 管理インターフェースのセキュア化

一般的な開発シナリオでは、セキュア化されていない JBoss EAP 6 を管理インターフェースで実行し、迅速に設定を変更できるようにします。
実稼働に向けた開発段階では、少なくとも以下の方法で管理インターフェースをセキュアにします。
また、デフォルトのサイレントローカル認証モードを使用すると、ローカルクライアント (サーバーマシン側の) はユーザー名やパスポートを必要とせずに管理 CLI へ接続できます。これは、ローカルユーザーや管理 CLI スクリプトには便利な機能です。この機能を無効にする場合は「デフォルトセキュリティーレルムからのサイレント認証の削除」を参照してください。

5.1. デフォルトのユーザーセキュリティー設定

はじめに

JBoss EAP 6 のすべての管理インターフェースはデフォルトで保護されます。このセキュリティーには、2 つの形式があります。

  • ローカルインターフェースは、ローカルクライアントとローカルクライアントが接続するサーバーとの間の SASL コントラクトによって保護されます。このセキュリティーメカニズムは、ローカルファイルシステムにアクセスするクライアントの機能に基づきます。ローカルシステムへアクセスできるとクライアントによるユーザーの追加が可能で、他のセキュリティーメカニズムを無効にするよう設定を変更できるからです。これにより、ファイルシステムへ物理的にアクセスできると、他のセキュリティーメカニズムが不要になるという原則が厳守されます。このメカニズムは 4 つの手順で実現されます。

    注記

    HTTP を使用してローカルホストへ接続する場合でも、HTTP のアクセスはリモートと見なされます。
    1. ローカル SASL メカニズムを用いて認証する要求が含まれるメッセージをクライアントがサーバーに送信します。
    2. サーバーはワンタイムトークンを生成し、固有のファイルに書き込み、ファイルのフルパスが含まれるメッセージをクライアントへ送信します。
    3. クライアントはファイルよりトークンを読み取り、サーバーへ送信し、ファイルシステムへローカルアクセスできるかを検証します。
    4. サーバーはトークンを検証し、ファイルを削除します。
  • ローカル 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 の管理インターフェース設定は、ホストコントローラープロセスのバインド先となるネットワークインターフェース、利用可能な管理インターフェースのタイプ、および各インターフェースのユーザーを認証するために使用される認証システムのタイプを制御します。本トピックでは、ご使用の環境に合わせて管理インターフェースを設定する方法について説明します。
管理サブシステムは、以下の 4 つの設定可能な子要素が含まれる <management> 要素で構成されます。セキュリティレルムと送信接続はそれぞれ最初に定義されてから、管理インターフェースに属性として適用されます。
  • <security-realms>
  • <outbound-connections>
  • <management-interfaces>
  • <audit-log>

注記

監査ロギングの詳細は、『管理および設定ガイド』の「管理インターフェース監査ロギング」の項を参照してください。
セキュリティーレルム

セキュリティーレルムは、管理 API、管理 CLI、または Web ベースの管理コンソールを介して JBoss EAP 6 の管理を許可されているユーザーの認証と承認を行います。

デフォルトのインストールに含まれる 2 つの異なるファイルベースのセキュリティーレルムは ManagementRealmApplicationRealm です。これらのセキュリティーレルムはそれぞれ -users.properties ファイルを使用してユーザーおよびハッシュ化されたパスワードを保存し、-roles.properties を使用してユーザーとロール間のマッピングを保存します。サポートは LDAP 対応のセキュリティーレルムにも含まれています。

注記

独自のアプリケーションにセキュリティーレルムを使用することも可能です。このトピックで説明するセキュリティーレルムは管理インターフェース固有のものです。
送信接続

一部のセキュリティーレルムは、LDAP サーバーなどの外部インターフェースに接続します。送信接続は、この接続の確立方法を定義します。 事前に定義された接続タイプ ldap-connection は、LDAP サーバーに接続してクレデンシャルを検証するための必須およびオプションの属性をすべて設定します。

LDAP 認証の設定方法の詳細は、「管理インターフェースに対する LDAP を使用した認証」を参照してください。
管理インターフェース

管理インターフェースには、JBoss EAP の接続および設定方法に関するプロパティーが含まれています。この情報には、名前付きのネットワークインターフェース、ポート、セキュリティーレルム、およびインターフェースに関するその他の設定可能な情報が含まれます。デフォルトのインストールには 2 つのインターフェースが含まれています。

  • http-interface は Web ベースの管理コンソールの設定です。
  • native-interface はコマンドライン管理 CLI および REST ライクな管理 API の設定です。
ホスト管理サブシステムの設定可能要素はそれぞれ相関しています。セキュリティーレルムは送信接続を参照し、管理インターフェースはセキュリティーレルムを参照します。
関連情報は 5章管理インターフェースのセキュア化 を参照してください。

5.3. HTTP 管理インターフェースの無効化

管理対象ドメインでは、ドメインメンバーのサーバーではなく、ドメインコントローラー上の HTTP インターフェースへのアクセスのみが必要です。また、実稼働サーバー上では、Web ベースの管理コンソールを完全に無効化することが可能です。

注記

JBoss Operations Network などの他のクライアントも HTTP インターフェースを使用して稼働します。これらのサービスを使用したり、管理コンソール自体を無効にしたい場合は、インターフェースを完全に無効化する代わりに HTTP インターフェースの console-enabled 属性 を false に設定できます。
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=false)
HTTP インターフェースへのアクセスを無効にすると、Web ベースの管理コンソールへのアクセスも無効になるため、HTTP インターフェースを完全に削除して無効化できます。
次の JBoss CLI コマンドを使用すると、再度追加する場合に備えて HTTP インターフェースの現在の内容を読み込むことができます。

例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"
    }
}
HTTP インターフェースを削除するには、次のコマンドを実行します。

例5.2 HTTP インターフェースの削除

/host=master/core-service=management/management-interface=http-interface/:remove
アクセスを再度有効化するには、以下のコマンドを実行し、デフォルト値を使用して HTTP インターフェースを再作成します。

例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 要素の削除を考慮するようにしてください。
推奨されるサイレント認証の削除方法は、管理 CLI を使用して、次の例に示された local 要素を直接削除することです。

例5.4 security-realmlocal 要素の例

<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 要素を削除します。
    1. 管理レルムから local 要素を削除します。
      • スタンドアロンの場合

        /core-service=management/security-realm=ManagementRealm/authentication=local:remove
      • 管理対象ドメインの場合

        /host=HOST_NAME/core-service=management/security-realm=ManagementRealm/authentication=local:remove
    2. アプリケーションレルムから local 要素を削除します。
      • スタンドアロンの場合

        /core-service=management/security-realm=ApplicationRealm/authentication=local:remove
      • 管理対象ドメインの場合

        /host=HOST_NAME/core-service=management/security-realm=ApplicationRealm/authentication=local:remove
結果

サイレント認証モードが、ManagementRealmApplicationRealm から削除されます。

5.5. JMX サブシステムへのリモートアクセスの無効化

JMX サブシステムにリモートアクセスすると、JDK およびアプリケーション管理操作をリモートでトリガーすることができます。インストールをセキュア化するには、リモーティングコネクターまたは JMX サブシステムを削除してこの機能を無効化します。例の管理 CLI コマンドは管理対象ドメインを対象としています。スタンドアロンサーバーの場合はコマンドから /profile=default 接頭辞を削除してください。

注記

管理対象ドメインでは、リモート処理コネクターはデフォルトで JMX サブシステムから削除されています。以下のコマンドは、開発中にリモート処理コネクターを追加した場合に備えて、参考のために記載します。

例5.5 JMX サブシステムからのリモートコネクターの削除

/profile=default/subsystem=jmx/remoting-connector=jmx/:remove

例5.6 JMX サブシステムの削除

管理対象ドメインの場合は、各プロファイルに対してこのコマンドを実行します。
/profile=default/subsystem=jmx/:remove

5.6. 管理インターフェースのセキュリティーレルムの設定

管理インターフェースはセキュリティーレルムを使用して JBoss EAP 6 の認証および設定メカニズムへのアクセスを制御します。セキュリティーレルムは Unix グループと似ている、ユーザーの認証に使用できるユーザーとパスワードのデータベースです。
デフォルトの管理レルム

デフォルトでは、管理インターフェースは 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 の管理コンソールの設定

HTTPS のみを使用して通信用に JBoss EAP 管理コンソールを設定するとセキュリティーが向上されます。クライアント (Web ブラウザー) と管理コンソール間のネットワークトラフィックはすべて暗号化されるため、中間者攻撃 (man-in-the-middle attack) などのセキュリティー攻撃のリスクが軽減されます。JBoss EAP インスタンスを管理するユーザーは、非特権ユーザーよりもそのインスタンスに対する権限を多く持ちます。HTTPS を使用すると、そのインスタンスの整合性および可用性を保護できます。
この手順では、JBoss EAP スタンドアロンインスタンスまたはドメインとの暗号化されていない通信は無効になっています。このような通信で使用されるパスワードは、JBoss EAP の vault 機能を使用して暗号化され格納されます。また、設定ファイルで使用されるパスワードはマスクされます。
この手順は、standalone および domain モード設定の両方に適用されます。domain モードでは、/host=master のように、ホストの名前を管理 CLI コマンドの前に追加します。

手順5.2

  1. キーストアを作成し、管理コンソールをセキュアにします。

    注記

    管理コンソールは JCEKS 形式のキーストアと互換性がないため、このキーストアは JKS 形式でなければなりません。
    ターミナルエミュレーターで以下のコマンドを入力します。aliaskeypasskeystorestorepass、および 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
  2. 管理コンソールが 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.
  3. 任意設定: カスタム 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}"/>
  4. セキュリティーレルムを新たに作成します。

    以下のコマンドを実行し、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)
  5. 新しいセキュリティーを使用するよう管理インターフェースを設定します。

    以下のコマンドを入力します。
    /host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=ManagementRealmHTTPS)
  6. キーストアを使用するよう管理コンソールを設定します。

    以下の管理 CLI コマンドを入力します。filepassword および 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"
        }
    }
  7. 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

注記

セキュリティー上の理由により、キーストアのパスワードをマスクすることが推奨されます。マスクする方法の詳細は「パスワード valut システム」を参照してください。

5.8. 管理インターフェースへの HTTP および HTTPS 接続に異なるインターフェースを使用

管理インターフェースは HTTP および HTTPS 接続の異なるインターフェースでリッスンできます。その一例として、外部ネットワークの暗号化されたトラフィックをリッスンし、内部ネットワークの暗号化されていないトラフィックを使用することが挙げられます。
interface 属性によって指定されたインターフェースとは異なるインターフェースを使用する場合、secure-interface 属性が HTTPS 管理通信のホストのソケットを開くネットワークインターフェースを指定します。この属性を指定しないと、interface 属性によって指定されたインターフェースが使用されます。
secure-port 属性が設定されていなくても secure-interface 属性には影響はありません。
サーバーが同じインターフェースで HTTP および HTTPS トラフィックをリッスンすると、HTTP リスナーによって受信された HTTPS リクエストは自動的に HTTPS ポートへリダイレクトされることに注意してください。HTTP および HTTPS トラフィックに異なるインターフェースを使用すると、HTTP リスナーによって受信された HTTPS リクエストはリダイレクトされません。
HTTP トラフィックとは異なるインターフェース上で HTTPS トラフィックをリッスンするよう 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 の使用

双方向 SSL 認証は、クライアント認証とも呼ばれ、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

  1. ストアを生成します。
    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
  2. 証明書をエクスポートします。
    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
  3. 証明書を反対のトラストストアにインポートします。
    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
  4. インストールの設定に 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 を追加します。
  5. ネイティブインターフェースの security-realm を新しい証明書レルムに変更します。
    /host=master/core-service=management/management-interface=native-interface:write-attribute(name=security-realm,value=CertificateRealm)
  6. 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 を用いた管理インタフェースのセキュア化

JAAS を使用して管理インターフェースに対して認証を行うには、以下の手順に従います。
最初に、セキュリティードメインを作成し、UserRoles ログインモジュールを指定します。
/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()
次に、セキュリティーレルムを作成し、JAAS 認証を指定します。
/core-service=management/security-realm=SecurityDomainAuthnRealm:add
/core-service=management/security-realm=SecurityDomainAuthnRealm/authentication=jaas:add(name=UsersLMDomain)
assign-groups 属性は、セキュリティードメインからロードされたユーザーメンバーシップ情報がセキュリティーレルムのグループ割り当てに使用されるかどうかを決定します。true に設定すると、このグループの割り当てが RBAC (ロールベースアクセス制御) に使用されます。
以下の CLI コマンドを使用すると 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

LDAP (Lightweight Directory Access Protocol) はディレクトリーの情報をネットワーク全体で保存し分散するプロトコルです。ディレクトリーの情報にはユーザー、ハードウェアデバイス、アクセスロール、制限などの情報が含まれます。
LDAP の一般的な実装には OpenLDAP、Microsoft Active Directory、IBM Tivoli Directory Server、Oracle Internet Directory などがあります。
JBoss EAP 6 には、Web アプリケーションや EJB アプリケーションの認証承認権限として LDAP サーバーを使用できるようにする複数の認証および承認モジュールがあります。

5.11.2. 管理インターフェースに対する LDAP を使用した認証

管理コンソール、管理 CLI、管理 API の認証ソースとして LDAP ディレクトリーサーバーを使用するには、以下の手順を実行する必要があります。
  1. LDAP サーバーへの送信接続を作成します。
  2. LDAP 対応のセキュリティーレルムを作成します。
  3. 管理インターフェースの新規セキュリティードメインを参照します。
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
2 つ目のコマンドによって、LDAP 接続が追加されます。
/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 のオーセンティケーターは、最初にリモートディレクトリーサーバーへの接続を確立します。次に、LDAP レコードの完全修飾識別名 (DN) を探すため、ユーザーが認証システムに渡したユーザー名を使用して検索を実行します。クレデンシャルとしてユーザーの DN とユーザー提供のパスワードを使用して、新規接続が確立されます。 この LDAP サーバーに対するこの検証に成功すると、DN が有効であることが検証されます。

LDAP セキュリティーレルムは次の設定属性を使用します。
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>

警告

空の LDAP パスワードを許可しないようにすることが重要になります。ご使用の環境で具体的に空の LDAP パスワードを許可したい場合を除き、深刻なセキュリティー上の問題となります。
EAP 6.1 には CVE-2012-5629 のパッチが含まれています。このパッチは、LDAP ログインモジュールの allowEmptyPasswords オプションが設定されていない場合にこのオプションを False に設定します。6.1 以前のバージョンでは、このオプションを手作業で設定する必要があります。

例5.12 LDAP セキュリティーレルムの追加

以下のコマンドは、 LDAP 認証をセキュリティーレルムに追加し、ドメインの master という名前のホストに対して属性を設定します。
/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 インターフェースへのセキュリティーレルムの適用

この設定が有効になり、ホストコントローラーを再起動した後、Web ベースの管理コンソールは LDAP を使用してユーザーの認証を行います。
/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 を使用

JBoss EAP 6 では、管理インターフェースおよび CLI での認証に対して双方向 SSL を使用して LDAP サーバーへのアウトバウンド接続を使用するよう設定できます。
要件

手順5.4 双方向 SSL でのアウトバウンド LDAP の設定

  1. セキュリティーレルムのキーストアおよびトラストストアを設定します。セキュリティーレルムには、LDAP サーバーに対して認証を行うために JBoss EAP 6 サーバーが使用するキーを用いて設定されたキーストアが含まれている必要があります。また、セキュリティーレルムには LDAP サーバーの証明書を用いて設定されたトラストストアが含まれている必要もあります。キーストアとトラストストアの設定方法は、「管理インターフェースおよび CLI に対する双方向 SSL の使用」を参照してください。
  2. 設定されたセキュリティーレルムを指定し、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")
  3. 「管理インターフェースに対する LDAP を使用した認証」に示されたとおり、セキュリティーレルムおよび管理インターフェース内に LDAP 認証を設定します。

第6章 ロールベースアクセス制御を用いた管理インターフェースのセキュア化

6.1. ロールベースアクセス制御 (RBAC)

ロールベースアクセスコントロール (RBAC) は、管理ユーザーのパーミッションセットを指定するメカニズムです。これにより、無制限のアクセスを必要とせずに複数のユーザーが JBoss EAP 6.3 の管理業務を共有できます。JBoss EAP 6.3 は管理ユーザーの「職務の分離」を実現することで、不必要な特権を与えずに組織における個人またはグループの業務分散を容易にします。これにより、設定、デプロイメント、および管理の柔軟性を維持しながらサーバーやデータのセキュリティーを可能な限り強化できます。

JBoss EAP 6.3 のロールベースアクセス制御は、ロールパーミッションと制約の組み合わせにより動作します。

異なる固定パーミッションを持つ 7 つのロールが事前定義されています。事前定義されたロールは Monitor、Operator、Maintainer、Deployer、Auditor、Administrator、および SuperUser です。各管理ユーザーには 1 つ以上のロールが割り当てられます。各ロールは、サーバーを管理するときにユーザーが実行できる操作を指定します。

6.2. 管理コンソールおよび CLI でのロールベースアクセス制御

ロールベースアクセス制御 (RBAC) が有効になっている場合、ユーザーに割り当てられたロールによって、ユーザーがアクセスできるリソースやリソースの属性を用いて実行できる操作が決定されます。
管理コンソール

管理コンソールでは、ユーザーに割り当てられたロールのパーミッションによっては、制御およびビューの一部が無効化 (灰色で表示) されたり、全く表示されないことがあります。

リソース属性に対する読み取りパーミッションがない場合、その属性は管理コンソールでは空白で表示されます。たとえば、ほとんどのロールは、データソースのユーザー名およびパスワードフィールドを読み取りできません。

リソース属性に対する書き込みパーミッションがない場合、その属性はリソースの編集フォームで無効化 (灰色で表示) されます。リソースに対する書き込みパーミッションがない場合、リソースの編集ボタンは表示されません。

ユーザーがリソースまたは属性へアクセスするパーミッションを持たない場合 (ロールに対して「アドレス不可能」な場合)、コンソールではそのユーザーに対するリソースまたは属性が表示されません。アクセス制御システム自体がこの例で、デフォルトでは少数のロールのみに対して表示されます。
管理 CLI または API

RBAC が有効である場合、API での 管理 CLI や管理 API の動作が若干異なります。

読み取りできないリソースや属性は結果からフィルターされます。フィルターされた項目がロールによってアドレス可能である場合、結果の response-headers セクションにこれらの名前が filtered-attributes としてリストされます。リソースまたは属性がロールによってアドレス可能でない場合は、リストされません。

アドレス不可能なリソースにアクセスしようとすると、resource not found (リソースが見つかりません) というエラーが発生します。

適切な読み書きパーミッションのないユーザーが、アドレス可能なリソースを読み書きしようとすると、Permission Denied (パーミッションが拒否されました) というエラーが返されます。

6.3. サポートされる認証スキーム

ロールベースアクセス制御は、JBoss EAP 6.3 に含まれる標準の認証プロバイダーと動作します。標準の認証プロバイダーは username/passwordclient certificate、および local user です。
Username/Password

ユーザーはユーザー名とパスワードの組み合わせを使用して認証されます。この組み合わせは、mgmt-users.properties ファイルまたは LDAP サーバーに対して検証されます。
Client Certificate

トラストストアを使用します。
Local User

同じマシン上で実行されているサーバーの場合、jboss-cli.sh は自動的に Local User として認証します。デフォルトでは、Local User は SuperUser グループのメンバーになります。
使用されるプロバイダーに関係なく、JBoss EAP はロールをユーザーに割り当てます。しかし、mgmt-users.properties ファイルまたは LDAP サーバーで認証する場合、これらのシステムはユーザーグループ情報を提供できます。ユーザーグループ情報は、ロールをユーザーに割り当てるために JBoss EAP が使用することも可能です。

6.4. 標準のロール

JBoss EAP 6 は、Monitor、Operator、Maintainer、Deployer、Auditor、Administrator、および SuperUser の 7 つの事前定義されたユーザーロールを提供します。各ロールは特定のユースケース向けに設定されており、異なるパーミッションセットを持ちます。Monitor、Operator、Maintainer、Administrator、および SuperUser ロールは、それぞれ前のレベルのロールから継承したパーミッションと追加のパーミッションを持ちます。Auditor および Deployer ロールはそれぞれ Monitor および Maintainer ロールに似ていますが、特別なパーミッションおよび制限が追加されています。
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. ロールパーミッション

各ロールの権限は、各ロールのパーミッションによって定義されます。すべてのロールにすべてのパーミッションがあるわけではありません。SuperUser はすべてのパーミッションを持ちますが、Monitor のパーミッションは最も少なくなります。
各パーミッションは、リソースの単一のカテゴリーに対して読み書きのアクセスを付与します。
カテゴリーは、ランタイム状態、サーバー設定、機密データ、監査ログ、およびアクセス制御システムです。
表6.1「ロールパーミッション」 は各ロールのパーミッションを示しています。

表6.1 ロールパーミッション

 

Monitor

Operator

Maintainer

Deployer

Auditor

Administrator

SuperUser

設定と状態の読み取り

機密データの読み取り [2]
    

機密データの変更 [2]
     

監査ログの読み取り/変更
    

 

起動状態の変更
 

○[1]
 

永続化設定の変更
  

○[1]
 

アクセス制御の読み取り/変更
     

[1] パーミッションはアプリケーションリソースに制限されます。
[2] 機密性制約 (Sensitivity Constraint) を使用して「機密データ」として考慮されるリソースを設定します。

6.6. 制約

制約は、指定のリソースリストに対するアクセス制御設定の名前付きセットです。RBAC システムは制約とロールパーミッションの組み合わせを使用し、特定ユーザーが管理アクションを実行できるかどうかを判断します。

制約は、アプリケーション、機密性、および Vault 式の 3 つに分類されます。
アプリケーション制約

アプリケーション制約は、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 およびロールベースアクセス制御

ロールベースアクセス制御は、次の 3 つの方法で JMX に適用されます。
  1. JBoss EAP 6 の管理 API は JXM 管理 Bean として公開されます。これらの管理 Bean は「コア MBean」と呼ばれ、コア MBean へのアクセスは基盤の管理 API と全く同じように制御およびフィルターされます。
  2. JMX サブシステムは、書き込みパーミッションが「機密」で設定されます。そのため、Administrator および SuperUser ロールのユーザーのみがそのサブシステムに変更を追加できます。Auditor ロールのユーザーはこのサブシステムの設定を読み取りできます。
  3. デフォルトでは、デプロイされたアプリケーションおよびサービスによって登録された管理 Bean (コアでない MBean) へすべての管理ユーザーがアクセスできますが、Maintainer、Operator、Administrator、および SuperUser ロールのユーザーのみが書き込み可能です。

6.8. ロールベースアクセス制御の設定

6.8.1. RBAC 設定タスクの概要

RBAC が有効になっている場合、Administration および SuperUser ロールのユーザーのみがアクセス制御システムを表示し、変更を追加できます。
管理コンソールは、以下の一般的な RBAC タスクに対してインターフェースを提供します。
  • 各ユーザーへ割り当てられた (または除外された) ロールの表示および設定
  • 各グループへ割り当てられた (または除外された) ロールの表示および設定。
  • ロールごとのグループおよびユーザーメンバーシップの表示。
  • ロールごとのデフォルトメンバーシップの設定。
  • スコープ指定されたロールの作成。
管理 CLI は完全なアクセス制御システムへのアクセスを提供します。そのため、管理コンソールで行えることはすべて管理 CLI で行えますが、管理コンソールでは実行できない複数のタスクを 管理 CLI で実行できます。
管理 CLI で実行できる追加のタスクは次のとおりです。
  • RBAC の有効化および無効化
  • パーミッション組み合わせポリシーの変更
  • アプリケーションリソースおよびリソース機密性の制約の設定

6.8.2. ロールベースアクセス制御の有効化

デフォルトでは、ロールベースアクセス制御 (RABC) システムは無効になっています。有効にするには、プロバイダー属性を simple から rbac に変更します。この変更を行うには管理 CLI を使用しますが、サーバーがオフラインの場合はサーバー設定 XML ファイルを編集して変更できます。RBAC が稼働中のサーバー上で無効または有効になっている場合は、サーバー設定をリロードして変更を反映する必要があります。
一旦 RBAC を有効にすると、無効にできるのは Administrator または SuperUser ロールのユーザーのみです。デフォルトでは、サーバーと同じマシン上で実行されている場合、管理 CLI が 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
    }
サーバーがオフラインの場合は、XML 設定を編集して RBAC を有効または無効にできます。これを行うには、管理要素の 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]
    
サーバーがオフラインの場合は、XML 設定を編集してパーミッション組み合わせポリシーの値を変更できます。これを行うには、アクセス制御要素の 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. ロールメンバーシップ

ロールベースアクセス制御 (RBAC) が有効になっている場合、管理ユーザーに割り当てられたロールがそのユーザーに許可されるアクションを決定します。JBoss EAP 6.3 は、ユーザーおよびグループメンバーシップを基に、include (含まれる) および exclude (除外される) を使用して、ユーザーが属するロールを決定します。

以下の場合に、ロールがユーザーに割り当てられたとみなされます。
  1. ユーザーが以下のいずれかである場合。
    • ロールに含まれるユーザーとしてリストに記載されている。
    • ロールに含まれるとリストに記載されたグループのメンバーである。
  2. ユーザーが以下のいずれかに該当しない場合。
    • ロールから除外されるユーザーとしてリストに記載されている。
    • ロールから除外されるとリストに記載されたグループのメンバーである。

exclude は include よりも優先度が高くなります。

ユーザーおよびグループに対するロールの include および exclude 設定は、管理コンソールと管理 CLI の両方を使用して設定できます。

SuperUser または Administrator ロールのユーザーのみがこの設定を行えます。

6.9.2. ユーザーロール割り当ての設定

include (含まれる) および exclude (除外) されるユーザーロールは、管理コンソールおよび 管理 CLI で設定できます。ここでは、管理コンソールを使用した設定のみを説明します。
この設定が行えるのは SuperUser または Administrator ロールのユーザーのみです。

以下の手順で、管理コンソールのユーザーロール設定を確認します。
  1. 管理コンソールへログインします。
  2. Administration タブをクリックします。
  3. Access Control メニューを展開し、Role Assignment を選択します。
  4. USERS タブを選択します。

手順6.4 ユーザーの新しいロール割り当ての作成

  1. 管理コンソールへログインします。
  2. Role Assignment セクションの Users タブに移動します。
  3. ユーザーリストの右上にある Add ボタンをクリックします。Add User ダイアログが表示されます。
    Screenshot of Add User Dialog

    図6.1 Add User ダイアログ

  4. ユーザー名を指定し、任意でレルムを指定します。
  5. Type メニューを include または exclude に設定します。
  6. include または exclude するロールのチェックボックスをクリックします。Control キー (OSX では Command キー) を押しながらクリックすると、複数のチェックボックスを選択できます。
  7. Save をクリックして終了します。
    正常に保存されると、Add User ダイアログが閉じられます。ユーザーのリストが更新され、変更内容が反映されます。正常に保存されなかった場合は、Failed to save role assignment というメッセージが表示されます。

手順6.5 ユーザーロール割り当ての更新

  1. 管理コンソールへログインします。
  2. Role Assignment セクションの Users タブに移動します。
  3. リストよりユーザーを選択します。
  4. Edit をクリックします。選択パネルが編集モードになります。
    Screenshot of Selection Edit View

    図6.2 Selection Edit ビュー

    ここで、ユーザーに割り当てられたロールや除外されたロールを追加および削除できます。
    1. 割り当てられたロールを追加するには、左側の使用可能なロールのリストからロールを選択し、割り当てられたロールリストの横にある、右矢印のボタンをクリックします。ロールが、使用可能なロールのリストから割り当てられたロールのリストに移動します。
    2. 割り当てられたロールを削除するには、割り当てられたロールのリストからロールを選択し、割り当てられたロールリストの横にある左矢印のボタンをクリックします。ロールが、割り当てられたロールのリストから使用可能なロールのリストへ移動します。
    3. 除外されたロールを追加するには、左側の使用可能なロールのリストからロールを選択し、除外されたロールリストの横にある、右矢印のボタンをクリックします。ロールが、使用可能なロールのリストから除外されたロールのリストに移動します。
    4. 除外されたロールを削除するには、除外されたロールのリストからロールを選択し、除外されたロールリストの横にある左矢印のボタンをクリックします。ロールが、除外されたロールのリストから使用可能なロールのリストへ移動します。
  5. Save をクリックして終了します。
    正常に保存されると、編集ビューが閉じられます。ユーザーのリストが更新され、変更内容が反映されます。正常に保存されなかった場合は、Failed to save role assignment というメッセージが表示されます。

手順6.6 ユーザーのロール割り当ての削除

  1. 管理コンソールへログインします。
  2. Role Assignment セクションの Users タブへ移動します。
  3. リストよりユーザーを選択します。
  4. Remove をクリックします。Remove Role Assignment 確認プロンプトが表示されます。
  5. Confirm をクリックします。
    正しく削除されると、ユーザーロール割り当てのリストにユーザーが表示されなくなります。

重要

ロール割り当てのリストからユーザーを削除しても、ユーザーはシステムから削除されず、ユーザーにロールが割り当てられなくなる保証はありません。ロールはグループメンバーシップから割り当てられる可能性があります。

6.9.3. 管理 CLI を用いたユーザーロール割り当ての設定

include (含まれる) および exclude (除外) されるユーザーロールは、管理コンソールおよび 管理 CLI で設定できます。ここでは、管理 CLI を使用した設定のみを説明します。
ユーザーおよびグループをロールへマッピングする設定は、管理 API の role-mapping 要素とする /core-service=management/access=authorization にあります。
SuperUser または Administrator ロールのユーザーのみがこの設定を行えます。
コマンドへのアクセスを容易にするため、管理 CLI では /core-service=management/access=authorization の場所を変更します。
[standalone@localhost:9999] cd /core-service=management/access=authorization

手順6.7 ロール割り当て設定の表示

  1. :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"
        ]
    }
  2. 指定されたロールマッピングの 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 されるユーザーの追加

この手順では、ユーザーをロールの 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 されるユーザーの追加

この手順では、ユーザーをロールの 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 設定の削除

この手順では、ロールマッピングからユーザー 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 設定の削除

この手順では、ロールマッピングからユーザー 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 名以上のユーザーに割り当てできる任意のラベルです。
RBAC システムは、ユーザーがメンバーであるユーザーグループに応じて自動的にロールをユーザーに割り当てるよう設定できます。また、グループメンバーシップを基にユーザーをロールから exclude (除外) することも可能です。
mgmt-users.properties ファイルを使用する場合、グループ情報は mgmt-groups.properties ファイルに保存されます。LDAP を使用する場合、グループ情報は LDAP サーバーに保存され、LDAP サーバーの管理者によって維持されます。

6.9.5. グループロール割り当ての設定

ユーザーグループのユーザーのメンバーシップを基に、ロールをユーザーに割り当てできます。
include (含まれる) または exclude (除外) されるグループロールは、管理コンソールおよび 管理 CLI で設定できます。ここでは、管理コンソールを使用した設定のみを説明します。
この設定が行えるのは SuperUser または Administrator ロールのユーザーのみです。
以下の手順で、管理コンソールのグループロール設定を確認します。
  1. 管理コンソールへログインします。
  2. Administration タブをクリックします。
  3. Access Control メニューを展開し、Role Assignment を選択します。
  4. GROUPS タブを選択します。

手順6.13 グループの新しいロール割り当ての作成

  1. 管理コンソールへログインします。
  2. Role Assignment セクションの GROUPS タブに移動します。
  3. ユーザーリストの右上にある Add ボタンをクリックします。Add Group ダイアログが表示されます。
    Screenshot of Add Group dialog

    図6.3 Add Group ダイアログ

  4. グループ名を指定し、任意でレルムを指定します。
  5. Type メニューを include または exclude に設定します。
  6. include または exclude するロールのチェックボックスをクリックします。Control キー (OSX では Command キー) を押しながらクリックすると、複数のチェックボックスを選択できます。
  7. Save をクリックして終了します。
    正常に保存されると、Add Group ダイアログが閉じられます。グループのリストが更新され、変更内容が反映されます。正常に保存されなかった場合は、Failed to save role assignment というメッセージが表示されます。

手順6.14 グループロール割り当ての更新

  1. 管理コンソールへログインします。
  2. Role Assignment セクションの GROUPS タブへ移動します。
  3. リストよりグループを選択します。
  4. Edit をクリックします。Selection ビューが編集モードになります。
    Screenshot of Selection View in Edit Mode

    図6.4 Selection ビュー編集モード

    ここで、グループに割り当てられたロールや除外されたロールを追加および削除できます。
    • 割り当てられたロールを追加するには、左側の使用可能なロールのリストからロールを選択し、割り当てられたロールリストの横にある、右矢印のボタンをクリックします。ロールが、使用可能なロールのリストから割り当てられたロールのリストに移動します。
    • 割り当てられたロールを削除するには、割り当てられたロールのリストからロールを選択し、割り当てられたロールリストの横にある左矢印のボタンをクリックします。ロールが、割り当てられたロールのリストから使用可能なロールのリストへ移動します。
    • 除外されたロールを追加するには、左側の使用可能なロールのリストからロールを選択し、除外されたロールリストの横にある、右矢印のボタンをクリックします。ロールが、使用可能なロールのリストから除外されたロールのリストに移動します。
    • 除外されたロールを削除するには、除外されたロールのリストからロールを選択し、除外されたロールリストの横にある左矢印のボタンをクリックします。ロールが、除外されたロールのリストから使用可能なロールのリストへ移動します。
  5. Save をクリックして終了します。
    正常に保存されると、編集ビューが閉じられます。グループのリストが更新され、変更内容が反映されます。正常に保存されなかった場合は、Failed to save role assignment というメッセージが表示されます。

手順6.15 グループのロール割り当ての削除

  1. 管理コンソールへログインします。
  2. Role Assignment セクションの GROUPS タブへ移動します。
  3. リストよりグループを選択します。
  4. Remove をクリックします。Remove Role Assignment 確認プロンプトが表示されます。
  5. Confirm をクリックします。
    正しく削除されると、グループロール割り当てのリストにロールが表示されなくなります。
    ロール割り当てのリストからグループを削除しても、ユーザーグループはシステムから削除されず、そのグループのメンバーにロールが割り当てられなくなる保証はありません。各グループメンバーに直接ロールが割り当てられる可能性があります。

6.9.6. 管理 CLI を用いたグループロール割り当ての設定

include (含まれる) または exclude (除外) されるグループロールは、管理コンソールおよび 管理 CLI で設定できます。ここでは、管理 CLI を使用した設定のみを説明します。
ユーザーおよびグループをロールへマッピングする設定は、管理 API の role-mapping 要素とする /core-service=management/access=authorization にあります。
この設定を行えるのは、SuperUser または Administrator ロールのユーザーのみです。
コマンドへのアクセスを容易にするため、管理 CLI では /core-service=management/access=authorization の場所を変更します。
[standalone@localhost:9999] cd /core-service=management/access=authorization

手順6.16 グループロール割り当て設定の表示

  1. 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"
        ]
    }
  2. 指定されたロールマッピングの 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 されるユーザーの追加

この手順では、グループをロールの 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 されるグループの追加

この手順では、グループをロールの 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 設定の削除

この手順では、ロールマッピングからグループ 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 エントリーの削除

この手順では、ロールマッピングからグループ 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 での承認とグループローディング

LDAP ディレクトリーには、属性によって相互参照されるユーザーアカウントとグループのエントリーが含まれます。LDAP サーバーの設定によっては、memberOf 属性を用いてユーザーエンティティーがユーザーが属するグループをマップしたり、 uniqueMember 属性を用いてグループエンティティーが属するユーザーをマップしたりすることがあります。また、両方のマッピングが LDAP サーバーによって維持されることもあります。
通常、ユーザーは簡単なユーザー名を使用してサーバーに対して認証を行います。グループメンバーシップ情報を検索する場合、使用中のディレクトリーサーバーに応じて、検索がこの単純名を使用して実行されたり、ディレクトリーのユーザーエントリーの識別名を使用して実行されたりします。
必ず最初に、サーバーへ接続するユーザーを認証する手順が実行されます。ユーザーの認証に成功した後、サーバーはサーバーグループをロードします。認証手順と承認手順はそれぞれ 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 が有効である必要があるため、& などの特殊文字が使用される場合は、適切な形式が使用されるようにしてください。たとえば、& 文字には &amp; を使用します。

グループ検索

グループメンバーシップ情報の検索に 2 つのスタイルを使用できます。1 つ目のスタイルは、ユーザーがメンバーであるグループを参照する属性が含まれるユーザーのエントリーで、2 つ目のスタイルは、ユーザーエントリーを参照する属性が含まれるグループです。

使用するスタイルを選択できる場合、Red Hat はグループを参照するユーザーのエントリーに対する設定を使用することを推奨します。これは、検索を実行せずに既知の識別名の属性を読み取り、グループ情報をロードできるからです。別の方法は、ユーザーを参照するグループを特定するために大がかりな検索が必要となります。

設定を記述する前に、LDIF の例を見てみましょう。

例6.1 LDIF の例: プリンシパルからグループ

この例では、ユーザー TestUserOneGroupOne のメンバーで、 GroupOneGroupFive のメンバーです。グループメンバーシップは、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 の例: グループからプリンシパル

この例でも、ユーザー TestUserOneGroupOne のメンバーで、 GroupOneGroupFive のメンバーですが、相互参照にはグループからユーザーへ属性 uniqueMember が使用されます。

グループメンバーシップの相互参照に使用される属性は繰り返しが可能で、GroupFive を確認すると、別のユーザー TestUserFive への参照があります (ここでは示されていません)。
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

一般的なグループ検索

前述の 2 つの方法の例を確認する前に、両方の方法に共通する属性を定義する必要があります。
<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 プリンシパルからグループへの設定例

前述の LDIF の例を基にした、ユーザーのグループを繰り返しロードする設定の例は次のとおりです。相互参照に使用される属性はユーザーの 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 グループからプリンシパルへの設定例

この例は、前述のグループからプリンシパルへの LDIF の例に対する繰り返し検索を示しています。
<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 です。

group-to-principal 要素内に、相互参照を定義する membership-filter 要素があります。
  • principal-attribute: ユーザーエントリーを参照する、グループエントリー上の属性名。デフォルトは member です。

6.9.8. スコープ指定ロール

スコープ指定ロールは、指定された 1 つ以上のサーバーグループまたはホストに対してのみ、1 つの標準ロールのパーミッションを付与するユーザー定義のロールです。スコープ指定ロールにより、必要なサーバーグループやホストのみに限定されるパーミッションを管理ユーザーに付与できます。

Administrator または SuperUser ロールが割り当てされたユーザーがスコープ指定ロールを作成できます。

スコープ指定ロールは 5 つの特性によって定義されます。
  1. 一意名。
  2. ベースになる標準ロール。
  3. サーバーグループまたはホストへ適用されるかどうか。
  4. スコープ指定ロールが制限されるサーバーグループまたはホストのリスト。
  5. すべてのユーザーが自動的に含まれるかどうか。デフォルトは false です。

スコープ指定ロールの作成後、標準ロールと同様にユーザーやグループへ割り当てできます。

スコープ指定ロールを作成しても、新しいパーミッションは定義できません。スコープ指定ロールは、既存ロールのパーミッションを制限されたスコープで適用するために使用されます。たとえば、単一のサーバーグループに制限される Deployer ロールを基にスコープ指定ロールを作成できます。

ロールは、ホストとサーバーグループの 2 つのスコープのみに限定されます。
ホストスコープ指定ロール

ホストスコープ指定されたロールは、そのロールのパーミッションを 1 つ以上のホストに制限します。これにより、関連する /host=*/ リソースツリーにアクセスできますが、他のホスト固有のリソースは表示されません。
サーバーグループスコープ指定ロール

サーバーグループスコープ指定のロールは、そのロールのパーミッションを 1 つ以上のサーバーグループに制限します。さらに、ロールパーミッションは、指定されたサーバーグループに関連するプロファイル、ソケットバインディンググループ、サーバー設定、およびサーバーリソースにも適用されます。サーバーグループに論理的に関連しないリソース内のサブリソースは、ユーザーに対して表示されません。

ホストおよびサーバーグループスコープ指定ロールは、その他の管理対象ドメイン設定に対して Monitor ロールのパーミッションを持ちます。

6.9.9. スコープ指定ロールの作成

スコープ指定ロールは、指定された 1 つ以上のサーバーグループまたはホストに対してのみ、1 つの標準ロールのパーミッションを付与するユーザー定義のロールです。ここでは、スコープ指定ロールの作成方法を説明します。

この設定が行えるのは SuperUser または Administrator ロールのユーザーのみです。

管理コンソールのスコープ指定ロール設定は、以下の手順で確認できます。
  1. 管理コンソールへログインします。
  2. Administration タブをクリックします。
  3. Access Control メニューを展開し、Role Assignment を選択します。
  4. ROLES タブを選択し、そのタブ内にある Scoped Roles タブを選択します。
管理コンソールの Scoped Roles セクションは、現在設定されているスコープ指定ロールのリストが含まれるテーブルと、テーブルで現在選択されているロールの詳細を表示する Selection パネルの 2 つの主なエリアで構成されます。
スコープ指定ロールの設定タスクを実行する手順は次のとおりです。

手順6.22 新しいスコープ指定ロールの追加

  1. 管理コンソールへログインします。
  2. Roles タブの Scoped Roles エリアに移動します。
  3. Add をクリックします。Add Scoped Role ダイアログが表示されます。
  4. 次の詳細を指定します。
    • Name: 新しいスコープ指定ロールの一意名。
    • Base Role: このロールのパーミッションがベースとなるロール。
    • Type: このロールがホストまたはサーバーグループに制限されるかどうか。
    • Scope: ロールが制限されるホストまたはサーバーグループのリスト。複数のエントリーを選択できます。
    • Include All: このロールにすべてのユーザーが自動的に含まれるかどうか。デフォルトは no です。
  5. Save ボタンをクリックすると、ダイアログが閉じられ、新規作成されたロールがテーブルに表示されます。

手順6.23 スコープ指定ロールの編集

  1. 管理コンソールへログインします。
  2. Roles タブの Scoped Roles エリアに移動します。
  3. テーブル上で編集するスコープ指定ロールをクリックします。ロールの詳細がテーブルの下の Selection パネルに表示されます。
  4. Selection パネルの Edit をクリックします。Selection パネルが編集モードになります。
  5. 変更する必要がある詳細を変更し、Save ボタンをクリックします。Selection パネルが以前の状態に戻ります。Selection パネルとテーブルの両方に、新たに更新された詳細が表示されます。

手順6.24 スコープ指定ロールメンバーの表示

  1. 管理コンソールへログインします。
  2. Roles タブの Scoped Roles エリアに移動します。
  3. テーブル上で、Members を表示したいスコープ指定ロールをクリックし、Members をクリックします。Members of role ダイアログが表示されます。このダイアログには、ロールに含まれるまたは除外されるユーザーとグループが表示されます。
  4. 情報を確認した後、Done ボタンをクリックします。

手順6.25 スコープ指定ロールの削除

重要

ユーザーまたはグループが Scoped Role に割り当てられている場合、Scoped Role は削除できません。ロールの割り当てを解除してから削除してください。
  1. 管理コンソールへログインします。
  2. Roles タブの Scoped Roles エリアに移動します。
  3. テーブル上で、削除するスコープ指定ロールを選択します。
  4. Remove ボタンをクリックします。Remove Scoped Role ダイアログが表示されます。
  5. Confirm ボタンをクリックします。ダイアログが閉じられ、ロールが削除されます。

6.10. 制約の設定

6.10.1. 機密性制約の設定

各機密性制約は、「機密」とみなされるリソースのセットを定義します。通常、機密リソースとは、パスワードなどの秘密にしなければならないリソースや、ネットワーキング、JVM 設定、システムプロパティーなどのサーバーに深刻な影響を与えるリソースのことです。アクセス制御システム自体も機密とみなされます。リソースの機密性は、特定リソースの読み取り、書き込み、またはアドレス指定の可能なロールを制限します。

機密性制約の設定は、管理 API の /core-service=management/access=authorization/constraint=sensitivity-classification にあります。

管理モデル内で、各機密性制約は classification として識別されます。classification (分類) は types にグループ化されます。39 個の分類が含まれ、それらは 13 個のタイプにグループ化されます。

機密性の制約を設定するには、write-attribute 操作を使用して configured-requires-readconfigured-requires-write、または configured-requires-addressable 属性を設定します。操作のタイプを機密にするには、true を値として設定します。機密にしない場合は false を設定します。デフォルトではこれらの属性は設定されておらず、default-requires-readdefault-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「機密性制約の設定結果」 に説明されている属性の設定によって異なります。

表6.2 機密性制約の設定結果

requires-readrequires-writerequires-addressable

true

読み取りは機密です。

AuditorAdministrator、および SuperUser のみ読み取りできます。

書き込みは機密です。

Administrator および SuperUser のみ書き込みできます。

アドレス指定は機密です。

AuditorAdministrator、および SuperUser のみアドレス可能です。

false

読み取りは機密ではありません。

すべての管理ユーザーが読み取りできます。

書き込みは機密ではありません。

MaintainerAdministrator、および SuperUser のみ書き込みできます。Deployers はアプリケーションリソースのアプリケーションを書き込みできます。

アドレス指定は機密ではありません。

すべての管理ユーザーがアドレス指定できます。

6.10.2. アプリケーションリソース制約の設定

各アプリケーションリソース制約は、アプリケーションおよびサービスのデプロイメントに関連するリソース、属性、および操作のセットを定義します。アプリケーションリソース制約が有効になっていると、Deployer ロールの管理ユーザーは適用されるリソースへアクセスできます。

アプリケーション制約の設定は、管理モデルの /core-service=management/access=authorization/constraint=application-classification/ にあります。

管理モデル内で、各アプリケーションリソース制約は classification として識別されます。classification (分類) は types にグループ化されます。14 個の分類が含まれ、それらは 8 つのタイプにグループ化されます。各分類には、分類設定が適用されるリソースパスパターンのリストである applies-to 要素が含まれます。

デフォルトでは、有効になっているアプリケーションリソース分類は core のみです。core にはデプロイメント、デプロイメントオーバーレイ、およびデプロイメント操作が含まれます。

アプリケーションリソースを有効にするには、write-attribute 操作を使用して、分類の configured-application attributetrue に設定します。アプリケーションリソースを無効にするには、この属性を 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 式制約の設定

デフォルトでは、vault 式の読み書きは機密操作になっています。vault 式の制約を設定すると、読み取りと書き込みのどちらかまたは両方を非機密の操作にすることができます。この制約を変更すると、vault 式を読み書きできるロールの数を増やすことができます。

vault 式の制約は、管理モデルの /core-service=management/access=authorization/constraint=vault-expression にあります。

vault 式の制約を設定するには、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]

どのロールが vault 式へ読み書きできるかは、表6.3「vault 式制約の設定結果」 に説明されている設定によって異なります。

表6.3 vault 式制約の設定結果

requires-readrequires-write

true

読み取り操作は機密です。

AuditorAdministrator、および SuperUser のみ読み取りできます。

書き込み操作は機密です。

Administrator および SuperUser のみ書き込みできます。

false

読み取り操作は機密ではありません。

すべての管理ユーザーが読み取りできます。

書き込み操作は機密ではありません。

MaintainerAdministrator、および 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 システム

JBoss EAP 6 にはパスワード vault が含まれています。このパスワード vault は、機密性の高い文字列を暗号化して暗号化されたキーストアに保存し、アプリケーションや検証システムに対して復号化します。
XML デプロイメント記述子などのプレーンテキストの設定ファイルには、パスワードなどの機密性の高い情報を指定する必要があります。
JBoss EAP のパスワード vault を使用して、プレーンテキストファイルの機密性の高い文字列をセキュアに保存します。

7.2. 機密性が高い文字列を格納する Java キーストアの作成

要件

  • keytool コマンドを使用できる必要があります。これは Java Runtime Environment (JRE) により提供されます。このファイルのパスを見つけます。Red Hat Enterprise Linux では、これは /usr/bin/keytool にインストールされます。

警告

JCEKS キーストア実装は Java ベンダーによって異なります。使用する JDK と同じベンダーの keytool を使用して vault.keystore を生成する必要があります。
あるベンダーの JDK の keytool によって生成された vault を別のベンダーの JDK で実行されている EAP インスタンスで使用すると、以下の例外が発生します。
java.io.IOException: com.sun.crypto.provider.SealedObjectForKeyProtector

手順7.1 Java キーストアの設定

  1. キーストアと他の暗号化された情報を格納するディレクトリーを作成します。

    キーストアと他の重要な情報を保持するディレクトリーを作成します。この残りの手順では、ディレクトリーが EAP_HOME/vault/ であることを前提とします。このディレクトリーには機密情報が含まれるため、限られたユーザーのみがアクセスできるようにする必要があります。JBoss EAP が実行されるユーザーアカウントでは、最低でも読み書きアクセスが必要です。
  2. keytool で使用するパラメーターを決定します。

    以下のパラメーターを決定します。
    alias
    エイリアスは資格情報コンテナまたはキーストアに格納された vault または他のデータの一意の ID です。この手順の最後にあるコマンド例のエイリアスは vault です。エイリアスは大文字と小文字を区別します。
    keyalg
    暗号化に使用するアルゴリズム。この手順の例では AES を使用します。利用可能な他の選択肢については、JRE およびオペレーティングシステムのドキュメンテーションを参照してください。
    keysize
    暗号化キーのサイズは、ブルートフォース攻撃で復号化を行う難しさに影響します。この手順の例では、128 を使用します。適切な値についての詳細情報は、keytool で配布されるドキュメントを参照してください。
    keystore
    暗号化された情報と暗号化方法に関する情報を保持するデータベースのキーストア。キーストアを指定しない場合、使用するデフォルトのキーストアはホームディレクトリーの .keystore という名前のファイルです。これは、キーストアにデータを初めて追加したときに作成されます。この手順の例では、vault.keystore キーストアを使用します。
    keytool コマンドには他にも多くのオプションがあります。詳細については、JRE またはオペレーティングシステムのドキュメンテーションを参照してください。
  3. keystore コマンドが尋ねる質問の回答を決定します。

    keystore は、キーストアエントリーに値を入力するために次の情報を必要とします。
    キーストアパスワード
    キーストアを作成する場合は、パスワードを設定する必要があります。将来キーストアを使用するために、パスワードを提供する必要があります。覚えやすい強度の高いパスワードを作成します。キーストアは、パスワードや、キーストアが存在するファイルシステムおよびオペレーティングシステムのセキュリティーと同程度にセキュアです。
    キーパスワード (任意設定)
    キーストアパスワードに加え、保持する各キーにパスワードを指定することが可能です。このようなキーを使用するには、使用するたびにパスワードを提供する必要があります。通常、このファシリティーは使用されません。
    名前 (名) と 名字 (姓)
    この情報と一覧の他の情報は、一意にキーを識別して他のキーの階層に置くのに役立ちます。名前である必要はありませんが、キーに一意な 2 つの言葉である必要があります。この手順の例では、Accounting Administrator を使用します。これが証明書のコモンネームになります。
    組織単位
    証明書を使用する人物を特定する単一の言葉です。アプリケーションユニットやビジネスユニットである場合もあります。この手順の例では AccountingServices を使用します。通常、1 つのグループやアプリケーションによって使用されるキーストアはすべて同じ組織単位を使用します。
    組織
    通常、所属する組織名を表す単一の言葉になります。一般的に、1 つの組織で使用されるすべての証明書で同じになります。この例では MyOrganization を使用します。
    市または自治体
    お住まいの市名。
    州または県
    お住まいの州や県、または同等の行政区画。
    2 文字の国コード。
    これらすべての情報によってキーストアや証明書の階層が作成され、一貫性のある一意な名前付け構造が確実に使用されるようにします。
  4. 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 の初期化

  1. vault.sh コマンドを実行します。

    EAP_HOME/bin/vault.sh を実行します。0 を入力して新しい対話セッションを開始します。
  2. 暗号化されたファイルが保存されるディレクトリーを入力します。

    限られたユーザーのみがこのディレクトリーにアクセスできるようにする必要があります。JBoss EAP が実行されるユーザーアカウントでは、最低でも読み書きアクセスが必要です。「機密性が高い文字列を格納する Java キーストアの作成」に従ってキーストアを作成した場合、キーストアは EAP_HOME/vault/ というディレクトリーにあります。

    注記

    必ずディレクトリー名の最後にスラッシュが含まれるようにしてください。ご使用のオペレーティングシステムに応じて / または \ を使用します。
  3. キーストアへのパスを入力します。

    キーストアファイルへのフルパスを入力します。この例では EAP_HOME/vault/vault.keystore を使用します。
  4. キーストアパスワードを暗号化します。

    次の手順に従って、設定ファイルやアプリケーションで安全に使用できるようキーストアのパスワードを暗号化します。
    1. キーストアパスワードを入力します。

      入力を促されたらキーストアのパスワードを入力します。
    2. salt 値を入力します。

      8 文字の salt 値を入力します。salt 値は繰り返す回数 (下記) と共にハッシュ値の作成に使用されます。
    3. 繰り返す回数を入力します。

      繰り返す回数の値を入力します。
    4. マスクされたパスワード情報を書き留めておきます。

      マスクされたパスワード、salt、および繰り返す回数は標準出力へ書き出されます。これらの情報を安全な場所に書き留めておきます。攻撃者がこれらの情報を使用してパスワードを復号化する可能性があるからです。
    5. vault のエイリアスを入力します。

      入力を促されたら、vault のエイリアスを入力します。「機密性が高い文字列を格納する Java キーストアの作成」 に従って vault を作成した場合、エイリアスは vault になります。
  5. 対話コンソールを終了します。

    2 を入力して対話コンソールを終了します。
結果

設定ファイルとデプロイメントで使用するため、キーストアパスワードがマスキングされます。また、vault が完全設定され、すぐ使用できる状態になります。

7.4. パスワード vault を使用するよう JBoss EAP 6 を設定

概要

設定ファイルにあるパスワードや機密性の高いその他の属性をマスキングする前に、これらを保存し復号化するパスワード vault を JBoss EAP 6 が認識するようにする必要があります。次の手順に従ってこの機能を有効にします。

手順7.2 パスワード vault の設定

  1. コマンドの適切な値を決定します。

    キーストアの作成に使用されるコマンドによって決定される以下のパラメーターの値を決定します。キーストア作成の詳細は「機密性が高い文字列を格納する Java キーストアの作成」および「キーストアパスワードのマスキングとパスワード vault の初期化」を参照してください。
    Parameter説明
    KEYSTORE_URL
    ファイルシステムのパスまたはキーストアファイル。通常 vault.keystore のようになります。
    KEYSTORE_PASSWORD
    キーストアのアクセスに使用されるパスワード。この値はマスクされる必要があります。
    KEYSTORE_ALIAS
    キーストアエイリアスの名前。
    SALT
    キーストアの値を暗号化および復号化するために使用される salt。
    ITERATION_COUNT
    暗号化アルゴリズムが実行される回数。
    ENC_FILE_DIR
    キーストアコマンドが実行されるディレクトリーへのパス。通常、パスワード vault が含まれるディレクトリーになります。
    host (管理対象ドメインのみ)
    設定するホストの名前。
  2. 管理 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 のカスタム実装の使用

  1. インターフェース SecurityVault を実装するクラスを作成します。
  2. 前の手順のクラスが含まれるモジュールを作成し、インターフェースが SecurityVault である org.picketbox の依存関係を指定します。
  3. 以下の属性を用いて 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 には、このような機密性の高い文字列をマスキングして暗号化されたキーストアに保存する機能や、設定ファイルでマスクされた値を使用する機能が含まれています。

手順7.4 Java キーストアの設定

  1. vault.sh コマンドを実行します。

    EAP_HOME/bin/vault.sh を実行します。0 を入力して新しい対話セッションを開始します。
  2. 暗号化されたファイルが保存されるディレクトリーを入力します。

    「機密性が高い文字列を格納する Java キーストアの作成」」に従ってキーストアを作成した場合、キーストアは EAP_HOME/vault/ というディレクトリーにあります。ほとんどの場合、暗号化した情報をキーストアと同じ場所に保存することは適切です。このディレクトリーには機密性の高い情報が含まれるため、アクセスできるユーザーを制限する必要があります。最低でも、JBoss EAP を実行するユーザーアカウントには読み書き権限が必要です。

    注記

    必ずディレクトリー名の最後にスラッシュが含まれるようにしてください。ご使用のオペレーティングシステムに応じて / または \ を使用します。
  3. キーストアへのパスを入力します。

    キーストアファイルへのフルパスを入力します。この例では EAP_HOME/vault/vault.keystore を使用します。
  4. キーストアパスワード、vault 名、ソルト、繰り返す回数を入力します。

    入力を促されたら、キーストアパスワード、vault 名、ソルト、繰り返す回数を入力します。ハンドシェイクが実行されます。
  5. パスワードを保存するオプションを選択します。

    オプション 0 を選択して、パスワードや機密性の高い他の文字列を保存します。
  6. 値を入力します。

    入力を促されたら、値を 2 回入力します。値が一致しない場合は再度入力するよう要求されます。
  7. vault ブロックを入力します。

    同じリソースに関連する属性のコンテナである vault ブロックを入力します。属性名の例としては ds_ExampleDS などが挙げられます。データソースまたは他のサービス定義で、暗号化された文字列への参照の一部を形成します。
  8. 属性名を入力します。

    保存する属性の名前を入力します。 password が属性名の例の 1 つになります。
    結果

    以下のようなメッセージによって、属性が保存されたことが示されます。

    Secured attribute value has been stored in vault.
  9. 暗号化された文字列に関する情報を書き留めます。

    メッセージは vault ブロック、属性名、共有キー、および設定で文字列を使用する場合のアドバイスを表示する標準出力を出力します。安全な場所にこの情報を書き留めておくようにしてください。出力例は次のとおりです。
    ********************************************
    Vault Block:ds_ExampleDS
    Attribute Name:password
    Configuration should be done as follows:
    VAULT::ds_ExampleDS::password::1
    ********************************************
  10. 設定で暗号化された文字列を使用します。

    プレーンテキストの文字列の代わりに、前の設定手順の文字列を使用します。以下は、上記の暗号化されたパスワードを使用するデータソースになります。
    ...
      <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 にパスワードを追加します。次に、クリアテキストのパスワードを vault に保存されているパスワードに置き換えます。この方法を使用してアプリケーションの機密性の高い文字列を分かりにくくすることができます。
要件

この手順を実行する前に、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: Exit
0
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: Exit
0
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: Exit
2
Java コードに追加される文字列は、出力の最後の値である VAULT で始まる行です。
次のサーブレットは、クリアテキストのパスワードの代わりに 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) + "");
    }
}
これでサーブレットが vault された文字列を解決できるようになります。

第8章 Web、HTTP コネクター、および HTTP クラスタリング

8.1. mod_cluster ワーカーノードの設定

概要

mod_cluster ワーカーノードは、負荷分散されたクラスターに参加するアプリケーションサーバーです。ユーザーからのリクエストは web サーバーが受信した後、mod_cluster ワーカーノードのプールへ転送します。ワーカーノードは、管理対象ドメインまたはスタンドアロンサーバーのサーバーグループの一部にすることができます。web サーバーの負荷分散については『管理および設定ガイド』の「HTTP コネクターの概要」を参照してください。

負荷分散 web サーバーは 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 という名前のクラスター対応サーバーグループが同梱されます。

注記

管理 CLI コマンドが提供された場合は、管理対象ドメインが使用されると見なされます。スタンドアロンサーバーを使用する場合は、コマンドの /profile=full-ha 部分を削除します。

手順8.1 ワーカーノードの設定

  1. ネットワークインターフェースの設定

    デフォルトでは、ネットワークインターフェースがすべて 127.0.0.1 に設定されます。スタンドアロンサーバーまたはサーバーグループ内の 1 つまたは複数のサーバーをホストする各物理ホストでは、インターフェースが他のサーバーが見つけることができるパブリック IP アドレスを使用するよう設定する必要があります。
    JBoss EAP 6 ホストの IP アドレスを変更するには、ホストをシャットダウンし、設定ファイルを直接編集する必要があります。これは、管理コンソールと管理 CLI を駆動する管理 API は固定管理アドレスに依存するためです。
    クラスター内の各サーバーの IP アドレスをマスターのパブリック IP アドレスに変更するには、次の手順を実行します。
    1. 本トピックでこれまでに説明したプロファイルを使用して JBoss EAP サーバーを起動します。
    2. EAP_HOME/bin/jboss-cli.sh コマンド (Linux の場合) または EAP_HOME\bin\jboss-cli.bat コマンド (Microsoft Windows Server の場合) を使用して管理 CLI を起動します。connect と入力して localhost 上のドメインコントローラーに接続するか、connect IP_ADDRESS と入力してリモートサーバー上のドメインコントローラーに接続します。
    3. 以下のコマンドを入力し、managementpublic、および 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"
    4. 管理対象ドメインに参加するマスターでないホストの場合、ホスト名を master から一意の名前に変更する必要があります。この名前はスレーブ全体で一意となる必要があり、クラスターに対する識別のために使用されます。そのため、使用する名前を覚えておくようにしてください。
      1. 以下の構文を使用して、JBoss EAP スレーブホストを起動します。
        bin/domain.sh --host-config=HOST_SLAVE_XML_FILE_NAME
        例:
        bin/domain.sh --host-config=host-slave01.xml
      2. 管理 CLI を起動します。
      3. 以下の構文を使用してホスト名を置き換えます。
        /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">
    5. 管理対象ドメインに参加する必要がある新たに設定されたホストの場合は、local 要素を削除し、ドメインコントローラーを示す host 属性の remote 要素を追加する必要があります。この手順はスタンドアロンサーバーには適用されません。
      1. 以下の構文を使用して、JBoss EAP スレーブホストを起動します。
        bin/domain.sh --host-config=HOST_SLAVE_XML_FILE_NAME
        例:
        bin/domain.sh --host-config=host-slave01.xml
      2. 管理 CLI を起動します。
      3. 次の構文を使用してドメインコントローラーを指定します。
        /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>
  2. 各スレーブサーバーの認証を設定します。

    各スレーブサーバーでは、ドメインコントローラーまたはスタンドアロンマスターの 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=" />
  3. add-user.sh の出力から Base64 でエンコードされた <secret> 要素をコピーします。

    認証に Base64 でエンコードされたパスワード値を指定したい場合、add-user.sh の出力の最終行より <secret> 要素値をコピーします。次の手順でこの値が必要になります。
  4. 新しい認証を使用するようスレーブホストのセキュリティーレルムを変更します。

    以下の方法の 1 つを用いて秘密の値を指定できます。
    • 管理 CLI を使用して、サーバー設定ファイルに Base64 でエンコードされたパスワード値を指定します。

      1. EAP_HOME/bin/jboss-cli.sh コマンド (Linux の場合) または EAP_HOME\bin\jboss-cli.bat コマンド (Microsoft Windows Server の場合) を使用して管理 CLI を起動します。connect と入力して localhost 上のドメインコントローラーに接続するか、connect IP_ADDRESS と入力してリモートサーバー上のドメインコントローラーに接続します。
      2. 以下のコマンドを入力して秘密の値を指定します。必ず SECRET_VALUE を前の手順の add-user 出力から返された秘密の値に置き換えてください。
        /core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="SECRET_VALUE") 
        :reload
        各コマンドに対して以下のような結果が表示されるはずです。
         "outcome" => "success"
    • ホストを設定し、vault よりパスワードを取得します。

      1. vault.sh スクリプトを使用してマスクされたパスワードを生成します。次のような文字列が生成されます: VAULT::secret::password::ODVmYmJjNGMtZDU2ZC00YmNlLWE4ODMtZjQ1NWNmNDU4ZDc1TElORV9CUkVBS3ZhdWx0
        vault に関する詳細は、「機密性の高い文字列のパスワード vault」の項にある 「パスワード valut システム」 を参照してください。
      2. EAP_HOME/bin/jboss-cli.sh コマンド (Linux の場合) または EAP_HOME\bin\jboss-cli.bat コマンド (Microsoft Windows Server の場合) を使用して管理 CLI を起動します。connect と入力して localhost 上のドメインコントローラーに接続するか、connect IP_ADDRESS と入力してリモートサーバー上のドメインコントローラーに接続します。
      3. 以下のコマンドを入力して秘密の値を指定します。必ず 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 をパスワードのシステムプロパティー名として使用します。
      1. 管理 CLI を使用してサーバー設定ファイルにパスワードのシステムプロパティーを指定します。
        1. EAP_HOME/bin/jboss-cli.sh コマンド (Linux の場合) または EAP_HOME\bin\jboss-cli.bat コマンド (Microsoft Windows Server の場合) を使用して管理 CLI を起動します。connect と入力して localhost 上のドメインコントローラーに接続するか、connect IP_ADDRESS と入力してリモートサーバー上のドメインコントローラーに接続します。
        2. 以下のコマンドを入力し、システムプロパティーを使用する秘密のアイデンティティーを設定します。
          /core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="${server.identity.password}") 
          :reload
          各コマンドに対して以下のような結果が表示されるはずです。
           "outcome" => "success"
      2. システムプロパティーとしてパスワードを指定する場合、次の方法のいずれかを用いてホストを設定できます。
        • 次の例のように、プレーンテキストのパスワードをコマンドライン引数として入力し、サーバーを起動します。
          -Dserver.identity.password=changeme

          注記

          パスワードはプレーンテキストで入力する必要があります。ps -ef コマンドを実行すると、このパスワードを確認できます。
        • パスワードをプロパティーファイルに格納し、プロパティーファイルの URL をコマンドライン引数として渡します。
          1. キーと値のペアをプロパティーファイルに追加します。例は次のとおりです。
            server.identity.password=changeme
          2. コマンドライン引数を用いてサーバーを起動します。
            --properties=URL_TO_PROPERTIES_FILE
            .
  5. サーバーを再起動します。

    ホスト名をユーザー名として使用し、暗号化された文字列をパスワードとして使用してスレーブがマスターに対して認証されます。
結果

スタンドアロンサーバーまたは管理対象ドメインのサーバーグループ内のサーバーが mod_cluster ワーカーノードとして設定されます。クラスター化されたアプリケーションをデプロイする場合、セッションはフェイルオーバーのためにすべてのクラスターサーバーに複製され、外部の web サーバーまたはロードバランサーから要求を許可できます。クラスターの各ノードは、デフォルトで自動検出を使用して他のノードを検出します。自動検出と mod_cluster サブシステムの他の固有設定値を設定するには、『管理および設定ガイド』の「mod_cluster サブシステムの設定」を参照してください。Apache HTTP サーバーを設定するには、『管理および設定ガイド』の「外部 Web サーバーを JBoss EAP 6 アプリケーションの Web フロントエンドとして使用」を参照してください。

第9章 パッチインストール

9.1. パッチおよびアップグレード

JBoss EAP 6 のパッチ適用により、JBoss EAP 6 の特定のマイナーバージョン (JBoss EAP 6.2 など) で利用可能なアップデートが適用されます。パッチには、個別アップデートまたは累積アップデートが含まれます。
アップグレードは、新しいメジャーバージョン (たとえば、5.0 から 6.0) または新しいマイナーバージョン (たとえば、6.1 から 6.2) に移行するプロセスであり、パッチ適用で実行することはできません。

9.2. パッチ適用の仕組み

JBoss のパッチは、zip (全製品) と RPM (製品のサブセット) の 2 つの形式で配布されます。

重要

JBoss 製品のインストールは、必ず zip パッチまたは RPM パッチのいずれかの方法を使用して更新する必要があります。セキュリティーパッチと累積パッチは RPM でのみ配布され、RPM インストールを使用しているユーザーは zip パッチを使用して更新できません。
JBoss のパッチは非同期更新または計画更新のいずれかです。
  • 非同期更新: 既存製品の通常の更新サイクル以外にリリースされる個別のパッチ。これらには、セキュリティーパッチや、Red Hat Global Support Services (GSS) が特定の問題を修正するために提供する他の個別パッチなどがあります。
  • 計画更新: これらには、累積パッチと、既存製品のマイクロアップグレード、マイナーアップグレード、またはメジャーアップグレードなどがあります。累積パッチには、製品の該当バージョンに対してすでに開発された更新がすべて含まれます。
パッチが計画された更新の一部としてリリースされるか、または随時の更新としてリリースされるかは、修正される問題の深刻度によって決まります。通常、深刻度が低い問題は先送りされ、対象製品の次の累積パッチまたはマイナーリリースで解決されます。深刻度が中程度以上の問題は、対象製品の随時の更新で重要度の高い順に解決されます (特定の問題の修正のみが含まれます)。
JBoss 製品のセキュリティー更新はエラータによって提供されます (zip および RPM の両方)。エラータは、解決された欠陥、それらの深刻度、影響する製品、欠陥の詳細、およびパッチへの参照が含まれるリストをカプセル化します。バグ修正の更新はエラータによって通知されません。

重要

パッチの適用後は、実行時に取得される jar が EAP_HOME/modules/system/layers/base/.overlays/$PATCH_ID/$MODULE ディレクトリーから取得されることに注意してください。元のファイルは EAP_HOME/modules/system/layers/base/$MODULE に残ったままになります。セキュリティー上の理由のため、パッチ適用メカニズムにより元の jar ファイルが無効な状態になります。つまり、モジュールを更新するパッチを適用すると、元のモジュールの jar ファイルが変更され使用不可の状態になります。パッチがロールバックされると、元のファイルが使用可能な状態に戻ります。これは、適用されたどのパッチをロールバックするにも、適切なロールバック手順に従う必要があることを意味します。適切なロールバック手順については、「パッチ管理システムを使用して Zip 形式のパッチ適用をロールバックする」を参照してください。
JBoss セキュリティーの欠陥に対する Red Hat の評価の詳細については、「JBoss セキュリティーパッチの深刻度および影響度」を参照してください。
Red Hat は、セキュリティー関連の欠陥をサブスクライバーに通知するメーリングリストを管理しています。「パッチメーリングリストへのサブスクライブ」を参照してください。

9.3. パッチメーリングリストへのサブスクライブ

概要

Red Hat の JBoss チームは、Red Hat JBoss Middleware 製品のセキュリティーに関する情報をお知らせするメーリングリストを管理しています。ここでは、このリストをサブスクライブする方法について取り上げます。

要件

  • なし

手順9.1 JBoss Watch List をサブスクライブする

  1. JBoss Watch メーリングリストのページへ移動します。このリンク をクリックしてください。
  2. Subscribing to Jboss-watch-list (Jboss-watch-list へのサブスクライブ) にメールアドレスを入力します。
  3. 名前を入力し、パスワードを選択することも可能です。名前とパスワードの指定は任意ですが推奨されます。
  4. Subscribe (サブスクライブ) ボタンを押してサブスクリプションプロセスを開始します。
  5. メーリングリストのアーカイブは JBoss Watch Mailing List Archives で閲覧できます。
結果

メールアドレスの確認後に、JBoss パッチメーリングリストへのサブスクライブが完了し、セキュリティー関連の通知を受け取るようになります。

9.4. zip 形式のパッチのインストール

9.4.1. パッチ管理システム

JBoss EAP 6 パッチ管理システムは、ダウンロードされた zip パッチを単一の JBoss EAP 6 サーバーに適用するために使用されます。JBoss EAP 6 パッチ管理システムには、管理 CLI で patch コマンドを使用するか、管理コンソールを使用してアクセスできます。パッチ管理システムは、管理ドメイン全体で JBoss EAP 6 サーバーインスタンスを自動的にパッチを適用するために使用できませんが、管理ドメインの各サーバーインスタンスにはパッチを個別に適用できます。

重要

RPM を使用してインストールされた JBoss EAP 6 サーバーインスタンスは、パッチ管理システムを使用して更新できません。RPM でインストールされた JBoss EAP 6 サーバーを更新するには、「RPM インストールへのパッチ適用」を参照してください。

注記

パッチ管理システムは、JBoss EAP 6.2 以降のバージョン用に作成されたパッチでのみ使用できます。JBoss EAP 6.2 よりも前のバージョン用のパッチについては、該当するバージョンのドキュメンテーション (https://access.redhat.com/site/documentation/) を参照してください。
パッチの適用以外に、パッチ管理システムはインストールされたパッチの状態に関する基本的な情報を提供し、パッチの適用をすぐにロールバックする方法も提供します。
パッチの適用またはロールバック操作を開始する前に、パッチ管理システムは変更するモジュールとその他のファイルでユーザーによる変更がないかをチェックします。ユーザーによる変更が検出され、conflict-handling スイッチが指定されていない場合は、パッチ管理システムが操作を中止し、競合が存在することを警告します。警告には、競合があるモジュールと他のファイルのリストが含まれます。操作を完了するには、競合の解決方法 (ユーザーによる変更を保持するか、または上書きするか) を指定するスイッチを使用して再試行する必要があります。
以下の表には、管理 CLI の 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 パッチ管理システムを使用してインストールできます。

重要

パッチ管理システムは、JBoss EAP 6.2 で追加された機能です。JBoss EAP 6.2 よりも前のバージョンでは、zip 形式のパッチをインストールするプロセスが異なります。該当するバージョンのドキュメンテーション (https://access.redhat.com/site/documentation/) を参照してください。

要件

  • Red Hat カスタマーポータルへの有効なアクセスおよびサブスクリプション。
  • zip 形式でインストールされた JBoss 製品の現在のサブスクリプション。
  • JBoss EAP 6 サーバーを更新するには、管理 CLI または管理コンソールにアクセスします。『管理設定ガイド』の「管理 CLI の起動」または「管理コンソールへログイン」を参照してください。

警告

パッチをインストールする前に、JBoss 製品とカスタマイズされた設定ファイルをすべてバックアップする必要があります。

手順9.2 管理 CLI を使用して zip パッチを JBoss EAP 6 サーバーインスタンスに適用する

  1. カスタマーポータル ( https://access.redhat.com/downloads/) からパッチ zip ファイルをダウンロードします。
  2. 管理 CLI から、以下のコマンドでパッチファイルへの適切なパスを指定してパッチを適用します。
    [standalone@localhost:9999 /] patch apply /path/to/downloaded-patch.zip
    パッチを適用するときに競合が発生した場合、patch ツールは警告を発します。コマンドを再実行して競合を解決する場合に利用可能な patch コマンドのスイッチについては、「パッチ管理システム」を参照してください。
  3. 以下のコマンドを実行して、パッチを適用するために JBoss EAP 6 サーバーを再起動します。
    [standalone@localhost:9999 /] shutdown --restart=true

手順9.3 管理コンソールを使用して zip パッチを JBoss EAP 6 サーバーインスタンスに適用する

  1. カスタマーポータル ( https://access.redhat.com/downloads/) からパッチ zip ファイルをダウンロードします。
  2. 管理コンソールで以下の操作を行います。
    • スタンドアロンサーバーの場合: 画面の上部にある Runtime (ランタイム) タブをクリックし、次に Patch Management (パッチ管理) をクリックします。
    • 管理ドメインの場合: 画面の上部にある Domain (ドメイン) タブをクリックし、Host (ホスト) ドロップダウンメニューからパッチを適用するホストを選択して、Patch Management (パッチ管理) をクリックします。
  3. Apply a New Patch (新規パッチの適用) をクリックします。
    1. 管理ドメインホストにパッチを適用する場合は、次の画面でホストのサーバーをシャットダウンするかどうかを選択し、Next (次へ) をクリックします。
  4. Browse (参照) ボタンをクリックし、適用するダウンロード済みパッチを選択して、Next (次へ) をクリックします。
    1. パッチを適用する場合に競合がある場合は、警告が表示されます。View error details (エラー詳細の表示) をクリックして競合の詳細を表示します。競合がある場合は、操作をキャンセルするか、Override all conflicts (すべての競合のオーバーライド) チェックボックスを選択します。競合をオーバーライドすると、すべてのユーザーの変更がパッチの内容によって上書きされます。
  5. パッチが正常に適用されたら、パッチを有効にするために JBoss EAP 6 サーバーを再起動するかどうかを選択し、Finish (完了) をクリックします。
結果

JBoss EAP 6 サーバーインスタンスに、最新のパッチが適用されます。

9.4.3. パッチ管理システムを使用して Zip 形式のパッチ適用をロールバックする

概要

JBoss EAP 6 パッチ管理システムは、以前に適用された zip パッチの適用を管理 CLI または管理コンソールを使用してロールバックするために使用できます。

警告

パッチ管理システムを使用したパッチ適用のロールバックは、一般的なアンインストール機能として使用するものではありません。不適切な結果をもたらしたパッチ適用の直後に使用することを目的としています。

重要

パッチ管理システムは、JBoss EAP 6.2 で追加された機能です。JBoss EAP 6.2 よりも前のバージョンでは、zip 形式のパッチをロールバックするプロセスが異なります。該当するバージョンのドキュメンテーション (https://access.redhat.com/site/documentation/) を参照してください。

要件

  • JBoss EAP 6 パッチ管理システムを使用して以前に適用されたパッチ。
  • JBoss EAP 6 サーバーの管理 CLI または管理コンソールにアクセスします。『管理設定ガイド』の「管理 CLI の起動」または「管理コンソールへログイン」を参照してください。

警告

いずれかの手順に従う場合は、Reset Configuration オプションの値を指定するときに注意してください。
TRUE に設定された場合、パッチロールバックプロセスにより JBoss EAP 6 サーバー設定ファイルがパッチ適用前の状態にロールバックされます。パッチの適用後に JBoss EAP 6 サーバー設定ファイルに行われたすべての変更は失われます。
FALSE に設定された場合、サーバー設定ファイルはロールバックされません。この状況では、ネームスペースなどの設定がパッチにより変更され (設定は有効でなくなり、手動で修正する必要があります)、ロールバック後にサーバーを起動できないことがあります。

手順9.4 管理 CLI を使用して JBoss EAP 6 サーバーインスタンスからパッチをロールバックする

  1. 管理 CLI から patch info コマンドを使用して、ロールバックするパッチの ID を見つけます。
    • 累積パッチの場合、パッチ ID は patch info 出力に表示された最初の cumulative-patch-id の値です。
    • 個別セキュリティーまたはバグ修正 ID は、patch info 出力に表示された最初の patches の値としてリストされます (最も最近に適用された 個別パッチが最初にリストされます)。
  2. 管理 CLI から、以前の手順の適切なパッチ ID を持つパッチをロールバックします。
    [standalone@localhost:9999 /] patch rollback --patch-id=PATCH_ID --reset-configuration=TRUE
    パッチをロールバックするときに競合が発生した場合、patch ツールは警告を発します。コマンドを再実行して競合を解決する場合に利用可能な patch コマンドのスイッチについては、「パッチ管理システム」を参照してください。
  3. パッチのロールバックを反映するために、JBoss EAP 6 サーバーを再起動します。
    [standalone@localhost:9999 /] shutdown --restart=true

手順9.5 管理コンソールを使用して JBoss EAP 6 サーバーインスタンスからパッチをロールバックする

  1. 管理コンソールで以下の操作を行います。
    • スタンドアロンサーバーの場合: 画面の上部にある Runtime (ランタイム) タブをクリックし、次に Patch Management (パッチ管理) をクリックします。
    • 管理ドメインの場合: 画面の上部にある Domain (ドメイン) タブをクリックし、Host (ホスト) ドロップダウンメニューから該当するホストを選択して、Patch Management (パッチ管理) をクリックします。
  2. Recent Patch History (最近のパッチ履歴) テーブルで、ロールバックするパッチを選択し、Rollback (ロールバック) をクリックします。
    1. 管理ドメインホストの場合は、次の画面でホストのサーバーをシャットダウンするかどうかを選択し、Next (次へ) をクリックします。
  3. ロールバックプロセスのオプションを選択し、Next (次へ) をクリックします。
  4. オプションとロールバックするパッチを確認し、Next (次へ) をクリックします。
    1. Override all (すべてのオーバーライド) オプションが選択されておらず、パッチをロールバックするときに競合がある場合は、警告が表示されます。View error details (エラー詳細の表示) をクリックして競合の詳細を表示します。競合がある場合は、操作をキャンセルするか、Choose Options (オプションの選択) をクリックし、Override all (すべてのオーバーライド) チェックボックスを選択した状態で操作を再試行します。競合をオーバーライドすると、すべてのユーザーの変更がロールバック操作によって上書きされます。
  5. パッチが正常にロールバックされたら、変更を反映するために JBoss EAP 6 サーバーを今すぐ再起動するかどうかを選択し、Finish (完了) をクリックします。
結果

パッチ (およびオプションでサーバー設定ファイル) は、JBoss EAP 6 サーバーインスタンスでロールバックされます。

9.5. RPM インストールへのパッチ適用

概要

JBoss パッチは、zip (全製品) と RPM (製品のサブセット) の 2 つの形式で配布されます。このタスクでは、RPM 形式でパッチをインストールするのに実行する必要がある手順を示します。

要件

  • Red Hat Network への有効なサブスクリプション。
  • RPM パッケージでインストールされた JBoss 製品の現在のサブスクリプション。

手順9.6 RPM 形式で JBoss 製品へパッチを適用する

JBoss 製品のセキュリティー更新はエラータによって提供されます (zip および RPM)。エラータは、解決された欠陥、それらの深刻度、影響する製品、欠陥の詳細、およびパッチへの参照のリストをカプセル化します。
JBoss 製品の RPM ディストリビューションでは、更新済みの RPM パッケージへの参照がエラータに含まれます。yum を使用して、パッチをインストールすることが可能です。

警告

パッチをインストールする前に、JBoss 製品とカスタマイズされた設定ファイルをすべてバックアップする必要があります。
  1. JBoss watch メーリングリストにサブスクライブするか、JBoss watch メーリングリストのアーカイブを閲覧して、セキュリティーパッチに関する情報を入手します。
  2. エラータを読んでセキュリティーパッチに関する情報を取得し、使用環境の JBoss 製品に適用されることを確認します。
  3. セキュリティーパッチが使用環境の JBoss 製品に適用される場合は、リンク先よりエラータに含まれている更新済みの RPM パッケージをダウンロードします。
  4. パッチをインストールするには、以下のコマンドまたは同様のコマンドを実行します。
    yum update

    重要

    RPM インストールを更新する場合、JBoss 製品は RPM でリリースされた修正で累積的に更新されます。
結果

RPM 形式を使用して JBoss 製品に最新の更新が適用されます。

9.6. JBoss セキュリティーパッチの深刻度および影響度

JBoss のセキュリティー欠陥のリスクを伝達するため、Red Hat は low (低)、moderate (中)、important (高)、critical (重大) の 4 段階の深刻度を使用します。さらに、欠陥の影響度を特定するため、CVSS (Common Vulnerability Scoring System: 共通脆弱性評価システム) のバージョン 2 をベースにしたスコアも使用します。

表9.2 JBoss セキュリティーパッチの深刻度

深刻度説明
Critical (重大)
非認証のリモート攻撃者が簡単に悪用でき、ユーザーとやりとりしなくてもシステムが危険にさらされる (任意コード実行) 欠陥にこの深刻度が適用されます。ワームによって悪用される脆弱性になります。認証されたリモートユーザー、ローカルユーザー、または想定外の設定を必要とする欠陥は重大な欠陥とは分類されません。
Important (高)
リソースの機密性、整合性、または可用性が簡単に危険にさらされる欠陥にこの深刻度が付けられます。ローカルユーザーが権限を取得できる場合、非認証のリモートユーザーが認証によって保護されるリソースを閲覧できる場合、認証されたリモートユーザーが任意コードを実行できる場合、あるいはサービス拒否がローカルまたはリモートユーザーによって引き起こされる場合、この脆弱性タイプになります。
Moderate (中)
悪用するのは比較的困難であっても、リソースの機密性、整合性、または可用性が一部危険にさらされる原因となる欠陥にこの深刻度が付けられます。重大または重要な影響を与える可能性はあっても、欠陥の技術評価を基にするとそれほど簡単には悪用できなかったり、想定外の設定に影響しない脆弱性のタイプになります。
Low (低)
セキュリティーに影響する問題で、前述の深刻度に該当しないものにこの深刻度が適用されます。想定外の状況でのみ悪用される可能性があるとみられる脆弱性や、悪用されても影響が最小限にとどまる脆弱性のタイプになります。
CVSS v2 スコアの影響度は、機密性 (C: Confidentiality)、整合性 (I: Integrity)、可用性 (A: Availability) の 3 つの潜在的な影響を組み合わせて評価します。これら 3 つの要素に、なし (N: None)、一部的 (P: Partial)、または全面的 (C: Complete) のいずれかを評価します。
JBoss サーバープロセスは非特権ユーザーとして実行され、ホストのオペレーティングシステムから分離されているため、JBoss のセキュリティー欠陥に対する影響の評価は N または P のみになります。

例9.1 CVSS v2 の影響スコア

以下の例は、欠陥の悪用によるシステムの機密性への影響はなく、システムの整合性は一部影響があり、システムの可用性は全面的に影響がある場合 (カーネルクラッシュなど、システムが完全に使用できなくなる場合) の CVSS v2 の影響スコアを表しています。
C:N/I:P/A:C
深刻度と CVSS スコアに応じて、固有の環境で発生する問題のリスクを把握し、状況に応じてアップグレードをスケジュールできます。
CVSS2 の詳細は、「CVSS2 Guide」を参照してください。

9.7. JBoss EAP にデプロイされたアプリケーション内にバンドルされた依存関係のセキュリティー更新管理

Red Hat は、JBoss EAP ディストリビューションの一部であるすべてのコンポーネントに対してセキュリティーパッチを提供します。しかし、JBoss EAP ユーザーの多くは、JBoss EAP ディストリビューションの一部として提供されるコンポーネントのみを使用せずに、独自の依存関係をバンドルするアプリケーションをデプロイします。たとえば、デプロイされた WAR ファイルの依存関係 JAR が WEB-INF/lib/ ディレクトリーに含まれることがあります。これらの JAR は、Red Hat が提供するセキュリティーパッチの範囲外となります。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. アプリケーションセキュリティー

アプリケーションの開発者はアプリケーションをセキュアにすることが多面的で重要であることを認識しています。JBoss EAP 6 は以下のような機能が含まれる、セキュアなアプリケーションの作成に必要なツールをすべて提供します。

10.2. 宣言型セキュリティー

宣言的セキュリティー とは、セキュリティー管理にコンテナーを使うことで、お使いのアプリケーションコードからセキュリティーの問題を切り離す方法です。コンテナーにより、ファイルのパーミッション、またはユーザー、グループ、ロールに基づき承認を行います。このアプローチは、セキュリティー関連すべてをアプリケーション自体で請け負うプログラム的セキュリティーよりも優れています。
JBoss EAP 6 はセキュリティードメインより宣言的セキュリティーを提供します。

10.2.1. Java EE 宣言型セキュリティーの概要

Java EE セキュリティーモデルは宣言的で、セキュリティーをビジネスコンポーネントに埋め込まずに、セキュリティーロールおよびパーミッションを標準的な XML 記述子で記述します。セキュリティーは、コンポーネントのビジネスロジックに固有のものではなく、コンポーネントがデプロイされる場所の機能となる傾向にあるため、このモデルによりセキュリティーがビジネスレベルのコードから分離されます。たとえば、銀行の預金口座を利用するために使用する ATM の場合、預金口座へのアクセス方法、口座を管理する銀行、ATM の場所などの条件によって、セキュリティー要件、ロール、およびパーミッションが大きく異なります。
Java EE アプリケーションは、標準の Java EE デプロイメント記述子によって指定されたアプリケーションセキュリティー要件を基にセキュア化されます。ejb-jar.xml および web.xml デプロイメント記述子を使用して、エンタープライズアプリケーションの EJB および Web コンポーネントへのアクセスをセキュア化します。

10.2.2. セキュリティーの参照

Enterprise Java Bean (EJB) およびサーブレットは、1 つまたは複数の <security-role-ref> 要素を宣言できます。
Illustration of Security Roles Reference Model

図10.1 セキュリティーロール参照モデル

この要素は、コンポーネントが <role-name> 要素の 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>

注記

これは実例ではありません。デプロイメントでは、このセクションの要素に EJB デプロイメントに関連するロール名およびリンクが含まれている必要があります。

例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)

Enterprise Java Bean (EJB) は、<security-identity> 要素を使用してコンポーネント上でメソッドを呼び出すときに使用する必要がある、別の EJB の ID を指定できます。
Illustration of Java EE Security Identity Model

図10.2 Java EE セキュリティーアイデンティティーデータモデル

呼び出し ID は現在の呼び出し元の ID、または特定のロールを指定できます。アプリケーションアセンブラーは、<security-identity> 要素と <use-caller-identity> 子要素を使用します。そのため、現在の呼び出し元の ID は、EJB によって実行されたメソッド呼び出しのセキュリティー IDとして伝播される必要があります。呼び出し元の ID の伝播は、<security-identity> 要素が明示的に宣言されていない場合に使用されるデフォルトの動作です。
また、アプリケーションアセンブラーで <run-as> または <role-name> 子要素を使用して、<role-name> 要素値によって提供される特定のセキュリティーロールが、EJB によって実行されたメソッド呼び出しのセキュリティー ID として使用されるように指定することも可能です。
EJBContext.getCallerPrincipal() メソッドのように呼び出し元の ID が変更されないことに注意してください。呼び出し元のセキュリティーロールは、<run-as> または <role-name> 要素値によって指定された単一のロールに設定されます。
<run-as> 要素を使用すると、外部クライアントによる内部 EJB へのアクセスを防ぐことができます。この挙動を設定するには、内部 EJB の <method-permission> 要素を割り当てます。この要素は、外部クライアントへ割り当てられていないロールへのアクセスを制限します。この後、内部 EJB を使用しなければならない EJB は、<run-as> または <role-name> が制限されたロールと同等として設定されます。以下は記述子の一部で、<security-identity> 要素の使用例になります。

<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>
<run-as> を使用して特定のロールを発信呼び出しへ割り当てると、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>
<run-as> 要素は、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 など)。
Java EE 仕様には、デプロイメント記述子のセキュリティーロールはアプリケーションの論理セキュリティービューを定義するために使用されることを考慮することが重要であると記載されています。Java EE デプロイメント記述子に定義されるロールを、ユーザーグループ、ユーザー、プリンシパル、および目的企業の操作環境に存在するその他の概念と混同してはなりません。デプロイメント記述子ロールは、アプリケーションドメイン固有の名前を持つアプリケーションコンストラクトです。たとえば、銀行取引のアプリケーションでは BankManager、Teller、Customer などをロール名として使用することがあります。
JBoss EAP では、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 メソッドのパーミッション

アプリケーションアセンブラーは、method-permission 要素を宣言して EJB のホームおよびリモートインターフェースメソッドを呼び出せるロールを設定できます。
Illustration of the Java EE method permissions element

図10.3 Java EE メソッドパーミッション要素

method-permission 要素には、メソッド子要素によって特定された EJB メソッドへアクセスできる論理ロールを定義する 1 つ以上の role-name 子要素が含まれています。また、role-name 要素の代わりに unchecked 要素を指定して、認証されたすべてのユーザーがメソッド子要素によって特定されたメソッドにアクセスできることを宣言できます。さらに、exclude-list 要素があるメソッドにはアクセスできないことを宣言することも可能です。method-permission 要素を使用して、ロールによるアクセスが可能であると宣言されていないメソッドが EJB にある場合、EJB メソッドはデフォルトでは使用されません。これは、メソッドがデフォルトで exclude-list に含まれるようにすることと同じです。
Illustration of the Java EE method element

図10.4 Java EE メソッド要素

メソッド要素宣言のサポートされるスタイルは 3 つあります。
1 つ目のスタイルは、名前付きエンタープライズ Bean のホームおよびコンポーネントインターフェースメソッドをすべて参照するために使用されます。
<method>
  <ejb-name>EJBNAME</ejb-name>
  <method-name>*</method-name>
</method>
2 つ目のスタイルは、名前付きエンタープライズ Bean のホームまたはコンポーネントインターフェースの指定されたメソッドを参照するために使用されます。
  <method>
    <ejb-name>EJBNAME</ejb-name>
    <method-name>METHOD</method-name>
  </method>
同じオーバーロードされた名前を持つ複数のメソッドがある場合、このスタイルはすべてのオーバーロードされたメソッドを参照します。
3 つ目のスタイルは、オーバーロードされた名前を持つメソッドのセット内で指定されたメソッドを参照するために使用されます。
<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>
メソッドは指定されたエンタープライズ Bean のホームまたはリモートインターフェースに定義する必要があります。method-param 要素の値は、対応するメソッドパラメータータイプの完全修飾名です。同じオーバーロードされたシグネチャーを持つメソッドが複数ある場合、パーミッションは一致するオーバーロードされたメソッドすべてに適用されます。
任意の 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 セキュリティーアノテーション

エンタープライズ Bean はアノテーションを使用し、アプリケーションのセキュリティーやその他の情報をデプロイヤーへ渡します。アノテーションまたはデプロイメント記述子に指定された場合、デプロイヤーはアプリケーションに対して適切なエンタープライズ Bean セキュリティーポリシーを設定できます。
アノテーションの値は、デプロイメント記述子に明示的に指定されたメソッドの値によって上書きされます。メソッドの値がデプロイメント記述子に指定されていない場合、アノテーションを使用して設定された値が使用されます。粒度の上書きはメソッドごとに行われます。
セキュリティーに対応し、エンタープライズ 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 アプリケーションでは、保護されたコンテンツを識別する URL パターンよりコンテンツへのアクセスが許可されるロールによってセキュリティーが定義されます。この情報セットは、web.xmlsecurity-constraint 要素を使用して宣言されます。
Illustration of Web Content Security Constraints

図10.5 Web コンテンツのセキュリティー制約

セキュア化するコンテンツは、1 つ以上の <web-resource-collection> 要素を使用して宣言されます。各 <web-resource-collection> 要素には、任意の <url-pattern> 要素と、これに続く任意の <http-method> 要素が含まれます。<url-pattern> 要素の値は、リクエストがセキュア化されたコンテンツへのアクセスに対応するため、リクエスト URL が一致しなければならない URL パターンを指定します。<http-method> 要素の値は、許可する HTTP リクエストのタイプを指定します。
任意の <user-data-constraint> 要素は、クライアントサーバー接続のトランスポート層の要件を指定します。要件は、コンテンツの整合性 (通信プロセスでのデータ改ざんを防ぐ) または機密性 (送信中の読み取りを防ぐ) に関係することがあります。<transport-guarantee> 要素の値は、クライアントとサーバー間の通信に対する保護レベルを指定します。値は NONEINTEGRAL、および CONFIDENTIAL になります。NONE を指定すると、アプリケーションはトランスポートの保証を必要としません。INTEGRAL の場合、アプリケーションはクライアントとサーバー間での送信中でデータが変更されない方法を必要とします。CONFIDENTIAL の場合、アプリケーションは送信中のデータが他のエンティティーによって見られないようにする方法を必要とします。ほとんどの場合で、INTEGRAL または CONFIDENTIAL フラグが存在すると SSL の使用が必要になります。
任意の <login-config> 要素は、使用される認証メソッド、アプリケーションに使用されるレルム名、およびフォームログインのメカニズムに必要な属性を設定するために使用されます。
Illustration of Web Login Configuration

図10.6 Web ログインの設定

<auth-method> 子要素は、Web アプリケーションの認証メカニズムを指定します。承認制約によって保護された Web リソースへアクセスするには、設定されたメカニズムを使用してユーザーが認証されている必要があります。<auth-method> の有効な値は、 BASICDIGESTFORMSPNEGO、および CLIENT-CERT です。<realm-name> 子要素は、HTTP ベーシックおよびダイジェスト認証で使用されるレルム名を指定します。<form-login-config> 子要素は、フォームベースのログインで使用されるログインおよびエラーページを指定します。<auth-method> 値が FORM でない場合、form-login-config と子要素は無視されます。
以下の設定例は、Web アプリケーションの /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. フォームベース認証の有効化

フォームベース認証では、ログインのカスタム JSP/HTML ページや、ログイン中にエラーが発生した場合にユーザーが移動される別のページを柔軟に定義できます。
フォームベースの認証を定義するには、デプロイメント記述子 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>
フォームベース認証の Web アプリケーションがデプロイされると、Web コンテナは FormAuthenticator を使用してユーザーを適切なページに移動します。JBoss EAP はセッションプールを保持するため、リクエストごとに認証情報が存在する必要はありません。FormAuthenticator がリクエストを受け取ると、既存のセッションに関して org.apache.catalina.session.Manager をクエリーします。セッションが存在しない場合、新しいセッションが作成されます。その後、FormAuthenticator がセッションのクレデンシャルを検証します。

注記

各セッションは、セッション ID によって識別されます。セッション ID は、乱数値から生成された 16 バイトの文字列です。これらの値はデフォルトでは /dev/urandom (Linux の場合) より取得され、MD5 でハッシュ化されます。セッション ID は作成時にチェックされ、作成された ID が一意になるようにします。
検証後、セッション ID はクッキーの一部として割り当てられ、クライアントに返されます。後続のクライアントリクエストではクッキーがあることが想定され、ユーザーセッションの識別に使用されます。
クライアントへ渡されるクッキーは、名前と値のペアで、任意の属性が複数含まれています。識別子属性は JSESSIONID と呼ばれ、値はセッション ID の 16 進数列です。このクッキーは、非永続となるよう設定されます。そのため、ブラウザーを終了するとクライアント側でこのクッキーが削除されます。サーバー側では、30 分間活動がないとセッションが期限切れになり、セッションオブジェクトとそれらのクレデンシャルが削除されます。
ユーザーがフォームベースの認証で保護された Web アプリケーションにアクセスしようとすると、FormAuthenticator によってリクエストがキャッシュされ、必要な場合は新しいセッションが作成されます。さらに、ユーザーは login-config に定義されたログインページへリダイレクトされます (前述のコード例では、ログインページは login.html になります)。その後、ユーザーは提供される HTML フォームにユーザー名とパスワードを入力します。ユーザー名とパスワードは、j_security_check フォームアクションを介して FormAuthenticator へ渡されます。
次に、FormAuthenticator によって、ユーザー名とパスワードが Web アプリケーションコンテキストにアタッチされるレルムに対して認証されます。JBoss Enterprise Application Platform では、レルムは JBossWebRealm になります。認証に成功すると、FormAuthenticator によってキャッシュから保存されたリクエストが読み出され、ユーザーが元のリクエストへリダイレクトされます。

注記

サーバーは、URI が /j_security_check で終わり、最低でも j_username および j_password パラメーターが存在する場合のみ、フォーム認証リクエストを認識します。

10.2.9. 宣言型セキュリティーの有効化

これまで取り上げた Java EE セキュリティー要素は、アプリケーションの視点のみからセキュリティー要件を記述します。Java EE セキュリティー要素は論理ルールを宣言するため、アプリケーションデプロイヤーはロールをアプリケーションドメインからデプロイメント環境へマップします。Java EE 仕様は、このようなアプリケーションサーバー固有の詳細を省略します。
アプリケーションロールをデプロイメント環境にマップするには、JBoss EAP 固有のデプロイメント記述子を使用して Java EE セキュリティーモデルを実装するセキュリティーマネージャーを指定します。

第11章 アプリケーションのセキュリティー

11.1. データソースセキュリティー

11.1.1. データソースセキュリティー

データソースセキュリティーは、データソース接続のパスワードを暗号化したり分かりにくくすることを言います。これらのパスワードはプレーンテキストで設定ファイルに保存できますが、セキュリティーリスクが高くなります。
データソースセキュリティーのソリューションには、セキュリティードメインまたはパスワード vault のいずれかを使用することが推奨されます。以下にそれぞれの例を示します。詳細については、以下のドキュメントを参照してください。

例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>
DsRealm ドメインはデータソースによって参照されます。
<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 のセキュリティーアイデンティティー

EJB は、他のコンポーネントでメソッドを呼び出すときに使用するアイデンティティーを指定できます。これは EJB のセキュリティーアイデンティティー (または呼び出しアイデンティティー) です。
デフォルトでは、EJB は独自の呼び出し側アイデンティティーを使用します。アイデンティティーは特定のセキュリティーロールに設定することもできます。特定のセキュリティーロールを使用すると、内部 EJB のみへのコンポーネントセットのアクセスを制限する場合など、セグメント化されたセキュリティーモデルを構築するのに便利です。

11.2.1.2. EJB のセキュリティーアイデンティティーの設定

EJB のセキュリティーアイデンティティーは、セキュリティー設定の <security-identity> タグより設定されます。
デフォルトでは、<security-identity> タグが存在しないと、EJB の独自の呼び出し側アイデンティティーが使用されます。

例11.3 呼び出し側と同じになるように EJB のセキュリティーアイデンティティーを設定する

この例は、現在の呼び出し側のアイデンティティーと同じになるように、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 メソッドパーミッション

EJB は、特定のセキュリティーロールへのメソッドのアクセスを制限できます。
EJB の <method-permisison> 要素宣言は、EJB のインターフェースメソッドを呼び出しできるロールを指定します。以下の組み合わせのパーミッションを指定できます。
  • 名前付き EJB のホームおよびコンポーネントインターフェースメソッド
  • 名前付き EJB のホームあるいはコンポーネントインターフェースの指定メソッド
  • オーバーロードした名前を持つメソッドセット内の指定メソッド

11.2.2.2. EJB メソッドパーミッションの使用

概要

<method-permission> 要素は、<method> 要素によって定義される EJB メソッドへアクセスできる論理ロールを定義します。XML の構文を表す例は複数あります。メソッドパーミッションステートメントは複数存在することがあり、累積的な影響があります。<method-permission> 要素は <ejb-jar> 記述子の <assembly-descriptor> 要素の子要素です。

XML 構文は、EJB メソッドへセキュリティーアノテーションを使用することの代替となります。

例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 セキュリティーアノテーション

EJB の javax.annotation.security アノテーションは JSR250 に定義されています。
EJB はセキュリティーアノテーションを使いセキュリティー関連の情報をデプロイヤーに渡します。セキュリティーアノテーションには以下が含まれます。
@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. リモートメソッドアクセス

JBoss Remoting は EJB や JMX MBeans、その他類似のサービスにリモートアクセスを提供するフレームワークです。SSL の有無にかかわらず次のトランスポートタイプ内で動作します。

サポートされているトランスポートタイプ

  • ソケット / セキュアソケット
  • RMI / RMI over SSL
  • HTTP / HTTPS
  • サーブレット / セキュアサーブレット
  • バイソケット (Bisocket) / セキュアバイソケット (Secure Bisocket)

警告

Red Hat は、影響するすべてのパッケージで TLSv1.1 または TLSv1.2 を利用するために SSL を明示的に無効化することを推奨しています。
JBoss Remoting はマルチキャストまたは JNDI からの自動ディスカバリーも提供します。
自動ディスカバリーは JBoss EAP 6 内の多くのサブシステムによって使用されています。これにより、複数の異なるトランスポートメカニズム上でクライアントによってリモートで呼び出されるサービスを設計、実装、デプロイすることが可能になります。さらに、JBoss EAP 6 の既存サービスへのアクセスが可能になります。
データのマーシャリング

Remoting システムはデータのマーシャリングサービスやアンマーシャリングサービスも提供します。データのマーシャリングとは、別のシステムで処理を実行できるようネットワークやプラットフォーム境界の全体で安全にデータを移動できる機能のことを言います。処理結果は元のシステムへ返送され、ローカルで処理されたように動作します。

アーキテクチャーの概要

Remoting を使用するクライアントアプリケーションを設計する場合、URL 型の形式の単純な文字列である InvokerLocator と呼ばれる特別なリソースロケーターを使用するよう設定し、アプリケーションがサーバーと通信するようにします。remoting サブシステムの一部として設定される connector 上で、サーバーはリモートリソースの要求をリッスンします。connector は設定済みの ServerInvocationHandler へ要求を渡します。各 ServerInvocationHandler は要求の対処方法を認識するメソッド invoke(InvocationRequest) を実装します。

JBoss Remoting フレームワークにはクライアントとサーバー側でお互いをミラーリングする 3 つのレイヤーが含まれています。

JBoss Remoting フレームワークレイヤー

  • ユーザーは外部レイヤーとやりとりします。クライアント側では外部レイヤーは呼び出し要求を送信する Client クラスになります。サーバー側ではユーザーによって実装され、呼び出し要求を受信する InvocationHandler になります。
  • トランスポートはインボーカーレイヤーによって制御されます。
  • 最も下のレイヤーにはデータ形式をワイヤー形式に変換するマーシャラーとアンマーシャラーが含まれています。

11.2.4.2. Remoting コールバック

Remoting クライアントがサーバーからの情報を要求する時、サーバーをブロックし、サーバーの返答を待つことが可能ですが、この挙動は多くの場合で理想的ではありません。クライアントがサーバー上で非同期イベントをリッスンできるようにし、サーバーが要求の処理を終了するまでクライアントが別の作業を継続できるようにするには、サーバーが要求の処理を終了した時に通知を送信するようアプリケーションが要求するようにします。これをコールバックと呼びます。他のクライアントの代わりに生成された非同期イベントに対してクライアントは自身をリスナーとして追加することもできます。コールバックの受信方法には、プルコールバックとプッシュコールバックの 2 つの方法があります。クライアントはプルコールバックを同期的に確認しますが、プッシュコールバックは受動的にリッスンします。
基本的に、コールバックではサーバーが InvocationRequest をクライアントに送信します。コールバックが同期的または非同期的であるかに関わらず、サーバー側のコードは同様に動作します。クライアントのみが違いを認識する必要があります。サーバーの InvocationRequest は responseObject をクライアントに送信します。これはクライアントが要求したペイロードで、要求やイベント通知への直接応答になる場合があります。
また、サーバーは m_listeners オブジェクトを使用してリスナーを追跡します。これにはサーバーハンドラーに追加された全リスナーのリストが含まれます。ServerInvocationHandler インターフェースにはこのリストを管理できるようにするメソッドが含まれます。
クライアントは異なる方法でプルコールバックとプッシュコールバックを処理します。どちらの場合でもコールバックハンドラーを実装する必要があります。コールバックハンドラーはインターフェース org.jboss.remoting.InvokerCallbackHandler の実装で、コールバックデータを処理します。コールバックハンドラーの実装後、プルコールバックのリスナーを追加するか、プッシュコールバックのコールバックサーバーを実装します。
プルコールバック

プルコールバックでは、Client.addListener() メソッドを使用してクライアントがクライアント自体にサーバーのリスナーリストを追加します。その後、コールバックデータを同期的に配信するためにサーバーを周期的にプルします。ここでは Client.getCallbacks() を使用してプルが実行されます。

プッシュコールバック

プッシュコールバックではクライアントアプリケーションが独自の InvocationHandler を実行する必要があります。これには、クライアント上で Remoting サービスを実行する必要があります。これは コールバックサーバーと呼ばれます。コールバックサーバーは受信する要求を非同期的に許可し、要求元 (この場合はサーバー) のために処理します。メインサーバーを用いてクライアントのコールバックサーバーを登録するには、コールバックサーバーの InvokerLocatoraddListener への 2 番目の引数として渡します。

11.2.4.3. リモーティングサーバーの検出

リモーティングサーバーとクライアントは JNDI またはマルチキャストを使用してお互いを自動的に検出することができます。リモーティングディテクターはクライアントとサーバーの両方に追加され、NetworkRegistry はクライアントに追加されています。
サーバー側のディテクターは InvokerRegistry を周期的にスキャンし、作成したサーバーインボーカーをすべてプルします。この情報を使用して、ロケーターや各サーバーインボーカーによってサポートされるサブシステムが含まれる検出メッセージを公開します。マルチキャストブロードキャストよりメッセージを公開するか、JNDI サーバーへバインドしてメッセージを公開します。
クライアント側ではディテクターはマルチキャストメッセージを受信したり、JNDI サーバーを周期的にポーリングして検出メッセージを読み出します。検出メッセージが新たに検出されたリモーティングサーバーに対するメッセージであることが分かると、ディテクターは NetworkRegistry へ登録します。また、ディテクターは使用できないサーバーを検出すると、NetworkRegistry を更新します。

11.2.4.4. Remoting サブシステムの設定

概要

JBoss Remoting にはワーカースレッドプール、1 つ以上のコネクター、複数のローカルおよびリモート接続 URI の 3 つのトップレベル設定可能要素があります。ここでは設定可能な項目の説明、各項目の設定方法に対する CLI コマンド例、完全設定されたサブシステムの XML 例について取り上げます。この設定はサーバーのみに適用されます。独自のアプリケーションにカスタムコネクターを使用する場合を除き、Remoting のサブシステムの設定は必要でないことがほとんどです。EJB などの、Remoting クライアントとして動作するアプリケーションには特定のコネクターに接続するための別の設定が必要になります。

注記

Remoting サブシステムの設定は Web ベースの管理コンソールには公開されませんが、コマンドラインベースの管理 CLI より完全に設定することが可能です。手作業で XML を編集することは推奨されません。
CLI コマンドの適合

デフォルトの default プロファイルを設定する時の CLI コマンドについて説明します。異なるプロファイルを設定するには、プロファイルの名前を置き換えます。スタンドアロンサーバーではコマンドの /profile=default の部分を省略します。

Remoting サブシステム外部の設定

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 のコンポーネントはデフォルトで安全なインターフェースを使用します。

警告

StartTLS はクライアントの要求があればセキュアな接続を有効にしますが、セキュアでない接続がデフォルトになります。本質的に、StartTLS は攻撃者がクライアントの要求を妨害し、要求を編集してセキュアでない接続を要求する中間者攻撃の対象になりやすい欠点があります。セキュアでない接続が適切なフォールバックである場合を除き、クライアントがセキュアな接続を取得できなかったときに適切に失敗するよう記述する必要があります。
ワーカースレッドプール

ワーカースレッドプールは、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 子要素を定義する前に初期 SASL 要素を作成する必要があります。次のコマンドを使用します。

/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:add
SASL 要素の子要素は次の表のとおりです。
属性説明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 を取るエンクロージング要素です。
  • forward-secrecy – メカニズムによる前方秘匿性 (forward secrecy) の実装が必要であるかどうか (あるセッションが侵入されても、その後のセッションへの侵入に関する情報は自動的に提供されません)。
  • no-active – 辞書攻撃でない攻撃を受けやすいメカニズムを許可するかどうか。値が false の場合は許可し、 true の場合は許可しません。
  • no-anonymous – 匿名ログインを許可するメカニズムを許可するかどうか。値が false の場合は許可し、 true の場合は許可しません。
  • no-dictionary – 受動的な辞書攻撃を受けやすいメカニズムを許可するかどうか。値が false の場合は許可し、 true の場合は許可しません。
  • no-plain-text – 単純で受動的な辞書攻撃を受けやすいメカニズムを許可するかどうか。値が false の場合は許可し、 true の場合は許可しません。
  • pass-credentials – クライアントのクレデンシャルを渡すメカニズムを許可するかどうか。
/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 設定例

この例は JBoss EAP 6 に同梱されるデフォルトのリモーティングサブシステムを表しています。
<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 クライアントを用いたセキュリティーレルムの使用

セキュリティーレルムの使用は、リモートで EJB を呼び出すクライアントへセキュリティーを追加する 1 つの方法です。セキュリティーレルムはユーザー名とパスワードのペアとユーザー名とロールのペアの単純なデータベースです。セキュリティーレノムという言葉は Web コンテナーに関しても使用されますが、若干意味が異なります。
セキュリティーレルムに存在する特定のユーザー名とパスワードのペアを EJB に対して認証するには、以下の手順に従います。
  • 新しいセキュリティーレルムをドメインコントローラーかスタンドアロンサーバーに追加します。
  • 次のパラメーターをアプリケーションのクラスパスにある jboss-ejb-client.properties ファイルに追加します。この例では、ファイルの他のパラメーターは接続を default としてみなすことを前提とします。
    remote.connection.default.username=appuser
    remote.connection.default.password=apppassword
  • 新しいセキュリティーレルムを使用するドメインまたはスタンドアロンサーバー上にカスタム Remoting コネクターを作成します。
  • カスタム Remoting コネクターを用いてプロファイルを使用するよう設定されているサーバーグループに EJB をデプロイします。管理対象ドメインを使用していない場合はスタンドアロンサーバーに EJB をデプロイします。

11.2.4.6. 新しいセキュリティーレルムの追加

  1. 管理 CLI を実行します。

    jboss-cli.sh または jboss-cli.bat コマンドを開始し、サーバーに接続します。
  2. 新しいセキュリティーレルムを作成します。

    次のコマンドを実行し、ドメインコントローラーまたはスタンドアロンサーバー上で MyDomainRealm という名前の新しいセキュリティーレルムを作成します。
    ドメインインスタンスでは以下コマンドを使用します。
    /host=master/core-service=management/security-realm=MyDomainRealm:add()
    スタンドアロンインスタンスでは以下のコマンドを使用します。
    /core-service=management/security-realm=MyDomainRealm:add()
  3. 新しいロールの情報を保存するプロパティーファイルへの参照を作成します。

    次のコマンドを実行し、新しいロールに関連するプロパティーが含まれる 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. セキュリティーレルムへのユーザーの追加

  1. add-user.sh または add-user.bat コマンドを実行します。

    ターミナルを開き、EAP_HOME/bin/ ディレクトリーへ移動します。Red Hat Enterprise Linux や他の UNIX 系のオペレーティングシステムを稼働している場合は、add-user.sh を実行します。Microsoft Windows Server を稼働している場合は add-user.bat を実行します。
  2. 管理ユーザーかアプリケーションユーザーのどちらを追加するか選択します。

    この手順では b を入力し、アプリケーションユーザーを追加します。
  3. ユーザーが追加されるレルムを選択します。

    デフォルトでは、ApplicationRealm のみが選択可能です。カスタムレルムが追加されている場合はその名前を入力します。
  4. 入力を促されたらユーザー名、パスワード、ロールを入力します。

    入力を促されたら希望のユーザー名、パスワード、任意のロールを入力します。yes を入力して選択を確認するか、no を入力して変更をキャンセルします。変更はセキュリティーレルムの各プロパティーファイルに書き込まれます。

11.2.4.8. SSL による暗号化を使用したリモート EJB アクセス

デフォルトでは、EJB2 および EJB3 Bean の RMI (リモートメソッド呼び出し) に対するネットワークトラフィックは暗号化されていません。暗号化が必要な場合、SSL (セキュアソケットレイヤー) を使いクライアントとサーバー間の接続が暗号化されるようにします。SSL を使用すると、ファイアウォールの設定によってはネットワークトラフィックが一部のファイアウォールを通過できる利点があります。

警告

Red Hat は、影響するすべてのパッケージで TLSv1.1 または TLSv1.2 を利用するために SSL を明示的に無効化することを推奨しています。

11.3. JAX-RS アプリケーションセキュリティー

11.3.1. RESTEasy JAX-RS Web サービスのロールベースのセキュリティーの有効化

概要

RESTEasy は JAX-RS メソッドの @RolesAllowed、@PermitAll、@DenyAll アノテーションをサポートしますが、デフォルトではこれらのアノテーションを認識しません。次の手順に従って web.xml ファイルを設定し、ロールベースセキュリティーを有効にします。

警告

アプリケーションが EJB を使用する場合はロールベースセキュリティーを有効にしないでください。RESTEasy ではなく EJB コンテナーが機能を提供します。

手順11.1 RESTEasy JAX-RS Web サービスのロールベースのセキュリティーの有効化

  1. テキストエディターでアプリケーションの web.xml ファイルを開きます。
  2. 以下の <context-param> をファイルの web-app タグ内に追加します。
    <context-param>
        <param-name>resteasy.role.based.security</param-name>
        <param-value>true</param-value>
    </context-param>
  3. <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>
  4. すべてのロールに対して 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 サービスのセキュア化

  1. ロールベースセキュリティーを有効にします。詳細は 「RESTEasy JAX-RS Web サービスのロールベースのセキュリティーの有効化」 を参照してください。
  2. 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-policyjboss-web-policy、および other の 3 つのセキュリティードメインが含まれています。アプリケーションの要件に対応するため、必要な数のセキュリティードメインを作成できます。セキュリティードメインの詳細は、「アプリケーションでのセキュリティードメインの使用」を参照してください。

12.2. セキュリティーサブシステムの構造

セキュリティーサブシステムは、管理対象ドメインまたはスタンドアロン設定ファイルに設定されます。設定要素のほとんどは、Web ベースの管理コンソールまたはコンソールベースの管理 CLI を使用して設定することが可能です。以下の XML はセキュリティーサブシステムの例を表しています。

例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. セキュリティーサブシステムの設定

セキュリティーサブシステムの設定には、管理 CLI または Web ベースの管理コンソールを使用できます。
セキュリティーサブシステム内の各トップレベル要素には、セキュリティー設定の異なる情報が含まれています。セキュリティーサブシステムの設定例は 「セキュリティーサブシステムの構造」 を参照してください。
<security-management>
このセクションは、security サブシステムの高レベルの動作をオーバーライドします。スレッドの安全性を強化するため、セキュリティートークンへコピーまたはリンクするかどうかを指定するオプション設定 deep-copy-subject-mode が含まれます。
<security-domains>
複数のセキュリティードメインを保持するコンテナ要素です。セキュリティードメインには認証、承認、マッピング、監査モジュール、JASPI 認証、および JSSE 設定の情報が含まれることがあります。アプリケーションはセキュリティードメインを指定してセキュリティー情報を管理します。
<security-properties>
java.security.Security クラスに設定されるプロパティーの名前と値が含まれます。

12.3.2. セキュリティー管理

12.3.2.1. ディープコピーサブジェクトモード

ディープコピーサブジェクトモード が無効であるときに (デフォルト)、セキュリティーデータ構造をコピーすると、データ構造全体がコピーされずに元のデータ構造への参照が作成されます。この挙動は効率的ですが、同一 ID の複数のスレッドによってフラッシュまたはログアウトの操作が行われ、サブジェクトが消去されると、データが破損しやすくなります。
ディープコピーサブジェクトモードでは、クローン可能と指定されていると、データ構造およびデータ構造に関連するデータの完全コピーが作成されます。このモードはよりスレッドセーフですが、効率は悪くなります。
ディープコピーサブジェクトモードは、セキュリティーサブシステムの一部として設定されます。

12.3.2.2. ディープコピーサブジェクトモードの有効化

Web ベースの管理コンソールまたは管理 CLI より、ディープコピーセキュリティーモードを有効にできます。

手順12.1 管理コンソールからディープコピーセキュリティーモードを有効化

  1. 管理コンソールへのログイン

    手順の詳細は、カスタマーポータルの https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/ にある JBoss Enterprise Application Platform 6.x『管理および設定ガイド』の「管理コンソール」の章を参照してください。
  2. 管理対象ドメイン: 適切なプロファイルを選択します。

    管理対象ドメインではプロファイルごとにセキュリティーサブシステムが設定されているため、各プロファイルに対して個別にディープコピーセキュリティーモードを有効または無効にできます。
    プロファイルを選択するには、画面の上部にあるの右上にある Configuration をクリックし、左上にある Profile ドロップダウンボックスよりプロファイルを選択します。
  3. Security Subsystem 設定メニューを開きます。

    Security メニューを展開し、Security Subsystem を選択します。
  4. Deep Copy Subject モードを有効にします。

    Edit をクリックします。Deep Copy Subjects の横にあるボックスにチェックを入れ、ディープコピーサブジェクトモードを有効にします。
管理 CLI を使用したディープコピーサブジェクトモードの有効化

管理 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. セキュリティードメイン

セキュリティードメインは JBoss EAP 6 のセキュリティーサブシステムの一部になります。すべてのセキュリティー設定は、管理対象ドメインのドメインコントローラーまたはスタンドアローンサーバーによって集中管理されるようになりました。
セキュリティードメインは認証、承認、セキュリティーマッピング、監査の設定によって構成されます。セキュリティードメインは Java Authentication and Authorization Service (JAAS) の宣言的セキュリティーを実装します。
認証とはユーザーアイデンティティーを検証することを言います。セキュリティー用語では、このユーザーをプリンシパルと呼びます。認証と承認は異なりますが、含まれている認証モジュールの多くは承認の処理も行います。
承認は、認証されたユーザーが、システムまたは操作の特定のリソースへアクセスできるパーミッションまたは特権を持っているかどうかをサーバーが判断するセキュリティーポリシーです。セキュリティー用語では、ロールとも呼ばれます。
セキュリティーマッピングとは、情報をアプリケーションに渡す前にプリンシパル、ロール、または属性から情報を追加、編集、削除する機能のことです。
監査マネージャーは、プロバイダーモジュールを設定して、セキュリティーイベントの報告方法を制御できるようにします。
セキュリティードメインを使用する場合、アプリケーション自体から特定のセキュリティー設定をすべて削除することが可能です。これにより、一元的にセキュリティーパラメーターを変更できるようにします。このような設定構造が有効な一般的な例には、アプリケーションをテスト環境と実稼動環境間で移動するプロセスがあります。

第13章 認証および承認

13.1. Kerberos と SPNEGO の統合

13.1.1. Kerberos と SPNEGO の統合

Kerberos はオープンネットワークのコンピューティング環境向けの認証方法です。チケットとオーセンティケーターがユーザーとサーバーのアイデンティティーを確立することが基盤となります。これにより、セキュアでない環境上で通信する 2 つのノードがセキュアな状態でお互いのアイデンティティーを確立できるようにします。
SPNEGO は、クライアントアプリケーションによって使用される認証方法で、クライアントアプリケーション自体をサーバーに対して認証します。この技術は、通信を試みるクライアントアプリケーションとサーバーがお互いの認証プロトコルを把握していない場合に使用されます。SPNEGO は、クライアントアプリケーションとサーバー間の共通の GSSAPI メカニズムを判断し、その後のセキュリティー操作をすべてディスパッチします。
Kerberos と SPNEGO の統合

通常の設定では、アクティブディレクトリードメインによって制御されるデスクトップにユーザーがログインします。ユーザーは Web ブラウザー (Firefox または Internet Explorer) を使用して、JBoss EAP 上でホストされる JBoss Negotiation を使用する Web アプリケーションへアクセスします。Web ブラウザーは、デスクトップのサインオン情報を Web アプリケーションへ転送します。JBoss EAP は、アクティブディレクトリーまたは Kerberos サーバーを用いてバックグラウンドの GSS メッセージを使用し、ユーザーを検証します。これにより、ユーザーは Web アプリケーションへのシームレスな SSO を実現できます。

13.1.2. SPNEGO を使用したデスクトップ SSO

SPNEGO を使用するデスクトップ SSO を設定するには、以下を設定します。
  • セキュリティードメイン
  • システムプロパティー
  • Web アプリケーション

手順13.1 SPNEGO を使用するデスクトップ SSO の設定

  1. セキュリティードメインの設定

    セキュリティードメインを設定して、サーバーのアイデンティティーを表し、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>
  2. システムプロパティーの設定

    必要な場合は、システムプロパティーをドメインモデルに設定できます。

    例13.2 システムプロパティーの設定

    <system-properties>
    
          <property name="java.security.krb5.kdc" value="mykdc.mydomain"/>
    
          <property name="java.security.krb5.realm" value="MY_REALM"/>
    
        </system-properties>
  3. 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 の設定

本項では、Active Directory ドメインの一部である Microsoft Windows サーバー上で JBoss EAP が実行されている場合に、JBoss Negotiation で使用する必要があるアカウントの設定方法を説明します。
ここでは、サーバーへのアクセスに使用されるホスト名は {hostname}、レルムは {realm}、ドメインは {domain}、JBoss EAP インスタンスをホストするサーバーは {machine_name} を使用します。

手順13.2 Microsoft Windows ドメインでの JBoss Negotiation の設定

  1. 既存のサービスプリンシパルマッピングの消去

    Microsoft Windows ネットワークでは、一部のマッピングが自動作成されます。自動的に作成されたマッピングを削除し、ネゴシエーションが適切に行われるようにサーバーのアイデンティティーをサービスプリンシパルへマップします。マッピングにより、クライアントコンピューター上の Web ブラウザーがサーバーを信頼し、SPNEGO の実行を試みます。クライアントコンピューターは、HTTP{hostname} 形式のマッピングに対し、ドメインコントローラーを検証します。
    既存のマッピングを削除する手順は次のとおりです。
    • コマンド setspn -L {machine_name} を使用して、コンピューターに対してドメインに登録されたマッピングをリストします。
    • コマンド setspn -D HTTP/{hostname} {machine_name} および setspn -D host/{hostname} {machine_name} を使用して、既存のマッピングを削除します。
  2. ホストユーザーアカウントを作成します。

    注記

    ホストユーザー名には {machine_name} 以外の名前を使用してください。
    これ以降では、ホストユーザー名として {user_name} を使用します。
  3. {user_name}{hostname} の間のマッピングを定義します。

    • コマンド ktpass -princ HTTP/{hostname}@{realm} -pass * -mapuser {domain}\{user_name} を実行し、サービスプリンシパルマッピングを設定します。
    • 入力を要求されたら、ユーザー名のパスワードを入力します。

      注記

      ユーザー名のパスワードをリセットします。これはキータブをエクスポートするために必要です。
    • コマンド setspn -L {user_name} を実行し、マッピングを検証します。
  4. ユーザーのキータブを、JBoss EAP がインストールされているサーバーへエクスポートします。

    コマンド ktab -k service.keytab -a HTTP/{hostname}@{realm} を実行し、キータブをエクスポートします。

    注記

    このコマンドは、HTTP/{hostname} プリンシパルのチケットを、JBoss 上でホストセキュリティードメインを設定するために使用されるキータブ service.keytab へエクスポートします。
  5. セキュリティードメイン内のプリンシパルを次のように定義します。
    <module-option name="principal">HTTP/{hostname}@{realm}</module-option>

13.2. 認証

13.2.1. 認証

認証とは、サブジェクトを識別し、身分が本物であるかを検証することを言います。最も一般的な認証メカニズムはユーザー名とパスワードの組み合わせです。その他の一般的な認証メカニズムは共有キー、スマートカード、または指紋などを使用します。Java Enterprise Edition の宣言的セキュリティーでは、成功した認証の結果のことをプリンシパルと呼びます。
JBoss EAP 6 は認証モジュールのプラグ可能なシステムを使用して、組織ですでに使用されている認証システムへ柔軟に対応し、統合を実現します。各セキュリティードメインには 1 つ以上の設定された認証モジュールが含まれます。各モジュールには、挙動をカスタマイズするための追加の設定パラメーターが含まれています。Web ベースの管理コンソール内に認証サブシステムを設定するのが最も簡単な方法です。
認証と承認が関連している場合も多くありますが、認証と承認は同じではありません。含まれている多くの認証モジュールは承認も処理します。

13.2.2. セキュリティードメインでの認証の設定

セキュリティードメインの認証を設定するには、管理コンソールにログインして以下の手順を実行します。

手順13.8 セキュリティードメインの認証設定

  1. セキュリティードメインの詳細ビューを開きます。

    1. 管理コンソールの上部にある Configuration ラベルをクリックします。
    2. プロファイルビューの左上にある Profile 選択ボックスから編集するプロファイルを選択します。
    3. Security メニューを展開し、Security Domains を選択します。
    4. 編集したいセキュリティードメインの View リンクをクリックします。
  2. 認証サブシステム設定に移動します。

    ビューの上部にある Authentication ラベルを選択します (未選択である場合)。
    設定領域が Login ModulesDetails の 2 つの領域に分割されます。ログインモジュールは、設定の基本単位です。セキュリティードメインには複数のログインモジュールを含めることができ、各ログインモジュールには複数の属性とオプションを含めることができます。
  3. 認証モジュールを追加します。

    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 リストの下方向に進み認証が続行されます。
  4. 認証設定を編集します。

    モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code または Flags を変更できます。Attributes タブが選択されていることを確認します。
  5. モジュールオプションを追加、編集、または削除します (任意)。

    モジュールにオプションを追加する必要がある場合は、Login Modules リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add ボタンをクリックし、オプションのキーと値を指定します。Remove ボタンを使用してオプションを削除します。
結果

認証モジュールが、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。

jboss.security.security_domain モジュールのオプション

デフォルトでは、セキュリティードメインに定義された各ログインモジュールには jboss.security.security_domain モジュールオプションが自動的に追加されます。既知のオプションのみが定義されるようチェックを行うログインモジュールでは、このオプションによって問題が発生します。このようなログインモジュールの 1 つが IBM Kerberos ログインモジュールの com.ibm.security.auth.module.Krb5LoginModule です。

このモジュールオプションを追加する挙動を無効にするには、JBoss EAP 6 の起動時にシステムプロパティーを true に設定します。以下を起動パラメーターに追加します。
-Djboss.security.disable.secdomain.option=true
Web ベースの管理コンソールを使用してこのプロパティーを設定することも可能です。スタンドアロンサーバーでは、システムプロパティーを設定の Profile セクションに設定できます。管理対象ドメインでは、各サーバーグループのシステムプロパティーを設定できます。

13.3. JAAS - Java Authentication and Authorization Service

13.3.1. JAAS

JAAS は Java Authentication and Authorization Service の略で、Java EE 仕様の一部です。JAAS は、プラグ可能な認証および承認によってセキュリティープロバイダーからアプリケーションを抽象化できるようにします。
JAAS 1.0 API は、ユーザー認証および承認のために作成された Java パッケージのセットで構成されます。API は、標準のプラグ可能な認証モジュール (PAM) フレームワークの Java バージョンを実装し、ユーザーベースの承認をサポートするよう Java 2 Platform のアクセス制御アーキテクチャーを拡張します。
JAAS 認証は、プラグ可能な状態で実行されます。これにより、Java アプリケーションは基盤の認証技術に依存せず、セキュリティーマネージャーは異なるセキュリティーインフラストラクチャーで動作できます。セキュリティーマネージャーの実装を変更せずに、セキュリティーインフラストラクチャーとの統合を実現できます。JAAS が使用する認証スタックの設定のみを変更する必要があります。
JAAS の詳細は、Java EE JAAS ドキュメントを参照してください。
JBoss Enterprise Application Platform 6 セキュリティーサブシステムは JAAS API を基盤としています。

13.3.2. JAAS コアクラス

JAAS コアクラスは共通、認証、および承認の 3 つのコアクラスに分類できます。本章で取り上げる EAP セキュリティーサブシステムの機能を実装するために使用されるクラスは共通および認証クラスであるため、以下の一覧にはこの 2 つのクラスのみが記載されています。
共通クラスは次のとおりです。
  • 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. サブジェクトおよびプリンシパルクラス

リソースへのアクセスを承認するには、アプリケーションが最初に要求元を認証する必要があります。JAAS フレームワークはサブジェクトを定義して要求元を表します。Subject クラスは JAAS の中心クラスです。Subject は人やサービスなどの、単一エンティティーの情報を表します。これには、エンティティーのプリンシパル、パブリックのクレデンシャル、プライベートのクレデンシャルなどが含まれます。JAAS API は既存の Java 2 の java.security.Principal インターフェースを使用して、プリンシパルを表します。これは、基本的に入力された名前になります。
認証プロセス中、サブジェクトには関連するアイデンティティーまたはプリンシパルが入力されます。サブジェクトに複数のプリンシパルが含まれるようにすることができます。たとえば、一個人は名前のプリンシパル (John Doe)、ソーシャルセキュリティ番号のプリンシパル (123-45-6789)、ユーザー名のプリンシパル (johnd) を持つことができ、これらすべてのプリンシパルはサブジェクトを他のサブジェクトから区別するのに役立ちます。1 つのサブジェクトに関連するプリンシパルを取得する方法は 2 つあります。
public Set getPrincipals() {...}
public Set getPrincipals(Class c) {...}
getPrincipals() はサブジェクトに含まれるすべてのプリンシパルを返します。getPrincipals(Class c) は、クラス c のインスタンスまたはそのサブクラスの 1 つであるプリンシパルのみを返します。サブジェクトに一致するプリンシパルがない場合は、空のセットが返されます。
java.security.acl.Group インターフェースは java.security.Principal のサブインターフェースであるため、プリンシパルのセットのインスタンスは、他のプリンシパルやプリンシパルグループの論理グループを表すことがあります。

13.3.4. サブジェクトの認証

サブジェクト認証には JAAS ログインが必要です。JAAS ログイン設定ファイルの詳細は、Java ドキュメントの JAAS Login Configuration File を参照してください。
以下にログインプロセスを説明します。
  1. アプリケーションは LoginContext をインスタンス化し、ログイン設定の名前と CallbackHandler を渡して、設定 LoginModule が必要とする Callback オブジェクトを追加します。
  2. LoginContext は、名前付きログイン設定に含まれるすべての LoginModules をロードするため Configuration を確認します。このような名前付き設定が存在しない場合は、other 設定がデフォルトで使用されます。
  3. アプリケーションによって、LoginContext.login メソッドが呼び出されます。
  4. ログインメソッドはロードされた各 LoginModule を呼び出します。各 LoginModule はサブジェクトを認証するため、関連する LoginModule でハンドルメソッドを呼び出し、認証プロセスに必要な情報を取得します。必要な情報は、Callback オブジェクトのアレイの形式でハンドルメソッドに渡されます。認証に成功すると、LoginModule は関連のプリンシパルとクレデンシャルをサブジェクトに関連付けします。
  5. LoginContext は認証ステータスをアプリケーションに返します。ログインメソッドから返されると認証が成功したことになります。ログインメソッドによって LoginException が発生すると認証に失敗したことになります。
  6. 認証に成功すると、アプリケーションは LoginContext.getSubject メソッドを使用して認証されたサブジェクトを取得します。
  7. サブジェクトの認証が完了した後に 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 の全体的な認証が成功すると、各 LoginModulecommit が呼び出されます。フェーズ 1 が LoginModule に対して成功すると、コミットメソッドはフェーズ 2 を続行し、関連するプリンシパル、パブリッククレデンシャル、プライベートクレデンシャルをサブジェクトに関連付けます。フェーズ 1 が LoginModule に対して失敗すると、commit はユーザー名やパスワードなどの以前保存した認証状態をすべて削除します。commit メソッドのシグネチャーは boolean commit() throws LoginException です。コミットフェーズの完了に失敗すると、LoginException が発生します。true が返されるとメソッドが成功したことを示し、false が返されるとログインモジュールが無視されることを示します。
  • LoginContext の全体的な認証が失敗すると、各 LoginModuleabort メソッドが呼び出されます。abort メソッドはログインまたは初期化メソッドによって作成されたすべての認証状態を削除または破棄します。abort メソッドのシグネチャーは boolean abort() throws LoginException です。abort フェーズの完了に失敗すると LoginException が発生します。true が返されるとメソッドが成功したことを示し、false が返されるとログインモジュールが無視されることを示します
  • ログイン成功後に認証状態を削除するため、アプリケーションは LoginContextlogout を呼び出します。これにより、各 LoginModulelogout メソッドが呼び出されます。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 インターフェースです。これは複数のデフォルト実装が提供されているタグ付けインターフェースで、前述の例で使用した NameCallbackPasswordCallback が含まれます。LoginModuleCallback を使用し、認証メカニズムで必要となる情報を要求します。LoginModule は認証のログインフェーズの間に Callback のアレイを直接 CallbackHandler.handle メソッドに渡します。callbackhandler がハンドルメソッドに渡された Callback オブジェクトの使用方法が分からない場合は、UnsupportedCallbackException が発生し、ログイン呼び出しが中止されます。

13.4. JASPI (Java Authentication SPI for Containers)

13.4.1. JASPI (Java Authentication SPI for Containers) のセキュリティー

Java Authentication SPI for Containers (JASPI または JASPIC) は Java アプリケーションのプラグ可能なインターフェースです。Java Community Process の JSR-196 に定義されています。この仕様の詳細は http://www.jcp.org/en/jsr/detail?id=196 を参照してください。

13.4.2. JASPI (Java Authentication SPI for Containers) のセキュリティーの設定

JASPI プロバイダーに対して認証するには、<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>
ログインモジュール自体は標準的な認証モジュールと全く同じように設定されます。
Web ベースの管理コンソールは JASPI 認証モジュールの設定を公開しないため、JBoss EAP 6 を完全に停止してから、設定を EAP_HOME/domain/configuration/domain.xml または EAP_HOME/standalone/configuration/standalone.xml へ直接追加する必要があります。

13.5. 承認

13.5.1. 承認

承認とはアイデンティティーを基にリソースへのアクセスを許可または拒否するメカニズムのことです。プリンシパルに追加できる宣言的セキュリティーロールのセットとして実装されます。
JBoss EAP 6 はモジュラーシステムを使用して承認を設定します。各セキュリティードメインに 1 つ以上の承認ポリシーが含まれるようにすることができます。各ポリシーには動作を定義する基本モジュールがあり、特定のフラグや属性より設定されます。Web ベースの管理コンソールを使用すると承認サブシステムを最も簡単に設定できます。
承認は認証とは異なり、通常は認証後に承認が行われます。認証モジュールの多くは承認も処理します。

13.5.2. セキュリティードメインにおける承認の設定

セキュリティードメインの承認を設定するには、管理コンソールにログインして以下の手順を実行します。

手順13.9 セキュリティードメインの承認設定

  1. セキュリティードメインの詳細ビューを開きます。

    1. 管理コンソールの上部にある Configuration ラベルをクリックします。
    2. 管理対象ドメインでは、左上にある Profile ドロップダウンボックスで編集するプロファイルを選択します。
    3. Security メニューを展開し、Security Domains を選択します。
    4. 編集したいセキュリティードメインの View リンクをクリックします。
  2. 承認サブシステム設定に移動します。

    画面の上部にある Authorization ラベルを選択します。
    設定領域が PoliciesDetails の 2 つの領域に分割されます。ログインモジュールは、設定の基本単位です。セキュリティードメインには複数の承認ポリシーを含めることができ、各ログインモジュールには複数の属性とオプションを含めることができます。
  3. ポリシーを追加します。

    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 リストを下方向に進み承認が続行されます。
  4. 承認設定を編集します。

    モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code または Flags を変更できます。Attributes タブが選択されていることを確認します。
  5. モジュールオプションを追加、編集、または削除します (任意)。

    モジュールにオプションを追加する必要がある場合は、Policies リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add をクリックし、オプションのキーと値を指定します。Remove ボタンを使用してオプションを削除します。
結果

承認ポリシーモジュールが、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。

13.6. JACC (Java Authorization Contract for Containers)

13.6.1. JACC (Java Authorization Contract for Containers)

JACC (Java Authorization Contract for Containers) はコンテナーと承認サービスプロバイダー間のインターフェースを定義する規格で、これによりコンテナーによって使用されるプロバイダーの実装が可能になります。JACC は JSR-115 に定義されており、http://jcp.org/en/jsr/detail?id=115 の Java Community Process Web サイトで確認できます。Java EE バージョン 1.3 より、コアの Java Enterprise Edition (Java EE) 仕様の一部となっています。
JBoss EAP 6 はセキュリティーサブシステムのセキュリティー機能内に JACC のサポートを実装します。

13.6.2. JACC (Java Authorization Contract for Containers) のセキュリティーの設定

JACC (Java Authorization Contract for Containers) を設定するには、適切なモジュールでセキュリティードメインを設定し、適切なパラメーターが含まれるよう jboss-web.xml を編集する必要があります。
セキュリティードメインへの JACC サポートの追加

セキュリティードメインに 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>
JACC を使用するよう Web アプリケーションを設定

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 アプリケーションを設定

セキュリティードメインと 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>
Web アプリケーションと同様にセキュリティードメインを使用して EJB の認証および承認メカニズムを指定することも可能です。セキュリティードメインは <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

粒度の細かい承認 (Fine Grained Authorization) は、アクセスするモジュールを承認する基盤となる、意思決定プロセスに関係する要件や変数の変化に対応します。そのため、粒度の細かい承認のプロセスは複雑になります。
JBoss は XACML を媒体として使用し、粒度の細かい承認を実現します。XACML は標準ベースのソリューションを提供し、複雑な粒度の細かい承認に対応します。XACML は、意思決定に対するポリシー言語やアークテクチャーを定義します。XACML アーキテクチャーには、通常のプログラムフローで要求を阻止する PEP (ポリシー強制ポイント) が含まれ、PDP (ポリシー決定ポイント) に関連するポリシーを基にアクセスの決定を行うよう PEP に要求します。PDP は PEP によって作成された XACML 要求を評価し、ポリシーを確認して以下のアクセス決定の 1 つを選択します。
  • PERMIT - アクセスは許可されます。
  • DENY - アクセスは拒否されます。
  • INDETERMINATE - PDP にエラーがあります。
  • NOTAPPLICABLE - 要求に足りない属性があるか、一致するポリシーがありません。
XACML の機能は次のとおりです。
  • Oasis XACML v2.0 ライブラリー
  • JAXB v2.0 ベースのオブジェクトモデル
  • XACML ポリシーおよび属性を保存または読み出しするための ExistDB 統合。

13.6.3.2. 粒度の細かい承認向けの XACML の設定

XACML の設定手順は次のとおりです。

手順13.10 XACML の設定

  1. 単一の jar ファイルであるライブラリーをダウンロードします。
  2. 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>
    

  3. 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>

  4. PDP (ポリシー決定ポイント) を作成し、設定ファイルに渡します。
  5. 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 セキュリティードメインのセキュリティー監査の設定

  1. セキュリティードメインの詳細ビューを開きます。

    1. 画面の上部にある Configuration をクリックします。
    2. 管理対象ドメインでは、左上にある Profile 選択ボックスから編集するプロファイルを選択します。
    3. Security メニューを展開し、Security Domains を選択します。
    4. 編集したいセキュリティードメインの View リンクをクリックします。
  2. 監査サブシステム設定に移動します。

    画面の上部にある Audit タブを選択します。
    設定領域が Provider ModulesDetails の 2 つの領域に分割されます。プロバイダーモジュールは、設定の基本単位です。セキュリティードメインには複数のプロバイダーモジュールを含めることができ、各ログインモジュールには属性とオプションを含めることができます。
  3. プロバイダーモジュールを追加します。

    Add をクリックします。Code セクションに、プロバイダーモジュールのクラス名を入力します。
  4. モジュールの挙動を確認します。

    監査モジュールの目的は、セキュリティーサブシステムのイベントを監視する方法を提供することです。ログファイルの記述、メールによる通知、またはその他の監査メカニズムによって監視を行うことが可能です。
    たとえば、JBoss EAP 6 にはデフォルトで LogAuditProvider モジュールが含まれています。この監査モジュールを前述の手順に従って有効にすると、EAP_HOME ディレクトリー内の log サブフォルダーにある audit.log ファイルにセキュリティー通知を書き込みます。
    前述の手順が LogAuditProvider のコンテキスト内で動作するかを確認するには、通知が発生するようなアクションを実行した後、監査ログファイルをチェックします。
    含まれるセキュリティー監査プロバイダーモジュールの完全一覧は 「含まれるセキュリティー監査プロバイダーモジュール」 を参照してください。
  5. モジュールオプションを追加、編集、または削除します (任意)。

    モジュールにオプションを追加する場合は、Policies リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add をクリックし、オプションのキーと値を指定します。
    すでに存在するオプションを編集するには、Remove をクリックして削除し、Add をクリックして正しいオプションで再度追加します。
結果

セキュリティー監査モジュールは、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。

13.7.3. 新しいセキュリティープロパティー

JBoss EAP バージョン 6.2.2 およびそれ以降のバージョンでは、新しいシステムプロパティーがセキュリティー監査機能に追加されました。これらの新プロパティーは、特に BASIC または FORM ベース認証を使用する場合に関係する、Web リクエストコンポーネントのプレーンテキストロギングをめぐるセキュリティーの問題を緩和します。
新しいプロパティーを使用すると、Web リクエストのどのコンポーネントを監査ログに記録するかをさらに厳格に制御できます (パラメーター、クッキー、ヘッダー、または属性)。新しいプロパティーを使用して、これらのコンポーネントをマスクすることもできます。
新しいプロパティーは次のとおりです。

表13.1 新しいセキュリティープロパティー

名前説明設定可能な値挙動デフォルト
org.jboss.security.web.auditこのプロパティーは Web リクエストのセキュリティー監査の細かさを制御します。offheaderscookiesparametersattributes指定されたコンポーネント (またはカンマ区切りのコンポーネントグループ) が 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 セキュリティードメインでのセキュリティーマッピングの設定

  1. セキュリティードメインの詳細ビューを開きます。

    1. 管理コンソールの上部にある Configuration ラベルをクリックします。
    2. 管理対象ドメインでは、左上にある Profile 選択ボックスからプロファイルを選択します。
    3. Security メニューを展開し、Security Domains を選択します。
    4. 編集したいセキュリティードメインの View リンクをクリックします。
  2. マッピングサブシステム設定に移動します。

    画面の上部にある Mapping ラベルを選択します。
    設定領域が ModulesDetails の 2 つの領域に分割されます。マッピングモジュールは、設定の基本単位です。セキュリティードメインには複数のマッピングモジュールを含めることができ、各ログインモジュールには複数の属性とオプションを含めることができます。
  3. セキュリティーマッピングモジュールを追加します。

    Add をクリックします。
    モジュールの詳細を記入します。Code がモジュールのクラス名です。Type フィールドは、このモジュールが実行するマッピングのタイプを示します。許可される値は、principal、role、attribute、または credential です。
  4. セキュリティーマッピングモジュールを編集します。

    モジュールを追加したら、Code または Type を変更できます。
    1. Attributes タブを選択します。
    2. 画面の Details セクションにある Edit をクリックします。
  5. モジュールオプションを追加、編集、または削除します (任意)。

    モジュールにオプションを追加する場合は、Policies リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add をクリックし、オプションのキーと値を指定します。
    すでに存在するオプションを編集するには、Remove をクリックして削除し、新たな値で再度追加します。
    Remove ボタンを使用して、オプションを削除します。
結果

セキュリティーマッピングモジュールは、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。

13.9. アプリケーションでのセキュリティードメインの使用

概要

アプリケーションでセキュリティードメインを使用するには、最初にサーバーの設定でセキュリティードメインを定義し、アプリケーションのデプロイメント記述子でアプリケーションに対して有効にする必要があります。その後、使用する EJB に必要なアノテーションを追加する必要があります。ここでは、アプリケーションでセキュリティードメインを使用するために必要な手順について取り上げます。

警告

アプリケーションが、認証キャッシュを使用するセキュリティードメインの一部である場合、セキュリティードメインの他のアプリケーションもそのアプリケーションのユーザー認証を使用できます。

手順13.13 セキュリティードメインを使用するようアプリケーションを設定

  1. セキュリティードメインの定義

    サーバーの設定ファイルでセキュリティードメインを定義した後、アプリケーションの記述子ファイルでアプリケーションに対して有効にする必要があります。
    1. サーバーの設定ファイルへセキュリティードメインを設定

      セキュリティードメインは、サーバーの設定ファイルの security サブシステムに設定されます。JBoss EAP 6 インスタンスが管理対象ドメインで実行されている場合、domain/configuration/domain.xml ファイルになります。JBoss EAP 6 インスタンスがスタンドアロンサーバーとして実行されている場合は standalone/configuration/standalone.xml ファイルになります。
      otherjboss-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 を使用して、追加のセキュリティードメインを必要に応じて設定できます。
    2. アプリケーションの記述子ファイルでのセキュリティードメインの有効化

      セキュリティードメインはアプリケーションの 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 つになります。
  2. 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 は、アプリケーションの承認情報の共有を同じ仮想ホスト内に制限します。また、ホストの障害に対する耐性を持ちません。クラスター化された SSO データは複数の仮想ホストのアプリケーション間で共有することができ、フェイルオーバーに対する耐性を持ちます。さらに、クラスター化された SSO はロードバランサーからのリクエストを受信することができます。

SSO の仕組み

リソースが保護されていない場合、ユーザーの認証は完全に無視されます。ユーザーが保護されたリソースにアクセスすると、ユーザーの認証が必要になります。

認証に成功すると、ユーザーに関連するロールが保存され、関連する他のリソースすべての承認に使用されます。
ユーザーがアプリケーションからログアウトしたり、アプリケーションがプログラムを用いてセッションを無効化した場合、永続化された承認データはすべて削除され、プロセスを最初からやり直しします。
他のセッションが有効である場合、セッションタイムアウトは SSO セッションを無効化しません。

14.2. Web アプリケーションのクラスター化されたシングルサインオン (SSO)

シングルサインオン (SSO) とは、ユーザーを単一の Web アプリケーションに対して認証し、その認証に成功した場合は追加の認証を要求せずに他の複数のアプリケーションに対しても認証される機能のことです。クラスター化された SSO はクラスター化されたキャッシュに認証および承認情報を保存します。これにより、複数の異なるサーバー上にあるアプリケーションが情報を共有し、ホストの 1 つが障害を起こした場合でも情報が障害に耐えられるようにします。
SSO の設定はバルブと呼ばれます。バルブは、サーバーやサーバーグループのレベルに設定されるセキュリティードメインへ接続されます。キャッシュされた同じ認証情報を共有する必要がある各アプリケーションは同じバルブを使用するよう設定されます。これは、アプリケーションの jboss-web.xml に設定されます。
JBoss EAP 6 の Web サブシステムによってサポートされる一般的な SSO バルブの一部は次のとおりです。
  • Apache Tomcat の ClusteredSingleSignOn
  • Apache Tomcat の IDPWebBrowserSSOValve
  • PicketLink によって提供される SPNEGO ベースの SSO
バルブのタイプによっては、バルブが適切に動作するよう、セキュリティードメインに追加設定を行う必要がある場合があります。

14.3. 適切な SSO 実装の選択

JBoss EAP 6 は Web アプリケーションや EJB アプリケーション、Web サービスなどの Java Enterprise Edition (EE) アプリケーションを実行します。SSO (Single Sign On: シングルサインオン) により、これらのアプリケーションの間でセキュリティーコンテキストとアイデンティティー情報が伝播できるようになります。複数の SSO ソリューションを利用できますが、要件によって適切なソリューションは異なります。
クラスター化された Web アプリケーションと、クラスター化された SSO には明白な違いがあることに注意してください。クラスター化された Web アプリケーションは、クラスターのノード全体で分散され、アプリケーションをホストする負荷を分散します。分散可能と指定されると、新しいセッションと既存セッションへの変更がクラスターの他のメンバーへレプリケートされます。アプリケーションがクラスターノード全体で分散可能であることを指定するには、web.xml デプロイメント記述子で <distributable/> タグを使用します。クラスター化された SSO を使用すると、アプリケーションがクラスター化されているかどうかに関わらず、セキュリティーコンテキストやアイデンティティー情報のレプリケーションが可能になります。これらの技術は一緒に使用されることもありますが、概念は異なります。
Kerberos ベースのデスクトップ SSO

Microsoft Active Directory など、Kerberos ベースの認証承認システムがすでに組織で使用されている場合は、同じシステムを使用して JBoss EAP 6 上で実行されているエンタープライズアプリケーションを透過的に認証することができます。

クラスター化されていない Web アプリケーション SSO

1 つのインスタンスで複数のアプリケーションを実行し、これらのアプリケーションに対して SSO セッションのレプリケーションを有効にする必要がある場合、クラスター化されていない SSO が要件に合います。

クラスター化された Web アプリケーション 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 設定ファイルにある同じレルムを使用するよう設定されている必要があります。
クラスター化された SSO またはクラスター化されていない SSO の設定

サーバープロファイルの 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

Kerberos はクライアント/サーバーアプリケーションのネットワーク認証プロトコルです。秘密鍵の対称暗号化を使用して、セキュアでないネットワーク全域でセキュアに認証を行えるようにします。
Kerberos はチケットと呼ばれるセキュリティートークンを使用します。セキュアなサービスを使用するには、ネットワークのサーバー上で稼働している TGS (チケット交付サービス: Ticket Granting Service) よりチケットを取得する必要があります。チケットの取得後、ネットワーク上で実行している別のサービスである AS (認証サービス: Authentication Service) より ST (サービスチケット: Service Ticket) を要求します。その後、ST を使用して使用したいサービスを認証します。TGS と AS は KDC (鍵配布センター: Key Distribution Center) と呼ばれるエンクロージングサービス内で実行されます。
Kerberos はクライアントサーバー環境で使用する目的で開発されているため、Web アプリケーションやシンクライアント環境ではほとんど使用されません。しかし、多くの組織で Kerberos システムはデスクトップの認証に使用されており、Web アプリケーション向けに別のシステムを作成せずに既存システムを再使用することが好まれます。Kerberos は Microsoft Active Directory には不可欠なもので、多くの Red Hat Enterprise Linux 環境でも使用されています。

14.6. SPNEGO

SPNEGO (Simple and Protected GSS_API Negotiation Mechanism) は Web アプリケーションで使用するため Kerberos ベースの SSO (Single Sign On) 環境を拡張するメカニズムを提供します。
Web ブラウザーなどのクライアントコンピューター上のアプリケーションが Web サーバーの保護ページにアクセスしようとすると、サーバーは承認が必要であることを伝えます。その後、アプリケーションは KDC (Kerberos Key Distribution Center) からのサービスチケットを要求します。チケットの取得後、アプリケーションはこのチケットをSPNEGO 向けにフォーマットされた要求にラップし、ブラウザーより Web アプリケーションへ返信します。デプロイされた Web アプリケーションを実行している Web コンテナーが要求をアンパックし、チケットを認証します。認証に成功するとアクセスが許可されます。
SPNEGO は Red Hat Enterprise Linux に含まれる Kerberos サービスや Microsoft Active Directory には不可欠な Kerberos サーバーなど、全タイプの Kerberos プロバイダーと動作します。

14.7. Microsoft Active Directory

Microsoft Active Directory は Microsoft Windows のドメインでユーザーとコンピューターを認証するために Microsoft によって開発されたディレクトリーサービスです。Microsoft Windows Server に含まれています。Microsoft Windows Server のコンピューターはドメインコントローラーと呼ばれます。Samba サービスを実行している Red Hat Enterprise Linux サーバーもこのようなネットワークでドメインコントローラーとして機能することが可能です。
Active Directory は連携する以下の 3 つのコア技術に依存します。
  • ユーザー、コンピューター、パスワードなどのリソースの情報を保存する 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 Enterprise Application Platform の以前のバージョンとの相違点

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 ログインモジュール
SPNEGOorg.jboss.security.negotiation.spnego.SPNEGOLoginModuleWeb アプリケーションが Kerberos 認証サーバーへ認証できるようにするメカニズム。
AdvancedLdaporg.jboss.security.negotiation.AdvancedLdapLoginModuleMicrosoft Active Directory 以外の LDAP サーバーと使用されます。
AdvancedAdLdaporg.jboss.security.negotiation.AdvancedADLoginModuleMicrosoft Active Directory の LDAP サーバーと使用されます。
JBoss Negotiation Toolkit

JBoss Negotiation Toolkithttps://community.jboss.org/servlet/JiveServlet/download/16876-2-34629/jboss-negotiation-toolkit.war よりダウンロード可能なデバッグ用のツールです。アプリケーションを実稼動環境に導入する前に認証メカニズムをデバッグし、テストできるようにするため提供されている追加のツールです。サポート対象のツールではありませんが、SPENEGO を Web アプリケーションに対して設定することは難しいこともあるため、大変便利なツールと言えます。

手順14.1 Web または EJB アプリケーションへ SSO 認証を設定

  1. サーバーのアイデンティティーを表すセキュリティードメインを 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>
  2. 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>
  3. 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>
  4. 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>
  5. アプリケーションの 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 フォールバックの設定

以下の手順に従って、フォーム認証への SPNEGO フォールバックを設定します。

手順14.2 フォーム認証へフォールバックする SPNEGO セキュリティー

  1. SPNEGO の設定

  2. 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>
  3. 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>

注記

FORM ロジックへのフォールバックは、SPNEGO (または NTLM) トークンが存在しない場合のみ利用できます。そのため、ブラウザーが NTLM トークンを送信する場合はログインフォームがブラウザーに提供されません。

第15章 SAML を用いたシングルサインオン

15.1. セキュリティートークンサービス (STS)

セキュリティートークンサービスは、セキュリティートークンを生成および管理します。特定タイプのトークンは発行しませんが、複数のトークンプロバイダーがプラグインできるようにする汎用インターフェースを定義します。そのため、トークンプロバイダーがトークンタイプごとに存在すれば、さまざまなタイプのトークンに対応するよう設定できます。また、セキュリティートークン要求および応答メッセージの形式も指定します。
セキュリティートークン要求メッセージは、以下を指定します。
  • Issue や Renew などの要求タイプ。
  • トークンのタイプ。
  • 発行されたトークンのライフタイム。
  • トークンを要求したサービスプロバイダーに関する情報。
  • 生成されたトークンを暗号化するために使用される情報。

注記

PKCS#11 トークンのサポートが JBoss EAP バージョン 6.3.0 より追加されました。
provider 属性を使用すると、EAP のセキュリティーレルムは PKCS#11 キーおよびトラストストアの定義を許可できます。このパラメーターに指定された値は、関連する KeyStore.getInstance("PKCS11") 呼び出しへ渡され、キーとトラストストアが初期化されます。
この新しいサポートの設定については、EAP ドキュメントの範囲外になります。この機能を使用したいユーザーは、PKCS#11 ハードウェアおよびソフトウェアのインストールや、java.security ポリシーファイルに必要なエントリーに関する正しい知識が必要になります。Oracle の 『Java PKCs#11 Reference Guide』 にこの情報が記載されています。
トークン要求メッセージは、SOAP メッセージのボディーに含まれ送信されます。トークン要求に関連するすべての情報は RequestSecurityToken 要素で囲まれます。要求の例には、この要求が Issue 要求であることを指定する RequestType と、発行するトークンのタイプを指定する TokenType の 2 つの WS-Trust 要素も含まれています。
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 を使用してデフォルト値を設定します (要求がトークンのライフタイム値を指定しない場合など)。
  • WSTrustRequestHandlerWSTrustRequestContext を作成し、PicketLinkSTS より受信した JAXB 要求オブジェクトおよび呼び出し元プリンシパルを設定します。
  • WSTrustRequestHandlerSTSConfiguration を使用して、要求されたトークンのタイプを基に要求の処理に使用する必要がある SecurityTokenProvider を取得します。その後、プロバイダーを呼び出し、構築された WSTrustRequestContext をパラメーターとして渡します。
  • SecurityTokenProvider インスタンスはトークン要求を処理し、発行されたトークンを要求コンテキストに保存します。
  • WSTrustRequestHandler はトークンをコンテキストから取得し、必要な場合は暗号化します。また、セキュリティートークンが含まれる WS-Trust 応答オブジェクトを構築します。
  • PicketLinkSTS は要求ハンドラーによって生成される応答を書き取り、クライアントへ返します。

15.2. セキュリティートークンサービス (STS) の設定

EAP のセキュリティートークンサービス (STS) は拡張ポイントを提供する複数のインターフェースを定義します。実装は設定でプラグインでき、一部のプロパティーのデフォルト値は設定で指定できます。すべての STS 設定は、デプロイされたアプリケーションの WEB-INF ディレクトリーにある picketlink.xml ファイルで指定されます。picketlink.xml ファイルで設定できる要素は次のとおりです。

注記

以下では、サービスプロバイダーとはクライアントによって提示されるセキュリティートークンを必要とする Web サービスのことを言います。
  • 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 は、STSConfigurationgetProviderForTokenType (文字列タイプ) メソッドを呼び出し、適切な TokenProvider への参照を取得します。
  • TokenTimeout: WS-Trust 要求にライフタイムが指定されていない場合に、WSTrustRequestHandler によって使用されます。作成時間が現在の時間で、指定の秒数後に期限切れとなるライフタイムインスタンスを作成します。
  • ServiceProviders: 各サービスプロバイダー (セキュリティートークンを必要とする Web サービス) に使用しなければならないトークンタイプを指定します。WS-Trust 要求にトークンタイプが含まれていない場合、WSTrustRequestHandler はサービスプロバイダーエンドポイントを使用して、発行する必要があるトークンのタイプを確認する必要があります。
  • EncryptToken: 発行されたトークンを暗号化する必要があるかどうかを決定するために、 WSTrustRequestHandler によって使用されます。true の場合、サービスプロバイダーの公開鍵証明書 (PKC) を使用してトークンが暗号化されます。
以下に、STS の設定例を示します。

例15.3 STS 設定

<PicketLinkSTS xmlns="urn:picketlink:identity-federation:config:1.0"  
         STSName="Test STS" TokenTimeout="7200" EncryptToken="true">  
  <KeyProvider ClassName="org.picketlink.identity.federation.bindings.tomcat.KeyStoreKeyManager">  
    <Auth Key="KeyStoreURL" Value="keystore/sts_keystore.jks"/>   
    <Auth Key="KeyStorePass" Value="testpass"/>  
    <Auth Key="SigningKeyAlias" Value="sts"/>  
    <Auth Key="SigningKeyPass" Value="keypass"/>  
    <ValidatingAlias Key="http://services.testcorp.org/provider1" Value="service1"/>  
    <ValidatingAlias Key="http://services.testcorp.org/provider2" Value="service2"/>  
 </KeyProvider>  
 <RequestHandler>org.picketlink.identity.federation.core.wstrust.StandardRequestHandler</RequestHandler>  
 <TokenProviders>  
    <TokenProvider ProviderClass="org.picketlink.test.identity.federation.bindings.wstrust.SpecialTokenProvider"  
         TokenType="http://www.tokens.org/SpecialToken"/>  
    <TokenProvider ProviderClass="org.picketlink.identity.federation.api.wstrust.plugins.saml.SAML20TokenProvider"  
         TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"/>  
	</TokenProviders>  
	<ServiceProviders>  
		<ServiceProvider Endpoint="http://services.testcorp.org/provider1" TokenType="http://www.tokens.org/SpecialToken"  
         TruststoreAlias="service1"/>  
		<ServiceProvider Endpoint="http://services.testcorp.org/provider2" TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"  
         TruststoreAlias="service2"/>  
	</ServiceProviders>  
</PicketLinkSTS>