セキュリティーガイド


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
    Copy to Clipboard Toggle word wrap
    -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"
    Copy to Clipboard Toggle word wrap

    例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"
    Copy to Clipboard Toggle word wrap

    例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"
    Copy to Clipboard Toggle word wrap

    例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"
    Copy to Clipboard Toggle word wrap
  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
Copy to Clipboard Toggle word wrap

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"
Copy to Clipboard Toggle word wrap
Windows
set "JAVA_OPTS=%JAVA_OPTS% -Djava.security.debug=access:failure"
Copy to Clipboard Toggle word wrap
結果

セキュリティー関連デバッグ情報の一般的なレベルが有効になります。

第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()
    Copy to Clipboard Toggle word wrap
    スタンドアロンインスタンスでは以下のコマンドを使用します。
    /core-service=management/security-realm=MyDomainRealm:add()
    Copy to Clipboard Toggle word wrap
  3. 新しいロールの情報を保存するプロパティーファイルへの参照を作成します。

    次のコマンドを実行し、新しいロールに関連するプロパティーが含まれる myfile.properties という名前のファイルのポインターを作成します。

    注記

    新たに作成されたプロパティーファイルは、含まれる add-user.sh および add-user.bat スクリプトによって管理されません。そのため、外部で管理する必要があります。
    ドメインインスタンスでは以下コマンドを使用します。
    /host=master/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
    Copy to Clipboard Toggle word wrap
    スタンドアロンインスタンスでは以下のコマンドを使用します。
    /core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
    Copy to Clipboard Toggle word wrap
結果

新しいセキュリティーレルムが作成されます。新たに作成されたこのレルムにユーザーやロールを追加すると、デフォルトのセキュリティーレルムとは別のファイルに情報が保存されます。新規ファイルはご使用のアプリケーションやプロシージャーを使用して管理できます。

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
    Copy to Clipboard Toggle word wrap

    例4.2 管理インターフェースの指定

    EAP_HOME/bin/domain.sh -bmanagement=10.1.1.1
    Copy to Clipboard Toggle word wrap

    例4.3 各インターフェースへの異なるアドレスの指定

    EAP_HOME/bin/domain.sh -bmanagement=127.0.0.1 -b 10.1.1.1
    Copy to Clipboard Toggle word wrap

    例4.4 すべてのネットワークインターフェースへのパブリックインターフェースのバインド

    EAP_HOME/bin/domain.sh -b 0.0.0.0
    Copy to Clipboard Toggle word wrap
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"'
    Copy to Clipboard Toggle word wrap
  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"'
    Copy to Clipboard Toggle word wrap

手順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
    Copy to Clipboard Toggle word wrap

    注記

    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
Expand
表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 ベンダーのドキュメントを確認してください。
Expand
表4.2 推奨される暗号プリミティブ
2048 ビットキーと OAEP を使用する RSA
CBC モードの AES-128
SHA-256
HMAC-SHA-256
HMAC-SHA-1
Expand
表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)
    Copy to Clipboard Toggle word wrap
  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)
    Copy to Clipboard Toggle word wrap
  3. プロトコルを TLSv1 に設定します。

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

    注記

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

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

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

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

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

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

    CA で指示された順序で各証明書をインポートします。各証明書をインポートするには、intermediate.ca または server.crt を実際のファイル名に置き換えます。証明書が別のファイルとして提供されない場合は、各証明書に対して個別のファイルを作成し、その内容をファイルに貼り付けます。

    注記

    署名済み証明書および証明書キーは機密情報です。サーバー間での転送方法に注意してください。
    keytool -import -keystore server.keystore -alias intermediateCA -file intermediate.ca
    Copy to Clipboard Toggle word wrap
    keytool -importcert -alias jboss -keystore server.keystore -file server.crt
    Copy to Clipboard Toggle word wrap
  8. 証明書が正常にインポートされたことをテストします。

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

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

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

JBoss Web コネクターには、次の SSL 設定属性を含めることができます。提供された CLI コマンドは、プロファイル default を使用した管理対象ドメイン向けに設計されています。プロファイル名を、管理対象ドメインに対して設定する名前に変更するか、コマンドの /profile=default 部分を省略します (スタンドアロンサーバーの場合)。
Expand
表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)
Copy to Clipboard Toggle word wrap
2 つ目のコマンド例は APR コネクターを使用します。
/profile=default/subsystem=web/connector=APR/ssl=configuration/:write-attribute(name=verify-client,value=require)
Copy to Clipboard Toggle word wrap
verify-depth
クライアントが有効な証明を持たないと判断するまでにチェックされる中間証明書発行者の最大数。デフォルト値は 10 です。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=verify-depth,value=10)
Copy to Clipboard Toggle word wrap
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)
Copy to Clipboard Toggle word wrap
certificate-file
OpenSSL 暗号化を使用する場合は、このパラメーターの値を、サーバー証明書を含むファイルに対するパスに設定します。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=certificate-file,value=server.crt)
Copy to Clipboard Toggle word wrap
password
トラストストアおよびキーストアのパスワード。以下の例では、PASSWORD を実際のパスワードに置き換えます。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=password,value=PASSWORD)
Copy to Clipboard Toggle word wrap
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)
Copy to Clipboard Toggle word wrap
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=protocol,value="TLSv1, TLSv1.1,TLSv1.2")
Copy to Clipboard Toggle word wrap
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")
Copy to Clipboard Toggle word wrap
key-alias
キーストア内のサーバー証明書に使用されるエイリアス。以下の例では、KEY_ALIAS を実際の証明書のエイリアスに置き換えます。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=key-alias,value=KEY_ALIAS)
Copy to Clipboard Toggle word wrap
truststore-type
トラストストアのタイプ。PKCS12 や Java の標準 JKS など、さまざまなタイプのトラストストアが使用可能です。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=truststore-type,value=jks)
Copy to Clipboard Toggle word wrap
keystore-type
キーストアのタイプ。PKCS12 や Java の標準 JKS など、さまざまなタイプのキーストアが使用可能です。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=keystore-type,value=jks)
Copy to Clipboard Toggle word wrap
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)
Copy to Clipboard Toggle word wrap
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)
Copy to Clipboard Toggle word wrap
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)
Copy to Clipboard Toggle word wrap
session-cache-size
SSLSession キャッシュのサイズ。この属性は、JSSE コネクターへのみ適用されます。デフォルト値は 0 で、無制限のキャッシュサイズが指定されます。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=session-cache-size,value=100)
Copy to Clipboard Toggle word wrap
session-timeout
キャッシュされた SSLSession が期限切れになるまでの秒数。この属性は JSSE コネクターへのみ適用されます。デフォルト値は 86400 秒 (24 時間) です。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=session-timeout,value=43200)
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap
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
Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap
  2. NSS 設定ファイルの作成

    次の内容が含まれる nss_pkcsll_fips.cfg という名前の新しいテキストファイルを /usr/share/jboss-as ディレクトリーに作成します。
    name = nss-fips
    nssLibraryDirectory=/usr/lib64
    nssSecmodDirectory=/usr/share/jboss-as/nssdb
    nssModule = fips
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap
    この行に指定されている設定ファイルは手順 2 で作成されたファイルであることに注意してください。
    このプロバイダーを優先するため、このファイルにある他の security.provider.X 行の値 (X) に 1 を足す必要があります。
  4. NSS ライブラリーに対して FIPS モードを有効にする

    次のように modutil コマンドを実行し、FIPS モードを有効にします。
    modutil -fips true -dbdir /usr/share/jboss-as/nssdb
    Copy to Clipboard Toggle word wrap
    ここで指定するディレクトリーは手順 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
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap
  7. PKCS11 キーストアを使用するよう HTTPS コネクターを設定する

    JBoss CLI ツールで次のコマンドを使用し、HTTPS コネクターを追加します。
    /subsystem=web/connector=https/:add(socket-binding=https,scheme=https,protocol=HTTP/1.1,secure=true)
    Copy to Clipboard Toggle word wrap
    次に、以下のコマンドを使用して 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")
    Copy to Clipboard Toggle word wrap
  8. 検証

    次のコマンドを実行し、JVM が PKCS11 キーストアから公開鍵を読み取れることを検証します。
    keytool -list -storetype pkcs11
    Copy to Clipboard Toggle word wrap

例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>
Copy to Clipboard Toggle word wrap
読みやすくするため、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)
Copy to Clipboard Toggle word wrap
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"
    }
}
Copy to Clipboard Toggle word wrap
HTTP インターフェースを削除するには、次のコマンドを実行します。

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

/host=master/core-service=management/management-interface=http-interface/:remove
Copy to Clipboard Toggle word wrap
アクセスを再度有効化するには、以下のコマンドを実行し、デフォルト値を使用して 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)
Copy to Clipboard Toggle word wrap

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>
Copy to Clipboard Toggle word wrap

要件

  • JBoss EAP 6 インスタンスを起動します。
  • 管理 CLI を起動します。

手順5.1 デフォルトセキュリティーレルムからのサイレント認証の削除

  • 管理 CLI でのサイレント認証の削除

    必要に応じて、管理レルムとアプリケーションレルムから local 要素を削除します。
    1. 管理レルムから local 要素を削除します。
      • スタンドアロンの場合

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

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

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

        /host=HOST_NAME/core-service=management/security-realm=ApplicationRealm/authentication=local:remove
        Copy to Clipboard Toggle word wrap
結果

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

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

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

注記

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

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

/profile=default/subsystem=jmx/remoting-connector=jmx/:remove
Copy to Clipboard Toggle word wrap

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

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

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"
        }}
    }
}
Copy to Clipboard Toggle word wrap
セキュリティーレルムを新たに作成します。

以下のコマンドは 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)
Copy to Clipboard Toggle word wrap
既存のセキュリティードメインを用いたセキュリティーレルム認証の設定

セキュリティードメインを使用して管理インターフェースに対して認証を行うには、以下の手順に従います。

最初にセキュリティーレルムを作成します。次に、そのセキュリティーレルムを管理インターフェースの security-realm 属性の値として指定します。

例5.9 HTTP 管理インターフェースに使用するセキュリティーレルムの指定

/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=TestRealm)
Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap
  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)
      Copy to Clipboard Toggle word wrap
      /core-service=management/management-interface=http-interface:undefine-attribute(name=socket-binding)
      Copy to Clipboard Toggle word wrap
      これらのコマンド実行後、以下のような出力が表示されるはずです。
      {"outcome" => "success"}
      Copy to Clipboard Toggle word wrap

      注記

      この時点で、JBoss EAP のログに以下のようなエラーメッセージが表示されることがありますが、この時点では SSL の設定が完了していないため表示されます。
      JBAS015103: A secure port has been specified for the HTTP interface but no SSL configuration in the realm.
      Copy to Clipboard Toggle word wrap
    • ドメインモード

      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)
      Copy to Clipboard Toggle word wrap

      注記

      この時点で、JBoss EAP のログに以下のようなエラーメッセージが表示されることがありますが、この時点では SSL の設定が完了していないため表示されます。
      JBAS015103: A secure port has been specified for the HTTP interface but no SSL configuration in the realm.
      Copy to Clipboard Toggle word wrap
  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}"/>
    Copy to Clipboard Toggle word wrap
  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)
    Copy to Clipboard Toggle word wrap
  5. 新しいセキュリティーを使用するよう管理インターフェースを設定します。

    以下のコマンドを入力します。
    /host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=ManagementRealmHTTPS)
    Copy to Clipboard Toggle word wrap
  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)
    Copy to Clipboard Toggle word wrap
    このコマンド実行後、以下のような出力が表示されるはずです。
    {
        "outcome" => "success",
        "response-headers" => {
            "operation-requires-reload" => true,
            "process-state" => "reload-required"
        }
    }
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap

注記

セキュリティー上の理由により、キーストアのパスワードをマスクすることが推奨されます。マスクする方法の詳細は「パスワード 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>
Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap
    keytool -genkeypair -alias HOST2_alias -keyalg RSA -keysize 1024 -validity 365 -keystore host2.keystore.jks -dname "CA_HOST2" -keypass secret -storepass secret
    Copy to Clipboard Toggle word wrap
  2. 証明書をエクスポートします。
    keytool -exportcert  -keystore HOST1.keystore.jks -alias HOST1_alias -keypass secret -storepass secret -file HOST1.cer
    Copy to Clipboard Toggle word wrap
    keytool -exportcert  -keystore HOST2.keystore.jks -alias HOST2_alias -keypass secret -storepass secret -file HOST2.cer
    Copy to Clipboard Toggle word wrap
  3. 証明書を反対のトラストストアにインポートします。
    keytool -importcert -keystore HOST1.truststore.jks -storepass secret -alias HOST2_alias -trustcacerts -file HOST2.cer
    Copy to Clipboard Toggle word wrap
    keytool -importcert -keystore HOST2.truststore.jks -storepass secret -alias HOST1_alias -trustcacerts -file HOST1.cer
    Copy to Clipboard Toggle word wrap
  4. インストールの設定に CertificateRealm を定義し (host.xml または standalone.xml)、インターフェースがそれを示すようにします。
    これを行うには、設定ファイルを手作業で編集するか (非推奨)、以下のコマンドを使用します。
    /core-service=management/security-realm=CertificateRealm:add()
    Copy to Clipboard Toggle word wrap
    /core-service=management/security-realm=CertificateRealm/server-identity=ssl:add(keystore-path=/path/to/HOST1.keystore.jks,keystore-password=secret, alias=HOST1_alias)
    Copy to Clipboard Toggle word wrap
    /core-service=management/security-realm=CertificateRealm/authentication=truststore:add(keystore-path=/path/to/HOST1.truststore.jks,keystore-password=secret)
    Copy to Clipboard Toggle word wrap

    重要

    これらのコマンドはスタンドアロンモードのみに提供されます。ドメインモードでは各コマンドの前に /host=master を追加します。
  5. ネイティブインターフェースの security-realm を新しい証明書レルムに変更します。
    /host=master/core-service=management/management-interface=native-interface:write-attribute(name=security-realm,value=CertificateRealm)
    Copy to Clipboard Toggle word wrap
  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>
      Copy to Clipboard Toggle word wrap
    • プレーンテキストでキーストアおよびトラストストアのパスワードを保存する方法
      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>
      Copy to Clipboard Toggle word wrap

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()
Copy to Clipboard Toggle word wrap
次に、セキュリティーレルムを作成し、JAAS 認証を指定します。
/core-service=management/security-realm=SecurityDomainAuthnRealm:add
/core-service=management/security-realm=SecurityDomainAuthnRealm/authentication=jaas:add(name=UsersLMDomain)
Copy to Clipboard Toggle word wrap
assign-groups 属性は、セキュリティードメインからロードされたユーザーメンバーシップ情報がセキュリティーレルムのグループ割り当てに使用されるかどうかを決定します。true に設定すると、このグループの割り当てが RBAC (ロールベースアクセス制御) に使用されます。
以下の CLI コマンドを使用すると assign-groups 属性を true に設定できます。
/core-service=management/security-realm=ManagementRealm/authentication=jaas:write-attribute(name=assign-groups,value=true)
Copy to Clipboard Toggle word wrap

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 送信接続には、以下の属性を使用することができます。

Expand
表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
Copy to Clipboard Toggle word wrap
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")
Copy to Clipboard Toggle word wrap
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))
Copy to Clipboard Toggle word wrap

例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>
Copy to Clipboard Toggle word wrap

警告

空の 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")
Copy to Clipboard Toggle word wrap
管理インターフェースへの新規セキュリティーレルムの適用

セキュリティーレルムの作成が完了したら、管理インターフェースの設定でそのドメインを参照する必要があります。管理インターフェースは、HTTP ダイジェスト認証用のセキュリティーレルムを使用します。

例5.13 HTTP インターフェースへのセキュリティーレルムの適用

この設定が有効になり、ホストコントローラーを再起動した後、Web ベースの管理コンソールは LDAP を使用してユーザーの認証を行います。
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=ldap_security_realm)
Copy to Clipboard Toggle word wrap

例5.14 セキュリティーレルムのネイティブインターフェースへの適用

以下のコマンドを使用して同じ設定をネイティブインターフェースに適用します。
/host=master/core-service=management/management-interface=native-interface/:write-attribute(name=security-realm,value=ldap_security_realm)
Copy to Clipboard Toggle word wrap

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")
    Copy to Clipboard Toggle word wrap
  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「ロールパーミッション」 は各ロールのパーミッションを示しています。
Expand
表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)
    Copy to Clipboard Toggle word wrap
    [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
    }
    Copy to Clipboard Toggle word wrap

手順6.2 RBAC の無効化

  • 管理 CLI で RBAC を無効にするには、アクセス承認リソースの write-attribute 操作を使用して、プロバイダー属性を simple に設定します。
    /core-service=management/access=authorization:write-attribute(name=provider, value=simple)
    Copy to Clipboard Toggle word wrap
    [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
    }
    Copy to Clipboard Toggle word wrap
サーバーがオフラインの場合は、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>
Copy to Clipboard Toggle word wrap

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)
    Copy to Clipboard Toggle word wrap
    有効なポリシー名は 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]
    
    Copy to Clipboard Toggle word wrap
サーバーがオフラインの場合は、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>
Copy to Clipboard Toggle word wrap

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 ダイアログが表示されます。

    図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 をクリックします。選択パネルが編集モードになります。

    図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
Copy to Clipboard Toggle word wrap

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

  1. :read-children-names 操作を使用して、設定されたロールの完全リストを取得します。
    /core-service=management/access=authorization:read-children-names(child-type=role-mapping)
    Copy to Clipboard Toggle word wrap
    [standalone@localhost:9999 access=authorization] :read-children-names(child-type=role-mapping)
    {
        "outcome" => "success",
        "result" => [
            "Administrator",
            "Deployer",
            "Maintainer",
            "Monitor",
            "Operator",
            "SuperUser"
        ]
    }
    Copy to Clipboard Toggle word wrap
  2. 指定されたロールマッピングの read-resource 操作を使用して、特定ロールの完全詳細を取得します。
    /core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)
    Copy to Clipboard Toggle word wrap
    [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]
    Copy to Clipboard Toggle word wrap

手順6.8 新規ロールの追加

この手順は、ロールのロールマッピングエントリーを追加する方法を示しています。ロールを設定する前にこの手順を実行する必要があります。
  • add 操作を使用して、新しいロール設定を追加します。
    /core-service=management/access=authorization/role-mapping=ROLENAME:add
    Copy to Clipboard Toggle word wrap
    ROLENAME は新しいマッピングに対するロール名です。
    [standalone@localhost:9999 access=authorization] ./role-mapping=Auditor:add             
    {"outcome" => "success"}
    [standalone@localhost:9999 access=authorization]
    Copy to Clipboard Toggle word wrap

手順6.9 ロールに include されるユーザーの追加

この手順では、ユーザーをロールの include されたリストに追加する方法を説明します。
ロールの設定が行われていない場合は、最初にロールマッピングエントリーの設定を行う必要があります。
  • add 操作を使用して、ユーザーエントリーをロールの include リストに追加します。
    /core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=USERNAME, type=USER)
    Copy to Clipboard Toggle word wrap
    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]
    Copy to Clipboard Toggle word wrap

手順6.10 ロールに exclude されるユーザーの追加

この手順では、ユーザーをロールの exclude されたリストに追加する方法を説明します。
ロールの設定が行われていない場合は、最初にロールマッピングエントリーの設定を行う必要があります。
  • add 操作を使用して、ユーザーエントリーをロールの exclude リストに追加します。
    /core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=USERNAME, type=USER)
    Copy to Clipboard Toggle word wrap
    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]
    Copy to Clipboard Toggle word wrap

手順6.11 ユーザーロールの include 設定の削除

この手順では、ロールマッピングからユーザー include エントリーを削除する方法を説明します。
  • remove 操作を使用してエントリーを削除します。
    /core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
    Copy to Clipboard Toggle word wrap
    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]
    Copy to Clipboard Toggle word wrap
    include リストからユーザーを削除しても、ユーザーはシステムから削除されず、ロールがユーザーに割り当てられなくなる保証はありません。ロールはグループメンバーシップを基に割り当てられる可能性があります。

手順6.12 ユーザーロールの exclude 設定の削除

この手順では、ロールマッピングからユーザー exclude エントリーを削除する方法を説明します。
  • remove 操作を使用してエントリーを削除します。
    /core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
    Copy to Clipboard Toggle word wrap
    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]
    Copy to Clipboard Toggle word wrap
    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 ダイアログが表示されます。

    図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 ビューが編集モードになります。

    図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
Copy to Clipboard Toggle word wrap

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

  1. read-children-names 操作を使用して、設定されたロールの完全リストを取得します。
    /core-service=management/access=authorization:read-children-names(child-type=role-mapping)
    Copy to Clipboard Toggle word wrap
    [standalone@localhost:9999 access=authorization] :read-children-names(child-type=role-mapping)
    {
        "outcome" => "success",
        "result" => [
            "Administrator",
            "Deployer",
            "Maintainer",
            "Monitor",
            "Operator",
            "SuperUser"
        ]
    }
    Copy to Clipboard Toggle word wrap
  2. 指定されたロールマッピングの read-resource 操作を使用して、特定ロールの完全詳細を取得します。
    /core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)
    Copy to Clipboard Toggle word wrap
    [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]
    Copy to Clipboard Toggle word wrap

手順6.17 新規ロールの追加

この手順は、ロールのロールマッピングエントリーを追加する方法を示しています。ロールを設定する前にこの手順を実行する必要があります。
  • add 操作を使用して、新しいロール設定を追加します。
    /core-service=management/access=authorization/role-mapping=ROLENAME:add
    Copy to Clipboard Toggle word wrap
    [standalone@localhost:9999 access=authorization] ./role-mapping=Auditor:add             
    {"outcome" => "success"}
    [standalone@localhost:9999 access=authorization]
    Copy to Clipboard Toggle word wrap

手順6.18 グループに include されるユーザーの追加

この手順では、グループをロールの include されたリストに追加する方法を説明します。
ロールの設定が行われていない場合は、最初にロールマッピングエントリーの設定を行う必要があります。
  • add 操作を使用して、グループエントリーをロールの include リストに追加します。
    /core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=GROUPNAME, type=GROUP)
    Copy to Clipboard Toggle word wrap
    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]
    Copy to Clipboard Toggle word wrap

手順6.19 ロールに exclude されるグループの追加

この手順では、グループをロールの exclude されたリストに追加する方法を説明します。
ロールの設定が行われていない場合は、最初にロールマッピングエントリーを作成する必要があります。
  • add 操作を使用して、グループエントリーをロールの exclude リストに追加します。
    /core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=GROUPNAME, type=GROUP)
    Copy to Clipboard Toggle word wrap
    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]
    Copy to Clipboard Toggle word wrap

手順6.20 グループーロールの include 設定の削除

この手順では、ロールマッピングからグループ include エントリーを削除する方法を説明します。
  • remove 操作を使用してエントリーを削除します。
    /core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
    Copy to Clipboard Toggle word wrap
    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]
    Copy to Clipboard Toggle word wrap
    include リストからグループを削除しても、グループはシステムから削除されず、このグループのユーザーにロールが割り当てられなくなる保証はありません。ロールは、グループのユーザーへ個別に割り当てられる可能性があります。

手順6.21 ユーザーグループの exclude エントリーの削除

この手順では、ロールマッピングからグループ exclude エントリーを削除する方法を説明します。
  • remove 操作を使用してエントリーを削除します。
    /core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
    Copy to Clipboard Toggle word wrap
    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]
    Copy to Clipboard Toggle word wrap
    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>
Copy to Clipboard Toggle word wrap

重要

これらの例では、実証目的で一部の属性をデフォルト値に指定します。デフォルト値を指定する属性は、サーバーによって永続化されると設定から削除されます。例外は 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>
Copy to Clipboard Toggle word wrap

これは 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>
Copy to Clipboard Toggle word wrap

設定可能な属性は次のとおりです。
  • 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>
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

例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
Copy to Clipboard Toggle word wrap
一般的なグループ検索

前述の 2 つの方法の例を確認する前に、両方の方法に共通する属性を定義する必要があります。
<group-search group-name="..." iterative="..." group-dn-attribute="..." group-name-attribute="..." >
    ...
</group-search>
Copy to Clipboard Toggle word wrap
  • 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>
Copy to Clipboard Toggle word wrap

この設定で最も重要なことは、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>
Copy to Clipboard Toggle word wrap

ここでは、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]
Copy to Clipboard Toggle word wrap

どのロールがどの操作を実行できるかは、表6.2「機密性制約の設定結果」 に説明されている属性の設定によって異なります。
Expand
表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]
Copy to Clipboard Toggle word wrap

重要

アプリケーションリソース制約は、設定に一致するすべてのリソースに適用されます。たとえば、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]
Copy to Clipboard Toggle word wrap

どのロールが vault 式へ読み書きできるかは、表6.3「vault 式制約の設定結果」 に説明されている設定によって異なります。
Expand
表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
Copy to Clipboard Toggle word wrap

手順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):
    
    Copy to Clipboard Toggle word wrap
結果

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 の初期化」を参照してください。
    Expand
    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")])
      Copy to Clipboard Toggle word wrap
    • スタンドアロンサーバー

      /core-service=vault:add(vault-options=[("KEYSTORE_URL" => "PATH_TO_KEYSTORE"), ("KEYSTORE_PASSWORD" => "MASKED_PASSWORD"), ("KEYSTORE_ALIAS" => "ALIAS"), ("SALT" => "SALT"),("ITERATION_COUNT" => "ITERATION_COUNT"), ("ENC_FILE_DIR" => "ENC_FILE_DIR")])
      Copy to Clipboard Toggle word wrap
    仮の値を用いたコマンドの例は次のとおりです。
    /core-service=vault:add(vault-options=[("KEYSTORE_URL" => "/home/user/vault/vault.keystore"), ("KEYSTORE_PASSWORD" => "MASK-3y28rCZlcKR"), ("KEYSTORE_ALIAS" => "vault"), ("SALT" => "12438567"),("ITERATION_COUNT" => "50"), ("ENC_FILE_DIR" => "/home/user/vault/")])
    Copy to Clipboard Toggle word wrap
結果

パスワード 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")])
    Copy to Clipboard Toggle word wrap
結果

パスワード 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.
    Copy to Clipboard Toggle word wrap
  9. 暗号化された文字列に関する情報を書き留めます。

    メッセージは vault ブロック、属性名、共有キー、および設定で文字列を使用する場合のアドバイスを表示する標準出力を出力します。安全な場所にこの情報を書き留めておくようにしてください。出力例は次のとおりです。
    ********************************************
    Vault Block:ds_ExampleDS
    Attribute Name:password
    Configuration should be done as follows:
    VAULT::ds_ExampleDS::password::1
    ********************************************
    Copy to Clipboard Toggle word wrap
  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>
    ...
    
    Copy to Clipboard Toggle word wrap
    式が許可されるドメインまたはスタンドアロン設定ファイルであれば、どこでも暗号化された文字列を使用することができます。

    注記

    特定のサブシステム内で式が許可されるかを確認するには、そのサブシステムに対して次の CLI コマンドを実行します。
    /host=master/core-service=management/security-realm=TestRealm:read-resource-description(recursive=true)
    Copy to Clipboard Toggle word wrap
    このコマンドの出力で、expressions-allowed パラメーターの値を探します。値が true であればこのサブシステムの設定内で式を使用できます。
    文字列をキーストアに格納した後、次の構文を使用してクリアテキストの文字列を暗号化された文字列に置き換えます。
    ${VAULT::VAULT_BLOCK::ATTRIBUTE_NAME::ENCRYPTED_VALUE}
    Copy to Clipboard Toggle word wrap
    実環境の値の例は次のとおりです。vault ブロックは ds_ExampleDS、属性は password です。
    <password>${VAULT::ds_ExampleDS::password::1}</password>
    Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap
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) + "");
    }
}
Copy to Clipboard Toggle word wrap
これでサーブレットが 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
      Copy to Clipboard Toggle word wrap
      各コマンドに対して以下のような結果が表示されるはずです。
       "outcome" => "success"
      Copy to Clipboard Toggle word wrap
    4. 管理対象ドメインに参加するマスターでないホストの場合、ホスト名を master から一意の名前に変更する必要があります。この名前はスレーブ全体で一意となる必要があり、クラスターに対する識別のために使用されます。そのため、使用する名前を覚えておくようにしてください。
      1. 以下の構文を使用して、JBoss EAP スレーブホストを起動します。
        bin/domain.sh --host-config=HOST_SLAVE_XML_FILE_NAME
        Copy to Clipboard Toggle word wrap
        例:
        bin/domain.sh --host-config=host-slave01.xml
        Copy to Clipboard Toggle word wrap
      2. 管理 CLI を起動します。
      3. 以下の構文を使用してホスト名を置き換えます。
        /host=master:write-attribute(name="name",value=UNIQUE_HOST_SLAVE_NAME)
        Copy to Clipboard Toggle word wrap
        例:
        /host=master:write-attribute(name="name",value="host-slave01")
        Copy to Clipboard Toggle word wrap
        次の結果が表示されるはずです。
         "outcome" => "success"
        Copy to Clipboard Toggle word wrap
        これは、以下のように host-slave01.xml ファイルの XML を変更します。
        <host name="host-slave01" xmlns="urn:jboss:domain:1.6">
        Copy to Clipboard Toggle word wrap
    5. 管理対象ドメインに参加する必要がある新たに設定されたホストの場合は、local 要素を削除し、ドメインコントローラーを示す host 属性の remote 要素を追加する必要があります。この手順はスタンドアロンサーバーには適用されません。
      1. 以下の構文を使用して、JBoss EAP スレーブホストを起動します。
        bin/domain.sh --host-config=HOST_SLAVE_XML_FILE_NAME
        Copy to Clipboard Toggle word wrap
        例:
        bin/domain.sh --host-config=host-slave01.xml
        Copy to Clipboard Toggle word wrap
      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") 
        Copy to Clipboard Toggle word wrap
        例:
        /host=host-slave01/:write-remote-domain-controller(host="192.168.1.200",port=${jboss.domain.master.port:9999},security-realm="ManagementRealm") 
        Copy to Clipboard Toggle word wrap
        次の結果が表示されるはずです。
         "outcome" => "success"
        Copy to Clipboard Toggle word wrap
        これは、以下のように host-slave01.xml ファイルの XML を変更します。
        <domain-controller>
            <remote host="192.168.1.200" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm"/>
        </domain-controller>
        Copy to Clipboard Toggle word wrap
  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=" />
    Copy to Clipboard Toggle word wrap
  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
        Copy to Clipboard Toggle word wrap
        各コマンドに対して以下のような結果が表示されるはずです。
         "outcome" => "success"
        Copy to Clipboard Toggle word wrap
    • ホストを設定し、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
        Copy to Clipboard Toggle word wrap
        各コマンドに対して以下のような結果が表示されるはずです。
         "outcome" => "success"
        Copy to Clipboard Toggle word wrap

        注記

        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
          Copy to Clipboard Toggle word wrap
          各コマンドに対して以下のような結果が表示されるはずです。
           "outcome" => "success"
          Copy to Clipboard Toggle word wrap
      2. システムプロパティーとしてパスワードを指定する場合、次の方法のいずれかを用いてホストを設定できます。
        • 次の例のように、プレーンテキストのパスワードをコマンドライン引数として入力し、サーバーを起動します。
          -Dserver.identity.password=changeme
          Copy to Clipboard Toggle word wrap

          注記

          パスワードはプレーンテキストで入力する必要があります。ps -ef コマンドを実行すると、このパスワードを確認できます。
        • パスワードをプロパティーファイルに格納し、プロパティーファイルの URL をコマンドライン引数として渡します。
          1. キーと値のペアをプロパティーファイルに追加します。例は次のとおりです。
            server.identity.password=changeme
            Copy to Clipboard Toggle word wrap
          2. コマンドライン引数を用いてサーバーを起動します。
            --properties=URL_TO_PROPERTIES_FILE
            Copy to Clipboard Toggle word wrap
            .
  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 コマンドの引数とスイッチがリストされています。
Expand
表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
    Copy to Clipboard Toggle word wrap
    パッチを適用するときに競合が発生した場合、patch ツールは警告を発します。コマンドを再実行して競合を解決する場合に利用可能な patch コマンドのスイッチについては、「パッチ管理システム」を参照してください。
  3. 以下のコマンドを実行して、パッチを適用するために JBoss EAP 6 サーバーを再起動します。
    [standalone@localhost:9999 /] shutdown --restart=true
    Copy to Clipboard Toggle word wrap

手順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
    Copy to Clipboard Toggle word wrap
    パッチをロールバックするときに競合が発生した場合、patch ツールは警告を発します。コマンドを再実行して競合を解決する場合に利用可能な patch コマンドのスイッチについては、「パッチ管理システム」を参照してください。
  3. パッチのロールバックを反映するために、JBoss EAP 6 サーバーを再起動します。
    [standalone@localhost:9999 /] shutdown --restart=true
    Copy to Clipboard Toggle word wrap

手順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
    Copy to Clipboard Toggle word wrap

    重要

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

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

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

JBoss のセキュリティー欠陥のリスクを伝達するため、Red Hat は low (低)、moderate (中)、important (高)、critical (重大) の 4 段階の深刻度を使用します。さらに、欠陥の影響度を特定するため、CVSS (Common Vulnerability Scoring System: 共通脆弱性評価システム) のバージョン 2 をベースにしたスコアも使用します。
Expand
表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
Copy to Clipboard Toggle word wrap
深刻度と CVSS スコアに応じて、固有の環境で発生する問題のリスクを把握し、状況に応じてアップグレードをスケジュールできます。
CVSS2 の詳細は、「CVSS2 Guide」を参照してください。
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> 要素を宣言できます。

図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>
Copy to Clipboard Toggle word wrap

注記

これは実例ではありません。デプロイメントでは、このセクションの要素に 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>
Copy to Clipboard Toggle word wrap

10.2.3. セキュリティーアイデンティティー (ID)

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

図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>
Copy to Clipboard Toggle word wrap
<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>
Copy to Clipboard Toggle word wrap
<run-as> 要素は、web.xml ファイルのサーブレット定義にもあります。以下の例は、InternalRole ロールをサーブレットに割り当てる方法を示しています。
  <servlet>
    <servlet-name>AServlet</servlet-name>
    <!-- ... -->
    <run-as> 
        <role-name>InternalRole</role-name>
    </run-as>
  </servlet>
Copy to Clipboard Toggle word wrap
このサーブレットからの呼び出しは、匿名の principal に関連付けられます。run-as ロールに従う特定のプリンシパルを割り当てるため、<run-as-principal> 要素は jboss-web.xml ファイルにあります。以下は、internal という名前のプリンシパルを上記のサーブレットに関連付ける方法を示しています。
  <servlet>
    <servlet-name>AServlet</servlet-name>
    <run-as-principal>internal</run-as-principal>
  </servlet>
Copy to Clipboard Toggle word wrap

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>
Copy to Clipboard Toggle word wrap

例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>
Copy to Clipboard Toggle word wrap

10.2.5. EJB メソッドのパーミッション

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

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

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

図10.4 Java EE メソッド要素

メソッド要素宣言のサポートされるスタイルは 3 つあります。
1 つ目のスタイルは、名前付きエンタープライズ Bean のホームおよびコンポーネントインターフェースメソッドをすべて参照するために使用されます。
<method>
  <ejb-name>EJBNAME</ejb-name>
  <method-name>*</method-name>
</method>
Copy to Clipboard Toggle word wrap
2 つ目のスタイルは、名前付きエンタープライズ Bean のホームまたはコンポーネントインターフェースの指定されたメソッドを参照するために使用されます。
  <method>
    <ejb-name>EJBNAME</ejb-name>
    <method-name>METHOD</method-name>
  </method>
Copy to Clipboard Toggle word wrap
同じオーバーロードされた名前を持つ複数のメソッドがある場合、このスタイルはすべてのオーバーロードされたメソッドを参照します。
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>
Copy to Clipboard Toggle word wrap
メソッドは指定されたエンタープライズ 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>
Copy to Clipboard Toggle word wrap

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 要素を使用して宣言されます。

図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> 要素は、使用される認証メソッド、アプリケーションに使用されるレルム名、およびフォームログインのメカニズムに必要な属性を設定するために使用されます。

図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>
Copy to Clipboard Toggle word wrap

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>
Copy to Clipboard Toggle word wrap
フォームベース認証の 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>
Copy to Clipboard Toggle word wrap
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>
Copy to Clipboard Toggle word wrap

例11.2 パスワード vault の例

<security>
  <user-name>admin</user-name>
  <password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password>
</security>
Copy to Clipboard Toggle word wrap

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>
Copy to Clipboard Toggle word wrap

例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>
Copy to Clipboard Toggle word wrap
デフォルトでは、<run-as> を使用すると anonymous という名前のプリンシパルが発信呼び出しへ割り当てられます。違うプリンシパルを割り当てる場合は <run-as-principle> を使用します。
<session>
    <ejb-name>RunAsBean</ejb-name>
    <security-identity>
        <run-as-principal>internal</run-as-principal>
    </security-identity>
</session>
Copy to Clipboard Toggle word wrap

注記

サーブレット要素内に <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>

Copy to Clipboard Toggle word wrap

例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>
Copy to Clipboard Toggle word wrap

例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>
Copy to Clipboard Toggle word wrap

例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>
Copy to Clipboard Toggle word wrap

例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>
Copy to Clipboard Toggle word wrap

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;
	}
}
Copy to Clipboard Toggle word wrap
このコードでは、すべてのロールが 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>        

Copy to Clipboard Toggle word wrap
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>             

Copy to Clipboard Toggle word wrap
socket-binding
remoting サブシステムによって使用されるデフォルトの socket-binding は TCP ポート 4777 へバインドします。この設定を変更する必要がある場合はソケットバインディングとソケットバインディンググループに関するドキュメントを参照してください。
EJB の リモーティングコネクター参照
EJB サブシステムにはリモートメソッド呼び出しに対するリモーティングコネクターへの参照が含まれています。デフォルト設定は次のとおりです。
<remote connector-ref="remoting-connector" thread-pool-name="default"/>            

Copy to Clipboard Toggle word wrap
セキュアなトランスポート設定
Remoting はクライアントの要求があれば StartTLS を使用して安全な接続 (HTTPS、Secure Servlet など) を使用します。安全な接続と安全でない接続の両方で同じソケットバインディング (ネットワークポート) が使用されるため、サーバー側に追加の設定をする必要はありません。クライアントは必要に応じて安全なトランスポートまたは安全でないトランスポートを要求します。EJB、ORB、JMS プロバイダーなどの Remoting を使用する JBoss EAP のコンポーネントはデフォルトで安全なインターフェースを使用します。

警告

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

ワーカースレッドプールは、Remoting コネクターからの作業を処理できるスレッドのグループのことです。単一の要素 <worker-thread-pool> で、複数の属性を取ります。ネットワークタイムアウトやスレッド不足が発生したり、メモリーの使用を制限する場合にこれらの属性を調節します。特定の推奨設定は状況によって異なります。詳細は Red Hat グローバルサポートサービスまでご連絡ください。

Expand
表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 グローバルサポートサービスまでご連絡ください。

Expand
表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)
Expand
表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 属性を取り、認証に使用します。
Expand
表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
Copy to Clipboard Toggle word wrap
SASL 要素の子要素は次の表のとおりです。
Expand
属性説明CLI コマンド
include-mechanisms
SASL メカニズムのスペース区切りのリストである value 属性が含まれています。
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=include-mechanisms,value=["DIGEST","PLAIN","GSSAPI"])
Copy to Clipboard Toggle word wrap
qop
SASL の保護品質 (QoP) 値が希望順に並ぶスペース区切りのリストである value 属性が含まれます。
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=qop,value=["auth"])
Copy to Clipboard Toggle word wrap
strength
SASL の暗号強度の値が希望順に並ぶスペース区切りのリストである value 属性が含まれます。
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=strength,value=["medium"])
Copy to Clipboard Toggle word wrap
reuse-session
ブール値である value 属性が含まれます。true の場合、セッションの再使用を試みます。
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=reuse-session,value=false)
Copy to Clipboard Toggle word wrap
server-auth
ブール値である value 属性が含まれます。true の場合、サーバーはクライアントに対して認証します。
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=server-auth,value=false)
Copy to Clipboard Toggle word wrap
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
Copy to Clipboard Toggle word wrap
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=forward-secrecy,value=true)
Copy to Clipboard Toggle word wrap
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-active,value=false)
Copy to Clipboard Toggle word wrap
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-anonymous,value=false)
Copy to Clipboard Toggle word wrap
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-dictionary,value=true)
Copy to Clipboard Toggle word wrap
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-plain-text,value=false)
Copy to Clipboard Toggle word wrap
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=pass-credentials,value=true)
Copy to Clipboard Toggle word wrap
properties
1 つ以上の <property> 要素が含まれ、各要素には name 属性と任意の value 属性が含まれます。
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/property=myprop:add(value=1)
Copy to Clipboard Toggle word wrap
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/property=myprop2:add(value=2)
Copy to Clipboard Toggle word wrap

例11.11 設定例

この例は JBoss EAP 6 に同梱されるデフォルトのリモーティングサブシステムを表しています。
<subsystem xmlns="urn:jboss:domain:remoting:1.1">
    <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/>
</subsystem>    

Copy to Clipboard Toggle word wrap
この例には多くの仮説的な値が含まれており、前述の要素や属性がコンテキストに含まれています。
<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>    

Copy to Clipboard Toggle word wrap

文書化されていない設定内容

  • 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
    Copy to Clipboard Toggle word wrap
  • 新しいセキュリティーレルムを使用するドメインまたはスタンドアロンサーバー上にカスタム 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()
    Copy to Clipboard Toggle word wrap
    スタンドアロンインスタンスでは以下のコマンドを使用します。
    /core-service=management/security-realm=MyDomainRealm:add()
    Copy to Clipboard Toggle word wrap
  3. 新しいロールの情報を保存するプロパティーファイルへの参照を作成します。

    次のコマンドを実行し、新しいロールに関連するプロパティーが含まれる myfile.properties という名前のファイルのポインターを作成します。

    注記

    新たに作成されたプロパティーファイルは、含まれる add-user.sh および add-user.bat スクリプトによって管理されません。そのため、外部で管理する必要があります。
    ドメインインスタンスでは以下コマンドを使用します。
    /host=master/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
    Copy to Clipboard Toggle word wrap
    スタンドアロンインスタンスでは以下のコマンドを使用します。
    /core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
    Copy to Clipboard Toggle word wrap
結果

新しいセキュリティーレルムが作成されます。新たに作成されたこのレルムにユーザーやロールを追加すると、デフォルトのセキュリティーレルムとは別のファイルに情報が保存されます。新規ファイルはご使用のアプリケーションやプロシージャーを使用して管理できます。

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>
    Copy to Clipboard Toggle word wrap
  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>
    Copy to Clipboard Toggle word wrap
  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>
    Copy to Clipboard Toggle word wrap
結果

ロールベースセキュリティーが定義されたロールのセットによりアプリケーション内で有効になります。

例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>
Copy to Clipboard Toggle word wrap

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>		

Copy to Clipboard Toggle word wrap
<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)
Copy to Clipboard Toggle word wrap

例12.3 スタンドアロンサーバー

/subsystem=security/:write-attribute(name=deep-copy-subject-mode,value=TRUE)
Copy to Clipboard Toggle word wrap

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>
    Copy to Clipboard Toggle word wrap
  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>
    Copy to Clipboard Toggle word wrap
  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>
    Copy to Clipboard Toggle word wrap
    また、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
    Copy to Clipboard Toggle word wrap

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>
    Copy to Clipboard Toggle word wrap

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 に記載されています。詳細については、そのドキュメントを参照してください。

    Expand
    フラグ説明
    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
Copy to Clipboard Toggle word wrap
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) {...}
Copy to Clipboard Toggle word wrap
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");
            }
        }
    }
}
Copy to Clipboard Toggle word wrap
開発者は、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;
Copy to Clipboard Toggle word wrap
最後に説明する認証クラスは 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>
Copy to Clipboard Toggle word wrap
ログインモジュール自体は標準的な認証モジュールと全く同じように設定されます。
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 に記載されています。詳細については、そのドキュメントを参照してください。

    Expand
    フラグ説明
    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>
Copy to Clipboard Toggle word wrap
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>
Copy to Clipboard Toggle word wrap
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>
Copy to Clipboard Toggle word wrap
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>
Copy to Clipboard Toggle word wrap

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>
    Copy to Clipboard Toggle word wrap

    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>
    Copy to Clipboard Toggle word wrap

    例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>
    Copy to Clipboard Toggle word wrap

    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>
    
    Copy to Clipboard Toggle word wrap

  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>
    Copy to Clipboard Toggle word wrap

    ポリシーセットを定義する設定ファイル

    <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>
    Copy to Clipboard Toggle word wrap

  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>
    Copy to Clipboard Toggle word wrap

    許可の拒否

        <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>
    Copy to Clipboard Toggle word wrap

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 リクエストのどのコンポーネントを監査ログに記録するかをさらに厳格に制御できます (パラメーター、クッキー、ヘッダー、または属性)。新しいプロパティーを使用して、これらのコンポーネントをマスクすることもできます。
新しいプロパティーは次のとおりです。
Expand
表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>
      Copy to Clipboard Toggle word wrap
      管理コンソールまたは CLI を使用して、追加のセキュリティードメインを必要に応じて設定できます。
    2. アプリケーションの記述子ファイルでのセキュリティードメインの有効化

      セキュリティードメインはアプリケーションの WEB-INF/web.xml ファイルにある <jboss-web> 要素の <security-domain> 子要素に指定されます。次の例は my-domain という名前のセキュリティードメインを設定します。
      <jboss-web>
          <security-domain>my-domain</security-domain>
      </jboss-web>
      Copy to Clipboard Toggle word wrap
      これが 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();
       }
    }
    Copy to Clipboard Toggle word wrap
    その他のコード例は、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)
    Copy to Clipboard Toggle word wrap
    サブシステムが存在する場合、結果は 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")
    Copy to Clipboard Toggle word wrap
    /profile=ha/subsystem=infinispan/cache-container=web/transport=TRANSPORT:add(lock-timeout=60000)
    Copy to Clipboard Toggle word wrap
    /profile=ha/subsystem=infinispan/cache-container=web/replicated-cache=repl:add(mode="ASYNC",batching=true)
    Copy to Clipboard Toggle word wrap

    例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)
    Copy to Clipboard Toggle word wrap
    "sso" => { のような出力を探します。
    このような出力が見つからない場合、設定に SSO replicated-cache は存在しません。

    例14.4 SSO replicated-cache の追加

    /profile=ha/subsystem=infinispan/cache-container=web/replicated-cache=sso:add(mode="SYNC", batching=true)
    Copy to Clipboard Toggle word wrap
  • 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")
    Copy to Clipboard Toggle word wrap
  • 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")
Copy to Clipboard Toggle word wrap

例14.6 クラスター化されていない SSO 設定の例

/subsystem=web/virtual-server=default-host/sso=configuration:add(reauthenticate="false")
Copy to Clipboard Toggle word wrap
セッションの無効化

アプリケーションはメソッド 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)。
はじめに

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 に使用されるクラスとのマッピングを表しています。
Expand
表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>
    Copy to Clipboard Toggle word wrap
  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>
    Copy to Clipboard Toggle word wrap
  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>
    Copy to Clipboard Toggle word wrap
  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>
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
    • この代わりに、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>
      Copy to Clipboard Toggle word wrap
結果

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>
    Copy to Clipboard Toggle word wrap
  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>
    Copy to Clipboard Toggle word wrap

注記

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>
Copy to Clipboard Toggle word wrap
セキュリティートークン応答の例は次のとおりです。

例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>
Copy to Clipboard Toggle word wrap
セキュリティートークン応答の例では、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>
Copy to Clipboard Toggle word wrap

15.4. STSIssuingLoginModule の設定

STSIssuingLoginModule は、ユーザー名とパスワードを使用し、トークンを読み出してユーザーを STS に対して認証します。

例15.4 STSIssuingLoginModule の設定

<security-domain name="saml-issue-token">
    <authentication>
        <login-module
            code="org.picketlink.identity.federation.core.wstrust.auth.STSIssuingLoginModule" flag="required">          <module-option name="configFile">./picketlink-sts-client.properties</module-option>
          <module-option name="endpointURI">http://security_saml/endpoint</module-option>
        </login-module>
    </authentication>
    <mapping>
        <mapping-module
            code="org.picketlink.identity.federation.bindings.jboss.auth.mapping.STSPrincipalMappingProvider"
            type="principal" />
        <mapping-module
            code="org.picketlink.identity.federation.bindings.jboss.auth.mapping.STSGroupMappingProvider"
            type="role" />
    </mapping>
</security-domain>
Copy to Clipboard Toggle word wrap
以下を実行すると、ほとんどの設定を上記の設定に変更できます。
  • 宣言されたセキュリティードメインの変更。
  • Principal マッピングプロバイダーの指定。
  • RoleGroup マッピングプロバイダーの指定。
Princial マッピングプロバイダーおよび RoleGroup マッピングプロバイダーが指定されると、認証されたサブジェクトが入力され、粒度の荒いロールベースの承認を実行できます。認証後、セキュリティートークンが使用可能になり、シングルサインオンで他のサービスを呼び出すために使用されることがあります。

15.5. STSValidatingLoginModule の設定

STSValidatingLoginModule は TokenCallback を使用し、トークンを呼び出して STS に設定された CallbackHandler を要求します。

例15.5 STSValidatingLoginModule の設定

<security-domain name="saml-validate-token">
    <authentication>
        <login-module
            code="org.picketlink.identity.federation.core.wstrust.auth.STSValidatingLoginModule" flag="required">
            <module-option name="configFile">./picketlink-sts-client.properties</module-option>
            <module-option name="endpointURI">http://security_saml/endpoint</module-option>
        </login-module>
    </authentication>
    <mapping>
        <mapping-module
            code="org.picketlink.identity.federation.bindings.jboss.auth.mapping.STSPrincipalMappingProvider"
            type="principal" />
        <mapping-module
            code="org.picketlink.identity.federation.bindings.jboss.auth.mapping.STSGroupMappingProvider"
            type="role" />
    </mapping>
</security-domain>
Copy to Clipboard Toggle word wrap
上例の設定は、アプリケーションとサービスに対してシングルサインオンを有効にします。直接 STS に要求して発行されたトークンまたはトークンを発行するログインモジュールを介して発行されたトークンを使用し、例の設定を使用すると、複数のアプリケーションやサービスに対して認証を行えます。Principal マッピングプロバイダーおよび RoleGroup マッピングプロバイダーを提供すると、認証されたサブジェクトが入力され、粒度の荒いロールベースの承認が有効になります。認証後、セキュリティートークンが使用可能になり、シングルサインオンで他のサービスを呼び出すために使用されることがあります。

15.6. STS クライアントのプーリング

PicketLink はサーバー側で STS クライアントのプールを提供します。これにより、ボトルネックであった STS クライアントの作成が解消されます。
クライアントプーリングは、SAML チケットの取得に STS クライアントが必要となるログインモジュールから利用できます。
STS クライアントプーリングを使用できるログインモジュールは以下のとおりです。
  • org.picketlink.identity.federation.core.wstrust.auth.STSIssuingLoginModule
  • org.picketlink.identity.federation.core.wstrust.auth.STSValidatingLoginModule
  • org.picketlink.trust.jbossws.jaas.JBWSTokenIssuingLoginModule
プールのデフォルトのクライアント数を各ログインモジュールに設定するには、initialNumberOfClients ログインモジュールオプションから設定します。
STSClientPoolFactory クラス org.picketlink.identity.federation.bindings.stspool.STSClientPoolFactory は、クライアントプール機能をアプリケーションに提供します。

STSClientPoolFactory の使用

STS クライアントは、設定をキーとして使用してサブプールに挿入されます。STSClientPool インスタンスを取得した後、設定を基にサブプールを初期化します (STS クライアントの最初の数またはデフォルトの数)。
final STSClientPool pool = STSClientPoolFactory.getPoolInstance();
pool.createPool(20, stsClientConfig);
final STSClient client = pool.getClient(stsClientConfig);
Copy to Clipboard Toggle word wrap
クライアントで作業を終えたら、以下のようにプールに返すことができます。
pool.returnClient();
Copy to Clipboard Toggle word wrap
指定の設定にサブプールがすでに存在するかどうかをチェックするには、以下を実行します。
if (! pool.configExists(stsClientConfig) {  
    pool.createPool(stsClientConfig);  
}
Copy to Clipboard Toggle word wrap
PicketLink Federation サブシステムが有効になると、デプロイメント向けに作成されたすべてのクライアントプールはアンデプロイ処理中に自動的に破棄されます。プールを手動で破棄するには、以下を実行します。
pool.destroyPool(stsClientConfig);
Copy to Clipboard Toggle word wrap

15.7. SAML Web ブラウザーベースの SSO

15.7.1. SAML Web ブラウザーベースの SSO

JBoss EAP の PicketLink は、フェデレーテッドアイデンティティーベースのサービスを実装するためのプラットフォームを提供します。これには、アプリケーションの集中アイデンティティーサービスおよびシングルサインオン (SSO) が含まれます。
SAML プロファイルは、集中アイデンティティーサービスを持つ HTTP POST および HTTP リダイレクトバインディングの両方をサポートし、アプリケーションの Web SSO を有効にします。SAML v2 ベースの Web SSO は、アイデンティティー管理のハブアンドスポーク型アーキテクチャーに従います。このアーキテクチャーでは、アイデンティティープロバイダー (IDP) はすべてのアプリケーション (サービスプロバイダー) へのアイデンティティーおよびロール情報の中心ソース (ハブ) として動作します。スポークはサービスプロバイダー (SP) です。

重要

2 つ以上の SP が同じ IDP を示している場合、IDP は異なる SP を区別しません。同じ IDP を示す異なる SP へリクエストを行うと、IDP は SP からの最も新しいリクエストを処理し、認証されたユーザーに関する SAML アサーションを返信します。以前の SP リクエストに戻るには、ブラウザーで SP の URL を再入力する必要があります。

15.7.2. SAML v2 ベースの Web SSO の設定

SAML v2 ベースの Web SSO を設定するには、以下を設定する必要があります。
  • アイデンティティープロバイダー: アイデンティティープロバイダーは、エンドユーザーを認証し、そのユーザーのアイデンティティーを信頼されたパートナーにアサートする権限のあるエンティティーです。
  • サービスプロバイダー: サービスプロバイダーはアイデンティティープロバイダーに依存し、ユーザーの電子クレデンシャルよりユーザーに関する情報をアサートするため、サービスプロバイダーはユーザークレデンシャルの信頼されたアサーションのセットを基にアクセス制御および伝播を管理します。

15.7.3. アイデンティティープロバイダーの設定

アイデンティティープロバイダーは JBoss EAP サーバーインスタンスです。

手順15.1 アイデンティティープロバイダー (IDP) の設定

  1. IDP の Web アプリケーションセキュリティーの設定

    Web アプリケーションをアイデンティティープロバイダーとして設定します。

    注記

    ログインページをカスタマイズできるため、FORM ベースの Web アプリケーションセキュリティーを使用することが推奨されます。
    web.xml の設定例は次のとおりです。

    例15.6 IDP の web.xml 設定

    <display-name>IDP</display-name>
    <description>IDP</description>
    <!-- Define a security constraint that gives unlimited access to images -->
    <security-constraint>
      <web-resource-collection>
      <web-resource-name>Images</web-resource-name>
      <url-pattern>/images/*</url-pattern>
    </web-resource-collection>
    </security-constraint>
    <!-- Define a Security Constraint on this Application -->
    <security-constraint>
      <web-resource-collection>
      <web-resource-name>IDP</web-resource-name>
      <url-pattern>/*</url-pattern>
    </web-resource-collection>
      <auth-constraint>
      <role-name>manager</role-name>
    </auth-constraint>
    </security-constraint>
    <!-- Define the Login Configuration for this Application -->
    <login-config>
      <auth-method>FORM</auth-method>
      <realm-name>IDP Application</realm-name>
      <form-login-config>
        <form-login-page>/jsp/login.jsp</form-login-page>
        <form-error-page>/jsp/loginerror.jsp</form-error-page>
      </form-login-config>
    </login-config>
    <!-- Security roles referenced by this web application -->
    <security-role>
     <description>
      The role that is required to log in to the IDP Application
     </description>
     <role-name>manager</role-name>
    </security-role>
    </web-app>
    Copy to Clipboard Toggle word wrap
  2. IDP のセキュリティードメインの作成

    IDP に対して定義された認証および承認メカニズムを用いてセキュリティードメインを作成します。詳細は「アプリケーションでのセキュリティードメインの使用」を参照してください。
  3. IDP バルブの設定

    IDP Web アプリケーションの WEB-INF ディレクトリーで jboss-web.xml ファイルを作成し、IDP のバルブを設定します。以下に jboss-web.xml ファイルの例を示します。

    例15.7 IDP バルブの jboss-web.xml ファイル設定

    <jboss-web>
      <security-domain>idp</security-domain>
      <context-root>idp</context-root>
      <valve>
        <class-name>org.picketlink.identity.federation.bindings.tomcat.idp.IDPWebBrowserSSOValve</class-name>
      </valve>
    </jboss-web>
    Copy to Clipboard Toggle word wrap
  4. PicketLink 設定ファイル (picketlink.xml) の設定

    以下は picketlink.xml 設定の例になります。この設定ファイルで、サービスプロバイダーおよび IDP へ送信される SAML2 アサーションに発行者として追加される URL を指定します。

    例15.8 picketlink.xml 設定

    <PicketLink xmlns="urn:picketlink:identity-federation:config:2.1">
      <PicketLinkIDP xmlns="urn:picketlink:identity-federation:config:2.1">
        <IdentityURL>http://localhost:8080/idp/</IdentityURL>
      </PicketLinkIDP>
      <Handlers xmlns="urn:picketlink:identity-federation:handler:config:2.1">
        <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2IssuerTrustHandler" />
        <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2LogOutHandler" />
        <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler" />
        <Handler class="org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler" />
      </Handlers>
    </PicketLink>
    Copy to Clipboard Toggle word wrap
    デフォルトでは、picketlink.xml は IDP Web アプリケーションの WEB-INF ディレクトリーにありますが、アプリケーションの外部にある picketlink.xml へのカスタムパスを設定できます。
    1. 任意設定: picketlink.xml へのカスタムパスの設定

      アプリケーションの WEB-INF/jboss-web.xml でバルブ要素に、configFiletimerInterval の 2 つのパラメーターを追加します。configFilepicketlink.xml へのパスを指定し、timerInterval は設定を再ロードする間隔をミリ秒単位で指定します。例を以下に示します。
      <valve>
        <class-name>...</class-name>
          <param>
            <param-name>timerInterval</param-name>
            <param-value>5000</param-value>
          </param>
          <param>
            <param-name>configFile</param-name>
            <param-value>path-to/picketlink.xml</param-value>
          </param>
      </valve>
      Copy to Clipboard Toggle word wrap
  5. PicketLink モジュール (META-INF/MANIFEST.MF または jboss-deployment-structure.xml) での依存関係の宣言

    PicketLink クラスの場所を特定できるようにするため、Web アプリケーションには META-INF/MANIFEST.MF または jboss-deployment-structure.xml に定義される依存関係が必要です。

    例15.9 META-INF/MANIFEST.MF での依存関係の定義

    Manifest-Version: 1.0
        Build-Jdk: 1.6.0_24
        Dependencies: org.picketlink
    Copy to Clipboard Toggle word wrap

    例15.10 META-INF/jboss-deployment-structure.xml での依存関係の定義

    <jboss-deployment-structure>  
      <deployment>    
        <dependencies>
          <module name="org.picketlink" />
        </dependencies>
      </deployment>
    </jboss-deployment-structure>
    Copy to Clipboard Toggle word wrap

15.7.4. HTTP/REDIRECT バインディングを使用したサービスプロバイダーの設定

サービスプロバイダー (SP) は JBoss EAP サーバーインスタンスである可能性があります。

手順15.2 サービスプロバイダー (SP) の設定

  1. SP の Web アプリケーションセキュリティーの設定

    SP として設定する Web アプリケーションの web.xml ファイルで、FORM ベースのセキュリティーを有効にする必要があります。

    例15.11 SP の web.xml 設定

    <display-name>SP</display-name>
    <description>SP</description>
    <!-- Define a security constraint that gives unlimited access to images -->
    <security-constraint>
      <web-resource-collection>
        <web-resource-name>Images</web-resource-name>
        <url-pattern>/images/*</url-pattern>
      </web-resource-collection>
    </security-constraint>
    <!-- Define a Security Constraint on this Application -->
    <security-constraint>
      <web-resource-collection>
        <web-resource-name>SP</web-resource-name>
        <url-pattern>/*</url-pattern>
      </web-resource-collection>
      <auth-constraint>
        <role-name>manager</role-name>
      </auth-constraint>
    </security-constraint>
    <!-- Define the Login Configuration for this Application -->
    <login-config>
      <auth-method>FORM</auth-method>
      <realm-name>SP Application</realm-name>
      <form-login-config>
        <form-login-page>/jsp/login.jsp</form-login-page>
        <form-error-page>/jsp/loginerror.jsp</form-error-page>
      </form-login-config>
    </login-config>
    <!-- Security roles referenced by this web application -->
    <security-role>
        <description>
       The role that is required to log in to the SP Application
      </description>
      <role-name>manager</role-name>
    </security-role>
    </web-app>
    Copy to Clipboard Toggle word wrap
  2. SP のセキュリティードメインの作成

    SAML2LoginModule を使用するセキュリティードメインを作成します。以下に設定例を示します。
    <security-domain name="sp" cache-type="default">
      <authentication>
        <login-module code="org.picketlink.identity.federation.bindings.jboss.auth.SAML2LoginModule" flag="required"/>
       </authentication>
    </security-domain>
    Copy to Clipboard Toggle word wrap
  3. SP バルブの設定

    SP のバルブを設定するには、SP Web アプリケーションの WEB-INF ディレクトリーに jboss-web.xml を作成します。

    例15.12 SP バルブの jboss-web.xml ファイル設定

    <jboss-web>
      <security-domain>sp</security-domain>
      <context-root>sales-post</context-root>
      <valve>
        <class-name>org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator</class-name>
      </valve>
    </jboss-web>
    Copy to Clipboard Toggle word wrap
  4. PicketLink 設定ファイル (picketlink.xml) の設定

    以下は SP の picketlink.xml 設定の例になります。この設定ファイルで、対応する SP のハンドラーを用いて SP および IDP の URL を指定します。

    例15.13 picketlink.xml 設定

    <PicketLink xmlns="urn:picketlink:identity-federation:config:2.1">
      <PicketLinkSP xmlns="urn:picketlink:identity-federation:config:2.1" ServerEnvironment="tomcat" BindingType="REDIRECT">
        <IdentityURL>${idp.url::http://localhost:8080/idp/}</IdentityURL>
        <ServiceURL>${sales-post.url::http://localhost:8080/sales-post/}</ServiceURL>
      </PicketLinkSP>
      <Handlers xmlns="urn:picketlink:identity-federation:handler:config:2.1">
        <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2LogOutHandler" />
        <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler" />
        <Handler class="org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler" />
      </Handlers>
    </PicketLink>
    Copy to Clipboard Toggle word wrap
    デフォルトでは、picketlink.xml はアプリケーションの WEB-INF ディレクトリーにありますが、アプリケーションの外部にある picketlink.xml へのカスタムパスを設定できます。
    1. 任意設定: picketlink.xml へのカスタムパスの設定

      アプリケーションの WEB-INF/jboss-web.xml でバルブ要素に、configFiletimerInterval の 2 つのパラメーターを追加します。configFilepicketlink.xml へのパスを指定し、timerInterval は設定を再ロードする間隔をミリ秒単位で指定します。例を以下に示します。
      <valve>
        <class-name>...</class-name>
          <param>
            <param-name>timerInterval</param-name>
            <param-value>5000</param-value>
          </param>
          <param>
            <param-name>configFile</param-name>
            <param-value>path-to/picketlink.xml</param-value>
          </param>
      </valve>
      Copy to Clipboard Toggle word wrap
  5. PicketLink モジュール (META-INF/MANIFEST.MF または jboss-deployment-structure.xml) での依存関係の宣言

    PicketLink クラスの場所を特定できるようにするため、Web アプリケーションには META-INF/MANIFEST.MF または jboss-deployment-structure.xml に定義される依存関係が必要です。

    例15.14 META-INF/MANIFEST.MF での依存関係の定義

    Manifest-Version: 1.0
        Build-Jdk: 1.6.0_24
        Dependencies: org.picketlink
    Copy to Clipboard Toggle word wrap

    例15.15 META-INF/jboss-deployment-structure.xml での依存関係の定義

    <jboss-deployment-structure>  
      <deployment>    
        <dependencies>
          <module name="org.picketlink" />
        </dependencies>
      </deployment>
    </jboss-deployment-structure>
    Copy to Clipboard Toggle word wrap

15.7.5. HTTP/POST バインディングを使用した SAML v2 ベースの Web SSO の設定

HTTP/POST バインディングは、Web ブラウザーベースの SSO の取得に推奨されるバインディングです。

手順15.3 HTTP/POST バインディングを使用した SAML v2 ベースの Web SSO の設定

  1. アイデンティティープロバイダー (IDP) を設定します。

    HTTP/POST バインディング向けに IDP を設定する手順は、HTTP/リダイレクトバインディング向けに IDP を設定する手順と同じです。IDP 設定の詳細は、「SAML v2 ベースの Web SSO の設定」を参照してください。
  2. サービスプロバイダー (SP) の設定

    HTTP/POST バインディング向けに SP を設定する手順は、HTTP/リダイレクトバインディング向けに SP を設定する手順と同じですが、SP の picketlink.xml ファイルに違いが 1 つあります。BindingType="REDIRECT"BindingType="POST" に変更します。

15.7.6. サービスプロバイダーにおける動的 Account Chooser (アカウントチューザー) の設定

サービスプロバイダー (SP) が複数のアイデンティティープロバイダー (IDP) と設定されている場合、どの IDP を使用してクレデンシャルを認証するかをユーザーが選択できるように PicketLink を設定することができます。

手順15.4 サービスプロバイダーにおける動的 Account Chooser (アカウントチューザー) の設定

  1. SP Web アプリケーションの WEB-INF ディレクトリーにある jboss-web.xml で Account Chooser (アカウントチューザー) バルブを設定します。

    例15.16 SP アカウントチューザーの jboss-web.xml ファイル設定

    <jboss-web>
      <security-domain>sp</security-domain>
      <context-root>accountchooser</context-root>
      <valve>
        <class-name>org.picketlink.identity.federation.bindings.tomcat.sp.AccountChooserValve</class-name>
      </valve>
      <valve>
        <class-name>org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator</class-name>
      </valve>
    </jboss-web>
    Copy to Clipboard Toggle word wrap
    AccountChooserValve には以下の設定可能なオプションがあります。
    DomainName
    ユーザーのブラウザーへ送信されるクッキーに使用されるドメイン名。
    CookieExpiry
    クッキーの有効期限 (秒単位)。デフォルトは -1 で、ブラウザーが閉じられたときにクッキーの有効期限が切れることを意味します。
    AccountIDPMapProvider
    IDP マッピングの実装の完全修飾名。デフォルトは、SP Web アプリケーションの WEB-INF ディレクトリーにある idpmap.properties プロパティーファイルです。この実装は、org.picketlink.identity.federation.bindings.tomcat.sp.AbstractAccountChooserValve.AccountIDPMapProvider を実装する必要があります。
    AccountChooserPage
    異なる IDP アカウントをリストする HTML/JSP ページの名前。デフォルトは /accountChooser.html です。
  2. IDP のマッピングを定義します。デフォルトは、SP Web アプリケーションの WEB-INF ディレクトリーにある idpmap.properties プロパティーファイルです。

    例15.17 idpmap.properties 設定

    DomainA=http://localhost:8080/idp1/
    DomainB=http://localhost:8080/idp2/
    Copy to Clipboard Toggle word wrap
  3. ユーザーが IDP を選択するための HTML ページを SP Web アプリケーションで作成します。デフォルトでは、このファイルは accountChooser.html になります。各 IDP への URL には、idpmap.properties にリストされた IDP の名前を指定する idp パラメーターが必要です。

    例15.18 accountChooser.html 設定

    <html>
      ...
      <a href="?idp=DomainA">DomainA</a>
      <hr/>
      <a href="?idp=DomainB">DomainB</a>
      ...
    </html>
    Copy to Clipboard Toggle word wrap

15.7.7. IDP-initiated SSO の設定

通常、PicketLink では SP が最初に認証リクエストを IDP へ送信し、その後 IDP が有効なアサーションとともに SAML 応答を SP へ送信します。このフローは SP-initiated SSO (SP が起点となる SSO) と呼ばれます。また、SAML 2.0 の仕様は IDP-initiated SSO (IDP が起点となる SSO) または Unsoliciated Response SSO (非要請応答 SSO) と呼ばれる別のフローも定義します。この場合、SP が認証フローを開始せず、IDP から SAML 応答を受信します。この認証フローは IDP 側で開始され、ユーザーは認証後にリストから特定の SP を選択し、その URL へリダイレクトされます。

順序

  1. ユーザーが IDP にアクセスします。
  2. IDP は SAML リクエストや応答がないことを確認し、IDP が初めて SAML を使用することを想定します。
  3. IDP がユーザーに認証を要求します。
  4. 認証後、すべての SP アプリケーションへリンクするページをユーザーが取得する、ホストされたセクションを IDP が表示します。
  5. ユーザーが SP アプリケーションを選択します。
  6. クエリーパラメーターの SAML 応答に SAML アサーションを持つサービスプロバイダーへ IDP がユーザーをリダイレクトします。
  7. SP は SAML アサーションをチェックし、アクセスを提供します。
設定

非要請応答をサポートするには特別な設定は必要ありません。IDP と SP を通常どおり設定できます。IDP と SP の設定方法に関する詳細は以下を参照してください。

使用方法

ユーザーの認証後、IDP はすべてのサービスプロバイダーアプリケーションへのリンクが含まれるページを表示します。通常、リンクは以下のようになります。

<a href="http://localhost:8080/idp?SAML_VERSION=2.0&TARGET=http://localhost:8080/sales-post/">Sales</a>
Copy to Clipboard Toggle word wrap
上記のリンクは、ターゲット SP アプリケーションへの URL が値である TARGET クエリーパラメーターを渡す IDP へユーザーをリダイレクトします。ユーザーが上記のリンクをクリックすると、IDP はリクエストから TARGET パラメーターを抽出して SAML v2.0 応答をビルドし、ユーザーをターゲット URL へリダイレクトします。ユーザーが SP にヒットすると、自動的に認証されます。
SAML_VERSION クエリーパラメーターを使用すると、 IDP が SAML 応答の作成に使用しなければならない SAML バージョンを指定できます。 SAML_VERSION パラメーターの可能な値は 2.0 と 1.1 です。

15.8. SAML グローバルログアウトプロファイルの設定

1 つのサービスプロバイダーで開始されるグローバルログアウトは、アイデンティティープロバイダー (IDP) およびすべてのサービスプロバイダーからユーザーをログアウトします。

注記

グローバルログアウトが正しく機能するようにするには、各アイデンティティープロバイダーのサービスプロバイダーの数を 5 つ以下にする必要があります。

手順15.5 グローバルログアウトの設定

  1. picketlink-handlers.xml の設定

    picketlink-handlers.xml に SAML2LogOutHandler を追加します。
  2. サービスプロバイダー Web ページの設定

    サービスプロバイダーの Web ページの最後にあるリンクに GLO=true を追加します。

    例15.19 グローバルログアウトへのリンク

    <a href="?GLO=true">Click to Globally LogOut</a>
    Copy to Clipboard Toggle word wrap
  3. logout.jsp ページの作成

    ログアウトプロセスの一部として、PicketLink はユーザーをサービスプロバイダーアプリケーションのルートディレクトリーにある logout.jsp ページへリダイレクトします。必ずこのページを作成してください。

第16章 ログインモジュール

16.1. モジュールの使用

JBoss EAP 6 には、ユーザー管理のニーズに見合うバンドルされたログインモジュールが複数含まれています。JBoss EAP 6 はリレーショナルデータベース、LDAP サーバー、またはフラットファイルからユーザー情報を読み取りできます。JBoss EAP 6 はこれらのコアログインモジュールの他に、特別なニーズに合わせたユーザー情報を提供するその他のログインモジュールも提供します。
その他のログインモジュールとオプションは付録 A.1 を参照してください。

16.1.1. パスワードスタッキング

複数のログインモジュールをスタックでチェーンし、各ログインモジュールが認証中にクレデンシャルの検証とロールの割り当てを両方を提供するようにできます。これは多くのユースケースで対応できますが、場合によってはクレデンシャルの検証とロールの割り当てが複数のユーザー管理ストアに分割されます。
LDAP とリレーショナルデータベースを組み合わせ、どちらかのシステムによってユーザーが認証されるようにする方法は、「Ldap ログインモジュール」に記述されています。ユーザーは中央の LDAP サーバーで管理され、 アプリケーション固有のロールはアプリケーションのリレーショナルデータベースに保存される場合を考えてみましょう。パスワードスタッキングモジュールオプションはこの関係をキャプチャーします。
パスワードスタッキングを使用するには、各ログインモジュールは <module-option> password-stacking 属性を useFirstPass に設定する必要があります。パスワードスタッキング用に設定された以前のモジュールがユーザーを認証した場合、他のすべてのスタッキングモジュールはユーザーが認証されたとみなし、承認手順のロールのみを提供しようとします。
password-stacking オプションが useFirstPass に設定されている場合、このモジュールは最初にログインモジュールの共有状態マップにて、プロパティー名 javax.security.auth.login.name 配下の共有ユーザー名とjavax.security.auth.login.password 配下のパスワードを探します。
これらのプロパティーが見つかると、プリンシパル名およびパスワードとして使用されます。見つからなかった場合、プリンシパル名およびパスワードはこのログインモジュールによって設定され、それぞれプロパティー名 javax.security.auth.login.name および javax.security.auth.login.password の配下に保存されます。

注記

パスワードスタッキングを使用する場合は、すべてのモジュールを必要 (required) として設定します。これにより、すべてのモジュールが考慮され、ロールを承認プロセスへ提供する機会が与えられます。

例16.1 パスワードスタッキングの例

以下の管理 CLI の例は、パスワードスタッキングの使用方法を示しています。
/subsystem=security/security-domain=pwdStack/authentication=classic/login-module=Ldap:add( \
  code=Ldap, \
  flag=required, \
  module-options=[ \
    ("password-stacking"=>"useFirstPass"), \
    ... Ldap login module configuration
  ])
/subsystem=security/security-domain=pwdStack/authentication=classic/login-module=Database:add( \
  code=Database, \
  flag=required, \
  module-options=[ \
    ("password-stacking"=>"useFirstPass"), \
    ... Database login module configuration
  ])
Copy to Clipboard Toggle word wrap

16.1.2. パスワードのハッシュ化

ログインモジュールのほとんどは、クライアントが提供するパスワードをユーザー管理システムに保存されたパスワードと比較する必要があります。通常、これらのモジュールはプレーンテキストのパスワードを使用しますが、プレーンテキストのパスワードがサーバー側に保存されないようにするため、ハッシュ化されたパスワードをサポートするよう設定できます。

重要

Red Hat JBoss Enterprise Application Platform Common Criteria の認定リリースは、パスワードのハッシュ化に SHA-256 のみをサポートします。

例16.2 パスワードのハッシュ化

以下は、base64 でエンコードされ、SHA-256 でハッシュ化されたパスワードが usersb64.properties ファイルに含まれ、認証されていないユーザーにプリンシパル名 nobody を割り当てるログインモジュールの設定になります。usersb64.properties ファイルはデプロイメントクラスパスの一部になります。
/subsystem=security/security-domain=testUsersRoles:add
/subsystem=security/security-domain=testUsersRoles/authentication=classic:add
/subsystem=security/security-domain=testUsersRoles/authentication=classic/login-module=UsersRoles:add( \
  code=UsersRoles, \
  flag=required, \
  module-options=[ \
    ("usersProperties"=>"usersb64.properties"), \
    ("rolesProperties"=>"test-users-roles.properties"), \
    ("unauthenticatedIdentity"=>"nobody"), \
    ("hashAlgorithm"=>"SHA-256"), \
    ("hashEncoding"=>"base64") \
  ])
Copy to Clipboard Toggle word wrap
hashAlgorithm
パスワードをハッシュ化するために使用される java.security.MessageDigest アルゴリズムの名前。デフォルトはないため、ハッシュ化を有効にするにはこのオプションを指定する必要があります。一般的な値は SHA-256SHA-1、および MD5 です。
hashEncoding
3 つのエンコーディング形式 (base64hex、または rfc2617) の 1 つを指定する文字列です。デフォルトは base64 です。
hashCharset
クリアテキストのパスワードをバイトアレイに変換するために使用されるエンコーディング文字。デフォルトはプラットフォームのデフォルトエンコーディングです。
hashUserPassword
ユーザーが送信するパスワードに適用されるハッシュアルゴリズムを指定します。ハッシュ化されたユーザーパスワードは、パスワードのハッシュであることが想定されるログインモジュールの値と比較されます。デフォルトは true です。
hashStorePassword
サーバー側に保存されるパスワードに適用されるハッシュアルゴリズムを指定します。これは、ユーザーがユーザーパスワードのハッシュとサーバーからのリクエスト固有のトークンを送信して比較するダイジェスト認証に使用されます。サーバー側のハッシュを算出するために、ハッシュアルゴリズム (ダイジェスト認証の場合は rfc2617) が使用されます。サーバー側のハッシュは、クライアントから送信されたハッシュ化された値と一致する必要があります。
パスワードをコードで生成する必要がある場合は、指定のエンコーディングを使用してパスワードをハッシュ化する静的ヘルパーメソッドが org.jboss.security.auth.spi.Util クラスによって提供されます。以下の例は、base64 でエンコードされ MD5 でハッシュ化されたパスワードを生成します。
String hashedPassword = Util.createPasswordHash("SHA-256",
 Util.BASE64_ENCODING, null, null, "password");
Copy to Clipboard Toggle word wrap
この他に、OpenSSL を使用してコマンドラインでハッシュ化されたパスワードを即座に生成する方法もあります。以下の例も、Base64 でエンコードされ SHA-256 でハッシュ化されたパスワードを生成します。この例では、プレーンテキストのパスワードである password が OpenSSL のダイジェスト関数へパイプ処理された後、base64 でエンコードされた形式に変換するために別の OpenSSL 関数へパイプ処理されます。
echo -n password | openssl dgst -sha256 -binary | openssl base64
Copy to Clipboard Toggle word wrap
ハッシュ化されたパスワードは XohImNooBHFR0OVvjcYpJ3NgPQ1qq73WKhHvch0VQtg= で、両方の場合で同じになります。上記の例では、この値はセキュリティードメインで指定されたユーザーのプロパティーファイル usersb64.properties に保存される必要があります。

16.1.3. 非認証のアイデンティティー

すべてのリクエストが認証された形で受信されるわけではありません。unauthenticatedIdentity は、関連する認証情報がない状態で作成されたリクエストへ特定のアイデンティティー (guest など) を割り当てるログインモジュール設定オプションです。このオプションを使用すると、保護されていないサーブレットは特定のロールを必要としない EJB 上でメソッドを呼び出しできます。このようなプリンシパルには関連するロールがなく、セキュアでない EJB やチェックされないパーミッション制約に関連する EJB メソッドへのみアクセスできます。
  • unauthenticatedIdentity: 認証情報が含まれないリクエストへ割り当てられるプリンシパル名を定義します。

16.1.4. Ldap ログインモジュール

Ldap ログインモジュールは LDAP (Lightweight Directory Access Protocol) サーバーに対して認証を行う LoginModule 実装です。JNDI (Java Naming and Directory Interface) LDAP プロバイダーを使用してアクセス可能な LDAP サーバーにユーザー名とクレデンシャルが保存される場合は、Ldap ログインモジュールを使用してください。

注記

SPNEGO を用いて LDAP を使用したい場合や、LDAP サーバーの使用中に認証フェーズの一部を省略したい場合は、SPNEGO ログインモジュールにチェーンされた AdvancedLdap ログインモジュールまたは AdvancedLdap ログインモジュールのみの使用を考慮してください。
識別名 (DN)
LDAP (Lightweight Directory Access Protocol) では、識別名によってディレクトリーでオブジェクトが一意に識別されます。各識別名には他のオブジェクトとは異なる一意な名前と場所が必要で、これには属性と値のペア (AVP) を使用します。AVP は共通名や組織単位などの情報を定義します。これらの値を組み合わせることで、LDAP が必要とする一意な文字列が作成されます。

注記

このログインモジュールは、非認証のアイデンティティーやパスワードスタッキングもサポートします。
LDAP の接続情報は、JNDI 初期コンテキストの作成に使用される環境オブジェクトへ渡される設定オプションとして提供されます。使用される標準の LDAP JNDI プロパティーには以下が含まれます。
java.naming.factory.initial
InitialContextFactory 実装クラス名。デフォルトは Sun LDAP プロバイダー実装 com.sun.jndi.ldap.LdapCtxFactory です。
java.naming.provider.url
LDAP サーバーの LDAP URL。
java.naming.security.authentication
使用するセキュリティープロトコルレベルです。使用可能な値は nonesimplestrong などです。プロパティーが定義されていないと、挙動はサービスプロバイダーによって決定されます。
java.naming.security.protocol
セキュリティーアクセスに使用されるトランスポートプロトコル。この設定オプションをサービスプロバイダーのタイプ (例: SSL) に設定します。プロパティーが定義されてされていないと、挙動はサービスプロバイダーによって決定されます。
java.naming.security.principal
サービスに対する呼び出し元を認証するプリンシパルのアイデンティティーを指定します。これは、以下に示された他のプロパティーから構築されます。
java.naming.security.credentials
サービスに対する呼び出し元を認証するプリンシパルのクレデンシャルを指定します。クレデンシャルの可能な形式はハッシュ化されたパスワード、クリアテキストのパスワード、キー、または証明書です。プロパティーが定義されていないと、挙動はサービスプロバイダーによって決定されます。
Ldap ログインモジュール設定オプションの詳細は、「含まれる認証モジュール」を参照してください。

注記

ディレクトリースキーマによっては (Microsoft Active Directory など)、ユーザーオブジェクトのロール属性が単純名ではなくロールオブジェクトへの DN として保存されます。このスキーマタイプを使用する実装では、roleAttributeIsDNtrue に設定する必要があります。
ユーザー認証は、ログインモジュール設定オプションを基に、LDAP サーバーへ接続して実行されます。LDAP サーバーへ接続するには、前述の LDAP JNDI プロパティーで構成される環境を用いて InitialLdapContext を作成します。
Context.SECURITY_PRINCIPAL は、コールバックハンドラーによって取得されたユーザーの識別名に設定されます。これは、principalDNPrefixprincipalDNSuffix オプションの値の組み合わせになります。Context.SECURITY_CREDENTIALS プロパティーは対応する String パスワードに設定されます。
認証に成功すると (InitialLdapContext インスタンスが作成されます)、roleAttributeName および uidAttributeName オプションの値に設定された検索属性で rolesCtxDN の場所を検索し、ユーザーのロールがクエリーされます。ロール名は、検索結果セットのロール属性で toString メソッドを呼び出して取得されます。

例16.3 LDAP ログインモジュールのセキュリティードメイン

以下の管理 CLI の例は、セキュリティードメイン認証設定でパラメーターを使用する方法を示しています。
/subsystem=security/security-domain=testLDAP:add(cache-type=default)
/subsystem=security/security-domain=testLDAP/authentication=classic:add
/subsystem=security/security-domain=testLDAP/authentication=classic/login-module=Ldap:add( \
  code=Ldap, \
  flag=required, \
  module-options=[ \
    ("java.naming.factory.initial"=>"com.sun.jndi.ldap.LdapCtxFactory"), \
    ("java.naming.provider.url"=>"ldap://ldaphost.jboss.org:1389/"), \
    ("java.naming.security.authentication"=>"simple"), \
    ("principalDNPrefix"=>"uid="), \
    ("principalDNSuffix"=>",ou=People,dc=jboss,dc=org"), \
    ("rolesCtxDN"=>"ou=Roles,dc=jboss,dc=org"), \
    ("uidAttributeID"=>"member"), \
    ("matchOnUserDN"=>true), \
    ("roleAttributeID"=>"cn"), \
    ("roleAttributeIsDN"=>false) \
  ])
Copy to Clipboard Toggle word wrap
testLDAP セキュリティードメイン設定の java.naming.factory.initialjava.naming.factory.url、および java.naming.security オプションは以下の条件を示します。
  • Sun LDAP JNDI プロバイダー実装が使用されます。
  • LDAP サーバーは、ポート 1389 のホスト ldaphost.jboss.org にあります。
  • LDAP サーバーへの接続には LDAP の単純な認証メソッドが使用されます。
ログインモジュールは、認証しようとしているユーザーを表す識別名 (DN) を使用して LDAP サーバーへの接続を試行します。この DN は、渡された principalDNPrefix、ユーザーのユーザー名、principalDNSuffix で構成されます。例16.4「LDIF ファイルの例」 では、ユーザー名 jsmithuid=jsmith,ou=People,dc=jboss,dc=org へマップされます。

注記

この例では、ユーザーエントリーの userPassword 属性 (この例では theduke) を使用して LDAP サーバーがユーザーを認証することを想定します。ほとんどの LDAP サーバーはこのように動作しますが、ご使用の LDAP サーバーの認証処理がこれとは異なる場合は、本番環境の要件に従って LDAP を設定する必要があります。
認証処理に成功すると、uidAttributeID がユーザーと一致するエントリーに対して rolesCtxDN のサブツリー検索が実行され、承認の基になるロールが読み出されます。matchOnUserDN が true の場合、ユーザーの完全な DN を基に検索が実行されます。true でない場合は、入力された実際のユーザー名を基にして検索が実行されます。この例では、ou=Roles,dc=jboss,dc=org 配下の uid=jsmith,ou=People,dc=jboss,dc=org と等しい member 属性を持つエントリーに対して検索が行われ、ロールエントリー配下の cn=JBossAdmin が見つかります。
検索は、roleAttributeID オプションに指定された属性を返します。この例では、属性は cn になります。返される値は JBossAdmin で、ユーザー jsmithJBossAdmin ロールに割り当てられます。
通常、ローカル LDAP サーバーはアイデンティティーおよび認証サービスを提供し、承認サービスは使用できません。これは、アプリケーションロールは LDAP グループへ適切にマップしないことがあり、通常 LDAP 管理者は外部アプリケーション固有のデータを中央の LDAP サーバーで許可したくないためです。多くの場合で LDAP 認証モジュールは、開発中のアプリケーションにより適したロールを提供できる別のログインモジュール (データベースログインモジュールなど) とともに使用されます。
このような操作が行われるディレクトリーの構造を表す LDAP データ変換形式 (LDIF) を例16.4「LDIF ファイルの例」に示します。
LDAP データ変換形式 (LDIF)
LDAP ディレクトリーの内容や更新リクエストを表すために使用されるプレーンテキストのデータ変換形式です。ディレクトリーの内容は 各オブジェクトまたは更新リクエストが 1 つのレコードとして示されます。内容は追加、変更、削除、および名前変更リクエストで構成されます。

例16.4 LDIF ファイルの例

dn: dc=jboss,dc=org
objectclass: top
objectclass: dcObject
objectclass: organization
dc: jboss
o: JBoss

dn: ou=People,dc=jboss,dc=org
objectclass: top
objectclass: organizationalUnit
ou: People

dn: uid=jsmith,ou=People,dc=jboss,dc=org
objectclass: top
objectclass: uidObject
objectclass: person
uid: jsmith
cn: John
sn: Smith
userPassword: theduke

dn: ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: organizationalUnit
ou: Roles

dn: cn=JBossAdmin,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: JBossAdmin
member: uid=jsmith,ou=People,dc=jboss,dc=org
description: the JBossAdmin group
Copy to Clipboard Toggle word wrap

16.1.5. LdapExtended ログインモジュール

識別名 (DN)
LDAP (Lightweight Directory Access Protocol) では、識別名によってディレクトリーでオブジェクトが一意に識別されます。各識別名には他のオブジェクトとは異なる一意な名前と場所が必要で、これには属性と値のペア (AVP) を使用します。AVP は共通名や組織単位などの情報を定義します。これらの値を組み合わせることで、LDAP が必要とする一意な文字列が作成されます。
LdapExtended (org.jboss.security.auth.spi.LdapExtLoginModule) はバインドするユーザーと関連するロールを検索します。ロールクエリーは再帰的に DN をたどり、階層的なロール構成を移動します。
LoginModule オプションには、選択した LDAP JNDI プロバイダーがサポートするオプションが含まれます。標準のプロパティー名の例は次のとおりです。
  • Context.INITIAL_CONTEXT_FACTORY = "java.naming.factory.initial"
  • Context.SECURITY_PROTOCOL = "java.naming.security.protocol"
  • Context.PROVIDER_URL = "java.naming.provider.url"
  • Context.SECURITY_AUTHENTICATION = "java.naming.security.authentication"
  • Context.REFERRAL = "java.naming.referral"
ログインモジュール実装ロジックは以下の順番に従います。
  1. 初期の LDAP サーバーのバインドは bindDN および bindCredential プロパティーを使用して認証されます。bindDN は、ユーザーとロールの baseCtxDN および rolesCtxDN ツリーを検索する権限を持つユーザーです。認証する user DN は、baseFilter プロパティーによって指定されたフィルターを使用してクエリーされます。
  2. 結果となる userDN は、InitialLdapContext 環境 Context.SECURITY_PRINCIPAL として userDN を使用して LDAP サーバーにバインドすることで認証されます。Context.SECURITY_CREDENTIALS プロパティーは、コールバックハンドラーにより取得された文字列パスワードに設定されます。
  3. これに成功すると、rolesCtxDN、roleAttributeID、roleAttributeIsDN、roleNameAttributeID、および roleFilter オプションを使用して関連するユーザーロールがクエリーされます。
LdapExtended ログインモジュールオプションの詳細は「含まれる認証モジュール」を参照してください。

図16.1 LDAP 構成の例

例16.5 LDAP 設定例 2

version: 1
dn: o=example2,dc=jboss,dc=org
objectClass: top
objectClass: organization
o: example2

dn: ou=People,o=example2,dc=jboss,dc=org
objectClass: top
objectClass: organizationalUnit
ou: People

dn: uid=jduke,ou=People,o=example2,dc=jboss,dc=org
objectClass: top
objectClass: uidObject
objectClass: person
objectClass: inetOrgPerson
cn: Java Duke
employeeNumber: judke-123
sn: Duke
uid: jduke
userPassword:: dGhlZHVrZQ==

dn: uid=jduke2,ou=People,o=example2,dc=jboss,dc=org
objectClass: top
objectClass: uidObject
objectClass: person
objectClass: inetOrgPerson
cn: Java Duke2
employeeNumber: judke2-123
sn: Duke2
uid: jduke2
userPassword:: dGhlZHVrZTI=

dn: ou=Roles,o=example2,dc=jboss,dc=org
objectClass: top
objectClass: organizationalUnit
ou: Roles

dn: uid=jduke,ou=Roles,o=example2,dc=jboss,dc=org
objectClass: top
objectClass: groupUserEx
memberOf: cn=Echo,ou=Roles,o=example2,dc=jboss,dc=org
memberOf: cn=TheDuke,ou=Roles,o=example2,dc=jboss,dc=org
uid: jduke

dn: uid=jduke2,ou=Roles,o=example2,dc=jboss,dc=org
objectClass: top
objectClass: groupUserEx
memberOf: cn=Echo2,ou=Roles,o=example2,dc=jboss,dc=org
memberOf: cn=TheDuke2,ou=Roles,o=example2,dc=jboss,dc=org
uid: jduke2

dn: cn=Echo,ou=Roles,o=example2,dc=jboss,dc=org
objectClass: top
objectClass: groupOfNames
cn: Echo
description: the echo role
member: uid=jduke,ou=People,dc=jboss,dc=org

dn: cn=TheDuke,ou=Roles,o=example2,dc=jboss,dc=org
objectClass: groupOfNames
objectClass: top
cn: TheDuke
description: the duke role
member: uid=jduke,ou=People,o=example2,dc=jboss,dc=org

dn: cn=Echo2,ou=Roles,o=example2,dc=jboss,dc=org
objectClass: top
objectClass: groupOfNames
cn: Echo2
description: the Echo2 role
member: uid=jduke2,ou=People,dc=jboss,dc=org

dn: cn=TheDuke2,ou=Roles,o=example2,dc=jboss,dc=org
objectClass: groupOfNames
objectClass: top
cn: TheDuke2
description: the duke2 role
member: uid=jduke2,ou=People,o=example2,dc=jboss,dc=org

dn: cn=JBossAdmin,ou=Roles,o=example2,dc=jboss,dc=org
objectClass: top
objectClass: groupOfNames
cn: JBossAdmin
description: the JBossAdmin group
member: uid=jduke,ou=People,dc=jboss,dc=org
Copy to Clipboard Toggle word wrap
この LDAP 構造例のモジュール設定を以下の管理 CLI コマンドに示します。
/subsystem=security/security-domain=testLdapExample2/authentication=classic/login-module=LdapExtended:add( \
  code=LdapExtended, \
  flag=required, \
  module-options=[ \
    ("java.naming.factory.initial"=>"com.sun.jndi.ldap.LdapCtxFactory"), \
    ("java.naming.provider.url"=>"ldap://ldaphost.jboss.org"), \
    ("java.naming.security.authentication"=>"simple"), \
    ("bindDN"=>"cn=Root,dc=jboss,dc=org"), \
    ("bindCredential"=>"secret1"), \
    ("baseCtxDN"=>"ou=People,o=example2,dc=jboss,dc=org"), \
    ("baseFilter"=>"(uid={0})"), \
    ("rolesCtxDN"=>"ou=Roles,o=example2,dc=jboss,dc=org"), \
    ("roleFilter"=>"(uid={0})"), \
    ("roleAttributeIsDN"=>"true"), \
    ("roleAttributeID"=>"memberOf"), \
    ("roleNameAttributeID"=>"cn") \
  ])
Copy to Clipboard Toggle word wrap

例16.6 LDAP 設定例 3

dn: o=example3,dc=jboss,dc=org
objectclass: top
objectclass: organization
o: example3

dn: ou=People,o=example3,dc=jboss,dc=org
objectclass: top
objectclass: organizationalUnit
ou: People

dn: uid=jduke,ou=People,o=example3,dc=jboss,dc=org
objectclass: top
objectclass: uidObject
objectclass: person
objectClass: inetOrgPerson
uid: jduke
employeeNumber: judke-123
cn: Java Duke
sn: Duke
userPassword: theduke

dn: ou=Roles,o=example3,dc=jboss,dc=org
objectClass: top
objectClass: organizationalUnit
ou: Roles

dn: uid=jduke,ou=Roles,o=example3,dc=jboss,dc=org
objectClass: top
objectClass: groupUserEx
memberOf: cn=Echo,ou=Roles,o=example3,dc=jboss,dc=org
memberOf: cn=TheDuke,ou=Roles,o=example3,dc=jboss,dc=org
uid: jduke

dn: cn=Echo,ou=Roles,o=example3,dc=jboss,dc=org
objectClass: top
objectClass: groupOfNames
cn: Echo
description: the JBossAdmin group
member: uid=jduke,ou=People,o=example3,dc=jboss,dc=org

dn: cn=TheDuke,ou=Roles,o=example3,dc=jboss,dc=org
objectClass: groupOfNames
objectClass: top
cn: TheDuke
member: uid=jduke,ou=People,o=example3,dc=jboss,dc=org
Copy to Clipboard Toggle word wrap
この LDAP 構造例のモジュール設定を以下の管理 CLI コマンドに示します。
/subsystem=security/security-domain=testLdapExample3/authentication=classic/login-module=LdapExtended:add( \
  code=LdapExtended, \
  flag=required, \
  module-options=[ \
    ("java.naming.factory.initial"=>"com.sun.jndi.ldap.LdapCtxFactory"), \
    ("java.naming.provider.url"=>"ldap://ldaphost.jboss.org"), \
    ("java.naming.security.authentication"=>"simple"), \
    ("bindDN"=>"cn=Root,dc=jboss,dc=org"), \
    ("bindCredential"=>"secret1"), \
    ("baseCtxDN"=>"ou=People,o=example3,dc=jboss,dc=org"), \
    ("baseFilter"=>"(cn={0})"), \
    ("rolesCtxDN"=>"ou=Roles,o=example3,dc=jboss,dc=org"), \
    ("roleFilter"=>"(member={1})"), \
    ("roleAttributeID"=>"cn") \
  ])
Copy to Clipboard Toggle word wrap

例16.7 LDAP 設定例 4

dn: o=example4,dc=jboss,dc=org
objectclass: top
objectclass: organization
o: example4

dn: ou=People,o=example4,dc=jboss,dc=org
objectclass: top
objectclass: organizationalUnit
ou: People

dn: uid=jduke,ou=People,o=example4,dc=jboss,dc=org
objectClass: top
objectClass: uidObject
objectClass: person
objectClass: inetOrgPerson
cn: Java Duke
employeeNumber: jduke-123
sn: Duke
uid: jduke
userPassword:: dGhlZHVrZQ==

dn: ou=Roles,o=example4,dc=jboss,dc=org
objectClass: top
objectClass: organizationalUnit
ou: Roles

dn: cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org
objectClass: groupOfNames
objectClass: top
cn: RG1
member: cn=empty

dn: cn=RG2,cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org
objectClass: groupOfNames
objectClass: top
cn: RG2
member: cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org
member: uid=jduke,ou=People,o=example4,dc=jboss,dc=org

dn: cn=RG3,cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org
objectClass: groupOfNames
objectClass: top
cn: RG3
member: cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org

dn: cn=R1,ou=Roles,o=example4,dc=jboss,dc=org
objectClass: groupOfNames
objectClass: top
cn: R1
member: cn=RG2,cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org

dn: cn=R2,ou=Roles,o=example4,dc=jboss,dc=org
objectClass: groupOfNames
objectClass: top
cn: R2
member: cn=RG2,cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org

dn: cn=R3,ou=Roles,o=example4,dc=jboss,dc=org
objectClass: groupOfNames
objectClass: top
cn: R3
member: cn=RG2,cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org
member: cn=RG3,cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org

dn: cn=R4,ou=Roles,o=example4,dc=jboss,dc=org
objectClass: groupOfNames
objectClass: top
cn: R4
member: cn=RG3,cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org

dn: cn=R5,ou=Roles,o=example4,dc=jboss,dc=org
objectClass: groupOfNames
objectClass: top
cn: R5
member: cn=RG3,cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org
member: uid=jduke,ou=People,o=example4,dc=jboss,dc=org
Copy to Clipboard Toggle word wrap
この LDAP 構成例のモジュール設定を以下のコードサンプルに示します。
/subsystem=security/security-domain=testLdapExample4/authentication=classic/login-module=LdapExtended:add( \
  code=LdapExtended, \
  flag=required, \
  module-options=[ \
    ("java.naming.factory.initial"=>"com.sun.jndi.ldap.LdapCtxFactory"), \
    ("java.naming.provider.url"=>"ldap://ldaphost.jboss.org"), \
    ("java.naming.security.authentication"=>"simple"), \
    ("bindDN"=>"cn=Root,dc=jboss,dc=org"), \
    ("bindCredential"=>"secret1"), \
    ("baseCtxDN"=>"ou=People,o=example4,dc=jboss,dc=org"), \
    ("baseFilter"=>"(cn={0})"), \
    ("rolesCtxDN"=>"ou=Roles,o=example4,dc=jboss,dc=org"), \
    ("roleFilter"=>"(member={1})"), \
    ("roleRecursion"=>"1"), \
    ("roleAttributeID"=>"memberOf") \
  ])
Copy to Clipboard Toggle word wrap

例16.8 デフォルトの Active Directory 設定

以下の例は、デフォルトの Active Directory 設定を示しています。
Active Directory の設定によっては、通常のポート 389 の代わりにポート 3268 で Global Catalog に対して検索を行う必要がある場合があります。Active Directory フォレストに複数のドメインが含まれる場合、ほぼ確実に対象となります。
/subsystem=security/security-domain=AD_Default/authentication=classic/login-module=LdapExtended:add( \
  code=LdapExtended, \
  flag=required, \
  module-options=[ \
    ("java.naming.provider.url"=>"ldap://ldaphost.jboss.org"), \
    ("bindDN"=>"JBOSS\searchuser"), \
    ("bindCredential"=>"password"), \
    ("baseCtxDN"=>"CN=Users,DC=jboss,DC=org"), \
    ("baseFilter"=>"(sAMAccountName={0})"), \
    ("rolesCtxDN"=>"CN=Users,DC=jboss,DC=org"), \
    ("roleFilter"=>"(sAMAccountName={0})"), \
    ("roleAttributeID"=>"memberOf"), \
    ("roleAttributeIsDN"=>"true"), \
    ("roleNameAttributeID"=>"cn"), \
    ("searchScope"=>"ONELEVEL_SCOPE"), \
    ("allowEmptyPasswords"=>"false") \
  ])
Copy to Clipboard Toggle word wrap

例16.9 再帰的なロールの Active Directory 設定

以下の例は、Active Directory 内で再帰的なロール検索を実装します。この例とデフォルト Active Directory の例との重要な違いは、ロール検索の代わりに、ユーザーの DN を使用してメンバー属性を検索することです。ログインモジュールはロールの DN を使用してメンバーであるグループを見つけます。
/subsystem=security/security-domain=AD_Recursive/authentication=classic/login-module=LdapExtended:add( \
  code=LdapExtended, \
  flag=required, \
  module-options=[ \
    ("java.naming.provider.url"=>"ldap://ldaphost.jboss.org"), \
    ("java.naming.referral"=>"follow"), \
    ("bindDN"=>"JBOSS\searchuser"), \
    ("bindCredential"=>"password"), \
    ("baseCtxDN"=>"CN=Users,DC=jboss,DC=org"), \
    ("baseFilter"=>"(sAMAccountName={0})"), \
    ("rolesCtxDN"=>"CN=Users,DC=jboss,DC=org"), \
    ("roleFilter"=>"(member={1})"), \
    ("roleAttributeID"=>"cn"), \
    ("roleAttributeIsDN"=>"false"), \
    ("roleRecursion"=>"2"), \
    ("searchScope"=>"ONELEVEL_SCOPE"), \
    ("allowEmptyPasswords"=>"false") \
  ])
Copy to Clipboard Toggle word wrap

16.1.6. UsersRoles ログインモジュール

UsersRoles ログインモジュールは、Java プロパティーファイルからロードされた複数のユーザーおよびユーザーロールをサポートする簡単なログインモジュールです。デフォルトのユーザー名対パスワードマッピングのファイル名は users.properties で、デフォルトのユーザー名対ロールマッピングのファイル名は roles.properties です。
UsersRoles ログインモジュールオプションの詳細は「含まれる認証モジュール」を参照してください。
このログインモジュールは、パスワードスタッキング、パスワードのハッシュ化、および非認証アイデンティティーをサポートします。
プロパティーファイルは、初期化メソッドのスレッドコンテキストクラスローダーを使用して初期化中にロードされます。そのため、これらのファイルを Java EE デプロイメントのクラスパス (例: WAR アーカイブの WEB-INF/classes フォルダー内) やサーバークラスパスのディレクトリー内に置くことができます。このログインモジュールの主な目的は、アプリケーションでデプロイされたプロパティーファイルを使用して複数のユーザーやロールのセキュリティー設定を簡単にテストすることです。

例16.10 UserRoles ログインモジュール

/subsystem=security/security-domain=ejb3-sampleapp/authentication=classic/login-module=UsersRoles:add( \
  code=UsersRoles, \
  flag=required, \
  module-options=[ \
    ("usersProperties"=>"ejb3-sampleapp-users.properties"), \
    ("rolesProperties"=>"ejb3-sampleapp-roles.properties") \
  ])
Copy to Clipboard Toggle word wrap
例16.10「UserRoles ログインモジュール」 では、ejb3-sampleapp-users.properties ファイルは各ユーザーエントリーが個別の行で示される username=password 形式を使用します。
username1=password1
username2=password2
...
Copy to Clipboard Toggle word wrap
例16.10「UserRoles ログインモジュール」ejb3-sampleapp-roles.properties ファイルは、グループ名の値を任意で用いて username=role1,role2, というパターンを使用します。例を以下に示します。
username1=role1,role2,...
username1.RoleGroup1=role3,role4,...
username2=role1,role3,...
Copy to Clipboard Toggle word wrap
ejb3-sampleapp-roles.propertiesuser name.XXX というプロパティー名のパターンは、ユーザー名ロールをロールの特定の名前を持つグループへ割り当てるために使用されます。プロパティー名の XXX 部分はグループ名になります。user name=...user name.Roles=... の省略形です。Roles グループ名は JBossAuthorizationManager が想定する、ユーザーの権限を定義するロールが含まれる標準名です。
以下は、ユーザー名 jduke と同等の定義になります。
jduke=TheDuke,AnimatedCharacter
jduke.Roles=TheDuke,AnimatedCharacter
Copy to Clipboard Toggle word wrap

16.1.7. Database ログインモジュール

Database ログインモジュールは、認証とロールマッピングをサポートする JDBC (Java Database Connectivity) ベースのログインモジュールです。ユーザー名、パスワード、およびロールの情報がリレーショナルデータベースに保存される場合は、このログインモジュールを使用します。

注記

このモジュールは、パスワードスタッキング、パスワードのハッシュ化、および非認証アイデンティティーをサポートします。
Database ログインモジュールは、以下の 2 つの論理テーブルを基にします。
Table Principals(PrincipalID text, Password text)
Table Roles(PrincipalID text, Role text, RoleGroup text)
Copy to Clipboard Toggle word wrap
Principals テーブルは、ユーザーの PrincipalID を有効なパスワードに関連付けます。Roles テーブルは、ユーザーの PrincipalID をロールセットに関連付けます。ユーザー権限に使用されるロールは、RoleGroup 列の値が Roles である行に含まれる必要があります。
テーブルは論理的で、ログインモジュールが使用する SQL クエリーを指定できます。唯一の要件は、java.sql.ResultSet の論理構成が前述の Principals および Roles テーブルと同じであることです。結果は列インデックスを基にアクセスされるため、テーブルおよび列の実際の名前は関係ありません。
この概念を明確にするため、すでに宣言された PrincipalsRoles の 2 つのテーブルを持つデータベースについて考えてみてください。以下のステートメントは以下のデータをテーブルに追加します。
  • Principals テーブル内の PasswordechomanPrincipalID java
  • Roles テーブル内の RolesRoleGroup にある Echo という名前のロールを持つ PrincipalID java
  • Roles テーブル内の CallerPrincipalRoleGroup にある caller_java という名前のロールを持つ PrincipalID java
INSERT INTO Principals VALUES('java', 'echoman')
INSERT INTO Roles VALUES('java', 'Echo', 'Roles')
INSERT INTO Roles VALUES('java', 'caller_java', 'CallerPrincipal')
Copy to Clipboard Toggle word wrap
Database ログインモジュールオプションの詳細は「含まれる認証モジュール」を参照してください。
Database login module ログインモジュールの設定例は、次のように構築できます。
CREATE TABLE Users(username VARCHAR(64) PRIMARY KEY, passwd VARCHAR(64))
CREATE TABLE UserRoles(username VARCHAR(64), role VARCHAR(32))
Copy to Clipboard Toggle word wrap
セキュリティーモジュールの対応するログインモジュール設定は次のとおりです。
/subsystem=security/security-domain=testDB/authentication=classic/login-module=Database:add( \
  code=Database, \
  flag=required, \
  module-options=[ \
    ("dsJndiName"=>"java:/MyDatabaseDS"), \
    ("principalsQuery"=>"select passwd from Users where username=?"), \
    ("rolesQuery"=>"select role, 'Roles' from UserRoles where username=?") \
  ])
Copy to Clipboard Toggle word wrap

16.1.8. Certificate ログインモジュール

Certificate ログインモジュールは X509 証明書を基にユーザーを認証します。このログインモジュールの典型的なユースケースが Web 層の CLIENT-CERT 認証です。
このログインモジュールは認証のみを実行します。セキュアな Web または EJB コンポーネントへのアクセスを完全に定義するには、承認ロールを取得できる別のログインモジュールと組み合わせる必要があります。このログインモジュールの 2 つのサブクラスである CertRolesLoginModule および DatabaseCertLoginModule は、動作を拡張してプロパティーファイルまたはデータベースから承認ロールを取得します。
Certificate ログインモジュールオプションの詳細は「含まれる認証モジュール」を参照してください。
Certificate ログインモジュールは、ユーザーの検証に KeyStore を必要とします。これは、以下の設定 (一部分) が示すとおり、リンクされたセキュリティードメインの JSSE 設定から取得されます。
/subsystem=security/security-domain=trust-domain:add
/subsystem=security/security-domain=trust-domain/jsse=classic:add( \
  truststore={ \
    password=>pass1234, \
    url=>/home/jbosseap/trusted-clients.jks \
  })

/subsystem=security/security-domain=testCert:add
/subsystem=security/security-domain=testCert/authentication=classic:add
/subsystem=security/security-domain=testCert/authentication=classic/login-module=Certificate:add( \
  code=Certificate, \
  flag=required, \
  module-options=[ \
    ("securityDomain"=>"trust-domain"), \
  ])
Copy to Clipboard Toggle word wrap

手順16.1 証明書およびロールベース承認を用いた Web アプリケーションのセキュア化

この手順では、クライアント証明書とロールベース承認を使用して user-app.war などの Web アプリケーションをセキュアにする方法を説明します。この例では、認証と承認に CertificateRoles ログインモジュールが使用されます。trusted-clients.keystore および app-roles.properties には、クライアント証明書に関連するプリンシパルへマップするエントリーが必要になります。
デフォルトでは、クライアント証明書の識別名 (例: 例16.11「証明書の例」 で指定された DN) を使用してプリンシパルが作成されます。
  1. リソースおよびロールの宣言

    web.xml を変更し、認証および承認に使用される許可されたロールおよびセキュリティードメインとともにセキュア化されるリソースを宣言します。
    <?xml version="1.0" encoding="UTF-8"?>
    <web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
            version="3.0">
    
            <security-constraint>
                    <web-resource-collection>
                            <web-resource-name>Protect App</web-resource-name>
                            <url-pattern>/*</url-pattern>
                    </web-resource-collection>
                    <auth-constraint>
                            <role-name>Admin</role-name>
                    </auth-constraint>
            </security-constraint>
    
            <login-config>
                    <auth-method>CLIENT-CERT</auth-method>
                    <realm-name>Secured area</realm-name>
            </login-config>
    
            <security-role>
                    <role-name>Admin</role-name>
            </security-role>
    </web-app>
    
    Copy to Clipboard Toggle word wrap
  2. セキュリティードメインの指定

    jboss-web.xml ファイルで、必要なセキュリティードメインを指定します。
    <jboss-web>
      <security-domain>app-sec-domain</security-domain>
    </jboss-web>
    
    Copy to Clipboard Toggle word wrap
  3. ログインモジュールの設定

    管理 CLI を使用して、指定した app-sec-domain ドメインのログインモジュール設定を定義します。
    [
    /subsystem=security/security-domain=trust-domain:add
    /subsystem=security/security-domain=trust-domain/jsse=classic:add( \
      truststore={ \
        password=>pass1234, \
        url=>/home/jbosseap/trusted-clients.jks \
      })
    
    /subsystem=security/security-domain=app-sec-domain:add
    /subsystem=security/security-domain=app-sec-domain/authentication=classic:add
    /subsystem=security/security-domain=app-sec-domain/authentication=classic/login-module=CertificateRoles:add( \
      code=CertificateRoles, \
      flag=required, \
      module-options=[ \
        ("securityDomain"=>"trust-domain"), \
        ("rolesProperties"=>"app-roles.properties") \
      ])
    Copy to Clipboard Toggle word wrap

例16.11 証明書の例

[conf]$ keytool -printcert -file valid-client-cert.crt
Owner: CN=valid-client, OU=Security QE, OU=JBoss, O=Red Hat, C=CZ
Issuer: CN=EAP Certification Authority, OU=Security QE, OU=JBoss, O=Red Hat, C=CZ
Serial number: 2
Valid from: Mon Mar 24 18:21:55 CET 2014 until: Tue Mar 24 18:21:55 CET 2015
Certificate fingerprints:
         MD5:  0C:54:AE:6E:29:ED:E4:EF:46:B5:14:30:F2:E0:2A:CB
         SHA1: D6:FB:19:E7:11:28:6C:DE:01:F2:92:2F:22:EF:BB:5D:BF:73:25:3D
         SHA256: CD:B7:B1:72:A3:02:42:55:A3:1C:30:E1:A6:F0:20:B0:2C:0F:23:4F:7A:8E:2F:2D:FA:AF:55:3E:A7:9B:2B:F4
         Signature algorithm name: SHA1withRSA
         Version: 3
Copy to Clipboard Toggle word wrap
trusted-clients.keystore は、例16.11「証明書の例」 の証明書が CN=valid-client, OU=Security QE, OU=JBoss, O=Red Hat, C=CZ のエイリアスと保存されることを要件とすることがあります。app-roles.properties には同じエントリーが存在する必要があります。DN には通常は区切り文字として使用される文字が含まれているため、以下のようにバックスラッシュ (\) を使用して区切り文字をエスケープする必要があります。
# A sample app-roles.properties file
CN\=valid-client,\ OU\=Security\ QE,\ OU\=JBoss,\ O\=Red\ Hat,\ C\=CZ
Copy to Clipboard Toggle word wrap

16.1.9. Identity ログインモジュール

Identity ログインモジュールは、ハードコードされたユーザー名をモジュールに対して認証されたサブジェクトに関連付ける簡単なログインモジュールです。このモジュールは、principal オプションによって指定された名前を使用して SimplePrincipal インスタンスを作成します。

注記

このモジュールはパスワードスタッキングをサポートします。
このログインモジュールは、固定のアイデンティティーをサービスに提供する必要がある場合や、開発環境で指定のプリンシパルに関連するセキュリティーや関連するロールをテストしたい場合に便利です。
Identity ログインモジュールオプションの詳細は「含まれる認証モジュール」を参照してください。
セキュリティードメインの設定例を以下に示します。これはすべてのユーザーを jduke という名前のプリンシパルとして認証し、TheDuke および AnimatedCharacter というロール名を割り当てます。
/subsystem=security/security-domain=testIdentity:add
/subsystem=security/security-domain=testIdentity/authentication=classic:add
/subsystem=security/security-domain=testIdentity/authentication=classic/login-module=Identity:add( \
  code=Identity, \
  flag=required, \
  module-options=[ \
    ("principal"=>"jduke"), \
    ("roles"=>"TheDuke,AnimatedCharacter") \
  ])

Copy to Clipboard Toggle word wrap

16.1.10. RunAs ログインモジュール

RunAs ログインモジュールはヘルパーモジュールで、認証のログイン段階の間に run as ロールをスタックへプッシュし、コミットまたはアボート段階で run as ロールをスタックからポップします。
このログインモジュールの目的は、認証を実行するためにセキュアなリソースにアクセスする必要がある他のログインモジュール (例: セキュアな EJBにアクセスするログインモジュール) のロールを提供することです。RunAs ロールを必要とするログインモジュールを確立する前に RunAs ログインモジュールを設定する必要があります。
RunAs ログインモジュールオプションの詳細は「含まれる認証モジュール」を参照してください。
16.1.10.1. RunAsIdentity の作成
JBoss EAP 6 によって EJB メソッドへのアクセスをセキュアにするため、メソッド呼び出しが行われたときにユーザーのアイデンティティーを公開する必要があります。
サーバーのユーザーのアイデンティティーは、javax.security.auth.Subject インスタンスまたは org.jboss.security.RunAsIdentity インスタンスのいずれかによって示されます。これらのクラスは、アイデンティティーとアイデンティティーが持つロールのリストを示す 1 つ以上のプリンシパルを保存します。javax.security.auth.Subject の場合は、クレデンシャルのリストも保存されます。
ejb-jar.xml デプロイメント記述子の <assembly-descriptor> セクションには、ユーザーがさまざまな EJB メソッドへアクセスするために必要な 1 つ以上のロールを指定します。これらのリストを比較すると、EJB メソッドへアクセスするために必要なロールの 1 つをユーザーが持っているかどうかが分かります。

例16.12 org.jboss.security.RunAsIdentity の作成

ejb-jar.xml ファイルには、<session> 要素の子として定義された <run-as> ロールを持つ <security-identity> 要素を指定します。
<session>
   ...
   <security-identity>
      <run-as>
         <role-name>Admin</role-name>
      </run-as>
   </security-identity>
   ...
</session>
Copy to Clipboard Toggle word wrap
この宣言は、Admin の RunAsIdentity ロールを作成する必要があることを意味します。
Admin ロールのプリンシパルに名前と付けるには、jboss-ejb3.xml ファイルで <run-as-principal> 要素を定義します。
<jboss:ejb-jar
        xmlns="http://java.sun.com/xml/ns/javaee"
        xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
        xmlns:s="urn:security:1.1"
        version="3.1" impl-version="2.0">
    <assembly-descriptor>
        <s:security>
            <ejb-name>WhoAmIBean</ejb-name>
            <s:run-as-principal>John</s:run-as-principal>
        </s:security>
    </assembly-descriptor>
</jboss:ejb-jar>
Copy to Clipboard Toggle word wrap
ejb-jar.xml ファイルの <security-identity> 要素と jboss-ejb3.xml ファイルの <security> 要素はデプロイメント時点で解析されます。<run-as> ロール名および <run-as-principal> 名は org.jboss.metadata.ejb.spec.SecurityIdentityMetaData クラスに保存されます。

例16.13 RunAsIdentity への複数ロールの割り当て

jboss-ejb3.xml デプロイメント記述子の <assembly-descriptor> 要素グループでロールをプリンシパルへマップすると、追加のロールを RunAsIdentity へ割り当てできます。
<jboss:ejb-jar xmlns:sr="urn:security-role"
        ...>
        <assembly-descriptor>
            ...
                <sr:security-role>
                        <sr:role-name>Support</sr:role-name>
                        <sr:principal-name>John</sr:principal-name>
                        <sr:principal-name>Jill</sr:principal-name>
                        <sr:principal-name>Tony</sr:principal-name>
                </sr:security-role>
        </assembly-descriptor>
</jboss:ejb-jar>
Copy to Clipboard Toggle word wrap
例16.12「org.jboss.security.RunAsIdentity の作成」では、John<run-as-principal> が作成されました。この例の設定は、Support ロールを追加して Admin ロールを拡張します。新しいロールには、追加のプリンシパルと最初に定義されたプリンシパル John が含まれます。
ejb-jar.xml および jboss-ejb3.xml ファイルの <security-role> 要素はデプロイ時に解析されます。<role-name> および <principal-name> データは org.jboss.metadata.ejb.spec.SecurityIdentityMetaData クラスに保存されます。

16.1.11. Client ログインモジュール

Client ログインモジュール (org.jboss.security.ClientLoginModule) は、呼び出し側のアイデンティティーとクレデンシャルを確立するときに JBoss クライアントによって使用される LoginModule の実装です。このモジュールは、新しい SecurityContext を作成してプリンシパルとクレデンシャルを割り当て、SecurityContextThreadLocal セキュリティーコンテキストに設定します。
Client ログインモジュールは、クライアントが現在のスレッドの呼び出し側を確立するために唯一サポートされるメカニズムです。スタンドアロンクライアントアプリケーションとサーバー環境 (EAP セキュリティーサブシステムを透過的に使用するよう設定されていないセキュリティー環境で JBoss EJB クライアントとして動作する) の両方は Client ログインモジュールを使用する必要があります。
このログインモジュールは認証を行わないことに注意してください。このモジュールは、サーバーで行われる後続の認証向けに、提供されたログイン情報をサーバーの EJB 呼び出しレイヤーにコピーします。クライアント側のユーザー認証を行う必要がある場合は、Client ログインモジュールの他に別のログインモジュールを設定する必要があります。
Client ログインモジュールオプションの詳細は「含まれる認証モジュール」を参照してください。

16.1.12. SPNEGO ログインモジュール

SPNEGO ログインモジュール (org.jboss.security.negotiation.spnego.SPNEGOLoginModule) は、KDC を用いて呼び出し側のアイデンティティーとクレデンシャルを確立する LoginModule の実装です。モジュールは JBoss Negotiation プロジェクトの一部で、SPNEGO (Simple and Protected GSSAPI Negotiation メカニズム) を実装します。AdvancedLdap ログインモジュールを用いてチェーンされた設定でこの認証を使用すると、LDAP サーバーとの連携を可能にできます。
SPNEGO ログインモジュールオプションの詳細は「含まれる認証モジュール」を参照してください。
JBoss Negotiation モジュールは、デプロイされたアプリケーションの標準の依存関係として含まれていません。プロジェクトで SPNEGO または AdvancedLdap ログインモジュールを使用するには、META-INF/jboss-deployment-structure.xml デプロイメント記述子ファイルを編集し、手作業で依存関係を追加する必要があります。

例16.14 JBoss Negotiation モジュールを依存関係として追加

<jboss-deployment-structure>
  <deployment>
    <dependencies>
      <module name="org.jboss.security.negotiation" />
    </dependencies>
  </deployment>
</jboss-deployment-structure>
Copy to Clipboard Toggle word wrap

16.1.13. RoleMapping ログインモジュール

RoleMapping ログインモジュールは、認証プロセスの最終結果であるロールを 1 つ以上の宣言的ロールへマップすることをサポートします。たとえば、ユーザー「A」は「ldapAdmin」および「testAdmin」ロールを持ち、アクセスのために web.xml または ejb-jar.xml ファイルに定義された宣言的ロールは admin であると認証プロセスによって判断された場合、このモジュールは admin ロールをユーザー A にマップします。
RoleMapping ログインモジュールオプションの詳細は「含まれる認証モジュール」を参照してください。
RoleMapping ログインモジュールはログインモジュール設定の任意のモジュールであると定義する必要があります。これにより、以前マップされたロールのマッピングが変更されます。

例16.15 マップされたロールの定義

/subsystem=security/security-domain=test-domain-2/:add
/subsystem=security/security-domain=test-domain-2/authentication=classic:add
/subsystem=security/security-domain=test-domain-2/authentication=classic/login-module=test-2-lm/:add(\
flag=required,\
code=UsersRoles,\
module-options=[("usersProperties"=>"users.properties"),("rolesProperties"=>"roles.properties")]\
)
/subsystem=security/security-domain=test-domain-2/authentication=classic/login-module=test2-map/:add(\
flag=optional,\
code=RoleMapping,\
module-options=[("rolesProperties"=>"rolesMapping-roles.properties")]\
)
Copy to Clipboard Toggle word wrap
以下はマッピングモジュールを使用して同じ結果を得る例になります。これは、ロールマッピングの推奨方法になります。

例16.16 マップされたロールを定義する推奨方法

/subsystem=security/security-domain=test-domain-2/:add
/subsystem=security/security-domain=test-domain-2/authentication=classic:add
/subsystem=security/security-domain=test-domain-2/authentication=classic/login-module=test-2-lm/:add(\
flag=required,\
code=UsersRoles,\
module-options=[("usersProperties"=>"users.properties"),("rolesProperties"=>"roles.properties")]\
)
/subsystem=security/security-domain=test-domain-2/mapping=classic/mapping-module=test2-map/:add(\
code=PropertiesRoles,type=role,\
module-options=[("rolesProperties"=>"rolesMapping-roles.properties")]\
)
Copy to Clipboard Toggle word wrap

例16.17 RoleMappingLoginModule によって使用されるプロパティーファイル

ldapAdmin=admin, testAdmin
Copy to Clipboard Toggle word wrap
認証されたサブジェクトに ldapAdmin ロールが含まれている場合、replaceRole プロパティーの値に応じて admin および testAdmin ロールが認証されたサブジェクトに追加されるか、認証されたサブジェクトの代替となります。

16.1.14. bindCredential モジュールオプション

bindCredential モジュールオプションは、DN のクレデンシャルを保存するために使用され、複数のログインおよびマッピングモジュールによって使用されます。パスワードを取得する方法は複数あります。

管理 CLI コマンドのプレーンテキスト。
bindCredential モジュールのパスワードは、("bindCredential"=>"secret1") のように管理 CLI コマンドにてプレーンテキストで提供されることがあります。セキュリティー上の理由で、このパスワードは JBoss EAP の vault メカニズムを使用して暗号化する必要があります。
外部コマンドの使用。
外部コマンドの出力からパスワードを入手するには、{EXT}... 形式を使用します (... は外部コマンドに置き換えます)。コマンド出力の最初の行がパスワードとして使用されます。
パフォーマンスを改善するため、{EXTC[:expiration_in_millis]} の亜種は指定のミリ秒の間パスワードをキャッシュします。デフォルトでは、キャッシュされたパスワードは失効しません。0 (ゼロ) が値として指定された場合、キャッシュされたクレデンシャルは失効しません。
EXTC の亜種は LdapExtended ログインモジュールのみによってサポートされます。

例16.18 外部コマンドからのパスワードの取得

{EXT}cat /mysecretpasswordfile
Copy to Clipboard Toggle word wrap

例16.19 外部ファイルからパスワードを取得し、500 ミリ秒間キャッシュする

{EXTC:500}cat /mysecretpasswordfile
Copy to Clipboard Toggle word wrap

16.2. カスタムモジュール

EAP セキュリティーフレームワークでバンドルされたログインモジュールがセキュリティー環境で動作しない場合、独自のカスタムログインモジュール実装を記述できます。AuthenticationManagerSubject プリンシパルセットの特定の使用パターンを必要とします。AuthenticationManager と動作するログインモジュールを書くには、JAAS サブジェクトクラスの情報ストレージ機能と、これらの機能の想定される使用方法を理解する必要があります。
本項ではこの要件を検証し、カスタムログインモジュールの実装に役立つ 2 つの抽象ベースの LoginModule 実装を紹介します。
以下のメソッドを使用すると Subject に関連するセキュリティー情報を取得できます。
java.util.Set getPrincipals()
java.util.Set getPrincipals(java.lang.Class c)
java.util.Set getPrivateCredentials()
java.util.Set getPrivateCredentials(java.lang.Class c)
java.util.Set getPublicCredentials()
java.util.Set getPublicCredentials(java.lang.Class c)
Copy to Clipboard Toggle word wrap
Subject アイデンティティーおよびロールに対し、EAP は getPrincipals() および getPrincipals(java.lang.Class) から取得したプリンシパルセットを選択します。使用パターンは次のとおりです。
  • ユーザーアイデンティティー (例: ユーザー名、従業員 ID など) は java.security.Principal オブジェクトとして SubjectPrincipals セットに保存されます。ユーザーアイデンティティーを示す Principal 実装は、プリンシパルの名前に基づいた比較および等価が必要になります。適切な実装は org.jboss.security.SimplePrincipal クラスとして使用可能です。必要な場合は、他の Principal インスタンスを SubjectPrincipals に追加できます。
  • 割り当てられたユーザーロールも Principals セットに保存され、java.security.acl.Group インスタンスを使用して名前付きロールセットにグループ化されます。Group インターフェースは java.security.Principal のサブインスタンスで、PrincipalGroup のコレクションを定義します。
  • 任意の数のロールセットを Subject に割り当てできます。
  • EAP セキュリティーフレームワークは、Roles および CallerPrincipal という名前の 2 つのロールセットを使用します。
    • Roles グループは、Subject が認証されたアプリケーションドメインで知られる名前付きロールの Principal のコレクションです。このロールセットは、現在の呼び出し側が名前付きアプリケーションドメインロールに属するかどうかを確認するために EJB が使用できる EJBContext.isCallerInRole(String) などのメソッドによって使用されます。メソッドパーミッションチェックを実行するセキュリティーインターセプターロジックもこのロールセットを使用します。
    • CallerPrincipal Group は、アプリケーションドメインのユーザーに割り当てられた単一の Principal アイデンティティーで構成されます。EJBContext.getCallerPrincipal() メソッドは CallerPrincipal を使用して、アプリケーションドメインが操作環境アイデンティティーからアプリケーションに適したユーザーアイデンティティーへマップできるようにします。SubjectCallerPrincipal Group がない場合、アプリケーションアイデンティティーは操作環境アイデンティティーと同じになります。

16.2.1. サブジェクト使用パターンのサポート

「カスタムモジュール」に記載されている Subject 使用パターンを正しく簡単に実装するため、適切に Subject を使用できるようにするテンプレートパターンを認証された Subject に追加するログインモジュールが EAP に含まれています。
AbstractServerLoginModule

2 つのログインモジュールでより汎用的なのが org.jboss.security.auth.spi.AbstractServerLoginModule クラスです。

これは、javax.security.auth.spi.LoginModule の実装を提供し、操作環境セキュリティーインフラストラクチャー固有の主要タスクに対して抽象メソッドを提供します。このクラスの主な詳細は、例16.20「AbstractServerLoginModule クラスの一部」を参照してください。JavaDoc のコメントでサブクラスの役割が説明されています。

重要

loginOk インスタンス変数が極めて重要になります。ログインに成功した場合はこれを true に設定する必要があります。ログインに失敗した場合は、ログインメソッドをオーバーライドするサブクラスによって false に設定する必要があります。この変数が適切に設定されないと、コミットメソッドは適切にサブジェクトを更新しません。
フェーズの結果でログを追跡すると、ログインモジュールを制御フラグとチェーンできるようになります。これらの制御フラグは、認証プロセスの一部としてログインモジュールの成功を必要としません。

例16.20 AbstractServerLoginModule クラスの一部

package org.jboss.security.auth.spi;
/**
 *  This class implements the common functionality required for a JAAS
 *  server-side LoginModule and implements the PicketBox standard
 *  Subject usage pattern of storing identities and roles. Subclass
 *  this module to create your own custom LoginModule and override the
 *  login(), getRoleSets(), and getIdentity() methods.
 */
public abstract class AbstractServerLoginModule
    implements javax.security.auth.spi.LoginModule
{
    protected Subject subject;
    protected CallbackHandler callbackHandler;
    protected Map sharedState;
    protected Map options;
    protected Logger log;

    /** Flag indicating if the shared credential should be used */
    protected boolean useFirstPass;
    /** 
     * Flag indicating if the login phase succeeded. Subclasses that
     * override the login method must set this to true on successful
     * completion of login
     */
    protected boolean loginOk;
                
    // ...
    /**
     * Initialize the login module. This stores the subject,
     * callbackHandler and sharedState and options for the login
     * session. Subclasses should override if they need to process
     * their own options. A call to super.initialize(...)  must be
     * made in the case of an override.
     *
     * <p>
     * The options are checked for the  <em>password-stacking</em> parameter.
     * If this is set to "useFirstPass", the login identity will be taken from the
     * <code>javax.security.auth.login.name</code> value of the sharedState map,
     * and the proof of identity from the
     * <code>javax.security.auth.login.password</code> value of the sharedState map.
     *
     * @param subject the Subject to update after a successful login.
     * @param callbackHandler the CallbackHandler that will be used to obtain the
     * the user identity and credentials.
     * @param sharedState a Map shared between all configured login module instances
     * @param options the parameters passed to the login module.
     */
    public void initialize(Subject subject,
                           CallbackHandler callbackHandler,
                           Map sharedState,
                           Map options)
    {
        // ...
    }
    

    /**
     *  Looks for javax.security.auth.login.name and
     *  javax.security.auth.login.password values in the sharedState
     *  map if the useFirstPass option was true and returns true if
     *  they exist. If they do not or are null this method returns
     *  false.  
     *  Note that subclasses that override the login method
     *  must set the loginOk var to true if the login succeeds in
     *  order for the commit phase to populate the Subject. This
     *  implementation sets loginOk to true if the login() method
     *  returns true, otherwise, it sets loginOk to false.
     */
    public boolean login() 
        throws LoginException
    {
        // ...
    }
    
    /**
     *  Overridden by subclasses to return the Principal that
     *  corresponds to the user primary identity.
     */
    abstract protected Principal getIdentity();
                
    /**
     *  Overridden by subclasses to return the Groups that correspond
     *  to the role sets assigned to the user. Subclasses should
     *  create at least a Group named "Roles" that contains the roles
     *  assigned to the user.  A second common group is
     *  "CallerPrincipal," which provides the application identity of
     *  the user rather than the security domain identity.
     * 
     *  @return Group[] containing the sets of roles
     */
    abstract protected Group[] getRoleSets() throws LoginException;
}
Copy to Clipboard Toggle word wrap
UsernamePasswordLoginModule

カスタムログインモジュールに適している 2 つ目の抽象ベースログインモジュールは org.jboss.security.auth.spi.UsernamePasswordLoginModule です。

このログインモジュールは、文字別ベースのユーザー名をユーザーアイデンティティーとし、char[] パスワードを認証クレデンシャルとすることで、カスタムログインモジュールの実装をさらに簡素化します。また、このログインモジュールは、匿名ユーザー (null のユーザー名とパスワードによって示される) をロールを持たないプリンシパルへマップすることをサポートします。クラスの主な詳細は以下を参照してください。JavaDoc のコメントでサブクラスの役割が説明されています。

例16.21 UsernamePasswordLoginModule クラスの一部

package org.jboss.security.auth.spi;

/**
 *  An abstract subclass of AbstractServerLoginModule that imposes a
 *  an identity == String username, credentials == String password
 *  view on the login process. Subclasses override the
 *  getUsersPassword() and getUsersRoles() methods to return the
 *  expected password and roles for the user.
 */
public abstract class UsernamePasswordLoginModule
    extends AbstractServerLoginModule
{
    /** The login identity */
    private Principal identity;
    /** The proof of login identity */
    private char[] credential;
    /** The principal to use when a null username and password are seen */
    private Principal unauthenticatedIdentity;

    /**
     * The message digest algorithm used to hash passwords. If null then
     * plain passwords will be used. */
    private String hashAlgorithm = null;

    /**
     *  The name of the charset/encoding to use when converting the
     * password String to a byte array. Default is the platform's
     * default encoding.
     */
     private String hashCharset = null;

    /** The string encoding format to use. Defaults to base64. */
    private String hashEncoding = null;
                
    // ...
                
    /** 
     *  Override the superclass method to look for an
     *  unauthenticatedIdentity property. This method first invokes
     *  the super version.
     *
     *  @param options,
     *  @option unauthenticatedIdentity: the name of the principal to
     *  assign and authenticate when a null username and password are
     *  seen.
     */
    public void initialize(Subject subject,
                           CallbackHandler callbackHandler,
                           Map sharedState,
                           Map options)
    {
        super.initialize(subject, callbackHandler, sharedState,
                         options);
        // Check for unauthenticatedIdentity option.
        Object option = options.get("unauthenticatedIdentity");
        String name = (String) option;
        if (name != null) {
            unauthenticatedIdentity = new SimplePrincipal(name);
        }
    }
                
    // ...
                
    /**
     *  A hook that allows subclasses to change the validation of the
     *  input password against the expected password. This version
     *  checks that neither inputPassword or expectedPassword are null
     *  and that inputPassword.equals(expectedPassword) is true;
     *
     *  @return true if the inputPassword is valid, false otherwise.
     */
    protected boolean validatePassword(String inputPassword,
                                       String expectedPassword)
    {
        if (inputPassword == null || expectedPassword == null) {
            return false;
        }
        return inputPassword.equals(expectedPassword);
    }
    
    /**
     *  Get the expected password for the current username available
     * via the getUsername() method. This is called from within the
     * login() method after the CallbackHandler has returned the
     * username and candidate password.
     *
     * @return the valid password String
     */
    abstract protected String getUsersPassword()
        throws LoginException;
}
Copy to Clipboard Toggle word wrap
ログインモジュールのサブクラス化

文字別ベースのユーザー名とクレデンシャルが、作成中のカスタムログインモジュールの認証技術で使用できるかどうかを基に AbstractServerLoginModuleUsernamePasswordLoginModule のどちらをサブクラス化するかを決定します。文字別ベースのセマンティックが有効な場合は UsernamePasswordLoginModule をサブクラス化し、その他の場合は AbstractServerLoginModule をサブクラスします。

サブクラス化の手順

カスタムログインモジュールが実行する手順は、選択するベースログインモジュールクラスによって異なります。セキュリティーインフラストラクチャーと統合するカスタムログインモジュールを作成する場合は、EAP セキュリティーマネージャーが想定する形式の認証された Principal 情報がログインモジュールによって提供されるようにするため、最初に AbstractServerLoginModule または UsernamePasswordLoginModule をサブクラス化します。

AbstractServerLoginModule をサブクラス化する場合は、以下をオーバーライドする必要があります。
  • void initialize(Subject, CallbackHandler, Map, Map): 解析するカスタムオプションがある場合。
  • boolean login(): 認証を行うため。ログインに成功した場合は必ず loginOk インスタンス変数を true に設定します。失敗した場合は false に設定します。
  • Principal getIdentity(): log() 手順によって認証されたユーザーの Principal オブジェクトを返します。
  • Group[] getRoleSets(): 最低でも、login() の間に認証された Principal へ割り当てられたロールが含まれる Roles という名前の Group を返します。次に一般的な Group の名前は CallerPrincipal で、セキュリティードメインアイデンティティーではなくユーザーのアプリケーションアイデンティティーを提供します。
UsernamePasswordLoginModule をサブクラス化する場合は、以下をオーバーライドする必要があります。
  • void initialize(Subject, CallbackHandler, Map, Map): 解析するカスタムオプションがある場合。
  • Group[] getRoleSets(): 最低でも、login() の間に認証された Principal へ割り当てられたロールが含まれる Roles という名前の Group を返します。次に一般的な Group の名前は CallerPrincipal で、セキュリティードメインアイデンティティーではなくユーザーのアプリケーションアイデンティティーを提供します。
  • String getUsersPassword(): getUsername() メソッドより使用可能な現在のユーザー名の想定されるパスワードを返します。callbackhandler がユーザー名と候補のパスワードを返した後、getUsersPassword() メソッドは login() 内から呼び出されます。

16.2.2. カスタム LoginModule の例

以下の情報は、UsernamePasswordLoginModule を拡張し、JNDI ルックアップからユーザーのパスワードとロール名を取得するカスタムログインモジュールの例を作成するのに役立ちます。
本項の最後では、password/<username> 形式 (<username> は認証中の現ユーザー) の名前を使用してコンテキストでルックアップを実行するとユーザーのパスワードが返されるカスタムの JNDI コンテキストログインモジュールが作成されます。同様に、roles/<username> 形式のルックアップは要求されたユーザーのロールを返します。JndiUserAndPassLoginModule カスタムログインモジュールのソースコードは 例16.22「JndiUserAndPassLoginModule カスタムログインモジュール」 を参照してください。
これにより JBoss の UsernamePasswordLoginModule が拡張されるため、JndiUserAndPassLoginModule はユーザーのパスワードとロールを JNDI ストアから取得することに注意してください。JndiUserAndPassLoginModule は JAAS LoginModule 操作とやりとりしません。

例16.22 JndiUserAndPassLoginModule カスタムログインモジュール

package org.jboss.book.security.ex2;
                    
import java.security.acl.Group;
import java.util.Map;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.security.auth.Subject;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.login.LoginException;
import org.jboss.logging.Logger;
import org.jboss.security.SimpleGroup;
import org.jboss.security.SimplePrincipal;
import org.jboss.security.auth.spi.UsernamePasswordLoginModule;
/**
 * An example custom login module that obtains passwords and roles for a user from a JNDI lookup.
 * 
 * @author Scott.Stark@jboss.org
 */
public class JndiUserAndPassLoginModule extends UsernamePasswordLoginModule {
  /** The JNDI name to the context that handles the password/username lookup */
  private String userPathPrefix;
  /** The JNDI name to the context that handles the roles/username lookup */
  private String rolesPathPrefix;
  private static Logger log = Logger.getLogger(JndiUserAndPassLoginModule.class);
  /**
   * Override to obtain the userPathPrefix and rolesPathPrefix options.
   */
  @Override
  public void initialize(Subject subject, CallbackHandler callbackHandler, Map sharedState, Map options) {
    super.initialize(subject, callbackHandler, sharedState, options);
    userPathPrefix = (String) options.get("userPathPrefix");
    rolesPathPrefix = (String) options.get("rolesPathPrefix");
  }
  /**
   * Get the roles the current user belongs to by querying the rolesPathPrefix + '/' + super.getUsername() JNDI location.
   */
  @Override
  protected Group[] getRoleSets() throws LoginException {
    try {
      InitialContext ctx = new InitialContext();
      String rolesPath = rolesPathPrefix + '/' + super.getUsername();
      String[] roles = (String[]) ctx.lookup(rolesPath);
      Group[] groups = { new SimpleGroup("Roles") };
      log.info("Getting roles for user=" + super.getUsername());
      for (int r = 0; r < roles.length; r++) {
        SimplePrincipal role = new SimplePrincipal(roles[r]);
        log.info("Found role=" + roles[r]);
        groups[0].addMember(role);
      }
      return groups;
    } catch (NamingException e) {
      log.error("Failed to obtain groups for user=" + super.getUsername(), e);
      throw new LoginException(e.toString(true));
    }
  }
  /**
   * Get the password of the current user by querying the userPathPrefix + '/' + super.getUsername() JNDI location.
   */
  @Override
  protected String getUsersPassword() throws LoginException {
    try {
      InitialContext ctx = new InitialContext();
      String userPath = userPathPrefix + '/' + super.getUsername();
      log.info("Getting password for user=" + super.getUsername());
      String passwd = (String) ctx.lookup(userPath);
      log.info("Found password=" + passwd);
      return passwd;
    } catch (NamingException e) {
      log.error("Failed to obtain password for user=" + super.getUsername(), e);
      throw new LoginException(e.toString(true));
    }
  }
}
Copy to Clipboard Toggle word wrap

例16.23 新規されたカスタムログインモジュールが含まれる security-ex2 セキュリティードメインの定義

/subsystem=security/security-domain=security-ex2/:add
/subsystem=security/security-domain=security-ex2/authentication=classic:add
/subsystem=security/security-domain=security-ex2/authentication=classic/login-module=ex2/:add(\
flag=required,\
code=org.jboss.book.security.ex2.JndiUserAndPassLoginModule,\
module-options=[("userPathPrefix"=>"/security/store/password"),\
("rolesPathPrefix"=>"/security/store/roles")]\
)
Copy to Clipboard Toggle word wrap
ユーザーのサーバー側認証に JndiUserAndPassLoginModule カスタムログインモジュールを使用することは、セキュリティードメイン例のログイン設定によって判断されます。EJB JAR META-INF/jboss-ejb3.xml 記述子はセキュリティードメインを設定します。Web アプリケーションでは、これは WEB-INF/jboss-web.xml ファイルの一部になります。

例16.24 jboss-ejb3.xml の例

<?xml version="1.0"?>
<jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:s="urn:security" version="3.1" impl-version="2.0">
  <assembly-descriptor>
    <s:security>
      <ejb-name>*</ejb-name>
      <s:security-domain>security-ex2</s:security-domain>
    </s:security>
  </assembly-descriptor>
</jboss:ejb-jar>
Copy to Clipboard Toggle word wrap

例16.25 jboss-web.xml example

<?xml version="1.0"?>
<jboss-web>
    <security-domain>security-ex2</security-domain>
</jboss-web>
Copy to Clipboard Toggle word wrap

第17章 アプリケーションのロールベースセキュリティー

17.1. Java Authentication and Authorization Service (JAAS)

Java Authentication and Authorization Service (JAAS) は、ユーザーの認証や承認向けに設計された Java パッケージで構成されるセキュリティー API です。API は標準的なプラグ可能認証モジュール (PAM) フレームワークの Java 実装です。Java Enterprise Edition のアクセス制御アーキテクチャーを拡張し、ユーザーベースの承認をサポートします。
JBoss EAP 6 では JAAS は宣言的ロールベースセキュリティーのみを提供します。宣言的セキュリティーについての詳細は 「宣言型セキュリティー」 を参照してください。
JAAS は Kerberos や LDAP などの基礎となる認証技術から独立しています。アプリケーションを変更せずに、JAAS の設定を変更するだけで基礎となるセキュリティー構造を変更することが可能です。

17.2. Java Authentication and Authorization Service (JAAS)

JBoss EAP 6 のセキュリティーアーキテクチャーは、セキュリティー設定サブシステムと、アプリケーション内の複数の設定ファイルに含まれるアプリケーション固有のセキュリティー設定で構成されます。
ドメイン、サーバーグループ、サーバー固有の設定

サーバーグループ (管理対象ドメイン内) とサーバー (スタンドアローンサーバー内) にはセキュリティードメインの設定が含まれます。セキュリティードメインには、認証、承認、マッピング、監査のモジュールの組み合わせと設定詳細に関する情報が含まれています。アプリケーションは必要なセキュリティードメインを名前で jboss-web.xml に指定します。

アプリケーション固有の設定

アプリケーション固有の設定は次の 4 つのファイルの 1 つ以上に設定されます。

Expand
表17.1 アプリケーション固有の設定ファイル
File説明
ejb-jar.xml
アーカイブの META-INF ディレクトリーにある Enterprise JavaBean (EJB) アプリケーションのデプロイメント記述子です。ejb-jar.xml を使用してロールを指定し、アプリケーションレベルでプリンシパルへマッピングします。また、特定のメソッドやクラスを特定のロールへ制限することも可能です。セキュリティーに関係しない他の EJB 固有の設定に対しても使用できます。
web.xml
Java Enterprise Edition (EE) の Web アプリケーションのデプロイメント記述子です。web.xml を使用して、アプリケーションのリソースおよびトランスポートの制約を宣言します (許可される HTTP リクエストタイプの制限など)。このファイルに簡単な Web ベースの認証を設定することもできます。セキュリティーに関係しない他のアプリケーション固有の設定に使用することもできます。アプリケーションが認証および承認に使用するセキュリティードメインは、jboss-web.xml に定義されます。
jboss-ejb3.xml
ejb-jar.xml 記述子への JBoss 固有の拡張が含まれます。
jboss-web.xml
web.xml 記述子への JBoss 固有の拡張が含まれます。

注記

ejb-jar.xmlweb.xml は Java Enterprise Edition (Java EE) 仕様に定義されています。jboss-ejb3.xmlejb-jar.xml の JBoss 固有の拡張を提供し、jboss-web.xmlweb.xml の JBoss 固有の拡張を提供します。

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

概要

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

警告

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

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

  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>
      Copy to Clipboard Toggle word wrap
      管理コンソールまたは CLI を使用して、追加のセキュリティードメインを必要に応じて設定できます。
    2. アプリケーションの記述子ファイルでのセキュリティードメインの有効化

      セキュリティードメインはアプリケーションの WEB-INF/web.xml ファイルにある <jboss-web> 要素の <security-domain> 子要素に指定されます。次の例は my-domain という名前のセキュリティードメインを設定します。
      <jboss-web>
          <security-domain>my-domain</security-domain>
      </jboss-web>
      Copy to Clipboard Toggle word wrap
      これが 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();
       }
    }
    Copy to Clipboard Toggle word wrap
    その他のコード例は、Red Hat カスタマーポータルより入手できる JBoss EAP 6 Quickstarts バンドルの ejb-security クイックスタートを参照してください。

17.4. サーブレットでのロールベースセキュリティーの使用

サーブレットにセキュリティーを追加するには、各サーブレットを URL パターンへマッピングし、保護する必要のある URL パターン上でセキュリティー制約を作成します。セキュリティー制約は、ロールに対して URL へのアクセスを制限します。認証と承認は WAR の jboss-web.xml に指定されたセキュリティードメインによって処理されます。
要件

サーブレットで ロールベースセキュリティーを使用する前に、アクセスの認証と承認に使用されるセキュリティードメインを JBoss EAP 6 のコンテナーに設定する必要があります。

手順17.2 ロールベースセキュリティーのサーブレットへの追加

  1. サーブレットと URL パターンの間にマッピングを追加します。

    web.xml<servlet-mapping> 要素を使用して各サーブレットを URL パターンへマッピングします。次の例は DisplayOpResult と呼ばれるサーブレットを URL パターン /DisplayOpResult にマッピングします。
    <servlet-mapping>
        <servlet-name>DisplayOpResult</servlet-name>
        <url-pattern>/DisplayOpResult</url-pattern>
    </servlet-mapping>		
    
    
    Copy to Clipboard Toggle word wrap
  2. URL パターンにセキュリティー制約を追加します。

    URL パターンをセキュリティー制約へマッピングするには、<security-constraint> を使用します。次の例は、URL パターン /DisplayOpResult のアクセスを、ロール eap_admin を持つプリンシパルのみに許可します。セキュリティードメインにロールが存在していなければなりません。
    <security-constraint>
    	<display-name>Restrict access to role eap_admin</display-name>
    	<web-resource-collection>
    		<web-resource-name>Restrict access to role eap_admin</web-resource-name>
    		<url-pattern>/DisplayOpResult/*</url-pattern>
    	</web-resource-collection>
    	<auth-constraint>
    		<role-name>eap_admin</role-name>
    	</auth-constraint>	
    </security-constraint>	
    
    <security-role>
      <role-name>eap_admin</role-name>
    </security-role>
    
    
    <login-config>
        <auth-method>BASIC</auth-method>
    </login-config>
    
    
    Copy to Clipboard Toggle word wrap
    認証メソッドを指定する必要があります。BASICFORMDIGESTCLIENT-CERTSPNEGO のいずれかを指定できます。この例では BASIC 認証を使用します。
  3. WAR の jboss-web.xml にセキュリティードメインを指定します。

    セキュリティードメインにサーブレットを接続するため、WAR の jboss-web.xml にセキュリティードメインを追加します。セキュリティードメインにはセキュリティー制約に対してプリンシパルを認証および承認する方法が設定されています。次の例は acme_domain というセキュリティードメインを使用します。
    <jboss-web>
    	...
    	<security-domain>acme_domain</security-domain>
    	...
    </jboss-web>
    
    
    Copy to Clipboard Toggle word wrap

例17.1 ロールベースセキュリティーが設定された web.xml の例

<web-app xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
         version="3.0">

<display-name>Use Role-Based Security In Servlets</display-name>

<welcome-file-list>
  <welcome-file>/index.jsp</welcome-file>
</welcome-file-list>

<servlet-mapping>
    <servlet-name>DisplayOpResult</servlet-name>
    <url-pattern>/DisplayOpResult</url-pattern>
</servlet-mapping>

<security-constraint>
  <display-name>Restrict access to role eap_admin</display-name>
    <web-resource-collection>
      <web-resource-name>Restrict access to role eap_admin</web-resource-name>
      <url-pattern>/DisplayOpResult/*</url-pattern>
      </web-resource-collection>
      <auth-constraint>
        <role-name>eap_admin</role-name>
      </auth-constraint>
    </security-constraint>

    <security-role>
      <role-name>eap_admin</role-name>
    </security-role>

    <login-config>
        <auth-method>BASIC</auth-method>
    </login-config>

</web-app>
Copy to Clipboard Toggle word wrap

17.5. アプリケーションにおけるサードパーティー認証システムの使用

サードパーティーのセキュリティーシステムを JBoss EAP 6 に統合することができます。このようなシステムは通常トークンベースのシステムです。外部システムが認証を実行し、要求ヘッダーよりトークンを Web アプリケーションに返します。このような認証はペリメーター認証と呼ばれることもあります。アプリケーションにペリメーターセキュリティーを設定するには、カスタムの認証バルブを追加します。サードパーティープロバイダーのバルブがある場合はクラスパスに存在するようにし、以下の例とサードパーティー認証モジュールのドキュメントに従うようにしてください。

注記

JBoss EAP 6 では、設定するバルブの場所が変更になりました。context.xml デプロイメント記述子には設定されないようになりました。バルブは直接 jboss-web.xml 記述子に設定されます。context.xml は無視されるようになりました。

例17.2 基本的な認証バルブ

<jboss-web>
  <valve>
    <class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name>
  </valve>
</jboss-web>
Copy to Clipboard Toggle word wrap
このバルブは Kerberos ベースの SSO に使用されます。また、Web アプリケーションに対してサードパーティーのオーセンティケーターを指定する最も単純なパターンを示しています。

例17.3 ヘッダー属性セットを持つカスタムバルブ

<jboss-web>
  <valve>
    <class-name>org.jboss.web.tomcat.security.GenericHeaderAuthenticator</class-name>
    <param>
      <param-name>httpHeaderForSSOAuth</param-name>
      <param-value>sm_ssoid,ct-remote-user,HTTP_OBLIX_UID</param-value>
    </param>
    <param>
      <param-name>sessionCookieForSSOAuth</param-name>
      <param-value>SMSESSION,CTSESSION,ObSSOCookie</param-value>
    </param>
  </valve>
</jboss-web>
Copy to Clipboard Toggle word wrap
この例ではバルブにカスタム属性を設定する方法が示されています。オーセンティケーターはヘッダー ID とセッション鍵の存在を確認し、ユーザー名とパスワードバルブとしてセキュリティー層を操作する JAAS フレームワークへ渡します。ユーザー名とパスワードの処理が可能で、サブジェクトに適切なロールを投入できるカスタムの JAAS ログインモジュールが必要となります。設定された値と一致するヘッダー値がない場合、通常のフォームベース認証のセマンティックが適用されます。
カスタムオーセンティケーターの作成

独自のオーセンティケーターの作成については本書の範囲外となりますが、次の Java コードを例として提供します。

例17.4 GenericHeaderAuthenticator.java

/*
 * JBoss, Home of Professional Open Source.
 * Copyright 2006, Red Hat Middleware LLC, and individual contributors
 * as indicated by the @author tags. See the copyright.txt file in the
 * distribution for a full listing of individual contributors.
 *
 * This is free software; you can redistribute it and/or modify it
 * under the terms of the GNU Lesser General Public License as
 * published by the Free Software Foundation; either version 2.1 of
 * the License, or (at your option) any later version.
 *
 * This software is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 * Lesser General Public License for more details.
 *
 * You should have received a copy of the GNU Lesser General Public
 * License along with this software; if not, write to the Free
 * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
 * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
 */
 
package org.jboss.web.tomcat.security;

import java.io.IOException;
import java.security.Principal;
import java.util.StringTokenizer;

import javax.management.JMException;
import javax.management.ObjectName;
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.apache.catalina.Realm;
import org.apache.catalina.Session;
import org.apache.catalina.authenticator.Constants;
import org.apache.catalina.connector.Request;
import org.apache.catalina.connector.Response;
import org.apache.catalina.deploy.LoginConfig;
import org.jboss.logging.Logger;

import org.jboss.as.web.security.ExtendedFormAuthenticator;

/**
 * JBAS-2283: Provide custom header based authentication support
 * 
 * Header Authenticator that deals with userid from the request header Requires
 * two attributes configured on the Tomcat Service - one for the http header
 * denoting the authenticated identity and the other is the SESSION cookie
 * 
 * @author <a href="mailto:Anil.Saldhana@jboss.org">Anil Saldhana</a>
 * @author <a href="mailto:sguilhen@redhat.com">Stefan Guilhen</a>
 * @version $Revision$
 * @since Sep 11, 2006
 */
public class GenericHeaderAuthenticator extends ExtendedFormAuthenticator {
  protected static Logger log = Logger
      .getLogger(GenericHeaderAuthenticator.class);

  protected boolean trace = log.isTraceEnabled();

  // JBAS-4804: GenericHeaderAuthenticator injection of ssoid and
  // sessioncookie name.
  private String httpHeaderForSSOAuth = null;

  private String sessionCookieForSSOAuth = null;

  /**
   * <p>
   * Obtain the value of the <code>httpHeaderForSSOAuth</code> attribute. This
   * attribute is used to indicate the request header ids that have to be
   * checked in order to retrieve the SSO identity set by a third party
   * security system.
   * </p>
   * 
   * @return a <code>String</code> containing the value of the
   *         <code>httpHeaderForSSOAuth</code> attribute.
   */
  public String getHttpHeaderForSSOAuth() {
    return httpHeaderForSSOAuth;
  }

  /**
   * <p>
   * Set the value of the <code>httpHeaderForSSOAuth</code> attribute. This
   * attribute is used to indicate the request header ids that have to be
   * checked in order to retrieve the SSO identity set by a third party
   * security system.
   * </p>
   * 
   * @param httpHeaderForSSOAuth
   *            a <code>String</code> containing the value of the
   *            <code>httpHeaderForSSOAuth</code> attribute.
   */
  public void setHttpHeaderForSSOAuth(String httpHeaderForSSOAuth) {
    this.httpHeaderForSSOAuth = httpHeaderForSSOAuth;
  }

  /**
   * <p>
   * Obtain the value of the <code>sessionCookieForSSOAuth</code> attribute.
   * This attribute is used to indicate the names of the SSO cookies that may
   * be present in the request object.
   * </p>
   * 
   * @return a <code>String</code> containing the names (separated by a
   *         <code>','</code>) of the SSO cookies that may have been set by a
   *         third party security system in the request.
   */
  public String getSessionCookieForSSOAuth() {
    return sessionCookieForSSOAuth;
  }

  /**
   * <p>
   * Set the value of the <code>sessionCookieForSSOAuth</code> attribute. This
   * attribute is used to indicate the names of the SSO cookies that may be
   * present in the request object.
   * </p>
   * 
   * @param sessionCookieForSSOAuth
   *            a <code>String</code> containing the names (separated by a
   *            <code>','</code>) of the SSO cookies that may have been set by
   *            a third party security system in the request.
   */
  public void setSessionCookieForSSOAuth(String sessionCookieForSSOAuth) {
    this.sessionCookieForSSOAuth = sessionCookieForSSOAuth;
  }

  /**
   * <p>
   * Creates an instance of <code>GenericHeaderAuthenticator</code>.
   * </p>
   */
  public GenericHeaderAuthenticator() {
    super();
  }

  public boolean authenticate(Request request, HttpServletResponse response,
      LoginConfig config) throws IOException {
    log.trace("Authenticating user");

    Principal principal = request.getUserPrincipal();
    if (principal != null) {
      if (trace)
        log.trace("Already authenticated '" + principal.getName() + "'");
      return true;
    }

    Realm realm = context.getRealm();
    Session session = request.getSessionInternal(true);

    String username = getUserId(request);
    String password = getSessionCookie(request);

    // Check if there is sso id as well as sessionkey
    if (username == null || password == null) {
      log.trace("Username is null or password(sessionkey) is null:fallback to form auth");
      return super.authenticate(request, response, config);
    }
    principal = realm.authenticate(username, password);

    if (principal == null) {
      forwardToErrorPage(request, response, config);
      return false;
    }

    session.setNote(Constants.SESS_USERNAME_NOTE, username);
    session.setNote(Constants.SESS_PASSWORD_NOTE, password);
    request.setUserPrincipal(principal);

    register(request, response, principal, HttpServletRequest.FORM_AUTH,
        username, password);
    return true;
  }

  /**
   * Get the username from the request header
   * 
   * @param request
   * @return
   */
  protected String getUserId(Request request) {
    String ssoid = null;
    // We can have a comma-separated ids
    String ids = "";
    try {
      ids = this.getIdentityHeaderId();
    } catch (JMException e) {
      if (trace)
        log.trace("getUserId exception", e);
    }
    if (ids == null || ids.length() == 0)
      throw new IllegalStateException(
          "Http headers configuration in tomcat service missing");

    StringTokenizer st = new StringTokenizer(ids, ",");
    while (st.hasMoreTokens()) {
      ssoid = request.getHeader(st.nextToken());
      if (ssoid != null)
        break;
    }
    if (trace)
      log.trace("SSOID-" + ssoid);
    return ssoid;
  }

  /**
   * Obtain the session cookie from the request
   * 
   * @param request
   * @return
   */
  protected String getSessionCookie(Request request) {
    Cookie[] cookies = request.getCookies();
    log.trace("Cookies:" + cookies);
    int numCookies = cookies != null ? cookies.length : 0;

    // We can have comma-separated ids
    String ids = "";
    try {
      ids = this.getSessionCookieId();
      log.trace("Session Cookie Ids=" + ids);
    } catch (JMException e) {
      if (trace)
        log.trace("checkSessionCookie exception", e);
    }
    if (ids == null || ids.length() == 0)
      throw new IllegalStateException(
          "Session cookies configuration in tomcat service missing");

    StringTokenizer st = new StringTokenizer(ids, ",");
    while (st.hasMoreTokens()) {
      String cookieToken = st.nextToken();
      String val = getCookieValue(cookies, numCookies, cookieToken);
      if (val != null)
        return val;
    }
    if (trace)
      log.trace("Session Cookie not found");
    return null;
  }

  /**
   * Get the configured header identity id in the tomcat service
   * 
   * @return
   * @throws JMException
   */
  protected String getIdentityHeaderId() throws JMException {
    if (this.httpHeaderForSSOAuth != null)
      return this.httpHeaderForSSOAuth;
    return (String) mserver.getAttribute(new ObjectName(
        "jboss.web:service=WebServer"), "HttpHeaderForSSOAuth");
  }

  /**
   * Get the configured session cookie id in the tomcat service
   * 
   * @return
   * @throws JMException
   */
  protected String getSessionCookieId() throws JMException {
    if (this.sessionCookieForSSOAuth != null)
      return this.sessionCookieForSSOAuth;
    return (String) mserver.getAttribute(new ObjectName(
        "jboss.web:service=WebServer"), "SessionCookieForSSOAuth");
  }

  /**
   * Get the value of a cookie if the name matches the token
   * 
   * @param cookies
   *            array of cookies
   * @param numCookies
   *            number of cookies in the array
   * @param token
   *            Key
   * @return value of cookie
   */
  protected String getCookieValue(Cookie[] cookies, int numCookies,
      String token) {
    for (int i = 0; i < numCookies; i++) {
      Cookie cookie = cookies[i];
      log.trace("Matching cookieToken:" + token + " with cookie name="
          + cookie.getName());
      if (token.equals(cookie.getName())) {
        if (trace)
          log.trace("Cookie-" + token + " value=" + cookie.getValue());
        return cookie.getValue();
      }
    }
    return null;
  }
}
Copy to Clipboard Toggle word wrap

第18章 マイグレーション

18.1. アプリケーションセキュリティーの変更設定

基本認証のセキュリティーの設定

以前のバージョンの JBoss EAP では、EAP_HOME/server/SERVER_NAME/conf/ ディレクトリーに置かれたプロパティーファイルはクラスパス上にあり、UsersRolesLoginModule によって簡単に見つかりました。JBoss EAP 6 ではディレクトリー構造が変更されたため、プロパティーファイルをアプリケーション内でパッケージ化し、クラスパスで使用できるようにする必要があります。

重要

サーバーの再起動後に変更が維持されるようにするには、サーバーを停止してからサーバー設定ファイルを編集する必要があります。
基本認証のセキュリティーを設定するには、security-domains 下の新しいセキュリティードメインを standalone/configuration/standalone.xml または domain/configuration/domain.xml サーバー設定ファイルに追加します。
<security-domain name="example">
    <authentication>
        <login-module code="UsersRoles" flag="required">
            <module-option name="usersProperties" 
                    value="${jboss.server.config.dir}/example-users.properties"/>
            <module-option name="rolesProperties" 
                    value="${jboss.server.config.dir}/example-roles.properties"/>
        </login-module>
    </authentication>
</security-domain>
Copy to Clipboard Toggle word wrap
JBoss EAP 6 インスタンスがスタンドアロンサーバーとして実行されている場合、 ${jboss.server.config.dir}EAP_HOME/standalone/configuration/ ディレクトリーを参照します。インスタンスが管理対象ドメインで実行されている場合、 ${jboss.server.config.dir}EAP_HOME/domain/configuration/ ディレクトリーを参照します。
セキュリティードメイン名の変更

JBoss EAP 6 では、セキュリティードメインの名前に接頭辞 java:/jaas/ を使用しません。

  • Web アプリケーションの場合は、jboss-web.xml のセキュリティードメイン設定からこの接頭辞を削除する必要があります。
  • エンタープライズアプリケーションの場合は、jboss-ejb3.xml ファイルのセキュリティードメイン設定からこの接頭辞を削除する必要があります。JBoss EAP 6 では、jboss.xml はこのファイルに置き換えられました。

付録A 参考資料

A.1. 含まれる認証モジュール

以下の認証モジュールが JBoss EAP 6 に含まれます。これらのモジュールの一部は許可と認証を処理します。通常、Role という単語が Code 名に含まれます。
これらのモジュールを設定する場合は、モジュールを参照するために Code 値またはフルネーム (パッケージ修飾) 使用します。

認証モジュール

Expand
表A.1 RealmDirect
コード
RealmDirect
クラス
org.jboss.as.security.RealmDirectLoginModule
説明
セキュリティーレルムと直接インターフェースで接続するログインモジュール実装。このログインモジュールは、バッキングストアとのやりとりがすべてレルムへ委譲されるようにするため、定義の重複や同期化が必要なくなります。リモーティング呼び出しや管理インターフェースに対して使用されます。
Expand
表A.2 RealmDirect モジュールオプション
オプションタイプデフォルト説明
realm
文字列
ApplicationRealm
指定するレルムの名前。
Expand
表A.3 Client
コード
Client
クラス
org.jboss.security.ClientLoginModule
説明
このログインモジュールは、JBoss EAP 6 がクライアントとして動作するときに呼び出し元 ID とクレデンシャルを確立するよう設定されています。サーバー認証に使用されるセキュリティードメインの一部として使用しないでください。
Expand
表A.4 Client モジュールオプション
オプションタイプデフォルト説明
multi-threaded
true または false
false
各スレッドが独自のプリンシパルとクレデンシャルストレージを持つ場合は、true に設定します。VM 内のすべてのスレッドが同じ ID とクレデンシャルを共有するよう指定する場合は false に設定します。
password-stacking
useFirstPass または false
false
このログインモジュールが ID として使用する LoginContext に格納された情報を探すよう指定する場合は、LoginContext に設定します。このオプションは、他のログインモジュールをスタックする場合に使用できます。
restore-login-identity
true または false
false
login() メソッドの先頭に示された ID とクレデンシャルを logout() メソッドの呼び出し後に復元する必要がある場合は true に設定します。
Expand
表A.5 Remoting
コード
Remoting
クラス
org.jboss.as.security.remoting.RemotingLoginModule
説明
このログインモジュールは、現在認証中の要求が Remoting 接続上で受信された要求であるかどうかを確認するために使用されます。Remoting 接続上で受信された要求である場合、Remoting 認証処理中に作成された ID が使用され、現在の要求に関連付けされます。要求が Remoting 接続上で受信されなかった場合は、このモジュールは何もせず、JAAS ベースのログインは次のモジュールへ続行されます。
Expand
表A.6 Remoting モジュールオプション
オプションタイプデフォルト説明
password-stacking
useFirstPass または false
false
このログインモジュールが ID を見つけるため LoginContext に格納された情報を最初に探すことを示す useFirstPass の値。このオプションは、他のログインモジュールをこのモジュールとスタックする場合に使用できます。
principalClass
完全修飾クラス名
なし
プリンシパル名に String 引数を取るコンストラクターを含む Principal 実装クラス。
unauthenticatedIdentity
プリンシパル名。
なし
認証情報を含まない要求に割り当てられるプリンシパル名を定義します。これにより、保護されていないサーブレットは特定のロールを必要としない EJB でメソッドを呼び出すことができるようになります。このようなプリンシパルには関連付けられたロールがなく、セキュアでない JEB または unchecked permission 制約に関連付けられた EJB メソッドのみにアクセスできます。
Expand
表A.7 Certificate
コード
Certificate
クラス
org.jboss.security.auth.spi.BaseCertLoginModule
説明
このログインモジュールは、X509 Certificates に基づいてユーザーを認証するよう設計されています。この使用例は、Web アプリケーションの CLIENT-CERT 認証です。
Expand
表A.8 Certificate モジュールオプション
オプションタイプデフォルト説明
securityDomain
文字列
other
信頼済み証明書を保持するトラストストア用 JSSE 設定を持つセキュリティードメインの名前。
verifier
class
なし
ログイン証明書の検証に使用する org.jboss.security.auth.certs.X509CertificateVerifier のクラス名。
Expand
表A.9 CertificateRoles
コード
CertificateRoles
クラス
org.jboss.security.auth.spi.CertRolesLoginModule
説明
このログインモジュールは、Certificate ログインモジュールを拡張して、プロパティーファイルからロールマッピング機能を追加します。同じすべてのオプションを Certificate ログインモジュールとして取得し、次のオプションを追加します。
Expand
表A.10 CertificateRoles モジュールオプション
オプションタイプデフォルト説明
rolesProperties
文字列
roles.properties
各ユーザーに割り当てるロールを含むリソースまたはファイルの名前。ロールプロパティーファイルの形式は username=role1,role2 である必要があります。username は証明書の DN で、= (等記号) やスペースをすべてエスケープします。正しい形式を用いた例は次のとおりです。
CN\=unit-tests-client,\ OU\=Red\ Hat\ Inc.,\ O\=Red\ Hat\ Inc.,\ ST\=North\ Carolina,\ C\=US
Copy to Clipboard Toggle word wrap
defaultRolesProperties
文字列
defaultRoles.properties
rolesProperties ファイルが見つからない場合に使用するリソースまたはファイルの名前。
roleGroupSeparator
単一の文字。
. (ピリオド 1 つ)
rolesProperties ファイルでどの文字をロールグループセパレーターとして使用するか。
Expand
表A.11 Database
コードDatabase
クラス
org.jboss.security.auth.spi.DatabaseServerLoginModule
説明
認証とロールマッピングをサポートする JDBC ベースのログインモジュール。これは、次の定義を使用して、2 つの論理テーブルに基づきます。
  • Principals: PrincipalID (text), Password (text)
  • Roles: PrincipalID (text), Role (text), RoleGroup (text)
Expand
表A.12 Database モジュールオプション
オプションタイプデフォルト説明
digestCallback
完全修飾クラス名
なし
入力パスワードをハッシュ化するソルト値などのプレまたはポストダイジェストコンテンツを含む DigestCallback 実装のクラス名。hashAlgorithm が指定された場合にのみ使用されます。
dsJndiName
JNDI リソース
java:/DefaultDS
認証情報を保持する JNDI リソースの名前。このオプションは必須です。
hashAlgorithm
String
プレーンパスワードを使用
パスワードをハッシュ化するのに使用されるメッセージダイジェストアルゴリズム。サポートされるアルゴリズムは Java セキュリティープロバイダーに依存しますが、MD5SHA-1、および SHA-256 がサポートされます。
hashCharset
String
プラットフォームのデフォルトのエンコーディング
パスワードの文字列をバイトアレイに変換するときに使用する文字セット/エンコーディングの名前。これにはサポートされるすべての Java 文字セット名が含まれます。
hashEncoding
String
Base64
使用する文字列エンコーディング形式。
ignorePasswordCase
boolean
false
パスワードの比較で大文字と小文字の区別を無視するかどうかを示すフラグ。
inputValidator
完全修飾クラス名
なし
クライアントによって提供されるユーザー名およびパスワードを検証するために使用される InputValidator 実装のインスタンス。
principalsQuery
準備済み SQL ステートメント
select Password from Principals where PrincipalID=?
プリンシパルに関する情報を取得するための準備済み SQL クエリー。
rolesQuery
準備済み SQL ステートメント
なし
ロールの情報を取得するための準備済み SQL クエリー。select Role, RoleGroup from Roles where PrincipalID=? と同等である必要があります。ここで、Role はロール名で、RoleGroup 列の値は常に R が大文字である Roles または CallerPrincipal である必要があります。
storeDigestCallback
完全修飾クラス名
なし
ストア/予想されるパスワードをハッシュ化するソルト値などのプレまたはポストダイジェストコンテンツを含む DigestCallback 実装のクラス名。hashStorePassword または hashUserPassword が true で、hashAlgorithm が指定された場合のみ使用されます。
suspendResume
boolean
true
データベース操作中に既存の JTA トランザクションを一時停止するかどうか。
throwValidatorError
boolean
false
検証エラーがクライアントへ公開されるべきかどうかを示すフラグ。
transactionManagerJndiName
JNDI リソース
java:/TransactionManager
ログインモジュールによって使用されるトランザクションマネージャーの JNDI 名。
Expand
表A.13 DatabaseCertificate
コード
DatabaseCertificate
クラス
org.jboss.security.auth.spi.DatabaseCertLoginModule
説明
このログインモジュールは、Certificate ログインモジュールを拡張して、データベーステーブルからロールマッピング機能を追加します。同じオプションと次の追加オプションが存在します。
Expand
表A.14 DatabaseCertificate モジュールオプション
オプションタイプデフォルト説明
dsJndiName
JNDI リソース
java:/DefaultDS
認証情報を保持する JNDI リソースの名前。このオプションは必須です。
rolesQuery
準備済み SQL ステートメント
select Role,RoleGroup from Roles where PrincipalID=?
ロールをマップするために実行される SQL 準備済みステートメント。これは、select Role, RoleGroup from Roles where PrincipalID=? と同等である必要があります。Role はロール名で、RoleGroup 列の値は常に R が大文字である Roles または CallerPrincipal である必要があります。
suspendResume
true または false
true
データベース操作中に既存の JTA トランザクションを一時停止するかどうか。
Expand
表A.15 Identity
コード
Identity
クラス
org.jboss.security.auth.spi.IdentityLoginModule
説明
モジュールオプションで指定されたプリンシパルをモジュールに対して認証されたサブジェクトと関連付けます。使用される Principal クラスのタイプは org.jboss.security.SimplePrincipal です。プリンシパルオプションが指定されない場合は、名前が guest のプリンシパルが使用されます。
Expand
表A.16 Identity モジュールオプション
オプションタイプデフォルト説明
principal
String
guest
プリンシパルに使用する名前。
roles
カンマ区切りの文字列リスト
なし
サブジェクトに割り当てられるロールのカンマ区切りリスト。
Expand
表A.17 Ldap
コード
Ldap
クラス
org.jboss.security.auth.spi.LdapLoginModule
説明
ユーザー名とパスワードが、JNDI LDAP プロバイダーを使用してアクセスできる LDAP サーバーに格納された場合に、LDAP サーバーに対して認証します。多くのオプションは、LDAP プロバイダーまたは環境によって決定されるため、必須ではありません。
Expand
表A.18 Ldap モジュールオプション
オプションタイプデフォルト説明
java.naming.factory.initial
クラス名
com.sun.jndi.ldap.LdapCtxFactory
InitialContextFactory 実装クラス名。
java.naming.provider.url
ldap:// URL
java.naming.security.protocol の値が SSL の場合は ldap://localhost:636 で、その他の場合は ldap://localhost:389
LDAP サーバーの URL。
java.naming.security.authentication
nonesimple、または SASL メカニズムの名前。
simple
LDAP サーバーにバインドするために使用するセキュリティーレベル。
java.naming.security.protocol
トランスポートプロトコル
指定されない場合は、プロバイダーによって決定されます。
SSL などの、セキュアアクセスに使用するトランスポートプロトコル。
java.naming.security.principal
文字列
なし
サービスに対する呼び出し元を認証するプリンシパルの名前。これは、以下に示された他のプロパティーから構築されます。
java.naming.security.credentials
クレデンシャルタイプ
なし
認証スキームにより使用されるクレデンシャルのタイプ。一部の例には、ハッシュ化されたパスワード、クリアテキストパスワード、キー、または証明書が含まれます。このプロパティーが指定されない場合は、動作がサービスプロバイダーにより決定されます。
principalDNPrefix
文字列
ユーザー DN を形成するユーザー名に追加される接頭辞。ユーザーにユーザー名の指定を要求したり、principalDNPrefix および principalDNSuffix を使用して完全修飾 DN を構築したりできます。
principalDNSuffix
文字列
ユーザー DN を形成するユーザー名に追加されるサフィックス。ユーザーにユーザー名の指定を要求したり、principalDNPrefix および principalDNSuffix を使用して完全修飾 DN を構築したりできます。
useObjectCredential
true または false
false
JAAS PasswordCallback を使用した char[] パスワードではなく Callback の org.jboss.security.auth.callback.ObjectCallback タイプを使用した不透明なオブジェクトとしてクレデンシャルを取得するかどうか。これにより、char[] クレデンシャル情報を LDAP サーバーに渡すことができます。
rolesCtxDN
完全修飾 DN
なし
ユーザーロールを検索するコンテキストの完全修飾 DN。
userRolesCtxDNAttributeName
属性
なし
ユーザーロールを検索するコンテキストの DN を含むユーザーオブジェクトの属性。これは、rolesCtxDN と異なるため、ユーザーのロールを検索するコンテキストは各ユーザーに対して一意になることがあります。
roleAttributeID
属性
roles
ユーザーロールを含む属性の名前。
roleAttributeIsDN
true または false
false
roleAttributeID にロールオブジェクトの完全修飾 DN が含まれるかどうか。false の場合は、コンテキスト名の roleNameAttributeId 属性の値からロール名が取得されます。Microsoft Active Directory などの特定のディレクトリースキーマでは、この属性を true に設定する必要があります。
roleNameAttributeID
属性
name
ロール名を含む roleCtxDN コンテキスト内の属性の名前。roleAttributeIsDN プロパティーが true に設定された場合、このプロパティーはロールオブジェクトの名前属性を見つけるために使用されます。
uidAttributeID
属性
uid
ユーザー ID に対応する UserRolesAttributeDN の属性の名前。これは、ユーザーロールを見つけるために使用されます。
matchOnUserDN
true または false
false
ユーザーロールの検索でユーザーの完全識別 DN またはユーザー名のみに一致するかどうか。true の場合、完全 userDN は一致する値として使用されます。false の場合は、ユーザー名のみが uidAttributeName 属性に対して一致する値として使用されます。
allowEmptyPasswords
true または false
false
空白のパスワードを許可するかどうか。ほとんどの LDAP サーバーでは、空白のパスワードが匿名ログイン試行として扱われます。空のパスワードを拒否するには、これを false に設定します。
Expand
表A.19 LdapExtended
コード
LdapExtended
クラス
org.jboss.security.auth.spi.LdapExtLoginModule
説明
検索を使用してバインドユーザーと関連するロールを見つける別の LDAP ログインモジュール実装。ロールクエリーは再帰的に DN に従い、階層ロール構造をナビゲートします。同じ java.naming オプションを Ldap モジュールとして使用し、Ldap モジュールの他のオプションの代わりに次のオプションを使用します。
認証は 2 つの手順で行われます。
  1. LDAP サーバーに対する初期バインドは、bindDN および bindCredential オプションを使用して行われます。bindDN は、baseCtxDN および rolesCtxDN ツリーの両方でユーザーとロールを検索できるユーザーです。認証するユーザー DN は、baseFilter 属性で指定されたフィルターを使用して問い合わされます。
  2. 結果となるユーザー DN は、InitialLdapContext 環境 Context.SECURITY_PRINCIPAL としてユーザー DN を使用して LDAP サーバーにバインドすることにより認証されます。Context.SECURITY_CREDENTIALS プロパティーは、コールバックハンドラーにより取得された String パスワードに設定されます。
Expand
表A.20 LdapExtended モジュールオプション
オプションタイプデフォルト説明
baseCtxDN
完全修飾 DN
なし
ユーザー検索を開始する最上位コンテキストの固定 DN。
bindCredential
文字列、オプションで暗号化
なし
詳細は「bindCredential モジュールオプション」を参照してください。
bindDN
完全修飾 DN
なし
ユーザーおよびロールクエリーのために LDAP サーバーに対してバインドするために使用される DN。この DN は baseCtxDN および rolesCtxDN の値に対する読み取りおよび検索パーミッションを必要とします。
baseFilter
LDAP フィルター文字列
なし
認証するユーザーのコンテキストを見つけるために使用される検索フィルター。入力ユーザー名またはログインモジュールコールバックから取得された userDN が、{0} 式が使用されたフィルターに置換されます。検索フィルターの一般的な例は (uid={0}) です。
rolesCtxDN
完全修飾 DN
なし
ユーザーロールを検索するコンテキストの固定 DN。これは、実際のロールが存在する DN ではなく、ユーザーロールを含むオブジェクトが存在する DN です。たとえば、Microsoft Active Directory サーバーでは、これは、ユーザーアカウントが存在する DN です。
roleFilter
LDAP フィルター文字列
なし
認証済みユーザーと関連付けられたロールを検索するために使用される検索フィルター。入力ユーザー名またはログインモジュールコールバックから取得された userDN{0} 式が使用されたフィルターに置換されます。認証済み userDN は、{1} が使用されたフィルターに置換されます。入力ユーザー名に一致する検索フィルター例は、(member={0}) です。認証済み userDN に一致する他の例は (member={1}) です。
roleAttributeIsDN
true または false
false
roleAttributeID にロールオブジェクトの完全修飾 DN が含まれるかどうか。false の場合は、コンテキスト名の roleNameAttributeId 属性の値からロール名が取得されます。Microsoft Active Directory などの特定のディレクトリースキーマでは、この属性を true に設定する必要があります。
defaultRole
ロール名
なし
認証された全ユーザーに対して含まれるロール
parseRoleNameFromDN
true または false
false
クエリによって返された DN に roleNameAttributeID が含まれるかどうかを示すフラグ。true に設定された場合、DN は roleNameATtributeID に対してチェックされます。false に設定された場合、DN は roleNameATtributeID に対してチェックされません。このフラグは LDAP クエリのパフォーマンスを向上できます。
parseUsername
true または false
false
DN がユーザー名に対して解析されるかどうかを示すフラグ。true に設定された場合、 DN はユーザー名に対して解析されます。false に設定された場合、 DN はユーザー名に対して解析されません。このオプションは usernameBeginString および usernameEndString と共に使用されます。
usernameBeginString
文字列
なし
ユーザー名を公開するため、DN の最初から削除される文字列を定義します。このオプションは usernameEndString と共に使用されます。
usernameEndString
文字列
なし
ユーザー名を公開するため、DN の最後から削除される文字列を定義します。このオプションは usernameBeginString と共に使用されます。
roleNameAttributeID
属性
name
ロール名を含む roleCtxDN コンテキスト内の属性の名前。roleAttributeIsDN プロパティーが true に設定された場合、このプロパティーはロールオブジェクトの名前属性を見つけるために使用されます。
distinguishedNameAttribute
属性
distinguishedName
ユーザーの DN を含むユーザーエントリーの属性の名前。これは、ユーザー自身の DN に正しいユーザーマッピングを妨げる特殊文字 (バックスラッシュなど) が含まれる場合に、必要になることがあります。属性が存在しない場合は、エントリーの DN が使用されます。
roleRecursion
整数
0
ロール検索が一致するコンテキストで行われる再帰のレベル数。再帰を無効にするには、これを 0 に設定します。
searchTimeLimit
整数
10000 (10 秒)
ユーザーまたはロール検索のタイムアウト (ミリ秒単位)。
searchScope
OBJECT_SCOPE, ONELEVEL_SCOPE, SUBTREE_SCOPE のいずれか。
SUBTREE_SCOPE
使用する検索範囲。
allowEmptyPasswords
true または false
false
空白のパスワードを許可するかどうか。ほとんどの LDAP サーバーでは、空白のパスワードが匿名ログイン試行として扱われます。空のパスワードを拒否するには、これを false に設定します。
referralUserAttributeIDToCheck
属性
なし
リファーラル (referral) を使用しない場合はこのオプションを無視してもかまいません。リファーラルを使用し、ロールオブジェクトがリファーラル内部にある場合、このオプションは特定のロール (例: member) に対して定義されたユーザーが含まれる属性名を示します。ユーザーはこの属性名の内容に対してチェックされます。このオプションが設定されていないとチェックは常に失敗するため、ロールオブジェクトはリファーラルツリーに保存できません。
Expand
表A.21 RoleMapping
コード
RoleMapping
クラス
org.jboss.security.auth.spi.RoleMappingLoginModule
説明
認証プロセスの結果であるロールを宣言ロールに対してマップします。このモジュールは、セキュリティードメインに追加する場合に optional とフラグ付けする必要があります。
Expand
表A.22 RoleMapping モジュールオプション
オプションタイプデフォルト説明
rolesProperties
プロパティーファイルまたはリソースの完全修飾ファイルパスまたは完全修飾ファイル名。
none
ロールを置換ロールに対してマップするプロパティーファイルまたはリソースの完全修飾ファイルパスまたはファイル名。形式は original_role=role1,role2,role3 になります。
replaceRole
true または false
false
現在のロールを追加するか、現在のロールをマップされたロールに置き換えるか。true に設定された場合は、置き換えられます。

注記

rolesProperties モジュールオプションは RoleMapping に必要です。
Expand
表A.23 RunAs
コード
RunAs
クラス
org.jboss.security.auth.spi.RunAsLoginModule
説明
run as ロールを、認証のログイン段階の間スタックにプッシュし、コミットまたはアボート段階でスタックから run as ロールをポップするヘルパーモジュール。このログインモジュールは、セキュアな EJB にアクセスするログインモジュールなどの、認証を実行するためにセキュアなリソースにアクセスする必要がある他のログインモジュール用ロールを提供します。run as ロールを確立する必要があるログインモジュールの前に、RunAsLoginModule を設定する必要があります。
Expand
表A.24 RunAs オプション
オプションタイプデフォルト説明
roleName
ロール名
nobody
ログイン段階で run as ロールとして使用するロールの名前。
principalName
プリンシパル名
nobody
ログインフェーズ中に run as プリンシパルとして使用するプリンシパルの名前。指定がない場合、デフォルトの nobody が使用されます。
principalClass
完全修飾クラス名
なし
プリンシパル名に String 引数を取るコンストラクターを含む Principal 実装クラス。
Expand
表A.25 Simple
コード
Simple
クラス
org.jboss.security.auth.spi.SimpleServerLoginModule
説明
テスト目的でセキュリティーを素早くセットアップするモジュール。次の単純なアルゴリズムが実装されます。
  • パスワードが null である場合、ユーザーを認証し、guest の ID と guest のロールを割り当てます。
  • パスワードが null でなくユーザーと同じ場合、ユーザー名と同じ ID、admin ロールおよび guest ロールを割り当てます。
  • それ以外の場合は認証に失敗します。
Simple モジュールオプション

Simpleモジュールにはオプションがありません。

Expand
表A.26 ConfiguredIdentity
コード
ConfiguredIdentity
クラス
org.picketbox.datasource.security.ConfiguredIdentityLoginModule
説明
モジュールオプションで指定されたプリンシパルをモジュールに対して認証されたサブジェクトに関連付けます。使用される Principal クラスのタイプは org.jboss.security.SimplePrincipal です。
Expand
表A.27 ConfiguredIdentity モジュールオプション
オプションタイプデフォルト説明
username
文字列なし認証のユーザー名
password
暗号化文字列""
認証に使用するパスワード。パスワードを暗号化するには、コマンドラインで直接モジュールを使用します。
java org.picketbox.datasource.security.SecureIdentityLoginModule password_to_encrypt
Copy to Clipboard Toggle word wrap
このコマンドの結果をモジュールオプションの値フィールドに貼り付けます。デフォルトの値は空の文字列です。
principal
プリンシパルの名前
none
モジュールに対して認証されるサブジェクトに関連付けられるプリンシパル。
Expand
表A.28 SecureIdentity
コード
SecureIdentity
クラス
org.picketbox.datasource.security.SecureIdentityLoginModule
説明
このモジュールは、レガシー対応のために提供されます。このモジュールを使用すると、パスワードを暗号化し、暗号化されたパスワードを最適なプリンシパルで使用します。アプリケーションが SecureIdentity を使用する場合は、パスワード vault メカニズムを代わりに使用することを検討してください。
Expand
表A.29 SecureIdentity モジュールオプション
オプションタイプデフォルト説明
username
文字列なし認証のユーザー名
password
暗号化文字列""
認証に使用するパスワード。パスワードを暗号化するには、コマンドラインで直接モジュールを使用します。
java org.picketbox.datasource.security.SecureIdentityLoginModule password_to_encrypt
Copy to Clipboard Toggle word wrap
このコマンドの結果をモジュールオプションの値フィールドに貼り付けます。デフォルトの値は空の文字列です。
managedConnectionFactoryName
JCA リソースなし
データソースの JCA 接続ファクトリーの名前。
Expand
表A.30 PropertiesUsers
コード
PropertiesUsers
クラス
org.jboss.security.auth.spi.PropertiesUsersLoginModule
説明
認証用ユーザー名およびパスワードを格納するプロパティーファイルを使用します。認証 (ロールマッピング) は提供されません。このモジュールは、テスト向けのみに限定されます。
Expand
表A.31 SimpleUsers
コード
SimpleUsers
クラス
org.jboss.security.auth.spi.SimpleUsersLoginModule
説明
このログインモジュールは module-option を使用してユーザー名とクリアテキストパスワードを保存します。module-optionname および value 属性はユーザー名とパスワードを指定します。テストの目的でのみ含まれているため、本番環境
Expand
表A.32 LdapUsers
コード
LdapUsers
クラス
org.jboss.security.auth.spi.LdapUsersLoginModule
説明
LdapUsers モジュールは ExtendedLDAP および AdvancedLdap モジュールが導入されたため廃止になりました。
Expand
表A.33 Kerberos
コード
Kerberos
クラス
com.sun.security.auth.module.Krb5LoginModule。IBM JDK でのクラス名は com.ibm.security.auth.module.Krb5LoginModule
説明
GSSAPI を使用して Kerberos ログイン認証を実行します。このモジュールは、Sun Microsystems により提供された API のセキュリティーフレームワークの一部です。詳細については、http://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html を参照してください。このモジュールは、認証とロールのマッピングを処理する別のモジュールと組み合わせる必要があります。
Expand
表A.34 Kerberos モジュールオプション
オプションタイプデフォルト説明
storekey
true または false
false
KerberosKey をサブジェクトのプライベートクレデンシャルに追加するかどうか。
doNotPrompt
true または false
false
true に設定された場合、ユーザーはパスワードを要求されません。
useTicketCache
true または false のブール値
.
false
true の場合、TGT はチケットキャッシュから取得されます。false の場合、チケットキャッシュは使用されません。
ticketcache
Kerberos チケットキャッシュを表すファイルまたはリソース。
デフォルトは使用するオペレーティングシステムによって異なります。
  • Red Hat Enterprise Linux / Solaris の場合: /tmp/krb5cc_uid (オペレーティングシステムの UID 数値を使用します)。
  • Microsoft Windows Server の場合: Local Security Authority (LSA) API を使用してチケットキャッシュを見つけます。
チケットキャッシュの場所。
useKeyTab
true または false
falseキーテーブルファイルからプリンシパルのキーを取得するかどうか。
keytab
Kerberos keytab を表すファイルまたはリソース。
オペレーティングシステムの Kerberos 設定ファイルの場所または /home/user/krb5.keytab
キーテーブルファイルの場所。
principal
文字列なし
プリンシパルの名前。これは、host/testserver.acme.com などの単純なユーザー名またはサービス名のいずれかになります。これは、キーテーブルからプリンシパルを取得する代わり、またはキーテーブルに複数のプリンシパルが含まれる場合に使用します。
useFirstPass
true または false
false
javax.security.auth.login.name および javax.security.auth.login.password をキーとして使用して、モジュールの共有状態からユーザー名とパスワードを取得するかどうか。認証が失敗した場合、再試行は行われません。
tryFirstPass
true または false
false
useFirstPass と同じです。ただし、認証が失敗した場合、モジュールは CallbackHandler を使用して新しいユーザー名とパスワードを取得します。2 番目の認証が失敗した場合、失敗は読み出し元アプリケーションに報告されます。
storePass
true または false
false
モジュールの共有状態でユーザー名とパスワードを格納するかどうか。これは、キーがすでに共有状態である場合、または認証に失敗した場合は、行われません。
clearPass
true または false
false
これを true に設定して、認証段階が完了した後に共有状態からユーザー名とパスワードを削除します。
Expand
表A.35 SPNEGO
コード
SPNEGO
クラス
org.jboss.security.negotiation.spnego.SPNEGOLoginModule
説明
Microsoft Active Directory サーバーまたは SPNEGO をサポートする他の環境に対して SPNEGO 認証を許可します。SPNEGO は Kerberos クレデンシャルを持つこともできます。このモジュールは、認証とロールのマッピングを処理する別のモジュールと組み合わせる必要があります。
Expand
表A.36 SPNEGO モジュールオプション
オプションタイプデフォルト説明
serverSecurityDomain
string
null
Kerberos ログインモジュールを介してサーバーサービスの ID を読み出すために使用されるドメインを定義します。このプロパティーは必ず設定する必要があります。
removeRealmFromPrincipal
boolean
false
処理を続行する前に Kerberos レルムをプリンシパルから削除する必要があることを指定します。
usernamePasswordDomain
string
null
Kerberos が失敗したときにフェールオーバーログインとして使用する必要がある設定内の別のセキュリティードメインを指定します。
Expand
表A.37 AdvancedLdap
コードAdvancedLdap
クラス
org.jboss.security.negotiation.AdvancedLdapLoginModule
説明
SASL や JAAS セキュリティードメインの使用など、追加機能を提供するモジュール。
Expand
表A.38 AdvancedLdap モジュールオプション
オプションタイプデフォルト説明
bindAuthentication
文字列
なし
ディレクトリーサーバーへのバインディングに使用する SASL 認証のタイプ。
java.naming.provider.url
string
java.naming.security.protocol の値が SSL の場合は ldap://localhost:686 で、その他の場合は ldap://localhost:389
ディレクトリーサーバーの URI。
baseCtxDN
完全修飾 DN
なし
検索の基盤として使用する識別名。
baseFilter
LDAP 検索フィルターを表す文字列。
なし
検索結果を絞り込むために使用するフィルター。
roleAttributeID
LDAP 属性を表す文字列値。
なし
承認ロールの名前が含まれる LDAP 属性。
roleAttributeIsDN
true または false
false
ロール属性が識別名 (DN) であるかどうか。
roleNameAttributeID
LDAP 属性を表す文字列。
なし
実際のロール属性が含まれる RoleAttributeId 内に格納された属性。
recurseRoles
true または false
false
ロールに対して RoleAttributeId を再帰的に検索するかどうか。
referralUserAttributeIDToCheck
属性
なし
リファーラル (referral) を使用しない場合はこのオプションを無視してもかまいません。リファーラルを使用し、ロールオブジェクトがリファーラル内部にある場合、このオプションは特定のロール (例: member) に対して定義されたユーザーが含まれる属性名を示します。ユーザーはこの属性名の内容に対してチェックされます。このオプションが設定されていないとチェックは常に失敗するため、ロールオブジェクトはリファーラルツリーに保存できません。
Expand
表A.39 AdvancedADLdap
コードAdvancedADLdap
クラス
org.jboss.security.negotiation.AdvancedADLoginModule
説明
このモジュールは AdvancedLdap ログインモジュールを拡張し、Microsoft Active Directory に関連する追加パラメーターを追加します。
Expand
表A.40 UsersRoles
コードUsersRoles
クラス
org.jboss.security.auth.spi.UsersRolesLoginModul
説明
2 つの異なるプロパティーファイルに格納された複数のユーザーおよびユーザーロールをサポートする簡単なログインモジュール。
Expand
表A.41 UsersRoles モジュールオプション
オプションタイプデフォルト説明
usersProperties
ファイルまたはリソースへのパス。
users.properties
ユーザーからパスワードへのマッピングが含まれるファイルまたはリソース。ファイルの形式は username=password になります。
rolesProperties
ファイルまたはリソースへのパス。
roles.properties
ユーザーからロールへのマッピングが含まれるファイルまたはリソース。ファイルの形式は username=role1,role2,role3 になります。
password-stacking
useFirstPass または false
false
このログインモジュールが ID を見つけるため LoginContext に格納された情報を最初に探すことを示す useFirstPass の値。このオプションは、他のログインモジュールをこのモジュールとスタックする場合に使用できます。
hashAlgorithm
パスワードをハッシュ化するアルゴリズムを表す文字列。
none
パスワードをハッシュ化するために使用する java.security.MessageDigest アルゴリズムの名前。デフォルト値はないため、ハッシュを有効にするためにこのオプションを明示的に設定する必要があります。hashAlgorithm が指定された場合は、inputPassword 引数として UsernamePasswordLoginModule.validatePassword に渡す前に CallbackHandler から取得されたクリアテキストパスワードがハッシュ化されます。users.properties ファイルに格納されたパスワードも、同様にハッシュ化する必要があります。
hashEncoding
base64 または hex
base64
hashAlgorithm も設定されている場合、ハッシュ化されたパスワードの文字列形式。
hashCharset
文字列
コンテナのランタイム環境に設定されるデフォルトのエンコーディング。
クリアテキストのパスワードをバイトアレイに変換するために使用されるエンコーディング。
unauthenticatedIdentity
プリンシパル名
なし
認証情報を含まない要求に割り当てるプリンシパル名を定義します。これにより、保護されていないサーブレットは特定のロールを必要としない EJB でメソッドを呼び出すことができるようになります。このようなプリンシパルは関連付けられたロールを持たず、unchecked permission 制約に関連付けられたセキュアでない EJB または EJB メソッドにのみアクセスできます。
カスタム認証モジュール

認証モジュールは、javax.security.auth.spi.LoginModule の実装です。カスタム認証モジュールの作成の詳細については、API ドキュメンテーションを参照してください。

A.2. 含まれる承認モジュール

以下のモジュールは承認サービスを提供します。
Expand
コードクラス
DenyAllorg.jboss.security.authorization.modules.AllDenyAuthorizationModule
PermitAllorg.jboss.security.authorization.modules.AllPermitAuthorizationModule
Delegatingorg.jboss.security.authorization.modules.DelegatingAuthorizationModule
Weborg.jboss.security.authorization.modules.web.WebAuthorizationModule
JACCorg.jboss.security.authorization.modules.JACCAuthorizationModule
XACMLorg.jboss.security.authorization.modules.XACMLAuthorizationModule
AllDenyAuthorizationModule

認証リクエストを常に拒否する単純な承認モジュールです。設定オプションはありません。

AllPermitAuthorizationModule

認証リクエストを常に許可する単純な承認モジュールです。設定オプションはありません。

DelegatingAuthorizationModule

意思決定を設定済みの delegate へ移譲するデフォルトの認証モジュールです。

WebAuthorizationModule

デフォルトの Tomcat 承認ロジック (permit all) を持つデフォルトの Web 認証モジュールです。

JACCAuthorizationModule

このモジュールは 2 つの delegate を使用して JACC セマンティックを強制します (Web コンテナ承認リクエストの WebJACCPolicyModuleDelegate と、EJB コンテナリクエストの EJBJACCPolicyModuleDelegate)。設定オプションはありません。

XACMLAuthorizationModule

このモジュールは Web コンテナと EJB コンテナの 2 つの delegate を使用して (WebXACMLPolicyModuleDelegate および EJBXACMLPolicyModuleDelegate) XACML 承認を強制します。このモジュールは登録されたポリシーを基に PDP オブジェクトを作成し、それに対して Web または EJB リクエストを評価します。

AbstractAuthorizationModule

これはオーバーライドされる必要があるベースの承認モジュールで、他の承認モジュールへ委譲するためのファシリティーを提供します。

A.3. 含まれるセキュリティーマッピングモジュール

以下のセキュリティーマッピングロールが JBoss EAP 6 で提供されます。
Expand
コードクラス
PropertiesRolesorg.jboss.security.mapping.providers.role.PropertiesRolesMappingProvider
SimpleRolesorg.jboss.security.mapping.providers.role.SimpleRolesMappingProvider
DeploymentRolesorg.jboss.security.mapping.providers.DeploymentRolesMappingProvider
DatabaseRolesorg.jboss.security.mapping.providers.role.DatabaseRolesMappingProvider
LdapRolesorg.jboss.security.mapping.providers.role.LdapRolesMappingProvider
LdapAttributesorg.jboss.security.mapping.providers.attribute.LdapAttributeMappingProvider
DeploymentRolesMappingProvider

jboss-web.xml および jboss-app.xml デプロイメント記述子で可能なプリンシパルからロールへのマッピングを考慮するロールマッピングモジュール。

例A.1 例

<jboss-web>
...
  <security-role>
      <role-name>Support</role-name>
      <principal-name>Mark</principal-name> 
      <principal-name>Tom</principal-name>
  </security-role>
...
</jboss-web>
Copy to Clipboard Toggle word wrap
org.jboss.security.mapping.providers.DeploymentRoleToRolesMappingProvider

jboss-web.xml および jboss-app.xml デプロイメント記述子で指定できるプリンシパルからロールへのマッピングを考慮するロールツーロール (Role to Roles) マッピングモジュールです。この場合、principal-name は他のロールをマップするロールを示します。

例A.2 例

  <jboss-web>
 ...
    <security-role>
      <role-name>Employee</role-name>
      <principal-name>Support</principal-name>
      <principal-name>Sales</principal-name>
    </security-role>
 ...
  </jboss-web>
Copy to Clipboard Toggle word wrap
これは、Support または Sales をロールに持つ各プリンシパルには Employee ロールも割り当てられることを意味します。
org.jboss.security.mapping.providers.OptionsRoleMappingProvider

オプションからロールを選び、渡されたグループの前に追加するロールマッピングプロバイダー。ロール (値) のカンマ区切りリストが含まれるロール名 (キー) のプロパティースタイルマッピングを取ります。

org.jboss.security.mapping.providers.principal.SimplePrincipalMappingProvider

SimplePrincipal を取り、異なるプリンシパル名で SimplePrincipal を変換するプリンシパルマッピングプロバイダー。

DatabaseRolesMappingProvider

データベースからロールを読み取る MappingProvider。

オプション:
  • dsJndiName: ロールをユーザーにマップするために使用されるデータソースの JNDI 名。
  • rolesQuery: このオプションは「select RoleName from Roles where User=?」と同等の準備済みステートメントです。「?」は現在のプリンシパル名に置き換えられます。
  • suspendResume: ブール値 - ロールの検索の実行中に、現在のスレッドに関連するトランザクションを停止し、その後再開します。
  • transactionManagerJndiName: トランザクションマネージャーの JNDI 名 (デフォルトは java:/TransactionManager)。
LdapRolesMappingProvider

ロールを検索するため LDAP サーバーを使用してロールを割り当てるマッピングプロバイダー。

オプション:
  • bindDN: ユーザーおよびロールクエリーのために LDAP サーバーに対してバインドするために使用される DN。この DN は baseCtxDN および rolesCtxDN の値では読み取りおよび検索パーミッションが必要です。
  • bindCredential: bindDN のパスワード。これは、jaasSecurityDomain が指定された場合に暗号化できます。
  • rolesCtxDN: ユーザーロールを検索するコンテキストの固定 DN。これは、実際のロールが存在する DN ではなく、ユーザーロールを含むオブジェクトが存在する DN です。たとえば、Microsoft Active Directory サーバーでは、これは、ユーザーアカウントが存在する DN です。
  • roleAttributeID: 承認ロールの名前が含まれる LDAP 属性。
  • roleAttributeIsDN: roleAttributeID にロールオブジェクトの完全修飾 DN が含まれるかどうか。false の場合は、コンテキスト名の roleNameAttributeId 属性の値からロール名が取得されます。Microsoft Active Directory などの特定のディレクトリースキーマでは、この属性を true に設定する必要があります。
  • roleNameAttributeID: ロール名を含む roleCtxDN コンテキスト内の属性の名前。roleAttributeIsDN プロパティーが true に設定された場合、このプロパティーはロールオブジェクトの名前属性を見つけるために使用されます。
  • parseRoleNameFromDN: クエリーによって返された DN に roleNameAttributeID が含まれるかどうかを示すフラグ。true に設定された場合、DN は roleNameATtributeID に対してチェックされます。false に設定された場合、DN は roleNameATtributeID に対してチェックされません。このフラグは LDAP クエリーのパフォーマンスを向上できます。
  • roleFilter: 認証済みユーザーと関連付けられたロールを検索するために使用される検索フィルター。入力ユーザー名またはログインモジュールコールバックから取得された userDN{0} 式が使用されたフィルターに置換されます。認証済み userDN は、{1} が使用されたフィルターに置換されます。入力ユーザー名に一致する検索フィルター例は、(member={0}) です。認証済み userDN に一致する他の例は (member={1}) です。
  • roleRecursion: ロール検索が一致するコンテキストで行われる再帰のレベル数。再帰を無効にするには、これを 0 に設定します。
  • searchTimeLimit: ユーザー/ロール検索のタイムアウト (ミリ秒単位)。デフォルトは 10000 (10 秒) です。
  • searchScope: 使用する検索範囲。
PropertiesRolesMappingProvider

「username=role1,role2,...」という形式でプロパティーファイルからロールを読み取る MappingProvider。

オプション:
  • rolesProperties: プロパティーでフォーマットされるファイル名。JBoss 変数の拡張は ${jboss.variable} という形式で使用されます。
SimpleRolesMappingProvider

オプションマップからロールを読み取る簡単な MappingProvider。オプションの属性名はロールを割り当てるプリンシパルの名前で、 属性値はプリンシパルに割り当てるロール名のカンマ区切りリストです。

例A.3 例

<module-option name="JavaDuke" value="JBossAdmin,Admin"/> 
<module-option name="joe" value="Users"/>
Copy to Clipboard Toggle word wrap
org.jboss.security.mapping.providers.attribute.DefaultAttributeMappingProvider

モジュールをチェックし、マッピングコンテキストからプリンシパル名を見つけ、principalName + ".email" という名前のモジュールオプションから属性電子メールアドレスを作成し、それを指定のプリンシパルへマップします。

LdapAttributeMappingProvider

属性を LDAP からサブジェクトへマップします。オプションには、ご使用の LDAP JNDI プロバイダーがサポートするオプションがすべて含まれます。

例A.4 標準のプロパティー名の例

Context.INITIAL_CONTEXT_FACTORY = "java.naming.factory.initial"
Context.SECURITY_PROTOCOL = "java.naming.security.protocol"
Context.PROVIDER_URL = "java.naming.provider.url"
Context.SECURITY_AUTHENTICATION = "java.naming.security.authentication"
Copy to Clipboard Toggle word wrap
オプション:
  • bindDN: ユーザーおよびロールクエリーのために LDAP サーバーに対してバインドするために使用される DN。この DN は baseCtxDN および rolesCtxDN の値では読み取りおよび検索パーミッションが必要です。
  • bindCredential: bindDN のパスワード。これは、jaasSecurityDomain が指定された場合に暗号化できます。
  • baseCtxDN: ユーザー検索を開始するコンテキストの固定 DN。
  • baseFilter: 認証するユーザーのコンテキストを見つけるために使用される検索フィルター。入力ユーザー名またはログインモジュールコールバックから取得された userDN が、{0} 式が使用されたフィルターに置換されます。この置換の挙動は標準の __DirContext.search(Name, String, Object[], SearchControls cons)__ メソッドからになります。一般的な検索フィルターの例は (uid={0}) です。
  • searchTimeLimit: ユーザー/ロール検索のタイムアウト (ミリ秒単位)。デフォルトは 10000 (10 秒) です。
  • attributeList: ユーザーの属性のカンマ区切りリスト (例: mail,cn,sn,employeeType,employeeNumber)。
  • jaasSecurityDomain: java.naming.security.principal の復号化に使用する JaasSecurityDomain。パスワードの暗号化された形式は JaasSecurityDomain#encrypt64(byte[]) によって返されます。org.jboss.security.plugins.PBEUtils を使用して暗号化された形式を生成することもできます。

A.4. 含まれるセキュリティー監査プロバイダーモジュール

JBoss EAP 6 はセキュリティー監査プロバイダーを 1 つ提供します。
Expand
コードクラス
LogAuditProviderorg.jboss.security.audit.providers.LogAuditProvider

A.5. jboss-web.xml の設定に関する参考資料

はじめに

jboss-web.xml はデプロイメントの WEB-INF ディレクトリー内にあるファイルです。このファイルには、JBoss Web コンテナが Servlet 3.0 仕様に追加する機能に関する設定情報が含まれています。Servlet 3.0 仕様は web.xml の同じディレクトリーに格納されます。

jboss-web.xml ファイルのトップレベル要素は <jboss-web> 要素です。
グローバルリソースの WAR 要件へのマッピング

使用可能な設定の多くは、アプリケーションの web.xml に設定される要件をローカルリソースへマッピングします。web.xml の設定に関する説明は http://docs.oracle.com/cd/E13222_01/wls/docs81/webapp/web_xml.html を参照してください。

たとえば、web.xmljdbc/MyDataSource が必要な場合、jboss-web.xml はグローバルデータソース java:/DefaultDS をマッピングして要件を満たすことがあります。WAR はグローバルデータソースを使用して jdbc/MyDataSource に対する要求を満たします。
Expand
表A.42 一般的なトップレベル属性
属性説明
env-entry
web.xml が必要とする env-entry へのマッピング。
ejb-ref
web.xml が必要とする ejb-ref へのマッピング。
ejb-local-ref
web.xml が必要とする ejb-local-ref へのマッピング。
service-ref
web.xml が必要とする service-ref へのマッピング。
resource-ref
web.xml が必要とする resource-ref へのマッピング。
resource-env-ref
web.xml が必要とするresource-env-ref へのマッピング。
message-destination-ref
web.xml が必要とする message-destination-ref へのマッピング。
persistence-context-ref
web.xml が必要とする persistence-context-ref へのマッピング。
persistence-unit-ref
web.xml が必要とする persistence-unit-ref へのマッピング。
post-construct
web.xml が必要とする post-context へのマッピング。
pre-destroy
web.xml が必要とする pre-destroy へのマッピング。
data-source
web.xml が必要とする data-source へのマッピング。
context-rootアプリケーションのルートコンテキスト。デフォルト値は .war サフィックスを除いたデプロイメントの名前です。
virtual-hostアプリケーションがリクエストを許可する HTTP 仮想ホストの名前。HTTP の Host ヘッダーの内容を参照します。
annotationアプリケーションによって使用されるアノテーションを記述します。詳細は <annotation> を参照してください。
listenerアプリケーションによって使用されるリスナーを記述します。詳細は <listener> を参照してください。
session-configこの要素は web.xml<session-config> 要素と同じ関数を入力します。互換性維持の目的でのみ含まれます。
valveアプリケーションによって使用されるバルブを記述します。詳細は <valve> を参照してください。
overlayアプリケーションに追加するオーバーレイの名前。
security-domainアプリケーションによって使用されるセキュリティードメインの名前。セキュリティードメイン自体は Web ベースの管理コンソールか管理 CLI に設定されます。
security-roleこの要素は web.xml<security-role> 要素と同じ関数を入力します。互換性維持の目的でのみ含まれます。
use-jboss-authorizationこの要素が存在し、大文字と小文字を区別しない true という値が含まれる場合、JBoss Web 承認スタックが使用されます。この要素が存在しない場合や、true でない値が含まれる場合は、Java enterprise Edition 仕様に指定された承認メカニズムのみが使用されます。この要素は JBoss EAP 6 に新規導入された要素です。
disable-auditWeb 監査を有効にする場合はこのブール値要素を false に設定し、無効にする場合は true に設定します。Web セキュリティー監査は Java EE 仕様の一部ではありません。この要素は JBoss EAP 6 に初めて導入された要素です。
disable-cross-contextfalse の場合、アプリケーションは他のアプリケーションコンテキストを呼び出すことができます。デフォルトは true です。
以下の各要素は子要素を持っています。
<annotation>

アプリケーションによって使用されるアノテーションを記述します。下表は <annotation> の子要素の一覧になります。

Expand
表A.43 アノテーション設定要素
属性説明
class-name
アノテーションのクラスの名前。
servlet-security
サーブレットのセキュリティーを表す @ServletSecurity などの要素。
run-as
run-as の情報を表す @RunAs などの要素。
multipart-config
multipart-config 情報を表す @MultiPart などの要素。
<listener>

リスナーを記述します。下表は <listener> の子要素の一覧になります。

Expand
表A.44 リスナー設定要素
属性説明
class-name
リスナーのクラスの名前。
listener-type
アプリケーションのコンテキストにどのようなリスナーを追加するかを示す condition 要素の一覧です。以下を選択することが可能です。
CONTAINER
コンテキストに ContainerListener を追加します。
LIFECYCLE
コンテキストに LifecycleListener を追加します。
SERVLET_INSTANCE
コンテキストに InstanceListener を追加します。
SERVLET_CONTAINER
コンテキストに WrapperListener を追加します。
SERVLET_LIFECYCLE
コンテキストに WrapperLifecycle を追加します。
module
リスナークラスが含まれるモジュールの名前。
param
パラメーター。<param-name><param-value> の 2 つの子要素が含まれます。
<valve>

アプリケーションのバルブを記述します。<listener> に似ており、class-name、module および param 要素を持ちます。

A.6. EJB セキュリティーパラメーターに関するリファレンス

Expand
表A.45 EJB セキュリティーパラメーター要素
要素説明
<security-identity>
EJB のセキュリティー ID に付随する子要素が含まれています。
<use-caller-identity />
EJB が呼び出し元と同じセキュリティー ID を使うよう指定します。
<run-as>
<role-name> 要素が含まれています。
<run-as-principal>
存在する場合、発信呼び出しへ割り当てられたプリンシパルを示します。存在しない場合、発信呼び出しは anonymous という名前のプリンシパルへ割り当てられます。
<role-name>
EJB が実行されるロールを指定します。
<description>
<role-name> に名前のあるロールを記述します
.

例A.5 セキュリティー ID の例

この例は、表A.45「EJB セキュリティーパラメーター要素」 で説明した各タグを示しています。これらのタグは、<session> の中でのみ利用可能です。
<ejb-jar>
    <enterprise-beans>
        <session>
            <ejb-name>ASessionBean</ejb-name>
            <security-identity>
                <use-caller-identity/>
            </security-identity>
        </session>
        <session>
            <ejb-name>RunAsBean</ejb-name>
            <security-identity>
                <run-as>
                    <description>A private internal role</description>
                    <role-name>InternalRole</role-name>
                </run-as>
            </security-identity>
        </session>
		  <session>
			 <ejb-name>RunAsBean</ejb-name>
			 <security-identity>
				<run-as-principal>internal</run-as-principal>
			 </security-identity>
		  </session>
    </enterprise-beans>
</ejb-jar>
Copy to Clipboard Toggle word wrap

付録B 改訂履歴

改訂履歴
改訂 6.3.0-50.1Mon Feb 11 2019Ludek Janda
翻訳ファイルを XML ソースバージョン 6.3.0-50 と同期
改訂 6.3.0-50Tuesday November 18 2014Russell Dickenson
Red Hat JBoss Enterprise Application Platform 6.3.0 連続リリース
改訂 6.3.0-43Friday August 8 2014Lucas Costi
Red Hat JBoss Enterprise Application Platform 6.3.0 連続リリース
改訂 6.3.0-42Wednesday, July 30 2014Russell Dickenson
Red Hat JBoss Enterprise Application Platform 6.3.0.GA

法律上の通知

Copyright © 2014 Red Hat, Inc..
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat