Menu Close

セキュリティーガイド

JBoss Enterprise Application Platform 6.1

JBoss Enterprise Application Platform 6 向け

エディッション 1

Nidhi Chaudhary

Lucas Costi

Russell Dickenson

Sande Gilda

Vikram Goyal

Eamon Logue

Darrin Mison

Scott Mumford

David Ryan

Misty Stanley-Jones

Keerat Verma

Tom Wells

概要

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

前書き

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

第1章 はじめに

1.1. セキュリティーについて

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

1.2. システム管理者のセキュリティー

常にコンピューターシステムやネットワーク上で作業を行うシステム管理者は、ネットワーク上の攻撃に対処できなければなりません。また、このような攻撃を阻止するためセキュリティーの訓練や監査を計画し、事前対応する必要もあります。
システム管理者としてセキュリティー違反に備えるには、科学と非科学を組み合わせる必要があります。セキュリティーの脅威は物理、ネットワーク、またはデータベースであるかどうかに関係なく本質的に異なるため、セキュリティーシステムの管理者はシステムの停止と冗長性の両方に対し準備することが必要となります。
専門のシステム管理者やセキュリティー管理者はシステムおよびネットワークレベルのセキュリティーのみを担当し、ミドルウェアやアプリケーションのセキュリティーは担当しません。

1.3. J2EE 開発者のセキュリティー

アプリケーションレベルのセキュリティーは J2EE 開発の手に委ねられます。このセキュリティーは、次の 3 つの役割に分担することができます。
  • アプリケーション開発者 - 開発レベルにおけるセキュリティーを担当し、ロール、ルール、およびビジネスロジックをアプリケーションロジックに定義します。
  • アプリケーションアセンブラー - アプリケーションにまたがる脆弱性が最低限になるよう EAR および WAR がパッケージ化されるようにします。
  • アプリケーションデプロイヤー - EAR のデプロイメントをセキュアにし、アクセス制御リストを割り当て、維持します。
これら 3 つの役割をすべて同じ開発者グループが担当することはまれではありません。
JBoss Enterprise Application Platform はコンポーネントプラットフォームとして宣言的セキュリティーを提供します。セキュリティーロジックをビジネスコンポーネントへ組み込まずに、セキュリティーロールとパーミッションを標準的な XML 記述子に記述します。これにより、ビジネスレベルのコードがセキュリティーコードより分離されます。JBoss Enterprise Application Platform での宣言的セキュリティーの詳細は 「宣言的セキュリティーについて」 を参照してください。
宣言的セキュリティーはプログラミングによるセキュリティーによってより強化されます。J2EE の開発者はコードに J2EE API を使用して承認を判断し、改良されたセキュリティーを実行できます。

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

第2章 セキュリティーサブシステム

2.1. セキュリティーサブシステムについて

セキュリティーサブシステムは、JBoss Enterprise Application Platform ですべてのセキュリティー機能のインフラストラクチャーを提供します。設定要素はほとんど変更する必要がありません。変更が必要となる可能性がある唯一の設定要素は、ディープコピーサブジェクトモード を使用するかどうかです。また、システム全体のセキュリティープロパティーを設定できます。ほとんどの設定はセキュリティードメインに関連します。
ディープコピーモード

ディープコピーサブジェクトモードが無効化されている場合 (デフォルト)、セキュリティーデータ構造をコピーすると、データ構造全体をコピーするのではなく、オリジナルが参照されます。この動作はより効率的ですが、フラッシュまたはログアウトの操作によって同一 ID の複数のスレッドが件名を消去すると、データの破損が発生する傾向にあります。

ディープコピーサブジェクトモードでは、クローン可能と指定されていると、データ構造およびデータ構造に関連するデータの完全コピーが作成されます。このモードはよりスレッドセーフですが、効率は悪くなります。
システム全体のセキュリティープロパティー

java.security.Security クラスに適用されるシステム全体のセキュリティープロパティーを設定できます。

セキュリティードメイン

セキュリティードメインとは、認証、承認、監査、およびマッピングを制御するために単一または複数のアプリケーションが使用する Java Authentication and Authorization Service (JAAS) 宣言型セキュリティー設定のセットです。デフォルトでは、jboss-ejb-policyjboss-web-policy、および other の 3 つのセキュリティードメインが含まれています。アプリケーションの必要性に対応するため、セキュリティードメインは必要に応じていくつでも作成できます。

2.2. セキュリティーサブシステムの構造について

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

例2.1 セキュリティーサブシステムの設定例

<subsystem xmlns="urn:jboss:domain:security:1.2">
	<security-management>
		...
	</security-management>
	<security-domains>
        <security-domain name="other" cache-type="default">
            <authentication>
                <login-module code="Remoting" flag="optional">
                    <module-option name="password-stacking" value="useFirstPass"/>
                </login-module>
                <login-module code="RealmUsersRoles" flag="required">
                    <module-option name="usersProperties" value="${jboss.domain.config.dir}/application-users.properties"/>
                    <module-option name="rolesProperties" value="${jboss.domain.config.dir}/application-roles.properties"/>
                    <module-option name="realm" value="ApplicationRealm"/>
                    <module-option name="password-stacking" value="useFirstPass"/>
                </login-module>
            </authentication>
        </security-domain>
        <security-domain name="jboss-web-policy" cache-type="default">
            <authorization>
                <policy-module code="Delegating" flag="required"/>
            </authorization>
        </security-domain>
        <security-domain name="jboss-ejb-policy" cache-type="default">
            <authorization>
                <policy-module code="Delegating" flag="required"/>
            </authorization>
        </security-domain>
    </security-domains>
    <vault>
    	...
    </vault>
</subsystem>		
		


<security-management><subject-factory> および <security-properties> 要素はデフォルト設定では存在しません。<subject-factory> および <security-properties> 要素は JBoss Enterprise Application Platform 6.1 およびそれ以降のバージョンで廃止になりました。

2.3. 暗号化について

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

2.4. 宣言的セキュリティーについて

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

2.5. セキュリティーサブシステムの設定

セキュリティーサブシステムの設定には、管理 CLI または Web ベースの管理コンソールを使用することができます。
セキュリティーサブシステム内の各トップレベル要素には、セキュリティー設定の異なる情報が含まれています。セキュリティーサブシステムの設定例は 「セキュリティーサブシステムの構造について」 を参照してください。
<security-management>
このセクションはセキュリティーサブシステムのハイレベルの挙動を上書きします。各設定は任意です。ディープコピーサブジェクトモード以外で、これらの設定を変更することはほとんどありません。
オプション 説明
deep-copy-subject-mode
スレッドの安全性を高めるため、セキュリティートークンへコピーまたはリンクするかどうかを指定します。
authentication-manager-class-name
使用する代替の AuthenticationManager 実装クラス名を指定します。
default-callback-handler-class-name
ログインモジュールで使用される CallbackHandler 実装のグローバルクラス名を指定します。
authorization-manager-class-name
使用する代替の AuthorizationManager 実装クラス名を指定します。
audit-manager-class-name
使用する代替の AuditManager 実装クラス名を指定します。
identity-trust-manager-class-name
使用する代替の IdentityTrustManager 実装クラス名を指定します。
mapping-manager-class-name
使用する MappingManager 実装クラス名を指定します。
<subject-factory>
サブジェクトファクトリはサブジェクトインスタンスの作成を制御します。呼び出し側を検証するため、認証マネージャーを使用することがあります。サブジェクトファクトリは、主に JCA コンポーネントがサブジェクトを確立するために使用されます。サブジェクトファクトリを変更する必要はあまりありません。
<security-domains>
複数のセキュリティードメインを保持するコンテナ要素です。セキュリティードメインには認証、承認、マッピング、監査モジュール、JASPI 認証、および JSSE 設定の情報が含まれることがあります。アプリケーションはセキュリティードメインを指定してセキュリティー情報を管理します。
<security-properties>
java.security.Security クラスに設定されるプロパティーの名前と値が含まれます。

第3章 管理インターフェースセキュリティー

3.1. 管理インターフェースのセキュア化

概要

テスト環境では、管理コンソール、管理 CLI および他の API 実装で構成される管理インターフェース上で、セキュリティーレイヤーがない状態で JBoss Enterprise Application Platform 6 を実行することがよくあります。これにより、開発や設定を迅速に変更できます。

また、デフォルトではサイレント認証モードを使用できるため、ホストマシン上のローカルクライアントはユーザー名またはパスワードを指定せずに管理 CLI に接続できます。この動作は、ローカルユーザーと管理 CLI スクリプトには便利ですが、必要な場合は無効にできます。この手順については、「デフォルトセキュリティーレルムからのサイレント認証の削除」 を参照してください。
本番稼働に移行するために環境のテストおよび準備を開始する場合は、少なくとも以下の方法で管理インターフェースをセキュアにすることが非常に重要です。

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

はじめに

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

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

    注記

    HTTP を使用してローカルホストへ接続する場合でも、HTTP のアクセスはリモートと見なされます。
    1. ローカル SASL メカニズムを用いて認証する要求が含まれるメッセージをクライアントがサーバーに送信します。
    2. サーバーはワンタイムトークンを生成し、固有のファイルに書き込み、ファイルのフルパスが含まれるメッセージをクライアントへ送信します。
    3. クライアントはファイルよりトークンを読み取り、サーバーへ送信し、ファイルシステムへローカルアクセスできるかを検証します。
    4. サーバーはトークンを検証し、ファイルを削除します。
  • ローカル HTTP クライアントを含むリモートクライアントはレルムベースのセキュリティーを使用します。管理インターフェースを使用して JBoss Enterprise Application Platform 6 をリモートで設定するパーミッションを持つデフォルトのレルムは ManagementRealm です。このレルム (またはユーザーが作成したレルム) にユーザーを追加できるスクリプトが提供されます。ユーザーの追加の詳細については、JBoss Enterprise Application Platform 6 のインストールガイドの章「JBoss Enterprise Application Platform 6 を初めて使用」を参照してください。ユーザーごとに、ユーザー名、ハッシュ化されたパスワード、およびレルムがファイルに格納されます。
    スタンドアロンサーバー
    JPP_HOME/standalone/configuration/mgmt-users.properties
    mgmt-users.properties の内容はマスクされていますが、機密ファイルとして取り扱うようにしてください。ファイルモードを、ファイル所有者による読み書きアクセスのみが許可される 600 に設定することが推奨されます。

3.3. 管理インターフェースの詳細設定の概要

EAP_HOME/domain/configuration/host.xml または EAP_HOME/standalone/configuration/standalone.xml の管理インターフェース設定は、ホストコントローラープロセスのバインド先となるネットワークインターフェース、利用可能な管理インターフェースのタイプ、各インターフェースでユーザー認証に使用する認証システムのタイプを制御します。本トピックでは、ご使用の環境に合わせて管理インターフェースを設定する方法について説明します。
管理サブシステムは、複数の設定可能な属性が含まれる <management> 要素と、以下の 3 つの設定可能な子要素で構成されます。セキュリティーレルムと送信接続はそれぞれ最初に定義されてから、管理インターフェースに属性として適用されます。
  • <security-realms>
  • <outbound-connections>
  • <management-interfaces>
セキュリティーレルム

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

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

注記

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

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

管理インターフェース

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

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

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

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

注記

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

例3.1 HTTP インターフェースの設定の読み込み

/host=master/core-service=management/management-interface=http-interface/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
{
    "outcome" => "success",
    "result" => {
        "console-enabled" => true,
        "interface" => "management",
        "port" => expression "${jboss.management.http.port:9990}",
        "secure-port" => undefined,
        "security-realm" => "ManagementRealm"
    }
}
HTTP インターフェースを削除するには、次のコマンドを実行します。

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

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

例3.3 HTTP インターフェースの再作成

/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=true)
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=interface,value=management)
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=port,value=${jboss.management.http.port:9990})
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=ManagementRealm)

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

概要

JBoss Enterprise Application Platform 6 には、ローカル管理 CLI ユーザーに対するサイレント認証方法が含まれます。これにより、ローカルユーザーは、ユーザー名またはパスワード認証なしで管理 CLI にアクセスできるようになります。この機能は、利便性のために有効であり、ローカルユーザーが認証なしで管理 CLI スクリプトを実行する場合に役に立ちます。この機能は、ローカル設定へのアクセスにより、ユーザーが独自のユーザー詳細を追加できる (または、セキュリティーチェックを無効にする) ため、役に立つ機能です。

ローカルユーザーのサイレント認証は便利ですが、さらに強力なセキュリティー制御が必要な場合に無効にできます。これは、設定ファイルの security-realm セクション内で local 要素を削除することにより、実現できます。これは、スタンドアロンサーバーインスタンス用の standalone.xml と管理対象ドメイン用の host.xml の両方に適用されます。特定のサーバー設定に与える可能性がある影響を考えると、local 要素を削除することをお勧めします。
サイレント認証の推奨される削除方法は、管理 CLI を使用して、次の例に示された local 要素を直接削除することです。

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


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

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

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

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

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

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

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

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

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

リモート JMX 接続により JDK およびアプリケーション管理操作のトリガーが可能となります。インストールをセキュリティー保護するには、この機能を無効にしてください。リモート接続の設定を削除するか、JMX サブシステムを完全に削除することによって無効にすることができます。JBoss CLI コマンドは管理対象ドメイン設定内のデフォルトのプロファイルを参照します。異なるプロファイルを修正するには、コマンドの /profile=default の部分を変更します。スタンドアロンサーバーの場合には、この部分を完全に削除してください。

注記

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

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

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

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

管理対象ドメインを使用している場合には、使用しているプロファイルごとにこのコマンドを実行してください。
/profile=default/subsystem=jmx/:remove

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

管理インターフェースはセキュリティーレルムを使用して JBoss Enterprise Application Platform の認証および設定メカニズムへのアクセスを制御します。 本トピックでは、セキュリティーレルムの読み込みと設定について説明します。以下に記載するコマンドには管理 CLI を使用します。
セキュリティーレルムの設定の読み込み

以下の例は、ManagementRealm セキュリティーレルムのデフォルト設定を示しています。mgmt-users.properties というファイルを使用して設定情報を保管します。

例3.7 デフォルトの ManagementRealm

	/host=master/core-service=management/security-realm=ManagementRealm/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
{
    "outcome" => "success",
    "result" => {
        "authorization" => undefined,
        "server-identity" => undefined,
        "authentication" => {"properties" => {
            "path" => "mgmt-users.properties",
            "plain-text" => false,
            "relative-to" => "jboss.domain.config.dir"
        }}
    }
}
セキュリティーレルムの書き込み

以下のコマンドは TestRealm というセキュリティーレルムを作成し、関連プロパティーファイルの名前とディレクトリを設定します。

例3.8 セキュリティーレルムの書き込み

/host=master/core-service=management/security-realm=TestRealm/:add/host=master/core-service=management/security-realm=TestRealm/authentication=properties/:add(path=TestUsers.properties, relative-to=jboss.domain.config.dir)

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

セキュリティーレルムを追加したら、その名前を管理インターフェースへの参照として指定します。

例3.9 管理インターフェースへのセキュリティーレルムの追加

host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=TestRealm)

3.8. 機密性の高い文字列のパスワードボールト

3.8.1. クリアテキストファイルでの機密性が高い文字列のセキュア化について

Web アプリケーションと他のデプロイメントには、パスワードや他の機密性が高い文字列のような機密性が高い情報を含む XML デプロイメント記述子などのクリアテキストファイルが含まれることがよくあります。JBoss Enterprise Application Platform には、機密性が高い文字列を暗号化し、暗号化キーストアに格納できるパスワード vault メカニズムが含まれます。vault メカニズムは、セキュリティードメイン、セキュリティー領域、または他の検証システムで使用する文字列の復号化を管理します。これにより、セキュリティーのレイヤーが追加されます。このメカニズムは、サポートされるすべての Java Development Kit (JDK) 実装に含まれるツールに依存します。

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

要件

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

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

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

    キーストアと他の重要な情報を保持するディレクトリーを作成します。この残りの手順では、ディレクトリーが /home/USER/vault/ であることを前提とします。
  2. keytool で使用するパラメーターを決定します。

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

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

    例3.10 keystore コマンドの入出力例

    $ keytool -genkey -alias vault -keyalg RSA -keysize 1024 -keystore /home/USER/vault/vault.keystore
    Enter keystore password: vault22 
    Re-enter new password:vault22 
    What is your first and last name?
      [Unknown]:  Accounting Administrator
    What is the name of your organizational unit?
      [Unknown]:  AccountingServices
    What is the name of your organization?
      [Unknown]:  MyOrganization
    What is the name of your City or Locality?
      [Unknown]:  Raleigh
    What is the name of your State or Province?
      [Unknown]:  NC
    What is the two-letter country code for this unit?
      [Unknown]:  US
    Is CN=Accounting Administrator, OU=AccountingServices, O=MyOrganization, L=Raleigh, ST=NC, C=US correct?
      [no]:  yes
    
    Enter key password for <vault>
            (RETURN if same as keystore password):
    
結果

/home/USER/vault/ ディレクトリに vault.keystore という名前のファイルが作成されます。JBoss Enterprise Application Platform のパスワードなど、暗号化された文字列を格納するため使用される vault という 1 つのキーがこのファイルに保存されます。

3.8.3. キーストアパスワードのマスキングとパスワード vault の初期化

要件

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

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

    このディレクトリはある程度保護されている必要がありますが、JBoss Enterprise Application Platform がアクセスできなければなりません。「機密性が高い文字列を格納する Java キーストアの作成」 の手順に従うと、キーストアはホームディレクトリにある vault/ というディレクトリの中にあります。この例では /home/USER/vault/ を使用します。

    注記

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

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

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

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

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

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

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

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

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

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

3.8.4. パスワード vault を使用するよう JBoss Enterprise Application Platform を設定

概要

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

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

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

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

    次のコマンドの 1 つを実行します。実行するコマンドは、管理対象ドメインを使用するか、スタンドアロンサーバー設定を使用するかによって異なります。コマンドの値は、手順の最初で使用した値に置き換えます。
    • 管理対象ドメイン

      /host=YOUR_HOST/core-service=vault:add(vault-options=[("KEYSTORE_URL" => "PATH_TO_KEYSTORE"), ("KEYSTORE_PASSWORD" => "MASKED_PASSWORD"), ("KEYSTORE_ALIAS" => "ALIAS"), ("SALT" => "SALT"),("ITERATION_COUNT" => "ITERATION_COUNT"), ("ENC_FILE_DIR" => "ENC_FILE_DIR")])
      
    • スタンドアロンサーバー

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

パスワード vault を使用してマスキングされた文字列を復号化するよう JBoss Enterprise Application Platform が設定されます。vault に文字列を追加し、設定で使用する場合は 「Java キーストアに暗号化された機密性の高い文字列の保存および読み出し」 を参照してください。

3.8.5. Java キーストアに暗号化された機密性の高い文字列の保存および読み出し

概要

パスワードや、機密性の高いその他の文字列が平文の設定ファイルに含まれるのはセキュアではありません。JBoss Enterprise Application Platform には、このような機密性の高い文字列をマスキングして暗号化されたキーストアに保存する機能や、設定ファイルでマスクされた値を使用する機能が含まれています。

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

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

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

    「機密性が高い文字列を格納する Java キーストアの作成」 に従って作業を行った場合は、キーストアはホームディレクトリの vault/ というディレクトリにあります。ほとんどの場合では、暗号化されたすべての情報をキーストアとして同じ場所に保存するのが普通です。この例では /home/USER/vault/ ディレクトリを使用します。

    注記

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

    キーストアファイルへの完全パスを入力します。この例では /home/USER/vault/vault.keystore を使用します。
  4. キーストアパスワード、vault 名、ソルト、反復回数を入力します。

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

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

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

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

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

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

    Attribute Value for (ds_ExampleDS, password) saved
  9. 暗号化された文字列に関する情報を書き留めます。

    メッセージは vault ブロック、属性名、共有キー、および設定で文字列を使用する場合のアドバイスを表示する標準出力を出力します。安全な場所にこの情報を書き留めておくようにしてください。出力例は次のとおりです。
    ********************************************
    Vault Block:ds_ExampleDS
    Attribute Name:password
    Shared Key:N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0
    Configuration should be done as follows:
    VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0
    ********************************************
    
  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::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password>
            </security>
          </datasource>
          <drivers>
             <driver name="h2" module="com.h2database.h2">
                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
             </driver>
          </drivers>
        </datasources>
      </subsystem>
    ...
    
    
    式が許可されるドメインまたはスタンドアロン設定ファイルであれば、どこでも暗号化された文字列を使用することができます。

    注記

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

3.8.6. アプリケーションで機密性の高い文字列を保存および解決

概要

JBoss Enterprise Application Platform の設定要素は、セキュリティー vault メカニズムを通じて Java キーストアに保存される値に対して暗号化された文字列を解決する機能をサポートしています。この機能に対するサポートを独自のアプリケーションに追加することができます。

最初に、vault にパスワードを追加します。次に、クリアテキストのパスワードを vault に保存されているパスワードに置き換えます。この方法を使用してアプリケーションの機密性の高い文字列を分かりにくくすることができます。
要件

この手順を実行する前に、vault ファイルを格納するディレクトリが存在することを確認してください。JBoss Enterprise Application Platform を実行するユーザーが vault ファイルを読み書きできるパーミッションを持っていれば、vault ファイルの場所はどこでも構いません。この例では、vault/ ディレクトリを /home/USER/vault/ ディレクトリに置きます。vault 自体は vault/ ディレクトリの中にある vault.keystore と呼ばれるファイルになります。

例3.11 vault へのパスワードの文字列の追加

EAP_HOME/bin/vault.sh コマンドを用いて文字列を vault へ追加します。次の画面出力にコマンドと応答がすべて含まれています。ユーザー入力の値は強調文字で表されています。出力の一部は書式上、削除されています。Microsoft Windows ではコマンド名は vault.bat になります。Microsoft Windows のファイルパスでは、ディレクトリの分離記号として / ではなく \ が使用されることに注意してください。
[user@host bin]$ ./vault.sh 
**********************************
****  JBoss Vault ********
**********************************
Please enter a Digit::   0: Start Interactive Session  1: Remove Interactive Session  2: 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
Attribute Value for (DS, thePass) saved

Please make note of the following:
********************************************
Vault Block:DS
Attribute Name:thePass
Shared Key:OWY5M2I5NzctYzdkOS00MmZhLWExZGYtNjczM2U5ZGUyOWIxTElORV9CUkVBS3ZhdWx0
Configuration should be done as follows:
VAULT::DS::thePass::OWY5M2I5NzctYzdkOS00MmZhLWExZGYtNjczM2U5ZGUyOWIxTElORV9CUkVBS3ZhdWx0
********************************************

Please enter a Digit::   0: Store a password  1: Check whether password exists  2: Exit
2
Java コードに追加される文字列は、出力の最後の値である VAULT で始まる行です。
次のサーブレットは、クリアテキストのパスワードの代わりに vault された文字列を使用します。違いを確認できるようにするため、クリアテキストのパスワードはコメントアウトされています。

例3.12 vault されたパスワードを使用するサーブレット

package vaulterror.web;
 
import java.io.IOException;
import java.io.Writer;
 
import javax.annotation.Resource;
import javax.annotation.sql.DataSourceDefinition;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.sql.DataSource;
 
 
/*@DataSourceDefinition(
        name = "java:jboss/datasources/LoginDS",
        user = "sa",
        password = "sa",
        className = "org.h2.jdbcx.JdbcDataSource",
        url = "jdbc:h2:tcp://localhost/mem:test"
)*/
@DataSourceDefinition(
        name = "java:jboss/datasources/LoginDS",
        user = "sa",
        password = "VAULT::DS::thePass::OWY5M2I5NzctYzdkOS00MmZhLWExZGYtNjczM2U5ZGUyOWIxTElORV9CUkVBS3ZhdWx0",
        className = "org.h2.jdbcx.JdbcDataSource",
        url = "jdbc:h2:tcp://localhost/mem:test"
)
@WebServlet(name = "MyTestServlet", urlPatterns = { "/my/" }, loadOnStartup = 1)
public class MyTestServlet  extends HttpServlet {
 
    private static final long serialVersionUID = 1L;
 
 
    @Resource(lookup = "java:jboss/datasources/LoginDS")
    private DataSource ds;
 
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        Writer writer = resp.getWriter();
        writer.write((ds != null) + "");
    }
}
これでサーブレットが vault された文字列を解決できるようになります。

3.9. LDAP

3.9.1. LDAP について

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

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

管理コンソール、管理 CLI、管理 API の認証ソースとして LDAP ディレクトリサーバーを使用するには、以下の手順を実行する必要があります。
  1. LDAP サーバーへの送信接続を作成します。
  2. LDAP 対応のセキュリティーレルムを作成します。
  3. 管理インターフェースの新規セキュリティードメインを参照します。
LDAP サーバーへの送信接続の作成

LDAP 送信接続には、以下の属性を使用することができます。

表3.1 LDAP 送信接続の属性

属性 必要性 説明
name 必要
この接続を識別するための名前。この名前はセキュリティーレルムの定義に使用されます。
url 必要
ディレクトリサーバーの URL アドレス。
search-dn 必要
検索の実行を許可されているユーザーの完全識別名 (DN)
search-credentials 必要
検索の実行を許可されているユーザーのパスワード。
initial-context-factory 不必要
接続を確立する際に使用する初期コンテキストファクトリ。デフォルトでは com.sun.jndi.ldap.LdapCtxFactory に設定されています。

例3.13 LDAP 送信接続の追加

この例では、以下のプロパティーセットを使用して送信接続を追加します。
  • DN の検索: cn=search,dc=acme,dc=com
  • 証明情報の検索: myPass
  • URL: ldap://127.0.0.1:389
/host=master/core-service=management/ldap-connection=ldap_connection/:add(search-credential=myPass,url=ldap://127.0.0.1:389,search-dn="cn=search,dc=acme,dc=com")

例3.14 LDAP 送信出力を示す XML

<outbound-connections>
   <ldap name="ldap_connection" url="ldap://127.0.0.1:389" search-dn="cn=search,dc=acme,dc=com" search-credential="myPass" />
</outboundconnections>	
	


LDAP 対応セキュリティーレルムの作成

管理インターフェースは、デフォルトで設定されているプロパティーファイルをベースとするセキュリティーレルムの代わりに LDAP サーバーに対して認証を行うことができます。LDAP のオーセンティケーターは、最初にリモートディレクトリサーバーへの接続を確立します。次に、LDAP レコードの完全修飾識別名 (DN) を探すため、ユーザーが認証システムに渡したユーザー名を使用して検索を実行します。認証情報としてユーザーの DN とユーザー提供のパスワードを使用して、新規接続が確立されます。 このLDAP サーバーに対するこの検証に成功すると、DN が有効であることが検証されます。

LDAP のセキュリティーレルムが機能するには、以下の属性と要素が必要です。
connection
<outbound-connections> に定義されている接続の名前。LDAP ディレクトリへの接続に使用します。
base-dn
ユーザー検索を開始するためのコンテキストの識別名
recursive
LDAP ディレクトリツリー全体にわたって再帰的に検索を行うか、指定のコンテキストのみを検索するかを指定します。デフォルトでは false に設定されています。
user-dn
識別名を持つするユーザーの属性。これは、後で認証のテストに使用されます。デフォルトでは dn に設定されています。
子要素として、username-filter または advanced-filter のいずれか。
username-filterattribute という単一の属性を取り、値は userNamesambaAccountName などのユーザー名を持つ LDAP 属性の名前です。
advanced-filterfilter と呼ばれる単一の属性を取ります。この属性には、標準的な LDAP 構文のフィルタークエリが含まれています。& 文字を &amp; に変更し、エスケープすることに注意してください。フィルターの例は次のとおりです。
(&(sAMAccountName={0})(memberOf=cn=admin,cn=users,dc=acme,dc=com))
アンパサンド文字をエスケープすると、フィルターは次のようになります。
(&amp;(sAMAccountName={0})(memberOf=cn=admin,cn=users,dc=acme,dc=com))

例3.15 LDAP 対応のセキュリティーレルムを示す XML

この例には、以下のパラメーターを使用します。
  • connection - ldap_connection
  • base-dn - cn=users,dc=acme,dc=com.
  • username-filter - attribute="sambaAccountName"
<security-realm name="TestRealm">
   <authentication>
      <ldap connection="ldap_connection" base-dn="cn=users,dc=acme,dc=com">
         <username-filter attribute="sambaAccountName" />
      </ldap>
  </authentication>
</security-realm>	



警告

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

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

次のコマンドはセキュリティーレルムを追加し、スタンドアロンサーバーの属性を設定します。
/host=master/core-service=management/security-realm=ldap_security_realm/authentication=ldap:add(base-dn="DC=mycompany,DC=org", recursive=true, username-attribute="MyAccountName", connection="ldap_connection")
管理インターフェースへの新規セキュリティーレルムの適用

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

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

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

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

4.1. Java Security Manager について

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

4.2. Java Security Manager のポリシーについて

Security Policy
様々なコードのクラスに対する定義済みのパーミッションセット。Java Security Manager はアプリケーションが要求したアクションと、このセキュリティーポリシーを比較します。ポリシーでアクションが許可された場合、Security Manager により、アクションの実行が許可されます。ポリシーによりアクションが許可されない場合、Security Manager はこのアクションを拒否します。セキュリティーポリシーは、コードの場所やコードのシグネチャーを基にパーミッションを定義することができます。
使用する Java Security Manager やセキュリティーポリシーは、Java 仮想マシンのオプションjava.security.managerjava.security.policy を使用して設定されます。

4.3. Java Security Manager 内での JBoss Enterprise Application Platform の実行

Java Security Manager ポリシーを指定するには、ブートストラッププロセス中にドメインまたはサーバーインスタンスに渡す Java オプションを編集する必要があります。このため、domain.sh スクリプトまたは standalone.sh スクリプトにパラメーターをオプションとして渡すことはできません。次の手順を実行すると、インスタンスが Java Security Manager ポリシー内で実行されるよう設定できます。

要件

  • この手順を実行する前に、Java Development Kit (JDK) に含まれる policytool コマンドを使用してセキュリティーポリシーを記述する必要があります。この手順では、ポリシーが EAP_HOME/bin/server.policy にあることを前提としています。
  • 設定ファイルを編集する前に、ドメインまたはスタンドアロンサーバーを完全に停止する必要があります。
複数のシステムにドメインメンバーが分散されている場合は、ドメインの各物理ホストまたはインスタンスに対して次の手順を実行してください。

手順4.1 設定ファイルの編集

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

    編集のために設定ファイルを開きます。このファイルは、管理対象ドメインを使用しているか、スタンドアロンサーバーを使用しているかに応じて、2 つの場所のいずれかに存在します。これは、サーバーまたはドメインを起動するために使用される実行可能ファイルではありません。
    • 管理対象ドメイン

      EAP_HOME/bin/domain.conf
    • スタンドアロンサーバー

      EAP_HOME/bin/standalone.conf
  2. ファイルの最後に Java オプションを追加します。

    以下の行をファイルの最後に追加します。-Djava.security.policy 値を変更してセキュリティーポリシーの場所を指定できます。改行をせずに 1 行で指定する必要があります。デバッグレベルを指定して -Djava.security.debug を変更し、さらに多くの情報または少ない情報をログに記録できます。最も冗長なのは failure,access,policy です。
    JAVA_OPTS="$JAVA_OPTS -Djava.security.manager -Djboss.home.dir=$PWD/.. -Djava.security.policy==$PWD/server.policy -Djava.security.debug=failure"
    
    
  3. ドメインサーバーを起動します。

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

4.4. Java Security Manager ポリシーの記述

はじめに

ほとんどの JDK および JRE ディストリビューションには、Java Security Manager セキュリティーポリシーを作成および編集するための policytool という名前のアプリケーションが含まれます。policytool の詳細については、http://docs.oracle.com/javase/6/docs/technotes/tools/ を参照してください。

基本情報

セキュリティーポリシーは、次の設定要素から構成されます。

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

手順4.2 新しい Java Security Manager ポリシーの設定

  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. 既存のポリシーを削除します。

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

JBoss Enterprise Application Platform に固有なパーミッション

org.jboss.security.SecurityAssociation.getPrincipalInfo
org.jboss.security.SecurityAssociation.getPrincipal() メソッドと getCredential() メソッドにアクセスを提供します。このランタイムパーミッションを使用する場合、現在のスレッド呼び出し元プリンシパルとクレデンシャルを設定できるというリスクが発生します。
org.jboss.security.SecurityAssociation.getSubject
org.jboss.security.SecurityAssociationgetSubject() メソッドにアクセスを提供します。
org.jboss.security.SecurityAssociation.setPrincipalInfo
org.jboss.security.SecurityAssociation.setPrincipal() メソッド、setCredential() メソッド、 setSubject() メソッド、pushSubjectContext() メソッド、および popSubjectContext() メソッドにアクセスを提供します。このランタイムパーミッションを使用する場合、現在のスレッド呼び出し元プリンシパルとクレデンシャルを見ることができるというリスクが発生します。
org.jboss.security.SecurityAssociation.setServer
org.jboss.security.SecurityAssociation.setServer() メソッドにアクセスを提供します。このランタイムパーミッションを使用する場合、呼び出し元プリンシパルとクレデンシャルのマルチスレッドストレージを有効または無効にできるというリスクが発生します。
org.jboss.security.SecurityAssociation.setRunAsRole
org.jboss.security.SecurityAssociation.pushRunAsRole() メソッド、popRunAsRole() メソッド, pushRunAsIdentity() メソッド、および popRunAsIdentity() メソッドにアクセスを提供します。このランタイムパーミッションを使用する場合、現在の呼び出し元プリンシパルの run-as ロールプリンシパルを変更できるというリスクが発生します。
org.jboss.security.SecurityAssociation.accessContextInfo
org.jboss.security.SecurityAssociationaccessContextInfo および accessContextInfo の getter および setter メソッドにアクセスを提供します。これにより、現在のセキュリティーコンテキスト情報を設定および取得できます。
org.jboss.naming.JndiPermission
特別なパーミッションを、指定された JNDI ツリーパスのファイルおよびディレクトリーに提供するか、またはすべてのファイルとディレクトリーに対して再帰的に提供します。JndiPermission は、ファイルまたはディレクトリーに関連するパス名および有効なパーミッションセットから構成されます。
利用可能なパーミッションには以下のものがあります。
  • bind
  • rebind
  • unbind
  • lookup
  • list
  • listBindings
  • createSubcontext
  • all
/* で終わるパス名は、指定されたパーミッションがパス名のすべてのファイルとディレクトリに適用されることを示します。/- で終わるパス名は、パス名のすべてのファイルとサブディレクトリに対して再帰的にパーミッションが与えられることを示します。パス名は、任意のディレクトリーの任意のファイルに一致する特別なトークン <<ALL BINDINGS>> から構成されます。
org.jboss.security.srp.SRPPermission
プライベートセッションキーやプライベートキーなどの機密性の高い SRP 情報へのアクセスを保護するカスタムパーミッションクラス。getSessionKey ターゲットは、SRP ネゴシエーションの結果得られるプライベートセッションへのアクセスを提供します。このキーへのアクセスでは、セッションキーで暗号化されたメッセージを暗号化および復号化できます。
org.hibernate.secure.HibernatePermission
このパーミッションクラスは、Hibernate セッションをセキュアにする基本的なパーミッションを提供します。このプロパティーのターゲットはエンティティー名です。利用可能なアクセスには以下のものがあります。
  • insert
  • delete
  • update
  • read
  • * (all)
org.jboss.metadata.spi.stack.MetaDataStackPermission
読み出し元がメタデータスタックと対話する方法を制御するカスタムパーミッションクラスを提供します。利用可能なパーミッションは以下のとおりです。
  • modify
  • push (スタックに対する)
  • pop (スタックから)
  • peek (スタックに対する)
  • * (all)
org.jboss.config.spi.ConfigurationPermission
設定プロパティーの設定をセキュアにします。パーミッションターゲット名のみを定義し、アクションを定義しません。このプロパティーのターゲットには以下のものが含まれます。
  • <property name> (このコードが設定するパーミッションを持つプロパティー)
  • * (すべてのプロパティー)
org.jboss.kernel.KernelPermission
カーネル設定へのアクセスをセキュアにします。パーミッションターゲット名のみを定義し、アクションを定義しません。このプロパティーのターゲットには以下のものが含まれます。
  • access (カーネル設定に対する)
  • configure (アクセスを含む)
  • * (all)
org.jboss.kernel.plugins.util.KernelLocatorPermission
カーネルへのアクセスをセキュアにします。パーミッションターゲット名のみを定義し、アクションを定義しません。このプロパティーのターゲットには以下のものが含まれます。
  • kernel
  • * (all)

4.5. Security Manager ポリシーのデバッグ

デバッグ情報を有効にすると、セキュリティーポリシーに関する問題のトラブルシューティングに便利です。java.security.debug オプションは、報告されたセキュリティー関連情報のレベルを設定します。コマンド java -Djava.security.debug=help は、すべてのデバッグオプションのヘルプ出力を表示します。デバッグレベルを all に設定すると、原因がまったくわからないセキュリティー関連の障害をトラブルシューティングするときに役に立ちますが、一般的な使用には多すぎる量の情報が表示されます。一般的に適切なデフォルト値は access:failure です。

手順4.3 一般的なデバッグの有効化

  • この手順を実行すると、セキュリティー関連デバッグ情報の一般的な機密レベルを有効にすることができます。

    次の行をサーバー設定ファイルに追加します。
    • 管理対象ドメインで JBoss Enterprise Application Platform インスタンスが実行されている場合、以下の行は Linux では bin/domain.conf ファイル、Windows では bin/domain.conf.bat ファイルに追加されます。
    • JBoss Enterprise Application Platform インスタンスがスタンドアロンサーバーとして実行されている場合、以下の行は Linux では bin/standalone.conf ファイル、Windows では bin\standalone.conf.bat ファイルに追加されます。
Linux
JAVA_OPTS="$JAVA_OPTS -Djava.security.debug=access:failure"
Windows
JAVA_OPTS="%JAVA_OPTS% -Djava.security.debug=access:failure"
結果

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

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

5.1. パッチングの仕組み

JBoss のセキュリティーおよびバグパッチは 2 つの形式でリリースされます。
  • 計画された更新: 既存製品のマイクロ、マイナー、またはメジャーアップグレード。
  • 非同期更新: 既存製品の通常のアップグレードサイクル以外にリリースされる 1 回限りのパッチ。
パッチが計画された更新の一部としてリリースされるか、それとも 1 回限りのパッチとしてリリースされるかは、修正される欠陥の深刻度によって決まります。通常、深刻度が低い欠陥は、対象製品の次回マイナーリリースで解決されます。深刻度が中程度以上の場合、非同期リリースによる製品の更新として重要度の高い順に対処され、その時点における欠陥の解決法のみが含まれます。
セキュリティー欠陥の深刻度は、Red Hat セキュリティーレスポンスチームが行うバグの評価が基準となり、次のような要因の組み合わせで評価されます。
  • バグ悪用の容易さ。
  • 悪用された場合、どのような被害があるか。
  • 欠陥の影響を低減する他の要素はあるか (ファイアウォール、Security-Enhanced Linux、コンパイラー指示文など)。
Red Hat は、セキュリティー関連の欠陥をサブスクライバーに通知するメーリングリストを管理しています。「パッチメーリングリストへのサブスクライブ」 を参照してください。
JBoss のセキュリティー欠陥を評価する方法についての詳細は、http://securityblog.redhat.com/2012/09/19/how-red-hat-rates-jboss-security-flaws/ を参照してください。

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

概要

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

要件

  • なし

手順5.1 JBoss Watch List へのサブスクライブ

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

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

5.3. zip 形式のパッチをインストールする

概要

JBoss セキュリティーパッチは、zip (全製品) と RPM (製品のサブセット) の 2 つの形式で配布されます。JBoss バグ修正パッチは zip 形式でのみ配布されます。このタスクでは、zip 形式でパッチ (セキュリティーまたはバグ修正) をインストールするために必要な手順について説明します。

要件

  • Red Hat カスタマーポータルへの有効なアクセスおよびサブスクリプション。
  • zip 形式でインストールされた JBoss 製品の現在のサブスクリプション。

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

JBoss 製品のセキュリティー更新はエラータによって提供されます (zip および RPM 両方)。エラータは、解決された欠陥、それらの深刻度、影響する製品、欠陥の詳細、およびパッチへの参照が含まれるリストをカプセル化します。バグ修正の更新はエラータによって通知されません。
JBoss 製品の zip ディストリビューションでは、パッチ zip がダウンロードできるカスタマーポータルの URL へのリンクがエラータに含まれています。このダウンロードには、既存 JBoss 製品のパッチ適用済みのバージョンが含まれ、以前のインストールから変更があったファイルのみが含まれています。

警告

パッチをインストールする前に、JBoss 製品とカスタマイズされた設定ファイルをすべてバックアップする必要があります。
  1. JBoss watch メーリングリストにサブスクライブするか、JBoss watch メーリングリストのアーカイブを閲覧して、セキュリティーパッチに関する情報を入手します。

    注記

    JBoss watch メーリングリストではセキュリティーパッチのお知らせのみが通知されます。
  2. エラータを読んでセキュリティーパッチに関する情報を取得し、使用環境の JBoss 製品に適用されることを確認します。
  3. セキュリティーパッチが使用環境の JBoss 製品に適用される場合は、リンク先の Red Hat カスタマーポータルからパッチをダウンロードします。
  4. カスタマーポータルのダウンロード可能な zip ファイルには、セキュリティーの問題やバグの修正に必要なファイルがすべて含まれています。ご使用の JBoss 製品がある場所にこのパッチ zip ファイルをダウンロードします。
  5. JBoss 製品がインストールされている場所でパッチファイルを展開します。パッチ適用済みのバージョンは既存ファイルを上書きします。
結果

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

5.4. RPM 形式のパッチをインストールする

概要

JBoss のパッチは、zip (全製品) と RPM (製品のサブセット) の 2 つの形式で配布されます。このタスクでは、RPM 形式でパッチをインストールするために必要な手順について説明します。RPM の更新方法は、セキュリティー非同期パッチと、製品のマクロ、マイナー、およびメジャー更新のみを配布するために使用されます。

要件

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

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

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

警告

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

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

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

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

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

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

例5.1 CVSS v2 の影響スコア

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

第6章 セキュリティードメイン

6.1. セキュリティードメインについて

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

6.2. Picketbox について

Picketbox は、認証、許可、監査、およびマッピング機能を、JBoss Enterprise Application Platform で実行されている Java アプリケーションに提供する基礎的なセキュリティーフレームワークです。単一の構成の単一のフレームワークで、次の機能を提供します。

6.3. 認証について

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

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

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

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

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

    管理コンソールの右上にある Profiles ラベルをクリックします。管理対象ドメインで、Profile ビューの左上にある Profile 選択ボックスから変更するプロファイルを選択します。左側の Security メニュー項目をクリックし、展開されたメニューで Security Domains をクリックします。編集するセキュリティードメインの View リンクをクリックします。
  2. 認証サブシステム設定に移動します。

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

    Add ボタンをクリックして JAAS 認証モジュールを追加します。モジュールの詳細を記入します。Code がモジュールのクラス名です。Flags は、モジュールが同じセキュリティードメイン内で他の認証モジュールにどのように関係するかを制御します。
    フラグの説明

    Java Enterprise Edition 6 の仕様では、セキュリティーモジュールの次の説明が提供されます。次のリストは、http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA に記載されています。詳細については、このドキュメントを参照してください。

    フラグ 詳細
    required
    LoginModule は成功する必要があります。成功または失敗すると、LoginModule リストで認証が引き続き続行されます。
    requisite
    LoginModule は成功する必要があります。成功すると、LoginModule リストで認証が続行されます。失敗すると、制御がアプリケーションにすぐに戻ります (認証は LoginModule リストで続行されません)。
    sufficient
    LoginModule は成功する必要はありません。成功した場合は、制御がアプリケーションにすぐに戻ります (認証は LoginModule リストで続行されません)。失敗すると、認証は LoginModule リストで続行されます。
    optional
    LoginModule は成功する必要がありません。成功または失敗した場合、認証は LoginModule リストで続行されます。
    モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code または Flags を変更できます。Attributes タブが選択されていることを確認します。
  4. モジュールオプションを追加、編集、または削除します (任意)。

    モジュールにオプションを追加する必要がある場合は、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 Enterprise Application Platform の起動時にシステムプロパティーを true に設定します。以下を起動パラメーターに追加します。
-Djboss.security.disable.secdomain.option=true
Web ベースの管理コンソールを使用してこのプロパティーを設定することも可能です。スタンドアロンサーバーでは、システムプロパティーを設定の Profile セクションに設定できます。管理対象ドメインでは、各サーバーグループのシステムプロパティーを設定できます。

6.5. 承認について

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

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

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

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

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

    管理コンソールの右上にある Profiles ラベルをクリックします。管理対象ドメインで、Profile ビューの左上にある Profile 選択ボックスから変更するプロファイルを選択します。左側の Security メニュー項目をクリックし、展開されたメニューで Security Domains をクリックします。編集するセキュリティードメインの View リンクをクリックします。
  2. 承認サブシステム設定に移動します。

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

    Add ボタンをクリックして JAAS 承認ポリシーモジュールを追加します。モジュールの詳細を記入します。Code がモジュールのクラス名です。Flags は、モジュールが同じセキュリティードメイン内で他の承認ポリシーモジュールにどのように関係するかを制御します。
    フラグの説明

    Java Enterprise Edition 6 の仕様では、セキュリティーモジュールの次の説明が提供されます。次のリストは、http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA に記載されています。詳細については、このドキュメントを参照してください。

    フラグ 詳細
    required
    LoginModule は成功する必要があります。成功または失敗すると、LoginModule リストで承認が引き続き続行されます。
    requisite
    LoginModule は成功する必要があります。成功すると、LoginModule リストで承認が続行されます。失敗すると、制御がアプリケーションにすぐに戻ります (承認は LoginModule リストで続行されません)。
    sufficient
    LoginModule は成功する必要はありません。成功した場合は、制御がアプリケーションにすぐに戻ります (承認は LoginModule リストで続行されません)。失敗すると、承認は LoginModule リストで続行されます。
    optional
    LoginModule は成功する必要がありません。成功または失敗した場合、承認は LoginModule リストで続行されます。
    モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code または Flags を変更できます。Attributes タブが選択されていることを確認します。
  4. モジュールオプションを追加、編集、または削除します (任意)。

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

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

6.7. セキュリティー監査について

セキュリティー監査とは、セキュリティーサブシステム内で発生したイベントに応答するため、ログへの書き込みなどのイベントをトリガーすることです。監査のメカニズムは、認証、承認、およびセキュリティーマッピングの詳細と共に、セキュリティードメインの一部として設定されます。
監査にはプロバイダーモジュールが使用されます。含まれているプロバイダーモジュールを使用するか、独自のモジュールを実装することができます。

6.8. セキュリティー監査の設定

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

手順6.3 セキュリティードメインのセキュリティー監査の設定

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

    管理コンソールの右上にある Profiles ラベルをクリックします。スタンドアロンサーバーでは、タブに Profile ラベルがあります。管理対象ドメインでは、Profile ビューの左上にある Profile 選択ボックスから変更するプロファイルを選択します。左側の Security メニュー項目をクリックし、展開されたメニューで Security Domains をクリックします。編集するセキュリティードメインの View リンクをクリックします。
  2. 監査サブシステム設定に移動します。

    ビューの最上部の Audit ラベルをクリックします (まだ設定されていない場合)。
    設定領域が Provider ModulesDetails の 2 つの領域に分割されます。プロバイダーモジュールは、設定の基本単位です。セキュリティードメインには複数のプロバイダーモジュールを含めることができ、各ログインモジュールには属性とオプションを含めることができます。
  3. プロバイダーモジュールを追加します。

    Add ボタンをクリックしてプロアクティブモジュールを追加します。Code セクションに、プロバイダーモジュールのクラス名を入力します。
    モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code を変更できます。Attributes タブが選択されていることを確認します。
  4. モジュールの挙動を確認します。

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

    モジュールにオプションを追加する必要がある場合は、Modules リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add ボタンをクリックし、オプションのキーと値を提供します。すでに存在するオプションを編集するには、Remove ラベルをクリックして削除するか、Add ボタンをクリックして正しいオプションで再び追加します。
結果

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

6.9. セキュリティーマッピングについて

セキュリティーマッピングを使用すると、認証または承認が実行された後、情報がアプリケーションに渡される前に認証情報と承認情報を組み合わせることができます。この例の 1 つが、X509 証明書を認証に使用した後、プリンシパルを証明書からアプリケーションが表示できる論理名へ変換することです。
プリンシパル (認証) やロール (承認)、証明情報 (プリンシパルやロールでない属性) をマッピングすることが可能です。
ロールマッピングは、認証後にサブジェクトへロールを追加、置換、または削除するために使用されます。
プリンシパルマッピングは、認証後にプリンシパルを変更するために使用されます。
属性マッピングは、外部システムからの属性値をアプリケーションで使用するために変換したり、逆にそのような外部システムへ属性を変換したりするために使用されます。

6.10. セキュリティードメインでのセキュリティーマッピングの設定

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

手順6.4 セキュリティードメインでのセキュリティーマッピングの設定

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

    管理コンソールの右上にある Profiles ラベルをクリックします。スタンドアロンサーバーでは、タブに Profile ラベルがあります。管理対象ドメインでは、Profile ビューの左上にある Profile 選択ボックスから変更するプロファイルを選択します。左側の Security メニュー項目をクリックし、展開されたメニューで Security Domains をクリックします。編集するセキュリティードメインの View リンクをクリックします。
  2. マッピングサブシステム設定に移動します。

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

    Add ボタンをクリックしてセキュリティーマッピングモジュールを追加します。モジュールの詳細を記入します。Code がモジュールのクラス名です。Type フィールドは、このモジュールが実行するマッピングのタイプを示します。許可される値は principal、role、attribute、または credential です。
    モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code または Type を変更できます。Attributes タブが選択されていることを確認します。
  4. モジュールオプションを追加、編集、または削除します (任意)。

    モジュールにオプションを追加する必要がある場合は、Modules リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add ボタンをクリックし、オプションのキーと値を提供します。すでに存在するオプションを編集するには、Remove ラベルキーをクリックして削除するか、新しい値で再び追加します。Remove ボタンを使用してオプションを削除します。
結果

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

第7章 SSL 暗号化

7.1. SSL 暗号化について

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

7.2. JBoss Enterprise Application Platform Web Server での SSL 暗号化の実装

はじめに

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

要件

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

注記

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

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

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

    プロファイルを適切に変更し、以下の管理 CLI コマンドを実行します。これにより、HTTPS という名前のセキュアコネクターが新規作成されます。これは https スキーム、https ソケットバインディング (デフォルト値は 8443) を使用し、セキュアに設定されます。

    例7.1 管理 CLI コマンド

    /profile=default/subsystem=web/connector=HTTPS/:add(socket-binding=https,scheme=https,protocol=HTTP/1.1,secure=true)
    
  2. SSL 暗号化証明書およびキーを設定します。

    例の値を独自の値に置き換え、以下の CLI コマンドを実行して SSL 証明書を設定します。この例では、キーストアはサーバー設定ディレクトリ (管理対象ドメインでは EAP_HOME/domain/configuration/) へコピーされることを想定しています。

    例7.2 管理 CLI コマンド

    /profile=default/subsystem=web/connector=HTTPS/ssl=configuration:add(name=https,certificate-key-file=${jboss.server.config.dir}/keystore.jks,password=SECRET, key-alias=KEY_ALIAS)
    
    コネクターの SSL プロパティーに設定できるパラメーターの完全な一覧については、「SSL コネクターリファレンス」を参照してください。
  3. アプリケーションをデプロイします。

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

7.3. 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 コマンドの固有な説明は範囲外です。

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

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

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

    注記

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

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

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

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

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

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

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

    注記

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

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

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

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

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

表7.1 SSL コネクター属性

属性 説明 CLI コマンド
name
SSL コネクターの表示名。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=name,value=https)
verify-client
接続を受け入れる前にクライアントから有効な証明書チェーンが必要な場合は、true に設定します。SSL スタックでクライアント証明書を要求し、クライアント証明書が提示されない場合でもエラーが発生しないようにするには、want に設定します。CLIENT-CERT 認証を使用するセキュリティー制約によって保護されたリソースをクライアントが要求する場合を除き、証明書チェーンを必要としないときは false (デフォルト値) に設定します。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=verify-client,value=want)
verify-depth
クライアントが有効な証明を持たないと判断するまでにチェックされる中間証明書発行者の最大数。デフォルト値は 10 です。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=verify-depth,value=10)
certificate-key-file
署名済みサーバー証明書が格納されるキーストアの完全ファイルパスおよびファイル名。JSSE 暗号化の場合、この証明書ファイルが唯一のファイルになり、OpenSSL は複数のファイルを使用します。デフォルト値は JBoss Enterprise Application Platform を実行しているユーザーのホームディレクトリー内にある .keystore ファイルになります。keystoreType がファイルを使用しない場合は、パラメーターを空の文字列に設定します。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=certificate-key-file,value=../domain/configuration/server.keystore)
certificate-file
OpenSSL 暗号化を使用する場合は、このパラメーターの値を、サーバー証明書を含むファイルに対するパスに設定します。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=certificate-file,value=server.crt)
password
トラストストアおよびキーストアに対するパスワード。デフォルト値は changeit であるため、設定が動作するためにはキーストアのパスワードに一致するようこの値を変更する必要があります。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=password,value=changeit)
protocol
使用する SSL プロトコルのバージョン。サポートされる値には、SLv2SSLv3TLSv1SSLv2+SSLv3、および ALL があります。デフォルト値は ALL です。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=protocol,value=ALL)
cipher-suite
許可される暗号のカンマ区切りのリスト。JSSE の JVM デフォルト値には、使用すべきでない強度が低い暗号が含まれます。例では可能な暗号が 2 つのみですが、実際ではそれ以上の暗号を使用することになります。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=cipher-suite, value="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA")
key-alias
キーストア内のサーバー証明書に使用されるエイリアス。デフォルト値は jboss です。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=key-alias,value=jboss)
truststore-type
トラストストアのタイプ。PKCS12 や Java の標準 JKS など、さまざまなタイプのキーストアが使用可能です。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=truststore-type,value=jks)
keystore-type
キーストアのタイプ。PKCS12 や Java の標準 JKS など、さまざまなタイプのキーストアが使用可能です。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=keystore-type,value=jks)
ca-certificate-file
CA 証明書が含まれるファイル。JSSE の場合、これは truststoreFile であり、キーストアと同じパスワードを使用します。クライアント証明書を検証するには、ca-certificate-file ファイルが使用されます。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=certificate-file,value=ca.crt)
ca-certificate-password
ca-certificate-file の証明書パスワード。下記の例では、パスワードを独自のマスクされたパスワードに置き換えます。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=ca-certificate-password,value=MASKED_PASSWORD)
ca-revocation-url
呼び出しリストが含まれるファイルまたは URL。JSSE の場合は、crlFile を参照し、SSL の場合は、SSLCARevocationFile を参照します。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=ca-revocation-url,value=ca.crl)
session-cache-size
SSLSession キャッシュのサイズ。デフォルト値は 0 であり、セッションキャッシュを無効にします。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=session-cache-size,value=100)
session-timeout
キャッシュされた SSLSession の有効期限が切れるまでの秒数。デフォルト値は 86400 秒 (24 時間) です。
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=session-timeout,value=43200)

第8章 セキュリティレルム

8.1. セキュリティーレルムについて

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

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

  1. Management CLI を実行します。

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

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

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

    注記

    新規作成されたプロパティーファイルは、含まれる add-user.sh および add-user.bat スクリプトによって管理されません。そのため、外部から管理する必要があります。
    /host=master/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
結果

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

8.3. セキュリティーレルムへユーザーを追加

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

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

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

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

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

第9章 サブシステムの設定

9.1. トランザクションサブシステムの設定

9.1.1. JTS トランザクション用 ORB の設定

JBoss Enterprise Application Platform のデフォルトインストールでは、ORB が無効になります。ORB は、コマンドライン管理 CLI を使用して有効にすることができます。

注記

管理対象ドメインでは、JacORB サブシステムが full および full-ha プロファイルでのみ利用可能です。スタンドアロンサーバーでは、standalone-full.xml または standalone-full-ha.xml 設定で利用可能です。

手順9.1 管理コンソールを使用した ORB の設定

  1. プロファイル設定を表示します。

    管理コンソールの右上から Profiles (管理対象ドメイン) または Profile (スタンドアロンサーバー) を選択します。管理対象ドメインを使用する場合は、左上にある選択ボックスから full または full-ha プロファイルを選択します。
  2. Initializers 設定の変更

    必要な場合は、左側にある Subsystems メニューを展開します。Container サブメニューを展開し、JacORB をクリックします。
    メイン画面に表示されるフォームで、Initializers タブを選択し、Edit ボタンをクリックします。
    Security の値を on に設定して、セキュリティーインターセプターを有効にします。
    JTS 用 ORB を有効にするには、Transaction Interceptors 値をデフォルトの spec ではなく on に設定します。
    これらの値に関する詳細な説明については、フォームの Need Help? リンクを参照してください。値の編集が完了したら、Save をクリックします。
  3. 高度な ORB 設定

    高度な設定オプションについては、フォームの他のセクションを参照してください。各セクションには、パラメーターに関する詳細な情報とともに Need Help? リンクが含まれます。
管理 CLI を使用して ORB を設定

管理 CLI を使用して ORB の各側面を設定できます。以下のコマンドは、管理コンソールに対するイニシャライザーに上記の手順と同じ値を設定します。これは、JTS と使用する ORB の最小設定です。

これらのコマンドは、full プロファイルを使用して管理対象ドメインに対して設定されます。必要な場合は、設定する必要があるプロファイルに合わせてプロファイルを変更します。スタンドアロンサーバーを使用する場合は、コマンドの /profile=full 部分を省略します。

例9.1 セキュリティーインターセプターの有効化

/profile=full/subsystem=jacorb/:write-attribute(name=security,value=on)

例9.2 JTS 用 ORB の有効化

/profile=full/subsystem=jacorb/:write-attribute(name=transactions,value=on)

9.2. JMS の設定

9.2.1. HornetQ 設定属性のリファレンス

HornetQ の JBoss Enterprise Application Platform 6 実装では、設定の以下の属性が公開されます。管理 CLI を使用すると、read-resource 操作で設定可能または表示可能な属性を公開できます。

例9.3 例

[standalone@localhost:9999 /] /subsystem=messaging/hornetq-server=default:read-resource

表9.1 HornetQ 属性

属性 サンプル値 タイプ
allow-failback true BOOLEAN
async-connection-execution-enabled true BOOLEAN
backup false BOOLEAN
cluster-password somethingsecure STRING
cluster-user HORNETQ.CLUSTER.ADMIN.USER STRING
clustered false BOOLEAN
connection-ttl-override -1 LONG
create-bindings-dir true BOOLEAN
create-journal-dir true BOOLEAN
failback-delay 5000 LONG
failover-on-shutdown false BOOLEAN
id-cache-size 2000 INT
jmx-domain org.hornetq STRING
jmx-management-enabled false BOOLEAN
journal-buffer-size 100 LONG
journal-buffer-timeout 100 LONG
journal-compact-min-files 10 INT
journal-compact-percentage 30 INT
journal-file-size 102400 LONG
journal-max-io 1 INT
journal-min-files 2 INT
journal-sync-non-transactional true BOOLEAN
journal-sync-transactional true BOOLEAN
journal-type ASYNCIO STRING
live-connector-ref reference STRING
log-journal-write-rate false BOOLEAN
management-address jms.queue.hornetq.management STRING
management-notification-address hornetq.notifications STRING
memory-measure-interval -1 LONG
memory-warning-threshold 25 INT
message-counter-enabled false BOOLEAN
message-counter-max-day-history 10 INT
message-counter-sample-period 10000 LONG
message-expiry-scan-period 30000 LONG
message-expiry-thread-priority 3 INT
page-max-concurrent-io 5 INT
perf-blast-pages -1 INT
persist-delivery-count-before-delivery false BOOLEAN
persist-id-cache true BOOLEAN
persistence-enabled true BOOLEAN
remoting-interceptors 未定義 LIST
run-sync-speed-test false BOOLEAN
scheduled-thread-pool-max-size 5 INT
security-domain other STRING
security-enabled true BOOLEAN
security-invalidation-interval 10000 LONG
server-dump-interval -1 LONG
shared-store true BOOLEAN
started true BOOLEAN
thread-pool-max-size 30 INT
transaction-timeout 300000 LONG
transaction-timeout-scan-period 1000 LONG
version 2.2.16.Final (HQ_2_2_16_FINAL, 122) STRING
wild-card-routing-enabled true BOOLEAN

警告

journal-file-size の値がサーバーへ送信されたメッセージのサイズよりも大きくないと、サーバーはメッセージを格納できません。

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

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

マスターは、mod_cluster サブシステムを介して 1 度だけ設定されます。mod_cluster サブシステムを設定するには、『管理および設定ガイド』 の 『mod_cluster サブシステムの設定』 を参照してください。各ワーカーノードは別々に設定されるため、クラスターを追加する各ノードに対してこの手順を繰り返してください。
管理対象ドメインを使用する場合、サーバーグループ内の各サーバーは同一の設定を共有するワーカーノードです。したがって、設定はサーバーグループ全体に対して行われます。スタンドアロンサーバーでは、設定は、単一の JBoss Enterprise Application Platform インスタンスに対して行われます。設定手順はそれ以外は同じです。

ワーカーノード設定

  • スタンドアロンサーバーを使用する場合は、スタンドアロンサーバーを standalone-ha プロファイルで起動する必要があります。
  • 管理対象ドメインを使用する場合、サーバーグループは ha または full-ha プロファイルとha-sockets または full-ha-sockets ソケットバインディンググループを使用する必要があります。JBoss Enterprise Application Platform には、これらの要件を満たす other-server-group という名前のクラスター対応サーバーグループが同梱されます。

注記

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

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

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

    デフォルトでは、ネットワークインターフェースがすべて 127.0.0.1 に設定されます。スタンドアロンサーバーまたはサーバーグループ内の 1 つまたは複数のサーバーをホストする各物理ホストでは、インターフェースが他のサーバーが見つけることができるパブリック IP アドレスを使用するよう設定する必要があります。
    JBoss Enterprise Application Platform ホストの IP アドレスを変更するには、ホストをシャットダウンし、設定ファイルを直接編集する必要があります。これは、管理コンソールと管理 CLI を駆動する管理 API は固定管理アドレスに依存するためです。
    クラスター内の各サーバーの IP アドレスをマスターのパブリック IP アドレスに変更するには、次の手順を実行します。
    1. サーバーを完全にシャットダウンします。
    2. EAP_HOME/domain/configuration/ 内にある管理対象ドメイン用の host.xml または EAP_HOME/standalone/configuration/ 内にあるスタンドアロンサーバー用の standalone-ha.xml を編集します。
    3. <interfaces> 要素を見つけます。managementpublic、および unsecured の 3 つのインターフェースが設定されます。これらそれぞれに対して、値 127.0.0.1 をホストの外部 IP アドレスに変更します。
    4. 管理対象ドメインに参加し、マスターでないホストの場合は、<host 要素を見つけます。この要素には > 閉じ記号がないことに注意してください。これはこの要素が属性を含むためです。名前属性の値を master から一意の名前 (スレーブごとに異なる名前) 変更します。この名前は、スレーブがクラスター対して身元を示すためにも使用されるため、注意してください。
    5. 管理対象ドメインを参加する必要がある新しく設定されたホストの場合は、<domain-controller> 要素を見つけます。<local /> 要素をコメントアウトまたは削除し、次の行を追加して、IP アドレス (X.X.X.X) をドメインコントローラーのアドレスに変更します。この手順は、スタンドアロンサーバーには適用されません。
      <remote host="X.X.X.X" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm"/>
      
    6. ファイルを保存し、終了します。
  2. 各スレーブサーバーの認証を設定します。

    各スレーブサーバーでは、ドメインコントローラーまたはスタンドアロンマスターの ManagementRealm で作成されたユーザー名とパスワードが必要です。ドメインコントローラーまたはスタンドアロンマスターで、EAP_HOME/add-user.sh コマンドを実行します。同じユーザー名を持つユーザーをスレーブとして ManagementRealm に追加します。このユーザーが外部 JBoss AS インスタンスに対して認証する必要があるかどうか尋ねられた場合は、yes と回答します。パスワード changeme を使用した、slave1 という名前のスレーブに対するコマンドの入力および出力の例は以下のとおりです。
    user:bin user$ ./add-user.sh
    
    What type of user do you wish to add? 
     a) Management User (mgmt-users.properties) 
     b) Application User (application-users.properties)
    (a): a
    
    Enter the details of the new user to add.
    Realm (ManagementRealm) : 
    Username : slave1
    Password : changeme
    Re-enter Password : changeme
    About to add user 'slave1' for realm 'ManagementRealm'
    Is this correct yes/no? yes
    Added user 'slave1' to file '/home/user/jboss-eap-6.0/standalone/configuration/mgmt-users.properties'
    Added user 'slave1' to file '/home/user/jboss-eap-6.0/domain/configuration/mgmt-users.properties'
    Is this new user going to be used for one AS process to connect to another AS process e.g. slave domain controller?
    yes/no? yes
    To represent the user add the following to the server-identities definition <secret value="Y2hhbmdlbWU=" />
    
  3. add-user.sh の出力から Base64 でエンコードされた <secret> 要素をコピーします。

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

    1. スレーブホストの host.xml または standalone-ha.xml ファイルを再度開きます。
    2. <security-realms> 要素を探します。ここにセキュリティーレルムを設定します。
    3. 以下の方法の 1 つを用いて秘密の値を指定できます。
      • 設定ファイルに Base64 でエンコードされたパスワード値を指定します。

        1. 以下の XML コードを <security-realm name="ManagementRealm"> 行のすぐ下に追加します。
          <server-identities>
              <secret value="Y2hhbmdlbWU="/>
          </server-identities>
                          
          
          
          
        2. "Y2hhbmdlbWU=" を前の手順で add-user.sh の出力より返された秘密の値に置き換えます。
      • ホストを設定し、ボールトよりパスワードを取得します。

        1. vault.sh スクリプトを使用してマスクされたパスワードを生成します。次のような文字列が生成されます: VAULT::secret::password::ODVmYmJjNGMtZDU2ZC00YmNlLWE4ODMtZjQ1NWNmNDU4ZDc1TElORV9CUkVBS3ZhdWx0
          ボールトに関する詳細は、「機密性の高い文字列のパスワード vault」の項にある 「クリアテキストファイルでの機密性が高い文字列のセキュア化について」 を参照してください。
        2. 以下の XML コードを <security-realm name="ManagementRealm"> 行のすぐ下に追加します。
          <server-identities>
              <secret value="${VAULT::secret::password::ODVmYmJjNGMtZDU2ZC00YmNlLWE4ODMtZjQ1NWNmNDU4ZDc1TElORV9CUkVBS3ZhdWx0}"/>
          </server-identities>
                          
          
          
          
          必ず秘密の値を前の手順で生成したマスクされたパスワードに置き換えるようにしてください。

          注記

          ボールトでパスワードを作成する場合、Base64 エンコードではなくプレーンテキストで指定する必要があります。
      • システムプロパティーとしてパスワードを指定します。

        1. 以下の XML コードを <security-realm name="ManagementRealm"> 行のすぐ下に追加します。
          <server-identities>
              <secret value=${server.identity.password}/>
          </server-identities>
                          
          
          
          
        2. システムプロパティーとしてパスワードを指定する場合、次の方法のいずれかを用いてホストを設定できます。
          • 次の例のように、プレーンテキストのパスワードをコマンドライン引数として入力し、サーバーを起動します。
            -Dserver.identity.password=changeme

            注記

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

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

第11章 ネットワークセキュリティー

11.1. 管理インターフェースのセキュア化

概要

テスト環境では、管理コンソール、管理 CLI および他の API 実装で構成される管理インターフェース上で、セキュリティーレイヤーがない状態で JBoss Enterprise Application Platform 6 を実行することがよくあります。これにより、開発や設定を迅速に変更できます。

また、デフォルトではサイレント認証モードを使用できるため、ホストマシン上のローカルクライアントはユーザー名またはパスワードを指定せずに管理 CLI に接続できます。この動作は、ローカルユーザーと管理 CLI スクリプトには便利ですが、必要な場合は無効にできます。この手順については、「デフォルトセキュリティーレルムからのサイレント認証の削除」 を参照してください。
本番稼働に移行するために環境のテストおよび準備を開始する場合は、少なくとも以下の方法で管理インターフェースをセキュアにすることが非常に重要です。

11.2. JBoss Enterprise Application Platform が使用するネットワークインターフェースの指定

概要

サービスを必要なクライアントにのみアクセスできるようサービスを隔離すると、ネットワークのセキュリティーが強化されます。JBoss Enterprise Application Platform には、デフォルト設定の 2 つのインターフェースが含まれ、どちらもデフォルトで IP アドレス 127.0.0.1 または localhost にバインドされます。インターフェースの 1 つは management と呼ばれ、管理コンソール、CLI、および API によって使用されます。他のインターフェースは public と呼ばれ、アプリケーションをデプロイするために使用されます。これらのインターフェースは、特別なものではありませんが、作業を始める土台として提供されます。

management インターフェースはデフォルトでポート 9990 と 9999 を使用し、public インターフェースはポート 8080 または 8443 (HTTPS を使用する場合) を使用します。
管理インターフェース、パブリックインターフェース、またはその両方の IP アドレスを変更できます。

警告

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

    オペレーティングシステムに適切な方法で割り込みを送信して JBoss Enterprise Application Platform を停止します。JBoss Enterprise Application Platform をフォアグラウンドアプリケーションとして実行している場合、通常は Ctrl+C を押してこれを行います。
  2. バインドアドレスを指定して JBoss Enterprise Application Platform を再起動します。

    -b コマンドラインスイッチを使用して特定のインターフェースで JBoss Enterprise Application Platform を起動します。

    例11.1 パブリックインターフェースを指定します。

    EAP_HOME/bin/domain.sh -b 10.1.1.1

    例11.2 管理インターフェースを指定します。

    EAP_HOME/bin/domain.sh -bmanagement=10.1.1.1

    例11.3 各インターフェースに異なるアドレスを指定します。

    EAP_HOME/bin/domain.sh -bmanagement=127.0.0.1 -b 10.1.1.1

    例11.4 すべてのネットワークインターフェースにパブリックインターフェースをバインドします。

    EAP_HOME/bin/domain.sh -b 0.0.0.0
XML 設定ファイルを直接編集してデフォルトのバインドアドレスを変更できますが、これを行うと -b コマンドラインスイッチを使用してランタイム時に IP アドレスを指定できなくなるため、お勧めしません。この作業を行う場合は、XML ファイルを編集する前に JBoss Enterprise Application Platform を完全に停止する必要があります。

11.3. JBoss Enterprise Application Platform 6 で動作するようネットワークファイアウォールを設定

概要

ほとんどの本番稼動環境では、ネットワークセキュリティー全体の方針の一部としてファイアウォールを使用します。複数のインスタンスが相互に通信したり、Web サーバーやデータベースなどの外部サービスと通信したりする必要がある場合は、ファイアウォールでこれを考慮する必要があります。適切に管理されたファイアウォールでは、操作する必要があるポートのみが開かれ、特定の IP アドレス、サブネット、およびネットワークプロトコルに対するポートへのアクセスが制限されます。

本書では、ファイアウォールの完全な説明は範囲外になります。

要件

  • 開く必要があるポートを決定します。それぞれの環境のポートのリストを決定するには、「JBoss Enterprise Application Platform 6 により使用されるネットワークポート」を参照してください。
  • ファイアウォールソフトウェアについて理解する必要があります。この手順では、Red Hat Enterprise Linux 6 の system-config-firewall コマンドを使用します。Microsoft Windows Server には、ファイアウォールが組み込まれ、各プラットフォーム用の複数のサードパーティー製ファイアウォールソリューションが利用可能です。
前提

この手順では、以下の前提で環境のファイアウォールを設定します。

  • オペレーティングシステムは Red Hat Enterprise Linux 6 です。
  • JBoss Enterprise Application Platform 6 がホスト 10.1.1.2 で実行されます。オプションで、サーバーには独自のファイアウォールがあります。
  • ネットワークファイアウォールサーバーは、ホスト 10.1.1.1 のインターフェース eth0 で実行され、外部インターフェース eth1 を持ちます。
  • ポート 5445 (JMS で使用されるポート) のトラフィックを JBoss Enterprise Application Platform 6 に転送します。ネットワークファイアウォールで他のトラフィックは許可されません。

手順11.1 ネットワークファイアウォールと JBoss Enterprise Application Platform 6 が共に動作するよう管理

  1. 管理コンソールにログインします。

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

    管理コンソールの右上にある Profiles ラベルをクリックします。画面の左側に一連のメニューが表示されます。下部のメニュー見出しは General Configuration です。この見出しの下の Socket Binding Groups 項目をクリックします。Socket Binding Declarations 画面が表示されます。最初に、standard-sockets グループが表示されます。異なるグループは、右側のコンボボックスで選択することにより選択できます。

    注記

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

    お使いの環境の特別なポートの機能とニーズによっては、一部のポートがファイアウォールを介してアクセスできる必要があります。ソケットバインディングの目的がわからない場合は、「JBoss Enterprise Application Platform 6 により使用されるネットワークポート」を参照して、デフォルトのソケットバインディングとその目的のリストを確認してください。
  4. JBoss Enterprise Application Platform 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 Enterprise Application Platform 6 ホストでファイアウォールを設定します。

    一部の組織では、JBoss Enterprise Application Platform 6 サーバー自体でファイアウォールを設定し、運用に必要ないすべてのポートを閉じます。「JBoss Enterprise Application Platform 6 により使用されるネットワークポート」 を参照して開くポートを決定し、残りのポートを閉じます。Red Hat Enterprise Linux 6 のデフォルトの設定では、22 (Secure Shell (SSH) 用) と 5353 (マルチキャスト DNS 用) 以外のすべてのポートが閉じられます。ポートを設定する場合は、間違ってロックアウトされないよう物理的にアクセスしてください。
結果

ファイアウォールが、ファイアウォール設定で指定したように、内部 JBoss Enterprise Application Platform 6 サーバーにトラフィックを転送します。サーバーでファイアウォールを有効にした場合は、アプリケーションを実行するために必要なポート以外はすべて閉じられます。

11.4. JBoss Enterprise Application Platform 6 により使用されるネットワークポート

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

注記

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

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

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

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

名前 ポート マルチキャストポート 説明 full-ha-sockets full-sockets ha-socket standard-socket
ajp 8009 Apache JServ プロトコル。HTTP クラスタリングおよび負荷分散に使用します。
http 8080 デプロイされた Web アプリケーションのデフォルトポート。
https 8443 デプロイされた Web アプリケーションとクライアント間の SSL 暗号化接続。
jacorb 3528 JTS トランザクションおよび他の ORB 依存サービス用の CORBA サービス。 × ×
jacorb-ssl 3529 SSL 暗号化 CORBA サービス。 × ×
jgroups-diagnostics 7500 マルチキャスト。HA クラスターでピア検出に使用されます。 × ×
jgroups-mping 45700 マルチキャスト。HA クラスタでの初期メンバーシップを検出するために使用されます。 × ×
jgroups-tcp 7600 TCP を使用した、HA クラスター内でのユニキャストピア検出。 × ×
jgroups-tcp-fd 57600 TCP を介した HA 障害検出に使用されます。 × ×
jgroups-udp 55200 45688 UDP を使用した、HA クラスター内でのユニキャストピア検出。 × ×
jgroups-udp-fd 54200 UDP を介した HA 障害検出に使用されます。 × ×
messaging 5445 JMS サービス。 × ×
messaging-group HornetQ JMS ブロードキャストと検出グループにより参照されます。 × ×
messaging-throughput 5455 JMS Remoting により使用されます。 × ×
mod_cluster 23364 JBoss Enterprise Application Platform と HTTP ロードバランサー間の通信に対するマルチキャストポート。 × ×
osgi-http 8090 OSGi サブシステムを使用する内部コンポーネントにより使用されます。
remoting 4447 リモート EJB の呼び出しに使用されます。
txn-recovery-environment 4712 JTA トランザクションリカバリーマネージャー。
txn-status-manager 4713 JTA / JTS トランザクションマネージャー。
管理ポート

ソケットバインディンググループ以外に、各ホストコントローラーは管理用にさらに 2 つのポートを開きます。

  • 9990 - Web 管理コンソールポート
  • 9999 - 管理コンソールと管理 API により使用されるポート

パート III. アプリケーションのセキュア化

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

12.1. 記述子ベースのプロパティー置換の有効化/無効化

警告

Topic 9089, Revision 431229 failed validation and is not included in this build.

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

12.2.1. データソースセキュリティーについて

データソースセキュリティーのソリューションには、セキュリティードメインまたはパスワード vault のいずれかを使用することが推奨されます。以下にそれぞれの例を示します。詳細については、以下のドキュメントを参照してください。

例12.1 セキュリティードメインの例

<security>
   <security-domain>mySecurityDomain</security-domain>
</security>

例12.2 パスワード vault の例

<security>
  <user-name>admin</user-name>
  <password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password>
</security>


12.3. EJB アプリケーションセキュリティー

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

12.3.1.1. EJB のセキュリティーアイデンティティーについて

セキュリティーアイデンティティー呼び出しアイデンティティー とも呼ばれており、セキュリティー設定では <security-identity> タグのことです。これは、EJB がコンポーネントでメソッド呼び出しを行う際に必ず使う必要のあるアイデンティティーを指します。
呼び出しアイデンティティーは現在の呼び出し元か特定のロールのいずれかになります。現在の呼び出し元である場合は、<use-caller-identity> タグがあり、特定ロールの場合は <run-as> タグが使用されます。
EJB のセキュリティーアイデンティティー設定に関する情報は 「EJB のセキュリティーアイデンティティーの設定」 を参照してください。

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

例12.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>

例12.4 特定ロールに EJB のセキュリティーアイデンティティーを設定する

特定のロールにセキュリティーアイデンティティーを設定するには、<security-identity> タグの中に <run-as> または <role> タグを使用します。
<ejb-jar>
  <enterprise-beans>
	 <session>
		<ejb-name>RunAsBean</ejb-name>
		<!-- ... -->
		<security-identity>
		  <run-as>
			 <description>A private internal role</description>
			 <role-name>InternalRole</role-name>
		  </run-as>
		</security-identity>
	 </session>
  </enterprise-beans>
  <!-- ... -->
</ejb-jar>

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

注記

サーブレット要素内に <run-as> 要素と <run-as-principal> 要素を使用することもできます。

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

12.3.2.1. EJB メソッドパーミッションについて

EJB は <method-permisison> 要素の宣言を提供します。この宣言により、EJB のインターフェースメソッドを呼び出し可能なロールを設定します。以下の組み合わせに対してパーミッションの指定が可能です。
  • 名前付き EJB のホームおよびコンポーネントインターフェースメソッド
  • 名前付き EJB のホームあるいはコンポーネントインターフェースの指定メソッド
  • オーバーロードした名前を持つメソッドセット内の指定メソッド
例は 「EJB メソッドパーミッションの使用」 を参照してください。

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

概要

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

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

例12.5 ロールが EJB の全メソッドへのアクセスできるようにする

<method-permission>
  <description>The employee and temp-employee roles may access any method
  of the EmployeeService bean </description>
  <role-name>employee</role-name>
  <role-name>temp-employee</role-name>
  <method>
    <ejb-name>EmployeeService</ejb-name>
    <method-name>*</method-name>
  </method>
</method-permission>
	


例12.6 EJB の特定メソッドへのみロールがアクセスできるようにし、パラメーターが渡すことができるメソッドを制限します。

<method-permission>
  <description>The employee role may access the findByPrimaryKey,
  getEmployeeInfo, and the updateEmployeeInfo(String) method of
  the AcmekPayroll bean </description>
  <role-name>employee</role-name>
  <method>
	<ejb-name>AcmekPayroll</ejb-name>
	<method-name>findByPrimaryKey</method-name>
  </method>
  <method>
	<ejb-name>AcmePayroll</ejb-name>
	<method-name>getEmployeeInfo</method-name>
  </method>
  <method>
	<ejb-name>AcmePayroll</ejb-name>
	<method-name>updateEmployeeInfo</method-name>
	<method-params>
	  <method-param>java.lang.String</method-param>
	</method-params>
  </method>
</method-permission>


例12.7 認証された全ユーザーが EJB のメソッドにアクセスできるようにする

<unchecked/> 要素を使用すると、認証された全ユーザーが指定のメソッドを使用できます。
<method-permission>
  <description>Any authenticated user may access any method of the
  EmployeeServiceHelp bean</description>
  <unchecked/>
  <method>
	<ejb-name>EmployeeServiceHelp</ejb-name>
	<method-name>*</method-name>
  </method>
</method-permission>


例12.8 特定の EJB メソッドを完全に除外して使用されないようにする

<exclude-list>
  <description>No fireTheCTO methods of the EmployeeFiring bean may be
  used in this deployment</description>
  <method>
	<ejb-name>EmployeeFiring</ejb-name>
	<method-name>fireTheCTO</method-name>
  </method>
</exclude-list>


例12.9 複数の <method-permission> ブロックが含まれる完全な <assembly-descriptor>

<ejb-jar>
    <assembly-descriptor>
        <method-permission>
            <description>The employee and temp-employee roles may access any
                method of the EmployeeService bean </description>
            <role-name>employee</role-name>
            <role-name>temp-employee</role-name>
            <method>
                <ejb-name>EmployeeService</ejb-name>
                <method-name>*</method-name>
            </method>
        </method-permission>
        <method-permission>
            <description>The employee role may access the findByPrimaryKey,
                getEmployeeInfo, and the updateEmployeeInfo(String) method of
                the AcmePayroll bean </description>
            <role-name>employee</role-name>
            <method>
                <ejb-name>AcmePayroll</ejb-name>
                <method-name>findByPrimaryKey</method-name>
            </method>
            <method>
                <ejb-name>AcmePayroll</ejb-name>
                <method-name>getEmployeeInfo</method-name>
            </method>
            <method>
                <ejb-name>AcmePayroll</ejb-name>
                <method-name>updateEmployeeInfo</method-name>
                <method-params>
                    <method-param>java.lang.String</method-param>
                </method-params>
            </method>
        </method-permission>
        <method-permission>
            <description>The admin role may access any method of the
                EmployeeServiceAdmin bean </description>
            <role-name>admin</role-name>
            <method>
                <ejb-name>EmployeeServiceAdmin</ejb-name>
                <method-name>*</method-name>
            </method>
        </method-permission>
        <method-permission>
            <description>Any authenticated user may access any method of the
                EmployeeServiceHelp bean</description>
            <unchecked/>
            <method>
                <ejb-name>EmployeeServiceHelp</ejb-name>
                <method-name>*</method-name>
            </method>
        </method-permission>
        <exclude-list>
            <description>No fireTheCTO methods of the EmployeeFiring bean may be
                used in this deployment</description>
            <method>
                <ejb-name>EmployeeFiring</ejb-name>
                <method-name>fireTheCTO</method-name>
            </method>
        </exclude-list>
    </assembly-descriptor>
</ejb-jar>


12.3.3. EJB セキュリティアノテーション

12.3.3.1. EJB セキュリティーアノテーションについて

EJB はセキュリティーアノテーションを使いセキュリティー関連の情報をデプロイヤーに渡します。セキュリティーアノテーションには以下が含まれます。
@DeclareRoles
どのロールが利用可能か宣言します。
@SecurityDomain
EJB に使用するセキュリティードメインを指定します。承認のため、EJB に @RolesAllowed アノテーションが付いている場合、EJB にセキュリティードメインがアノテーション付けされている場合のみ承認を適用します。
@RolesAllowed、@PermitAll、@DenyAll
どのメソッドパーミッションが可能か指定します。メソッドパーミッションについては 「EJB メソッドパーミッションについて」 を参照してください。
@RolesAllowed、@PermitAll、@DenyAll
どのメソッドパーミッションが可能か指定します。メソッドパーミッションについては 「EJB メソッドパーミッションについて」 を参照してください。
@RunAs
コンポーネントの伝搬されたセキュリティー ID を設定します。
詳細は 「EJB セキュリティーアノテーションの使用」 を参照してください。

12.3.3.2. EJB セキュリティーアノテーションの使用

概要

XML 記述子かアノテーションを使用して、どのセキュリティーロールが Enterprise JavaBean (EJB) でメソッドを呼び出しできるかを制御することができます。XML 記述子の使用については 「EJB メソッドパーミッションの使用」 を参照してください。

EJB のセキュリティーパーミッションを制御するアノテーション

@DeclareRoles
@DeclareRoles を使用して、どのセキュリティーロールに対してパーミッションをチェックするか定義します。@DeclareRoles が存在しない場合、@RolesAllowed アノテーションよりリストが自動的に構築されます。
@SecurityDomain
EJB に使用するセキュリティードメインを指定します。承認のため、EJB に @RolesAllowed アノテーションが付いている場合、EJB にセキュリティードメインがアノテーション付けされている場合のみ承認を適用します。
@RolesAllowed、@PermitAll、@DenyAll
@RolesAllowed を使用して、1 つまたは複数のメソッドへのアクセスが許可されるロールをリストします。すべてのロールに対して 1 つまたは複数のメソッドの使用を許可する場合は @PermitAll、すべてのロールに対してメソッドの使用を拒否する場合は @DenyAll を使用します。
@RunAs
@RunAs を使用してロールを指定すると、メソッドが常にそのロールとして実行されるようにします。

例12.10 セキュリティーアノテーションの例

@Stateless
@RolesAllowed({"admin"})
@SecurityDomain("other")
public class WelcomeEJB implements Welcome {
	@PermitAll
	public String WelcomeEveryone(String msg) {
		return "Welcome to " + msg;
	}
	@RunAs("tempemployee")
	public String GoodBye(String msg) {
	    return "Goodbye, " + msg;
	}
	public String
	public String GoodbyeAdmin(String msg) {
		return "See you later, " + msg;
	}
}
このコードでは、すべてのロールが WelcomeEveryone メソッドにアクセスできます。GoodBye メソッドは tempemployee ロールとして実行されます。GoodbyeAdmin メソッドと、セキュリティーアノテーションのない他のメソッドへは admin ロールのみがアクセスできます。

12.3.4. EJB へのリモートアクセス

12.3.4.1. リモートメソッドアクセスについて

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

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

  • ソケット / セキュアソケット
  • RMI / RMI over SSL
  • HTTP / HTTPS
  • サーブレット / セキュアサーブレット
  • バイソケット (Bisocket) / セキュアバイソケット (Secure Bisocket)
JBoss Remoting はマルチキャストまたは JNDI からの自動ディスカバリーも提供します。
自動ディスカバリーは JBoss Enterprise Application Platform 内の多くのサブシステムによって使用されています。これにより、複数の異なるトランスポートメカニズム上でクライアントによってリモートで呼び出されるサービスを設計、実装、デプロイすることが可能になります。さらに、JBoss Enterprise Application Platform の既存サービスへのアクセスが可能になります。
データのマーシャリング

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

アーキテクチャーの概要

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

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

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

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

12.3.4.2. Remoting コールバックについて

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

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

プッシュコールバック

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

12.3.4.3. リモーティングサーバーの検出について

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

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

概要

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

注記

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

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

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

remoting サブシステム外部となる設定もあります。

ネットワークインターフェース
remoting サブシステムによって使用されるネットワークネットワークインターフェースは domain/configuration/domain.xml または standalone/configuration/standalone.xml で定義される unsecure インターフェースです。
<interfaces>
   <interface name="management"/>
   <interface name="public"/>
   <interface name="unsecure"/>
</interfaces>        
            


unsecure インターフェースのホストごとの定義は domain.xml または standalone.xml と同じディレクトリにある host.xml で定義されます。また、このインターフェースは複数の他のサブシステムによっても使用されます。変更する場合は十分注意してください。
<interfaces>
   <interface name="management">
      <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
   </interface>
   <interface name="public">
      <inet-address value="${jboss.bind.address:127.0.0.1}"/>
   </interface>
   <interface name="unsecure">
      <!-- Used for IIOP sockets in the standard configuration.
         To secure JacORB you need to setup SSL -->
      <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
   </interface>
</interfaces>             
                 


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


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

警告

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

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

表12.1 ワーカースレッドプールの属性

属性 説明 CLI コマンド
read-threads
リモーティングワーカーに対して作成する読み取りスレッドの数。デフォルトは 1 です。
/profile=default/subsystem=remoting/:write-attribute(name=worker-read-threads,value=1)
write-threads
リモーティングワーカーに対して作成する書き込みスレッドの数。デフォルトは 1 です。
/profile=default/subsystem=remoting/:write-attribute(name=worker-write-threads,value=1)
task-keepalive
コアでないリモーティングワーカーのタスクスレッドを生存させておく期間 (ミリ秒単位) です。デフォルトは 60 です。
/profile=default/subsystem=remoting/:write-attribute(name=worker-task-keepalive,value=60)
task-max-threads
モーティングワーカーのタスクスレッドプールに対するスレッドの最大数です。デフォルトは 16 です。
/profile=default/subsystem=remoting/:write-attribute(name=worker-task-max-threads,value=16)
task-core-threads
モーティングワーカーのタスクスレッドプールに対するコアスレッドの数です。デフォルトは 4 です。
/profile=default/subsystem=remoting/:write-attribute(name=worker-task-core-threads,value=4)
task-limit
挿入前に許可されるリモーティングワーカータスクの最大数です。デフォルトは 16384 です。
/profile=default/subsystem=remoting/:write-attribute(name=worker-task-limit,value=16384)
コネクター

コネクターは主な Remoting 設定要素です。複数のコネクターを設定できます。各コネクターは、サブ要素を持つ <connector> 要素より構成され、複数の属性が含まれることもあります。デフォルトのコネクターは JBoss Enterprise Application Platform の複数のサブシステムによって使用されます。カスタムコネクターの要素や属性の設定はアプリケーションによって異なるため、詳細は Red Hat グローバルサポートサービスまでご連絡ください。

表12.2 コネクターの属性

属性 説明 CLI コマンド
name JNDI によって使用されるコネクターの名前です。
/profile=default/subsystem=remoting/connector=remoting-connector/:write-attribute(name=name,value=remoting-connector)
socket-binding このコネクターに使用するソケットバインディングの名前です。
/profile=default/subsystem=remoting/connector=remoting-connector/:write-attribute(name=socket-binding,value=remoting)
authentication-provider
このコネクターと使用する JASPIC (Java Authentication Service Provider Interface) モジュールです。このモジュールはクラスパスに存在しなければなりません。
/profile=default/subsystem=remoting/connector=remoting-connector/:write-attribute(name=authentication-provider,value=myProvider)
security-realm
任意の設定です。アプリケーションのユーザーやパスワード、ロールが含まれるセキュリティーレルムになります。EJB または Web アプリケーションがセキュリティーレルムに対して認証を行います。 ApplicationRealm はデフォルトの JBoss Enterprise Application Platform インストールで使用可能です。
/profile=default/subsystem=remoting/connector=remoting-connector/:write-attribute(name=security-realm,value=ApplicationRealm)

表12.3 コネクター要素

属性 説明 CLI コマンド
sasl
SASL (Simple Authentication and Security Layer) 認証メカニズムの囲み要素です。
N/A
properties
1 つ以上の <property> 要素が含まれ、各要素には name 属性と任意の value 属性が含まれます。
/profile=default/subsystem=remoting/connector=remoting-connector/property=myProp/:add(value=myPropValue)
送信接続

3 つのタイプの送信接続を指定することができます。

  • URI への送信接続。
  • ローカルの送信接続 – ソケットなどのローカルリソースへ接続します。
  • リモートの送信接続 – リモートリソースへ接続し、セキュリティーレルムを使用して認証を行います。
送信接続はすべて <outbound-connections> 要素で囲まれます。各接続タイプは outbound-socket-binding-ref 属性を取ります。送信接続は uri 属性を取ります。リモートの送信接続は任意の username 属性と security-realm 属性を取り、認証に使用します。

表12.4 送信接続要素

属性 説明 CLI コマンド
outbound-connection 汎用の送信接続。
/profile=default/subsystem=remoting/outbound-connection=my-connection/:add(uri=http://my-connection)
local-outbound-connection 暗黙の local:// URI スキームを持つ送信接続。
/profile=default/subsystem=remoting/local-outbound-connection=my-connection/:add(outbound-socket-binding-ref=remoting2)
remote-outbound-connection
セキュリティーレルムを用いた基本またはダイジェスト認証を使用する remote:// URI スキームの送信接続です。
/profile=default/subsystem=remoting/remote-outbound-connection=my-connection/:add(outbound-socket-binding-ref=remoting,username=myUser,security-realm=ApplicationRealm)
SASL 要素

SASL 子要素を定義する前に初期 SASL 要素を作成する必要があります。次のコマンドを使用します。

/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:add
SASL 要素の子要素は次の表の通りです。
属性 説明 CLI コマンド
include-mechanisms
SASL メカニズムのスペース区切りのリストである value 属性が含まれています。
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=include-mechanisms,value=["DIGEST","PLAIN","GSSAPI"])
qop
SASL の保護品質値が希望順に並ぶスペース区切りのリストである value 属性が含まれます。
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=qop,value=["auth"])
strength
SASL の暗号強度の値が希望順に並ぶスペース区切りのリストである value 属性が含まれます。
/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=strength,value=["medium"])
reuse-session
ブール値である value 属性が含まれます。true の場合、セッションの再使用を試みます。
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=reuse-session,value=false)
server-auth
ブール値である value 属性が含まれます。true の場合、サーバーはクライアントに対して認証します。
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=server-auth,value=false)
policy
以下の要素がゼロ個以上含まれ、各要素が単一の value を取るエンクロージング要素です。
  • forward-secrecy – メカニズムによるフォワード秘匿性 (forward secrecy) の実装が必要であるかどうか (あるセッションが侵入されても、その後のセッションへの侵入に関する情報は自動的に提供されません)。
  • no-active – 辞書攻撃でない攻撃を受けやすいメカニズムを許可するかどうか。値が false の場合は許可し、 true の場合は許可しません。
  • no-anonymous – 匿名ログインを許可するメカニズムを許可するかどうか。値が false の場合は許可し、 true の場合は許可しません。
  • no-dictionary – 受動的な辞書攻撃を受けやすいメカニズムを許可するかどうか。値が false の場合は許可し、 true の場合は許可しません。
  • no-plain-text – 単純で受動的な辞書攻撃を受けやすいメカニズムを許可するかどうか。値が false の場合は許可し、 true の場合は許可しません。
  • pass-credentials – クライアントの認証情報を渡すメカニズムを許可するかどうか。
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:add
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=forward-secrecy,value=true)
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-active,value=false)
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-dictionary,value=true)
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-plain-text,value=false)
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=pass-credentials,value=true)
properties
1 つ以上の <property> 要素が含まれ、各要素には name 属性と任意の value 属性が含まれます。
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/property=myprop:add(value=1)
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/property=myprop2:add(value=2)

例12.11 設定例

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


この例には多くの仮説的な値が含まれており、前述の要素や属性がコンテキストに含まれています。
<subsystem xmlns="urn:jboss:domain:remoting:1.1">
    <worker-thread-pool read-threads="1" task-keepalive="60' task-max-threads="16" task-core-thread="4" task-limit="16384" write-threads="1" />
    <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm">
        <sasl>
            <include-mechanisms value="GSSAPI PLAIN DIGEST-MD5" />
            <qop value="auth" />
            <strength value="medium" />
            <reuse-session value="false" />
            <server-auth value="false" />
            <policy>
                <forward-secrecy value="true" />
                <no-active value="false" />
                <no-anonymous value="false" />
                <no-dictionary value="true" />
                <no-plain-text value="false" />
                <pass-credentials value="true" />
            </policy>
            <properties>
                <property name="myprop1" value="1" />
                <property name="myprop2" value="2" />
            </properties>
        </sasl>
        <authentication-provider name="myprovider" />
        <properties>
            <property name="myprop3" value="propValue" />
        </properties>
    </connector>
    <outbound-connections>
        <outbound-connection name="my-outbound-connection" uri="htt\
p://myhost:7777/"/>
        <remote-outbound-connection name="my-remote-connection" outbound-socket-binding-ref="my-remote-socket" username="myUser" security-realm="ApplicationRealm"/>
        <local-outbound-connection name="myLocalConnection" outbound-socket-binding-ref="my-outbound-socket"/>
    </outbound-connections>
</subsystem>    
    


文書化されていない設定の側面

  • JIDI および マルチキャスト自動検出

12.3.4.5. リモート EJB クライアントを用いたセキュリティーレルムの使用

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

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

  1. Management CLI を実行します。

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

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

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

    注記

    新規作成されたプロパティーファイルは、含まれる add-user.sh および add-user.bat スクリプトによって管理されません。そのため、外部から管理する必要があります。
    /host=master/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
結果

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

12.3.4.7. セキュリティーレルムへユーザーを追加

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

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

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

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

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

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

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

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

12.4.1. RESTEasy JAX-RS Web サービスのロールベースのセキュリティーを有効にする

概要

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

警告

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

手順12.1 RESTEasy JAX-RS Web サービスのロールベースのセキュリティーを有効にする

  1. テキストエディターでアプリケーションの web.xml ファイルを開きます。
  2. 以下の <context-param> をファイルの web-app タグ内に追加します。
    <context-param>
        <param-name>resteasy.role.based.security</param-name>
        <param-value>true</param-value>
    </context-param>
    
    
    
  3. <security-role> タグを使用して RESTEasy JAX-RS WAR ファイル内で使用されるすべてのロールを宣言します。
    <security-role><role-name>ROLE_NAME</role-name></security-role><security-role><role-name>ROLE_NAME</role-name></security-role>
        
    
    
    
    
  4. すべてのロールに対して JAX-RS ランタイムが対応する全 URL へのアクセスを承認します。
    <security-constraint><web-resource-collection><web-resource-name>Resteasy</web-resource-name><url-pattern>/PATH</url-pattern></web-resource-collection><auth-constraint><role-name>ROLE_NAME</role-name><role-name>ROLE_NAME</role-name></auth-constraint></security-constraint>
        
    	
    	
        
        
    	
    	
    
    
結果

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

例12.12 ロールベースセキュリティーの設定例

<web-app>

    <context-param>
	<param-name>resteasy.role.based.security</param-name>
	<param-value>true</param-value>
    </context-param>

    <servlet-mapping>
	<servlet-name>Resteasy</servlet-name>
	<url-pattern>/*</url-pattern>
    </servlet-mapping>

    <security-constraint>
	<web-resource-collection>
	    <web-resource-name>Resteasy</web-resource-name>
	    <url-pattern>/security</url-pattern>
	</web-resource-collection>
	<auth-constraint>
	    <role-name>admin</role-name>
	    <role-name>user</role-name>
	</auth-constraint>
    </security-constraint>

    <security-role>
	<role-name>admin</role-name>
    </security-role>
    <security-role>
	<role-name>user</role-name>
    </security-role>
    
</web-app>


12.4.2. アノテーションを使用した JAX-RS Web サービスの保護

概要

サポート対象のセキュリティーアノテーションを使用して JAX-RS Web サービスを保護する手順を取り上げます。

手順12.2 サポート対象のセキュリティーアノテーションを使用した JAX-RS Web サービスのセキュア化

  1. ロールベースセキュリティーを有効にします。詳細は 「RESTEasy JAX-RS Web サービスのロールベースのセキュリティーを有効にする」 を参照してください。
  2. JAX-RS Web サービスにセキュリティーアノテーションを追加します。RESTEasy は次のアノテーションをサポートします。
    @RolesAllowed
    メソッドにアクセスできるロールを定義します。ロールはすべて web.xml ファイルに定義する必要があります。
    @PermitAll
    web.xml ファイルに定義されている全ロールによるメソッドへのアクセスを許可します。
    @DenyAll
    メソッドへのアクセスをすべて拒否します。

12.5. リモートパスワードプロトコルの保護

12.5.1. SRP (セキュアリモートパスワード) プロトコルについて

SRP (セキュアリモートパスワード) プロトコルは、Internet Standards Working Group の Request For Comments 2945 (RFC2945) に記載されている、公開鍵交換のハンドシェイク実装です。RFC2945 の要約は次のようになります。
この文書は SRP (セキュアリモートパスワード) プロトコルとして知られる、強固なネットワーク暗号化方式について説明しています。このメカニズムは従来の再利用可能なパスワードで起きていたセキュリティーの問題を排除しつつ、ユーザーによって提供されるパスワードを使いセキュアな接続をネゴシエーションするのに適しています。この仕組みは、認証プロセスでセキュアな鍵交換を行い、セッション時にセキュリティー層 (プライバシーや整合性保護) を有効にすることが可能です。信頼されたキーサーバーや証明書インフラストラクチャーは必要なく、また長期鍵の保存や管理にクライアントを必要としません。SRP には、既存のチャレンジレスポンス方式と比べセキュリティーやデプロイメントに両方において様々な利点があり、SRP は安全なパスワード認証が必要な場合に、互換性のある理想的な代用方式となります。
完全な RFC2945 仕様は http://www.rfc-editor.org/rfc.html から取得可能です。SRP アルゴリズムに関する追加情報および履歴については http://www.rfc-editor.org/rfc.html を参照してください。
Diffie-Hellman および RSA などのアルゴリズムは公開鍵交換アルゴリズムとして知られています。公開鍵アルゴリズムのコンセプトには、誰でも使用できる公開鍵と本人のみが把握する秘密鍵の 2 つの鍵が存在します。暗号化した情報を送信したい場合、この公開鍵を使い情報を暗号化します。秘密鍵を持つ本人のみが秘密鍵を使い情報を復号化することができます。従来の共有パスワードベースの暗号化方式では、受信者も送信者も共有パスワードを把握している必要があります。公開鍵アルゴリズムではパスワードを共有する必要がありません。

12.5.2. セキュアリモートパスワード (SRP) プロトコルの設定

セキュアリモートパスワード (SRP) プロトコルをアプリケーションで使用するには、最初に SRPVerifierStore インターフェースを実装する MBean を作成します。実装に関する詳細は SRPVerifierStore 実装 で確認できます。

手順12.3 既存パスワードストアの統合

  1. ハッシュ化されたパスワード情報ストアを作成します。

    パスワードが既に不可逆的にハッシュ化され、保存されている場合、この作業をユーザーごとに行う必要があります。
    noOP メソッドとして setUserVerifier(String, VerifierInfo) を実装するか、ストアが読み取り専用であることを知らせる例外をスローするメソッドとして setUserVerifier(String, VerifierInfo) を実装することができます。
  2. SRPVerifierStore インターフェースを作成します。

    作成したストアより VerifierInfo を取得できるカスタムの SRPVerifierStore インターフェース実装を作成します。
    verifyUserChallenge(String, Object) を使用すると、SafeWord や Radius のような既存のハードウェアトークンベースのスキームを SRP アルゴリズムへ統合することができます。このインターフェースメソッドは、クライアントの SRPLoginModule 設定で hasAuxChallenge オプションが指定されている場合のみ呼び出されます。
  3. JNDI MBean を作成します。

    JNDI が使用できる SRPVerifierStore インターフェースを公開し、必要な設定可能パラメーターを公開する MBean を作成します。
    デフォルトの org.jboss.security.srp.SRPVerifierStoreService でこれを実装することが可能です。また、 SRPVerifierStore の Java プロパティーファイル実装を使用して MBean を実装することもできます。
SRPVerifierStore 実装

すべてのパスワードハッシュ情報がシリアライズされたオブジェクトのファイルとして使用できなければならないため、SRPVerifierStore インターフェースのデフォルト実装は実稼動システムでは推奨されません。

SRPVerifierStore 実装は、特定のユーザー名に対して SRPVerifierStore.VerifierInfo オブジェクトへのアクセスを提供します。SRP アルゴリズムが必要とするパラメーターを取得するため、getUserVerifier(String) メソッドはユーザー SRP セッションの最初に SRPService によって呼び出されます。

VerifierInfo オブジェクトの要素

username
認証に使用されるユーザー名またはユーザー ID です。
verifier
アイデンティティーの証拠としてユーザーが入力するパスワードの一方向ハッシュです。org.jboss.security.Util クラスにはパスワードハッシュ化アルゴリズムを実行する calculateVerifier メソッドが含まれています。出力パスワードは H(salt | H(username | ':' | password)) の形式を取ります。 H は RFC2945 で定義されている SHA セキュアハッシュ関数になります。ユーザー名は UTF-8 エンコーディングを使用して文字列から byte[] へ変換されます。
salt
データベースの情報が漏えいされた場合に、ベリファイアーパスワードデータベース上での総当たり辞書攻撃を難しくするために使用される乱数です。ユーザーの既存のクリアテキストパスワードがハッシュ化される時に、暗号強度が高い乱数アルゴリズムより値が生成されなければなりません。
g
SRP アルゴリズムプリミティブジェネレーターです。ユーザーごとの設定ではなく、既知の固定パラメーターとなります。 org.jboss.security.srp.SRPConf ユーティリティクラスは g の設定を複数提供します。 これには SRPConf.getDefaultParams().g() により取得される適切なデフォルトなどが含まれます。
N
SRP アルゴリズムセーフプライムモジュールです。ユーザーごとの設定ではなく、既知の固定パラメーターとなります。 org.jboss.security.srp.SRPConf ユーティリティクラスは org.jboss.security.srp.SRPConf は N の設定を複数提供します。これには SRPConf.getDefaultParams().N() より取得される適切なデフォルトなどが含まれます。

例12.13 SRPVerifierStore インターフェース

package org.jboss.security.srp;

import java.io.IOException;
import java.io.Serializable;
import java.security.KeyException;

public interface SRPVerifierStore
{
    public static class VerifierInfo implements Serializable
    {

        public String username;


        public byte[] salt;
        public byte[] g;
        public byte[] N;
    }
    

    public VerifierInfo getUserVerifier(String username)
        throws KeyException, IOException;

    public void setUserVerifier(String username, VerifierInfo info)
        throws IOException;


     public void verifyUserChallenge(String username, Object auxChallenge)
         throws SecurityException;
}

第13章 シングルサインオン (SSO)

13.1. Web アプリケーションのシングルサインオン (SSO) について

概要

SSO (シングルサインオン) は 1 つのリソースへの認証を用いて他のリソースへのアクセスを暗黙的に承認できるようにします。

クラスター化された SSO とクラスター化されていない SSO

クラスター化されていない SSO は、アプリケーションの承認情報の共有を同じ仮想ホスト内に制限します。また、ホストの障害に対する耐性を持ちません。クラスター化された SSO データは複数の仮想ホストのアプリケーション間で共有することができ、フェイルオーバーに対する耐性を持ちます。さらに、クラスター化された SSO はロードバランサーからのリクエストを受信することができます。

SSO の仕組み

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

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

SSO の制限

サードパーティー境界にまたがる伝搬がない
JBoss Enterprise Application Platform のコンテナ内にデプロイされたアプリケーションの間でのみ SSO を使用できます。
コンテナ管理の認証のみ使用可能
アプリケーションの web.xml<login-config> などのコンテナ管理認証要素を使用しなければなりません。
クッキーが必要
SSO はブラウザークッキーを介して維持されます。URL の再書き込みはサポートされていません。
レルムとセキュリティードメインの制限
requireReauthentication パラメーターが true に設定されている場合を除き、同じ SSO バルブに設定されたすべての Web アプリケーションは、web.xml の同じレルム設定と同じセキュリティードメインを共有しなければなりません。
関与する Web アプリケーションの 1 つに対し、Host 要素内または Engine 要素周囲で Realm 要素をネストできますが、context.xml 要素内で Realm 要素はネストできません。
jboss-web.xml に設定された <security-domain> はすべての Web アプリケーション全体で一貫していなければなりません。
すべてのセキュリティー統合が同じ認証情報 (ユーザー名やパスワードなど) を許可しなければなりません。

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

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

13.3. 適切な SSO 実装の選択

JBoss Enterprise Application Platform は Web アプリケーションや EJB アプリケーション、Web サービスなどの Java Enterprise Edition (EE) アプリケーションを実行します。SSO (Single Sign On: シングルサインオン) により、これらのアプリケーションの間でセキュリティーコンテキストとアイデンティティー情報が伝播できるようになります。組織のニーズに合わせ、異なる SSO ソリューションを使用することができます。使用するソリューションは以下の状況により異なります。 1) Web アプリケーションや EJBアプリケーション、Web サービスのどれを使用するか。 2) アプリケーションが同じサーバー、複数のクラスター化されていないサーバー、複数のクラスター化されたサーバーのどれを使用するか。 3) デスクトップベースの認証システムに統合する必要があるかまたはアプリケーション間でのみ認証が必要になるか。
Kerberos ベースのデスクトップ SSO

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

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

同じサーバーグループやインスタンス内で実行するアプリケーション間でセキュリティー情報を伝播する必要がある場合、クラスター化されていない SSO を使用することができます。この場合、アプリケーションの jboss-web.xml 記述子にバルブを設定することのみが必要となります。

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

複数の JBoss Enterprise Application Platform インスタンス全体のクラスター化された環境で実行されるアプリケーションの間でセキュリティー情報を伝播する必要がある場合、クラスター化された SSO バルブを使用することができます。このバルブはアプリケーションの jboss-web.xml に設定されます。

13.4. Web アプリケーションでの SSO (シングルサインオン) の使用

概要

SSO (シングルサインオン) の機能は Web および Infinispan サブシステムによって提供されます。この手順に従って Web アプリケーションに SSO を設定します。

要件

  • 認証と承認を処理するセキュリティードメインが設定されている必要があります。
  • infinispan サブシステムが存在する必要があります。管理対象ドメインの場合、このサブシステムは full-ha プロファイルにあります。スタンドアロンサーバーでは standalone-full-ha.xml 設定を使用します。
  • webcache-container と SSO cache-container が存在する必要があります。例の設定ファイルには web cache-container がすでに含まれており、一部の設定には SSO cache-container も含まれています。以下のコマンドを使用して SSO キャッシュコンテナをチェックし、有効にします。これらのコマンドは管理対象ドメインの full プロファイルを変更することに注意してください。スタンドアロンサーバーに対して異なるプロファイルを使用したり、コマンドの /profile=full 部分を削除するため、コマンドを変更することもできます。

    例13.1 web cache-container の確認

    前述のプロファイルや設定には、デフォルトとして web cache-container が含まれています。次のコマンドを使用して、web cache-container の存在を確認します。異なるプロファイルを使用する場合は、ha をその名前に置き換えます。
    /profile=ha/subsystem=infinispan/cache-container=web/:read-resource(recursive=false,proxies=false,include-runtime=false,include-defaults=true)
    サブシステムが存在する場合、結果は success になります。存在しない場合は追加する必要があります。

    例13.2 web cache-container の追加

    次の 3 つのコマンドを使用して web cache-container を設定に対して有効にします。必要に応じてプロファイルの名前やその他のパラメーターを変更します。以下のパラメーターはデフォルト設定で使用されるパラメーターになります。
    /profile=ha/subsystem=infinispan/cache-container=web:add(aliases=["standard-session-cache"],default-cache="repl",module="org.jboss.as.clustering.web.infinispan")
    /profile=ha/subsystem=infinispan/cache-container=web/transport=TRANSPORT:add(lock-timeout=60000)
    /profile=ha/subsystem=infinispan/cache-container=web/replicated-cache=repl:add(mode="ASYNC",batching=true)

    例13.3 SSO cache-container の確認

    次の管理 CLI コマンドを実行します。
    /profile=ha/subsystem=infinispan/cache-container=web/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
    "sso" => { のような出力を探します。
    このような出力が見つからない場合、設定に SSO cache-container は存在しません。

    例13.4 SSO cache-container の追加

    /profile=ha/subsystem=infinispan/cache-container=web/replicated-cache=sso:add(mode="SYNC", batching=true)
  • SSO を使用するよう web サブシステムを設定する必要があります。次のコマンドは、default-host という仮想サーバー上と、クッキードメイン domain.com で SSO を有効にします。キャッシュ名は sso で、再認証は無効になっています。
    /profile=ha/subsystem=web/virtual-server=default-host/sso=configuration:add(cache-container="web",cache-name="sso",reauthenticate="false",domain="domain.com")
  • SSO 情報を共有する各アプリケーションは、jboss-web.xml デプロイメント記述子にある同じ <security-domain> と web.xml 設定ファイルにある同じレルムを使用するよう設定されている必要があります。
クラスター化された SSO バルブとクラスター化されていない SSO バルブの違い

クラスター化された SSO では個別のホスト間で認証を共有できますが、クラスター化されていない SSO では共有できません。どちらの SSO も同じように設定されますが、クラスター化された SSO には永続データのクラスタリングレプリケーションを制御する cacheConfigprocessExpiresIntervalmaxEmptyLife パラメーターが含まれています。

例13.5 クラスター化された SSO 設定の例

クラスター化された SSO とクラスター化されていない SSO は大変似ているため、クラスター化されている設定のみを取り上げます。この例は tomcat と呼ばれるセキュリティードメインを使用します。
<jboss-web>
	<security-domain>tomcat</security-domain>
	<valve>
		<class-name>org.jboss.web.tomcat.service.sso.ClusteredSingleSignOn</class-name>
		<param>
			<param-name>maxEmptyLife</param-name>
			<param-value>900</param-value>
		</param>
	</valve>
</jboss-web>
		


表13.1 SSO 設定のオプション

オプション 説明
cookieDomain
SSO クッキーに使用するホストドメインです。デフォルトは / です。app1.xyz.comapp2.xyz.com によるクッキーの共有を許可するには、cookieDomain を xyz.com に設定します。
maxEmptyLife
クラスター化された SSO のみ設定可能です。失効する前に、アクティブなセッションを持たない SSO バルブを 1 つのリクエストが使用できる最大秒数。唯一バルブにアクティブなセッションが付加されている場合、正の値を設定するとノードのシャットダウンが適切に処理されるようになります。maxEmptyLife を 0 に設定すると、ローカルセッションがコピーされると同時にバルブが終了しますが、クラスター化されたアプリケーションからのセッションのバックアップコピーは他のクラスターノードが使用できるようになります。バルブの管理セッションの生存期間を越えてバルブが生存できるようにすると、他のリクエストを実行する時間がユーザーに与えられます。このリクエストはセッションのバックアップコピーをアクティベートする他のノードへフェイルオーバーすることができます。デフォルトは 1800 秒 (30 分) です。
processExpiresInterval
クラスター化された SSO のみ設定可能です。MaxEmptyLife タイムアウトを失効した SSO インスタンスをバルブが発見し無効化する動作の間隔の最初秒数。デフォルトは 60 (1 分) です。
requiresReauthentication
true の場合、各リクエストはキャッシュされた認証情報を使用してセキュリティーレルムへ再認証します。false の場合 (デフォルト)、バルブによる新しい要求の認証には有効な SSO クッキーのみが必要になります。
セッションの無効化

アプリケーションはメソッド javax.servlet.http.HttpSession.invalidate() を呼び出し、プログラムを用いてセッションを無効化することができます。

13.5. Kerberos について

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 環境でも使用されています。

13.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 プロバイダーと動作します。

13.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)。

13.8. Web アプリケーションに対して Kerberos または Microsoft Active Directory のデスクトップ SSO を設定する

はじめに

Microsoft Active Directory など、組織における既存の Kerberos ベースの認証承認インフラストラクチャーを使用して Web アプリケーションや EJB アプリケーションを認証するため、Enterprise Application Platform 6 に内蔵される JBoss Negotiation の機能を使用することが可能です。Web アプリケーションを適切に設定すれば、デスクトップまたはネットワークへのログインに成功するだけでWeb アプリケーションに対して透過的な認証を行えるため、追加のログインプロンプトは必要ありません。

JBoss Enterprise Application Platform の以前のバージョンとの相違点

JBoss Enterprise Application Platform 6 と以前のバージョンには顕著な違いがいくつかあります。

  • セキュリティードメインは、管理対象ドメインの各プロファイルまたは各スタンドアロンサーバーに対して設定されます。セキュリティードメインはデプロイメントの一部ではありません。デプロイメントが使用する必要のあるセキュリティードメインは、デプロイメントの jboss-web.xml または jboss-ejb3.xml ファイルに名前が指定されています。
  • セキュリティープロパティーは設定の一部分で、セキュリティードメインの一部として設定されます。デプロイメントの一部ではありません。
  • デプロイメントの一部としてオーセンティケーターを上書きすることができなくなりましたが、NegotiationAuthenticator バルブを jboss-web.xml 記述子に追加すると同じ結果を得ることができます。バルブでも <security-constraint> および <login-config> 要素が web.xml に定義されている必要があります。これらはセキュアなリソースを決定するために使用されますが、選択された auth-method は jboss-web.xml の NegotiationAuthenticator バルブによって上書きされます。
  • セキュリティードメインの CODE 属性は、完全修飾クラス名ではなく、単純名を使用するようになりました。次の表は、これらのクラスと JBoss Negotiation に使用されるクラスとのマッピングを表しています。

表13.2 ログインモジュールコードとクラス名

単純名 クラス名 目的
Kerberos com.sun.security.auth.module.Krb5LoginModule Kerberos ログインモジュール
SPNEGO org.jboss.security.negotiation.spnego.SPNEGOLoginModule Web アプリケーションが Kerberos 認証サーバーへ認証できるようにするメカニズム。
AdvancedLdap org.jboss.security.negotiation.AdvancedLdapLoginModule Microsoft Active Directory 以外の LDAP サーバーと使用されます。
AdvancedAdLdap org.jboss.security.negotiation.AdvancedADLoginModule Microsoft Active Directory の LDAP サーバーを使用されます。
Jboss Negotiation Toolkit

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

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

  1. サーバーのアイデンティティーを表すセキュリティードメインを 1 つ設定します。必要な場合はシステムプロパティーを設定します。

    最初のセキュリティードメインは、コンテナ自体をディレクトリーサービスへ認証します。ユーザーではなくコンテナ自体の認証であるため、ある種の静的ログインメカニズムを受容するログインモジュールを使用する必要があります。この例では静的プリンシパルを使用し、認証情報が含まれるキータブファイルを参照します。
    明確にするため、この例では XML コードが提供されていますが、管理コンソールまたは管理 CLI を使用してセキュリティードメインを設定するようにしてください。
    <security-domain name="host" cache-type="default">
       <authentication>
          <login-module code="Kerberos" flag="required">
             <module-option name="storeKey" value="true"/>
             <module-option name="useKeyTab" value="true"/>
             <module-option name="principal" value="host/testserver@MY_REALM"/>
             <module-option name="keyTab" value="/home/username/service.keytab"/>
             <module-option name="doNotPrompt" value="true"/>
             <module-option name="debug" value="false"/>
          </login-module>
       </authentication>
    </security-domain>		
    		
    
    
    
  2. Web アプリケーションやアプリケーションをセキュアにするため、2 つ目のセキュリティードメインを設定します。必要な場合はシステムプロパティーを設定します。

    2 つ目のセキュリティードメインは、個別のユーザーを Kerberos または SPNEGO 認証サーバーへ認証するために使用されます。ユーザーの認証に最低でも 1 つのログインモジュールが必要で、ユーザーに適用するロールを検索するために別のログインモジュールが必要となります。次の XML コードは SPNEGO セキュリティードメインの例を表しています。これには、ロールを個別のユーザーにマッピングする承認モジュールが含まれます。認証サーバー上でロールを検索するモジュールを使用することもできます。
    <security-domain name="SPNEGO" cache-type="default">
       <authentication>
          <!-- Check the username and password -->
          <login-module code="SPNEGO"  flag="requisite">
             <module-option name="password-stacking" value="useFirstPass"/>
             <module-option name="serverSecurityDomain" value="host"/>
          </login-module>
          <!-- Search for roles -->
          <login-module code="UserRoles" flag="required">
             <module-option name="password-stacking" value="useFirstPass" />
             <module-option name="usersProperties" value="spnego-users.properties" />
             <module-option name="rolesProperties" value="spnego-roles.properties" />
          </login-module> 
       </authentication>
    </security-domain>		
    		
    
    
    
  3. web.xml の security-constraint と login-config を指定します。

    web.xml 記述子にはセキュリティー制約とログイン設定に関する情報が含まれています。セキュリティー制約とログイン情報の値の例は次の通りです。
    <security-constraint>
       <display-name>Security Constraint on Conversation</display-name>
       <web-resource-collection>
          <web-resource-name>examplesWebApp</web-resource-name>
          <url-pattern>/*</url-pattern>
       </web-resource-collection>
       <auth-constraint>
       <role-name>RequiredRole</role-name>
       </auth-constraint>
    </security-constraint>
    
    <login-config>
       <auth-method>SPNEGO</auth-method>
       <realm-name>SPNEGO</realm-name>
    </login-config>
     
    <security-role>
       <description> role required to log in to the Application</description>
       <role-name>RequiredRole</role-name>
    </security-role>		
    		
    
    
    
  4. jboss-web.xml 記述子にセキュリティードメインと他の設定を指定します。

    クライアント側のセキュリティードメイン (例の 2 番目のセキュリティードメイン) の名前をデプロイメントの jboss-web.xml 記述子に指定し、アプリケーションがこのセキュリティードメインを使用するよう指示します。
    オーセンティケーターを直接上書きすることができなくなりましたが、必要な場合は NegotiationAuthenticator をバルブとして jboss-web.xml 記述子に追加することができます。<jacc-star-role-allow> は任意で、複数のロール名を一致させるためアスタリスク (*) の使用を許可します。
    <jboss-web>
       <security-domain>java:/jaas/SPNEGO</security-domain>
       <valve>
          <class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name>
       </valve>
       <jacc-star-role-allow>true</jacc-star-role-allow>
    </jboss-web>		
    		
    
    
    
  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
    
結果

Web アプリケーションが Kerberos や Microsoft Active Directory、 SPNEGO 対応のディレクトリサービスに対して認証情報を許可し、認証します。既にディレクトリサービスにログインしているシステムよりユーザーがアプリケーションを実行し、必要なロールが既にユーザーに適用されている場合、Web アプリケーションは認証を要求しないため、SSO の機能が実現されます。

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

14.1. アプリケーションセキュリティーについて

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

14.2. セキュリティー監査について

セキュリティー監査とは、セキュリティーサブシステム内で発生したイベントに応答するため、ログへの書き込みなどのイベントをトリガーすることです。監査のメカニズムは、認証、承認、およびセキュリティーマッピングの詳細と共に、セキュリティードメインの一部として設定されます。
監査にはプロバイダーモジュールが使用されます。含まれているプロバイダーモジュールを使用するか、独自のモジュールを実装することができます。

14.3. セキュリティーマッピングについて

セキュリティーマッピングを使用すると、認証または承認が実行された後、情報がアプリケーションに渡される前に認証情報と承認情報を組み合わせることができます。この例の 1 つが、X509 証明書を認証に使用した後、プリンシパルを証明書からアプリケーションが表示できる論理名へ変換することです。
プリンシパル (認証) やロール (承認)、証明情報 (プリンシパルやロールでない属性) をマッピングすることが可能です。
ロールマッピングは、認証後にサブジェクトへロールを追加、置換、または削除するために使用されます。
プリンシパルマッピングは、認証後にプリンシパルを変更するために使用されます。
属性マッピングは、外部システムからの属性値をアプリケーションで使用するために変換したり、逆にそのような外部システムへ属性を変換したりするために使用されます。

14.4. セキュリティー拡張アーキテクチャーについて

JBoss Enterprise Application Platform のセキュリティー拡張のアーキテクチャーは 3 つの部分で構成されています。基盤のセキュリティーインフラストラクチャーが LDAP や Kerberos、その他の外部システムであるかに関わらず、これらの 3 つの部分はアプリケーションを基盤のセキュリティーインフラストラクチャーへ接続します。
JAAS

インフラストラクチャーの最初の部分は JAAS API になります。JAAS はセキュリティーインフラストラクチャーとアプリケーションの間の抽象化レイヤーを提供するプラグイン可能なフレームワークです。

JAAS の主な実装は、AuthenticationManager インターフェースと RealmMapping インターフェースを実装する org.jboss.security.plugins.JaasSecurityManager です。JaasSecurityManager は、対応するコンポーネントデプロイメント記述子の <security-domain> 要素を基に、EJB レイヤーと Web コンテナレイヤーに統合します。
JAAS に関する詳細は 「Java Authentication and Authorization Service (JAAS)」 を参照してください。
JaasSecurityManagerService MBean

JaasSecurityManagerService MBean サービスはセキュリティーマネージャーを管理します。名前は JAAS で始まりますが、処理するセキュリティーマネージャーは実装で JAAS を使用する必要はありません。この名前は、デフォルトのセキュリティーマネージャー実装が JaasSecurityManager であることを示しています。

JaasSecurityManagerService の主要な役割はセキュリティーマネージャー実装を外部化することです。AuthenticationManager インターフェースと RealmMapping インターフェースの代替の実装を提供してセキュリティーマネージャーの実装を変更することができます。
JaasSecurityManagerService の 2 つ目の基礎的な役割は、JNDI javax.naming.spi.ObjectFactory 実装を提供して JNDI 名とセキュリティーマネージャー実装との間でバインディングの簡単なコードのない管理を実現することです。セキュリティーを有効にするには、<security-domain> デプロイメント記述子要素よりセキュリティーマネージャー実装の JNDI 名を指定します。
JNDI 名を指定する時、オブジェクトバインディングが既に存在する必要があります。JNDI 名とセキュリティーマネージャー間のバインディング設定を簡単にするため、JaasSecurityManagerService次のネーミングシステムリファレンス をバインドし、java:/jaas という名前の JNDI の ObjectFactory として JaasSecurityManagerService 自体をノミネートします。これにより、java:/jaas/XYZ という形式の命名規則を <security-domain>要素の値とすることができます。セキュリティードメインの名前を取るコンストラクターを使用して SecurityManagerClassName 属性によって指定されるクラスのインスタンスを作成して、XYZ セキュリティードメインのセキュリティーマネージャーインスタンスは必要な時に作成されます。

注記

java:/jaas プレフィックスがデプロイメント記述子に含まれるようにする必要はありません。後方互換性を維持するため指定することがあるかもしれませんが、このプレフィックスは無視されます。
JaasSecurityDomain MBean

org.jboss.security.plugins.JaasSecurityDomain は、 SSL やその他の暗号化のユースケースをサポートするため KeyStoreKeyManagerFactoryTrustManagerFactory の概念を追加する JaasSecurityManager の拡張です。

詳細情報

詳細や動作しているセキュリティーアーキテクチャーの実例については 「Java Authentication and Authorization Service (JAAS) について」 を参照してください。

14.5. Java Authentication and Authorization Service (JAAS) について

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

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

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

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

表14.1 アプリケーション固有の設定ファイル

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

注記

ejb-jar.xmlweb.xml は Java Enterprise Edition (Java EE) 仕様に定義されています。jboss-ejb3.xmlejb-jar.xml の JBoss 固有の拡張を提供し、jboss-web.xmlweb.xml の JBoss 固有の拡張を提供します。
JAAS セキュリティーマネージャー MBean

Java Authentication and Authorization Service (JAAS) はプラグ可能認証モジュール (PAM) を使用した、 Java アプリケーションのユーザーレベルのセキュリティーに対するフレームワークです。JAAS は Java ランタイム環境 (JRE) に統合されます。JBoss Enterprise Application Platform では、コンテナ側のコンポーネントは org.jboss.security.plugins.JaasSecurityManager MBean で、AuthenticationManager インターフェースと RealmMapping インターフェースのデフォルト実装を提供します。

JaasSecurityManager MBean はアプリケーションの EJB または Web デプロイメント記述子ファイルに指定されているセキュリティードメインを EJB および Web コンテナレイヤーに統合します。アプリケーションがデプロイすると、コンテナはデプロイメント記述子に指定されたセキュリティードメインをコンテナのセキュリティーマネージャーインスタンスへ関連付けします。セキュリティーマネージャーはセキュリティードメインをサーバーグループまたはスタンドアローンサーバー上に設定します。
クライアントと JAAS を持つコンテナとの間の対話フロー

JaasSecurityManager は JAAS パッケージを使用して AuthenticationManager と RealmMapping インターフェースの動作を実装します。JaasSecurityManager へ割り当てられたセキュリティードメインに設定されたログインモジュールインスタンスを実行するとこの動作が生じます。ログインモジュールはセキュリティードメインのプリンシパルの認証やロールマッピングの挙動を実装します。ドメインの異なるログインモジュール設定を組み込むと、異なるセキュリティードメイン全体で JaasSecurityManager を使用することができます。

JaasSecurityManager がどのように JAAS 認証プロセスを使用するかを説明する次の手順を見てください。この手順はメソッド EJBHome を実装するメソッドのクライアント呼び出しの概要になります。EJB は既にサーバーにデプロイされ、EJBHome インターフェースメソッドは ejb-jar.xml 記述子の <method-permission> 要素を使用してセキュアな状態になっています。jboss-ejb3.xml ファイルの <security-domain> 要素に指定される jwdomain セキュリティードメインを使用します。以下の図は後で説明する手順を表しています。
EJB の認証手順

図14.1 保護された EJB メソッド呼び出しの手順

  1. クライアントが JAAS のログインを実行し、認証のプリンシパルと認証情報を確立します。上図では Client Side Login とラベル付けされます。JNDI より実行することも可能です。
    JAAS ログインを実行するには、LoginContext インスタンスを作成し、使用する設定の名前を渡します。ここでの設定名は other になります。このワンタイムログインは、ログインプリンシパルと認証情報を後続の EJB メソッド呼び出しすべてへ関連付けます。プロセスがユーザーを認証するとは限りません。クライアント側のログインの性質は、クライアントが使用するログインモジュール設定によって異なります。この例では、other というクライアント側ログイン設定エントリーが ClientLoginModule ログインモジュールを使用します。サーバー上で後で認証が行われるため、このモジュールはユーザー名とパスワードを EJB 呼び出しレイヤーへバインドします。クライアントのアイデンティティーはクライアント上で認証されません。
  2. クライアントは EJBHome メソッドを取得し、このメソッドをサーバー上で呼び出します。呼び出しにはクライアントによって渡されたメソッド引数や、クライアント側 JAAS ログインからのユーザー ID や認証情報が含まれます。
  3. サーバー上では、セキュリティーインターセプターがメソッドを呼び出したユーザーを認証します。これには別の JAAS ログインが関係します。
  4. セキュリティードメインはログインモジュールの選択を決定します。セキュリティードメインの名前はログイン設定エントリー名として LoginContext コンストラクターへ渡されます。EJB セキュリティードメインは jwdomain です。JAAS 認証に成功すると、JAAS サブジェクトが作成されます。JAAS サブジェクトには次の詳細を含む PrincipalSet が含まれます。
    • デプロイメントセキュリティー環境よりクライアントアイデンティティーへ対応する java.security.Principal インスタンス。
    • ユーザーのアプリケーションドメインからのロール名が含まれる Roles と呼ばれる java.security.acl.Grouporg.jboss.security.SimplePrincipal タイプのオブジェクトはロール名を表します。これらのロールは、ejb-jar.xmlEJBContext.isCallerInRole(String) メソッド実装の制約に従って EJB メソッドへのアクセスを検証します。
    • アプリケーションドメインの呼び出し側のアイデンティティーに対応する 1 つの org.jboss.security.SimplePrincipal が含まれる CallerPrincipal という名前の任意の java.security.acl.Group。CallerPrincipal グループメンバーは EJBContext.getCallerPrincipal() メソッドによって返される値です。このマッピングは、運用セキュリティー環境のプリンシパルがアプリケーションが認識するプリンシパルへマッピングできるようにします。CallerPrincipal マッピングが存在しない場合、運用プリンシパルはアプリケーションドメインプリンシパルと同じになります。
  5. EJB メソッドを呼び出しているユーザーは呼び出しが許可されているユーザーであることをサーバーが検証します。次の手順でこの承認を実行します。
    • EJB コンテナから EJBメソッドへアクセスすることが許可されるロールの名前を取得します。呼び出されたメソッドが含まれるすべての <method-permission> 要素の ejb-jar.xml 記述子 <role-name> 要素によってロール名が判断されます。
    • 割り当てられたロールがなかったり、メソッドが exclude-list 要素に指定されている場合、メソッドへのアクセスは拒否されます。それ以外の場合は、セキュリティーインターセプターによってセキュリティーマネージャー上で doesUserHaveRole メソッドが呼び出され、呼び出し側に割り当てられたロール名の 1 つがあるかどうかを確認します。このメソッドはロール名より繰り返され、認証されたユーザーの Subject Roles グループに割り当てられたロール名を持つ SimplePrincipal が含まれるか確認します。Roles グループメンバーのロール名がある場合はアクセスが許可されます。メンバーのロール名がない場合はアクセスが拒否されます。
    • EJB がカスタムのセキュリティープロキシを使用する場合、メソッドの呼び出しはプロキシへ委譲されます。セキュリティープロキシが呼び出し側へのアクセスを拒否すると、java.lang.SecurityException がスローされます。それ以外の場合は EJB メソッドへのアクセスは許可され、メソッド呼び出しは次のコンテナインターセプターへ渡されます。SecurityProxyInterceptor はこのチェックを処理し、このインターセプターは表示されません。
    • Web 接続要求の場合、web.xml で定義され、要求されたリソースとアクセスされた HTTP メソッドに一致するセキュリティー制約を Web サーバーがチェックします。
      要求に対して制約が存在する場合、Web サーバーは JaasSecurityManager を呼び出し、プリンシパルの認証を行います。これにより、確実にユーザーロールがプリンシパルオブジェクトへ関連付けられているようにします。

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

概要

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

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

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

    セキュリティードメインは、サーバーの設定ファイルまたはアプリケーションの記述子ファイルのいずれかに定義できます。
    • サーバーの設定ファイルへセキュリティードメインを設定

      セキュリティードメインは、サーバーの設定ファイルの security サブシステムに設定されます。JBoss Enterprise Application Platform インスタンスが管理対象ドメインで実行されている場合、domain/configuration/domain.xml ファイルになります。JBoss Enterprise Application Platform インスタンスがスタンドアロンサーバーとして実行されている場合は standalone/configuration/standalone.xml ファイルになります。
      otherjboss-web-policy および jboss-ejb-policy セキュリティードメインはデフォルトとして JBoss Enterprise Application Platform 6 に提供されます。次の XML の例は、サーバーの設定ファイルの security サブシステムよりコピーされました。
      <subsystem xmlns="urn:jboss:domain:security:1.2">
          <security-domains>
              <security-domain name="other" cache-type="default">
                  <authentication>
                      <login-module code="Remoting" flag="optional">
                          <module-option name="password-stacking" value="useFirstPass"/>
                      </login-module>
                      <login-module code="RealmDirect" flag="required">
                          <module-option name="password-stacking" value="useFirstPass"/>
                      </login-module>
                  </authentication>
              </security-domain>
              <security-domain name="jboss-web-policy" cache-type="default">
                  <authorization>
                      <policy-module code="Delegating" flag="required"/>
                  </authorization>
              </security-domain>
              <security-domain name="jboss-ejb-policy" cache-type="default">
                  <authorization>
                      <policy-module code="Delegating" flag="required"/>
                  </authorization>
              </security-domain>
          </security-domains>
      </subsystem>
      
      
      
      管理コンソールまたは CLI を使用して、追加のセキュリティードメインを必要に応じて設定することができます。
    • アプリケーションの記述子ファイルにセキュリティードメインを設定

      セキュリティードメインはアプリケーションの WEB-INF/web.xml ファイルにある <jboss-web> 要素の <security-domain> 子要素に指定されます。次の例は my-domain という名前のセキュリティードメインを設定します。
      <jboss-web>
          <security-domain>my-domain</security-domain>
      </jboss-web>        
              
      
      
      
      これが WEB-INF/jboss-web.xml 記述子に指定できる多くの設定の 1 つになります。
  2. EJB へ必要なアノテーションを追加

    @SecurityDomain および @RolesAllowed アノテーションを使用してセキュリティーを EJB に設定します。次の EJBコードの例は、guest ロールのユーザーによる other セキュリティードメインへのアクセスを制限します。
    package example.ejb3;
    
    import java.security.Principal;
    
    import javax.annotation.Resource;
    import javax.annotation.security.RolesAllowed;
    import javax.ejb.SessionContext;
    import javax.ejb.Stateless;
    
    import org.jboss.ejb3.annotation.SecurityDomain;
    
    /**
     * Simple secured EJB using EJB security annotations
     * Allow access to "other" security domain by users in a "guest" role.
     */
    @Stateless
    @RolesAllowed({ "guest" })
    @SecurityDomain("other")
    public class SecuredEJB {
    
       // Inject the Session Context
       @Resource
       private SessionContext ctx;
    
       /**
        * Secured EJB method using security annotations
        */
       public String getSecurityInfo() {
          // Session context injected using the resource annotation
          Principal principal = ctx.getCallerPrincipal();
          return principal.toString();
       }
    }
    
    その他のコード例は、Red Hat カスタマーポータルより入手できる JBoss Enterprise Application Platform 6 Quickstarts バンドルの ejb-security クイックスタートを参照してください。

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

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

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

手順14.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>		
    			
    
    
    
  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-role>
    		<role-name>eap_admin</role-name>
    	</security-role>
    </security-constraint>		
    			
    
    
    
  3. WAR の jboss-web.xml にセキュリティードメインを指定します。

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

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

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

注記

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

例14.1 基本的な認証バルブ

<jboss-web>
  <valve>
    <class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name>
  </valve>
</jboss-web>


このバルブは Kerberos ベースの SSO に使用されます。また、Web アプリケーションに対してサードパーティーのオーセンティケーターを指定する最も単純なパターンを示しています。

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

<jboss-web>
  <valve>
    <class-name>org.jboss.web.tomcat.security.GenericHeaderAuthenticator</class-name>
    <param>
      <param-name>httpHeaderForSSOAuth</param-name>
      <param-value>sm_ssoid,ct-remote-user,HTTP_OBLIX_UID</param-value>
    </param>
    <param>
      <param-name>sessionCookieForSSOAuth</param-name>
      <param-value>SMSESSION,CTSESSION,ObSSOCookie</param-value>
    </param>
  </valve>
</jboss-web>


この例ではバルブにカスタム属性を設定する方法が示されています。オーセンティケーターはヘッダー ID とセッション鍵の存在を確認し、ユーザー名とパスワードバルブとしてセキュリティー層を操作する JAAS フレームワークへ渡します。ユーザー名とパスワードの処理が可能で、サブジェクトに適切なロールを投入できるカスタムの JAAS ログインモジュールが必要となります。設定された値と一致するヘッダー値がない場合、通常のフォームベース認証のセマンティックが適用されます。
カスタムオーセンティケーターの作成

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

例14.3 GenericHeaderAuthenticator.java

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

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

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

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

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

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

  protected boolean trace = log.isTraceEnabled();

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

  private String sessionCookieForSSOAuth = null;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


第15章 マイグレーション

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

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

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

重要

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

JBoss Enterprise Application Platform 6 では、セキュリティードメインは名前で接頭辞 java:/jaas/ を使用しなくなりました。

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

第16章 認証および承認

16.1. 認証について

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

16.2. 承認について

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

16.3. Java Authentication and Authorization Service (JAAS)

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

16.4. Java Authentication and Authorization Service (JAAS) について

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

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

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

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

表16.1 アプリケーション固有の設定ファイル

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

注記

ejb-jar.xmlweb.xml は Java Enterprise Edition (Java EE) 仕様に定義されています。jboss-ejb3.xmlejb-jar.xml の JBoss 固有の拡張を提供し、jboss-web.xmlweb.xml の JBoss 固有の拡張を提供します。
JAAS セキュリティーマネージャー MBean

Java Authentication and Authorization Service (JAAS) はプラグ可能認証モジュール (PAM) を使用した、 Java アプリケーションのユーザーレベルのセキュリティーに対するフレームワークです。JAAS は Java ランタイム環境 (JRE) に統合されます。JBoss Enterprise Application Platform では、コンテナ側のコンポーネントは org.jboss.security.plugins.JaasSecurityManager MBean で、AuthenticationManager インターフェースと RealmMapping インターフェースのデフォルト実装を提供します。

JaasSecurityManager MBean はアプリケーションの EJB または Web デプロイメント記述子ファイルに指定されているセキュリティードメインを EJB および Web コンテナレイヤーに統合します。アプリケーションがデプロイすると、コンテナはデプロイメント記述子に指定されたセキュリティードメインをコンテナのセキュリティーマネージャーインスタンスへ関連付けします。セキュリティーマネージャーはセキュリティードメインをサーバーグループまたはスタンドアローンサーバー上に設定します。
クライアントと JAAS を持つコンテナとの間の対話フロー

JaasSecurityManager は JAAS パッケージを使用して AuthenticationManager と RealmMapping インターフェースの動作を実装します。JaasSecurityManager へ割り当てられたセキュリティードメインに設定されたログインモジュールインスタンスを実行するとこの動作が生じます。ログインモジュールはセキュリティードメインのプリンシパルの認証やロールマッピングの挙動を実装します。ドメインの異なるログインモジュール設定を組み込むと、異なるセキュリティードメイン全体で JaasSecurityManager を使用することができます。

JaasSecurityManager がどのように JAAS 認証プロセスを使用するかを説明する次の手順を見てください。この手順はメソッド EJBHome を実装するメソッドのクライアント呼び出しの概要になります。EJB は既にサーバーにデプロイされ、EJBHome インターフェースメソッドは ejb-jar.xml 記述子の <method-permission> 要素を使用してセキュアな状態になっています。jboss-ejb3.xml ファイルの <security-domain> 要素に指定される jwdomain セキュリティードメインを使用します。以下の図は後で説明する手順を表しています。
EJB の認証手順

図16.1 保護された EJB メソッド呼び出しの手順

  1. クライアントが JAAS のログインを実行し、認証のプリンシパルと認証情報を確立します。上図では Client Side Login とラベル付けされます。JNDI より実行することも可能です。
    JAAS ログインを実行するには、LoginContext インスタンスを作成し、使用する設定の名前を渡します。ここでの設定名は other になります。このワンタイムログインは、ログインプリンシパルと認証情報を後続の EJB メソッド呼び出しすべてへ関連付けます。プロセスがユーザーを認証するとは限りません。クライアント側のログインの性質は、クライアントが使用するログインモジュール設定によって異なります。この例では、other というクライアント側ログイン設定エントリーが ClientLoginModule ログインモジュールを使用します。サーバー上で後で認証が行われるため、このモジュールはユーザー名とパスワードを EJB 呼び出しレイヤーへバインドします。クライアントのアイデンティティーはクライアント上で認証されません。
  2. クライアントは EJBHome メソッドを取得し、このメソッドをサーバー上で呼び出します。呼び出しにはクライアントによって渡されたメソッド引数や、クライアント側 JAAS ログインからのユーザー ID や認証情報が含まれます。
  3. サーバー上では、セキュリティーインターセプターがメソッドを呼び出したユーザーを認証します。これには別の JAAS ログインが関係します。
  4. セキュリティードメインはログインモジュールの選択を決定します。セキュリティードメインの名前はログイン設定エントリー名として LoginContext コンストラクターへ渡されます。EJB セキュリティードメインは jwdomain です。JAAS 認証に成功すると、JAAS サブジェクトが作成されます。JAAS サブジェクトには次の詳細を含む PrincipalSet が含まれます。
    • デプロイメントセキュリティー環境よりクライアントアイデンティティーへ対応する java.security.Principal インスタンス。
    • ユーザーのアプリケーションドメインからのロール名が含まれる Roles と呼ばれる java.security.acl.Grouporg.jboss.security.SimplePrincipal タイプのオブジェクトはロール名を表します。これらのロールは、ejb-jar.xmlEJBContext.isCallerInRole(String) メソッド実装の制約に従って EJB メソッドへのアクセスを検証します。
    • アプリケーションドメインの呼び出し側のアイデンティティーに対応する 1 つの org.jboss.security.SimplePrincipal が含まれる CallerPrincipal という名前の任意の java.security.acl.Group。CallerPrincipal グループメンバーは EJBContext.getCallerPrincipal() メソッドによって返される値です。このマッピングは、運用セキュリティー環境のプリンシパルがアプリケーションが認識するプリンシパルへマッピングできるようにします。CallerPrincipal マッピングが存在しない場合、運用プリンシパルはアプリケーションドメインプリンシパルと同じになります。
  5. EJB メソッドを呼び出しているユーザーは呼び出しが許可されているユーザーであることをサーバーが検証します。次の手順でこの承認を実行します。
    • EJB コンテナから EJBメソッドへアクセスすることが許可されるロールの名前を取得します。呼び出されたメソッドが含まれるすべての <method-permission> 要素の ejb-jar.xml 記述子 <role-name> 要素によってロール名が判断されます。
    • 割り当てられたロールがなかったり、メソッドが exclude-list 要素に指定されている場合、メソッドへのアクセスは拒否されます。それ以外の場合は、セキュリティーインターセプターによってセキュリティーマネージャー上で doesUserHaveRole メソッドが呼び出され、呼び出し側に割り当てられたロール名の 1 つがあるかどうかを確認します。このメソッドはロール名より繰り返され、認証されたユーザーの Subject Roles グループに割り当てられたロール名を持つ SimplePrincipal が含まれるか確認します。Roles グループメンバーのロール名がある場合はアクセスが許可されます。メンバーのロール名がない場合はアクセスが拒否されます。
    • EJB がカスタムのセキュリティープロキシを使用する場合、メソッドの呼び出しはプロキシへ委譲されます。セキュリティープロキシが呼び出し側へのアクセスを拒否すると、java.lang.SecurityException がスローされます。それ以外の場合は EJB メソッドへのアクセスは許可され、メソッド呼び出しは次のコンテナインターセプターへ渡されます。SecurityProxyInterceptor はこのチェックを処理し、このインターセプターは表示されません。
    • Web 接続要求の場合、web.xml で定義され、要求されたリソースとアクセスされた HTTP メソッドに一致するセキュリティー制約を Web サーバーがチェックします。
      要求に対して制約が存在する場合、Web サーバーは JaasSecurityManager を呼び出し、プリンシパルの認証を行います。これにより、確実にユーザーロールがプリンシパルオブジェクトへ関連付けられているようにします。

16.5. JACC (Java Authorization Contract for Containers)

16.5.1. JACC (Java Authorization Contract for Containers) について

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 Enterprise Application Platform は、セキュリティーサブシステムのセキュリティー機能内に JACC のサポートを実装します。

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

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

セキュリティードメインに JACC サポートを追加するには、required フラグセットで JACC 承認ポリシーをセキュリティードメインの承認スタックへ追加します。以下は JACC サポートを持つセキュリティードメインの例になりますが、セキュリティードメインは 直接 XML には設定されず、管理コンソールまたは管理 CLI で設定されます。

<security-domain name="jacc" cache-type="default">
    <authentication>
        <login-module code="UsersRoles" flag="required">
        </login-module>
    </authentication>
    <authorization>
        <policy-module code="JACC" flag="required"/>
    </authorization>
</security-domain>

JACC を使用するよう Web アプリケーションを設定

jboss-web.xml は デプロイメントの META-INF/ または WEB-INF/ ディレクトリに存在し、Web コンテナに対する追加の JBoss 固有の設定を格納し、上書きします。JACC が有効になっているセキュリティードメインを使用するには、<security-domain> 要素が含まれるようにし、 さらに <use-jboss-authorization> 要素を true に設定する必要があります。以下は、上記の JACC セキュリティードメインを使用するよう適切に設定されているアプリケーションになります。

<jboss-web>
    <security-domain>jacc</security-domain>
    <use-jboss-authorization>true</use-jboss-authorization>
</jboss-web>

JACC を使用するよう EJB アプリケーションを設定

セキュリティードメインと JACC を使用するよう EJB を設定する方法は Web アプリケーションの場合とは異なります。EJB の場合、ejb-jar.xml 記述子にてメソッドまたはメソッドのグループ上でメソッドパーミッションを宣言できます。<ejb-jar> 要素内では、すべての子 <method-permission> 要素に JACC ロールに関する情報が含まれます。詳細は設定例を参照してください。EJBMethodPermission クラスは Java Enterprise Edition 6 API の一部で、http://docs.oracle.com/javaee/6/api/javax/security/jacc/EJBMethodPermission.html で説明されています。

例16.1 EJB の JACC メソッドパーミッション例

<ejb-jar>
  <method-permission>
    <description>The employee and temp-employee roles may access any method of the EmployeeService bean </description>
    <role-name>employee</role-name>
    <role-name>temp-employee</role-name>
    <method>
      <ejb-name>EmployeeService</ejb-name>
      <method-name>*</method-name>
    </method>
  </method-permission>
</ejb-jar>
	      


Web アプリケーションと同様にセキュリティードメインを使用して EJB の認証および承認メカニズムを指定することも可能です。セキュリティードメインは <security> 子要素の jboss-ejb3.xml 記述子に宣言されます。セキュリティードメインの他に、EJB が実行されるプリンシパルを変更する run-as プリンシパル を指定することもできます。

例16.2 EJB におけるセキュリティードメイン宣言の例


<security>
  <ejb-name>*</ejb-name>
  <security-domain>myDomain</s:security-domain>
  <run-as-principal>myPrincipal</s:run-as-principal>
</s:security>



16.6. JASPI (Java Authentication SPI for Containers)

16.6.1. JASPI (Java Authentication SPI for Containers) のセキュリティーについて

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

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

JASPI プロバイダーに対して認証するには、<authentication-jaspi> 要素をセキュリティードメインに追加します。設定は標準的な認証モジュールと似ていますが、ログインモジュール要素は <login-module-stack> 要素で囲まれています。設定の構成は次のとおりです。

例16.3 authentication-jaspi 要素の構成

<authentication-jaspi>
	<login-module-stack name="...">
	  <login-module code="..." flag="...">
	    <module-option name="..." value="..."/>
	  </login-module>
	</login-module-stack>
	<auth-module code="..." login-module-stack-ref="...">
	  <module-option name="..." value="..."/>
	</auth-module>
</authentication-jaspi>



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

付録A 参考資料

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

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

表A.1 Client

コード
Client
クラス
org.jboss.security.ClientLoginModule
説明
このログインモジュールは、JBoss Enterprise Application Platform がクライアントとして動作するときに呼び出し元 ID とクレデンシャルを確立するよう設定されています。これは、実際のサーバー認証に使用されるセキュリティードメインの一部として使用しないでください。

表A.2 クライアントモジュールオプション

オプション タイプ デフォルト 説明
multi-threaded
true または false
false
各スレッドが独自のプリンシパルとクレデンシャルストレージを持つ場合は、true に設定します。VM 内のすべてのスレッドが同じ ID とクレデンシャルを共有するよう指定する場合は false に設定します。
password-stacking
useFirstPass または false
false
このログインモジュールが ID として使用する LoginContext に格納された情報を探すよう指定する場合は、useFirstPass に設定します。このオプションは、他のログインモジュールをスタックする場合に使用できます。
>restore-login-identity
true または false
false
() メソッドの先頭に示された ID とクレデンシャルを logout() メソッドの呼び出し後に復元する必要がある場合は true に設定します。

表A.3 Certificate

コード
Certificate
クラス
org.jboss.security.auth.spi.BaseCertLoginModule
説明
このログインモジュールは、X509 Certificates に基づいてユーザーを認証するよう設計されています。この使用例は、Web アプリケーションの CLIENT-CERT 認証です。

表A.4 Certificate モジュールオプション

オプション タイプ デフォルト 説明
securityDomain
文字列
なし
信頼済み証明書を保持するトラストストア用 JSSE 設定を持つセキュリティードメインの名前。
verifier
クラス
なし
ログイン証明書の検証に使用する org.jboss.security.auth.certs.X509CertificateVerifier のクラス名。

表A.5 CertificateUsers

コード
CertificateUsers
クラス
org.jboss.security.auth.spi.UsersRolesLoginModule
説明
プロパティーリソースを使用します。最初のコードがユーザー名をパスワードにマッピングし、次のコードがユーザー名をロールにマッピングします。

表A.6 CertificateUsers モジュールオプション

オプション タイプ デフォルト 説明
unauthenticatedIdentity
文字列
なし
認証情報を含まない要求に割り当てる必要があるプリンシパル名を定義します。これにより、保護されていないサーブレットは特定のロールを必要としない EJB でメソッドを呼び出すことができるようになります。このようなプリンシパルでは、ロールが割り当てられず、unchecked permission 制約に関連付けられたセキュアでない EJB または EJB メソッドにのみアクセスできます。
password-stacking
useFirstPass または false
false
このログインモジュールが ID として使用する LoginContext に格納された情報を探すよう指定する場合は、useFirstPass に設定します。このオプションは、他のログインモジュールをスタックする場合に使用できます。
hashAlgorithm 文字列
なし
パスワードをハッシュ化するために使用する java.security.MessageDigest アルゴリズムの名前。デフォルト値はないため、ハッシュを有効にするためにこのオプションを明示的に設定する必要があります。hashAlgorithm が指定された場合は、inputPassword 引数として UsernamePasswordLoginModule.validatePassword に渡す前に CallbackHandler から取得されたクリアテキストパスワードがハッシュ化されます。users.properties ファイルに格納された expectedPassword も、同様にハッシュ化する必要があります。java.security.MessageDigest およびこのクラスがサポートするアルゴリズムの詳細は http://docs.oracle.com/javase/6/docs/api/java/security/MessageDigest.html を参照してください。
hashEncoding
base64 または hex
base64
hashAlgorithm も設定されている場合、ハッシュ化されたパスワードの文字列形式。
hashCharSet
文字列
コンテナの環境で設定されたデフォルトのエンコーディング。
クリアテキストのパスワードをバイトアレイに変換するために使用されるエンコーディング。
usersProperties
プロパティーファイルまたはリソースの完全修飾ファイルパスまたは完全修飾ファイル名。
users.properties
ユーザーとパスワード間のマッピングが含まれるファイル。ファイルの各プロパティーの形式は username=password です。
rolesProperties
プロパティーファイルまたはリソースの完全修飾ファイルパスまたは完全修飾ファイル名。
roles.properties
ユーザーとロール間のマッピングを含むファイル。ファイルの各プロパティーの形式は username=role1,role2,...,roleN です。
ignorePasswordCase
true または false
false
パスワード比較で大文字と小文字の区別を無視するかどうか。これは、ハッシュ化されたパスワードが大文字であるか小文字であるかが重要でない、ハッシュ化パスワードエンコーディングの場合に役に立ちます。
principalClass
完全修飾クラス名
なし
プリンシパル名として String 引数を取るコンストラクターを含む Principal 実装クラス。
roleGroupSeparator
単一の文字
. (ピリオド 1 つ)
rolesGroup ファイルでユーザー名とロールグループ名を区別するために使用される文字。
defaultUsersProperties
文字列
defaultUsers.properties
usersProperties ファイルが見つからない場合に使用するリソースまたはファイルの名前。
defaultRolesProperties
文字列
defaultRoles.properties
rolesProperties ファイルが見つからない場合に使用するリソースまたはファイルの名前。
hashUserPassword
true または false
true
hashAlgorithm が指定された場合にユーザーが入力したパスワードをハッシュ化するかどうか。デフォルト値は true です。
hashStorePassword
true または false
true
hashAlgorithm が指定された場合に getUsersPassword() から返されたストアパスワードをハッシュ化するかどうか。
digestCallback
完全修飾クラス名
なし
ソルト値などのプレまたはポストダイジェストコンテンツを含む org.jboss.crypto.digest.DigestCallback 実装のクラス名。hashAlgorithm が指定された場合にのみ使用されます。
storeDigestCallback
完全修飾クラス名
なし
ストアパスワードをハッシュ化するソルト値などのプレまたはポストダイジェストコンテンツを含む org.jboss.crypto.digest.DigestCallback 実装のクラス名。hashStorePassword が true であり、hashAlgorithm が指定された場合にのみ使用されます。
callback.option.STRING
各種 なし
callback.option. の前に指定されたすべてのオプションは、DigestCallback.init(Map) メソッドに渡されます。入力されたユーザー名は、常に javax.security.auth.login.name オプションを介して渡され、入力/ストアパスワードは、javax.security.auth.login.password オプションを介して digestCallback または storeDigestCallback に渡されます。

表A.7 CertificateRoles

コード
CertificateRoles
クラス
org.jboss.security.auth.spi.CertRolesLoginModule
説明
このログインモジュールは、Certificate ログインモジュールを拡張して、プロパティーファイルからロールマッピング機能を追加します。同じすべてのオプションを Certificate ログインモジュールとして取得し、次のオプションを追加します。

表A.8 CertificateRoles モジュールオプション

オプション タイプ デフォルト 説明
rolesProperties
文字列
roles.properties
各ユーザーに割り当てるロールを含むリソースまたはファイルの名前。ロールプロパティーファイルの形式は username=role1,role2 である必要があります。username は証明書の DN で、= (等記号) やスペース文字をすべてエスケープします。正しい形式を用いた例は次のとおりです。
CN\=unit-tests-client,\ OU\=Red\ Hat\ Inc.,\ O\=Red\ Hat\ Inc.,\ ST\=North\ Carolina,\ C\=US=JBossAdmin
defaultRolesProperties
文字列
defaultRoles.properties
rolesProperties ファイルが見つからない場合に使用するリソースまたはファイルの名前。
roleGroupSeparator
単一の文字
. (ピリオド 1 つ)
roleProperties ファイルでどの文字をロールグループセパレーターとして使用するか。

表A.9 Database

コード Database
クラス
org.jboss.security.auth.spi.DatabaseServerLoginModule
説明
認証とロールマッピングをサポートする JDBC ベースのログインモジュール。これは、次の定義を使用して、2 つの論理テーブルに基づきます。
  • Principals: PrincipalID (text), Password (text)
  • Roles: PrincipalID (text), Role (text), RoleGroup (text)

表A.10 Database モジュールオプション

オプション タイプ デフォルト 説明
dsJndiName
JNDI リソース
なし
認証情報を保持する JNDI リソースの名前。このオプションは必須です。
principalsQuery
準備済み SQL ステートメント
select Password from Principals where PrincipalID=?
プリンシパルに関する情報を取得するための準備済み SQL クエリー。
rolesQuery
準備済み SQL ステートメント
select Role, RoleGroup from Roles where PrincipalID=?
ロールの情報を取得するための準備済み SQL クエリー。select Role, RoleGroup from Roles where PrincipalID=? と同等である必要があります。ここで、Role はロール名で、RoleGroup 列の値は常に R が大文字である Roles または CallerPrincipal である必要があります。

表A.11 DatabaseCertificate

コード
DatabaseCertificate
クラス
org.jboss.security.auth.spi.DatabaseCertLoginModule
説明
このログインモジュールは、Certificate ログインモジュールを拡張して、データベーステーブルからロールマッピング機能を追加します。同じオプションと次の追加オプションが存在します。

表A.12 DatabaseCertificate モジュールオプション

オプション タイプ デフォルト 説明
dsJndiName
JNDI リソース
認証情報を保持する JNDI リソースの名前。このオプションは必須です。
rolesQuery
準備済み SQL ステートメント
select Role,RoleGroup from Roles where PrincipalID=?
ロールをマップするために実行される SQL 準備済みステートメント。これは、select Role, RoleGroup from Roles where PrincipalID=? と同等である必要があります。Role はロール名で、RoleGroup 列の値は常に R が大文字である Roles または CallerPrincipal である必要があります。
suspendResume
true または false
true
データベース操作中に既存の JTA トランザクションを一時停止するかどうか。

表A.13 Identity

コード
Identity
クラス
org.jboss.security.auth.spi.IdentityLoginModule
説明
モジュールオプションで指定されたプリンシパルをモジュールに対して認証されたサブジェクトと関連付けます。使用される Principal クラスのタイプは org.jboss.security.SimplePrincipal. です。プリンシパルオプションが指定されない場合は、名前が guest のプリンシパルが使用されます。

表A.14 Identity モジュールオプション

オプション タイプ デフォルト 説明
principal
文字列
guest
プリンシパルに使用する名前。
roles
文字列のカンマ区切りリスト
なし
サブジェクトに割り当てられるロールのカンマ区切りリスト。

表A.15 Ldap

コード
Ldap
クラス
org.jboss.security.auth.spi.LdapLoginModule
説明
ユーザー名とパスワードが、JNDI LDAP プロバイダーを使用してアクセスできる LDAP サーバーに格納された場合に、LDAP サーバーに対して認証します。多くのオプションは、LDAP プロバイダーまたは環境によって決定されるため、必須ではありません。

表A.16 Ldap モジュールオプション

オプション タイプ デフォルト 説明
java.naming.factory.initial
クラス名
com.sun.jndi.ldap.LdapCtxFactory
InitialContextFactory 実装クラス名。
java.naming.provider.url
ldap:// URL
なし
LDAP サーバーの URL。
java.naming.security.authentication
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 タイプを使用した不透明なオブジェクトとしてクレデンシャルを取得するかどうか。これにより、non-char[] クレデンシャル情報を LDAP サーバーに渡すことができるようになります。
rolesCtxDN
完全修飾 DN
なし
ユーザーロールを検索するコンテキストの完全修飾 DN。
userRolesCtxDNAttributeName
属性
なし
ユーザーロールを検索するコンテキストの DN を含むユーザーオブジェクトの属性。これは、rolesCtxDN と異なるため、ユーザーのロールを検索するコンテキストは各ユーザーに対して一意になることがあります。
rolesAttributeID
属性
roles
ユーザーロールを含む属性の名前。
rolesAttributeIsDN
true または false
false
roleAttributeID にロールオブジェクトの完全修飾 DN が含まれるかどうか。false の場合は、コンテキスト名の roleNameAttributeId 属性の値からロール名が取得されます。Microsoft Active Directory などの特定のディレクトリースキーマでは、この属性を true に設定する必要があります。
rolesNameAttributeID
属性
group
ロール名を含む roleCtxDN コンテキスト内の属性の名前。roleAttributeIsDN プロパティーが true に設定された場合、このプロパティーはロールオブジェクトの名前属性を見つけるために使用されます。
uidAttributeID
属性
uid
ユーザー ID に対応する UserRolesAttributeDN の属性の名前。これは、ユーザーロールを見つけるために使用されます。
matchOnUserDN
true または false
false
ユーザーロールの検索でユーザーの完全識別 DN またはユーザー名のみに一致するかどうか。true の場合、完全 userDN は一致する値として使用されます。false の場合は、ユーザー名のみが uidAttributeName 属性に対して一致する値として使用されます。
allowEmptyPasswords
true または false
true
空白のパスワードを許可するかどうか。ほとんどの LDAP サーバーでは、空白のパスワードが匿名ログイン試行として扱われます。空のパスワードを拒否するには、これを false に設定します。

表A.17 LdapExtended

コード
LdapExtended
クラス
org.jboss.security.auth.spi.LdapExtLoginModule
説明
検索を使用してバインドユーザーと関連するロールを見つける別の LDAP ログインモジュール実装。ロールクエリーは再帰的に DN に従い、階層ロール構造をナビゲートします。同じ java.naming オプションを Ldap モジュールとして使用し、Ldap モジュールの他のオプションの代わりに次のオプションを使用します。
認証は 2 つの手順で行われます。
  1. LDAP サーバーに対する初期バインドは、bindDN および bindCredential オプションを使用して行われます。bindDN は、baseCtxDN および rolesCtxDN ツリーの両方でユーザーとロールを検索できるユーザーです。認証するユーザー DN は、baseFilter 属性で指定されたフィルターを使用して問い合わされます。
  2. 結果となるユーザー DN は、InitialLdapContext 環境 Context.SECURITY_PRINCIPAL としてユーザー DN を使用して LDAP サーバーにバインドすることにより認証されます。Context.SECURITY_CREDENTIALS プロパティーは、コールバックハンドラーにより取得された String パスワードに設定されます。

表A.18 LdapExtended モジュールオプション

オプション タイプ デフォルト 説明
baseCtxDN
完全修飾 DN
なし
ユーザー検索を開始する最上位コンテキストの固定 DN。
bindDN
完全修飾 DN
なし
ユーザーおよびロールクエリーのために LDAP サーバーに対してバインドするために使用される DN。この DN は baseCtxDN および rolesCtxDN の値に対する読み取りおよび検索パーミッションを必要とします。
bindCredential
文字列、オプションで暗号化
なし
bindDN のパスワード。これは、jaasSecurityDomain が指定された場合に暗号化できます。
jaasSecurityDomain
JMX ObjectName
なし
bindCredential を暗号化するために使用する JaasSecurityDomain の JMX ObjectName。パスワードの暗号化形式は、JaasSecurityDomain.encrypt64(byte[]) メソッドにより返された形式です。
baseFilter
LDAP フィルター文字列
なし
認証するユーザーのコンテキストを見つけるために使用される検索フィルター。入力ユーザー名またはログインモジュールコールバックから取得された userDN が、{0} 式が使用されたフィルターに置換されます。検索フィルターの一般的な例は (uid={0}) です。
rolesCtxDN
完全修飾 DN
なし
ユーザーロールを検索するコンテキストの固定 DN。これは、実際のロールが存在する DN ではなく、ユーザーロールを含むオブジェクトが存在する DN です。たとえば、Microsoft Active Directory サーバーでは、これは、ユーザーアカウントが存在する DN です。
roleFilter
LDAP フィルター文字列
認証済みユーザーと関連付けられたロールを検索するために使用される検索フィルター。入力ユーザー名またはログインモジュールコールバックから取得された userDN が {0} 式が使用されたフィルターに置換されます。認証済み userDN は、{1} が使用されたフィルターに置換されます。入力ユーザー名に一致する検索フィルター例は、(member={0}) です。認証済み userDN に一致する他の例は (member={1}) です。
roleAttributeIsDN
true または false
false
roleAttributeID にロールオブジェクトの完全修飾 DN が含まれるかどうか。false の場合は、コンテキスト名の roleNameAttributeId 属性の値からロール名が取得されます。Microsoft Active Directory などの特定のディレクトリースキーマでは、この属性を true に設定する必要があります。
defaultRole
ロール名
なし
認証された全ユーザーに対して含まれるロール
parseRoleNameFromDN
true または false
false
クエリによって返された DN に roleNameAttributeID が含まれるかどうかを示すフラグ。true に設定された場合、DN は roleNameATtributeID に対してチェックされます。false に設定された場合、DN は roleNameATtributeID に対してチェックされません。このフラグは LDAP クエリのパフォーマンスを向上できます。
parseUsername
true または false
false
DN がユーザー名に対して解析されるかどうかを示すフラグ。true に設定された場合、 DN はユーザー名に対して解析されます。false に設定された場合、 DN はユーザー名に対して解析されません。このオプションは usernameBeginString および usernameEndString と共に使用されます。
usernameBeginString
文字列
なし
ユーザー名を公開するため、DN の最初から削除される文字列を定義します。このオプションは usernameEndString と共に使用されます。
usernameEndString
文字列
なし
ユーザー名を公開するため、DN の最後から削除される文字列を定義します。このオプションは usernameBeginString と共に使用されます。
roleNameAttributeID
属性
group
ロール名を含む roleCtxDN コンテキスト内の属性の名前。roleAttributeIsDN プロパティーが true に設定された場合、このプロパティーはロールオブジェクトの名前属性を見つけるために使用されます。
distinguishedNameAttribute
属性
distinguishedName
ユーザーの DN を含むユーザーエントリーの属性の名前。これは、ユーザー自身の DN に正しいユーザーマッピングを防ぐ特殊文字 (バックスラッシュなど) が含まれる場合に、必要になることがあります。属性が存在しない場合は、エントリーの DN が使用されます。
roleRecursion
整数
0
ロール検索が一致するコンテキストで行われる再帰のレベル数。再帰を無効にするには、これを 0 に設定します。
searchTimeLimit
整数
10000 (10 秒)
ユーザーまたはロール検索のタイムアウト (ミリ秒単位)。
searchScope
OBJECT_SCOPE, ONELEVEL_SCOPE, SUBTREE_SCOPE のいずれか。
SUBTREE_SCOPE
使用する検索範囲。
allowEmptyPasswords
true または false
true
空白のパスワードを許可するかどうか。ほとんどの LDAP サーバーでは、空白のパスワードが匿名ログイン試行として扱われます。空のパスワードを拒否するには、これを false に設定します。

表A.19 RoleMapping

コード
RoleMapping
クラス
org.jboss.security.auth.spi.RoleMappingLoginModule
説明
認証プロセスの結果であるロールを宣言ロールに対してマップします。このモジュールは、セキュリティードメインに追加する場合に optional とフラグ付けする必要があります。

表A.20 RoleMapping モジュールオプション

オプション タイプ デフォルト 説明
rolesProperties
プロパティーファイルまたはリソースの完全修飾ファイルパスまたは完全修飾ファイル名。
roles.properties
ロールを置換ロールに対してマップするプロパティーファイルまたはリソースの完全修飾ファイルパスまたはファイル名。形式は original_role=role1,role2,role3 になります。
replaceRole
true または false
false
現在のロールを追加するか、現在のロールをマップされたロールに置き換えるか。true に設定された場合は、置き換えられます。

表A.21 RunAs

コード
RunAs
クラス
Class: org.jboss.security.auth.spi.RunAsLoginModule
説明
run as ロールを、認証のログイン段階の間スタックにプッシュし、コミットまたはアボート段階でスタックから run as ロールをポップするヘルパーモジュール。このログインモジュールは、セキュアな EJB にアクセスするログインモジュールなどの、認証を実行するためにセキュアなリソースにアクセスする必要がある他のログインモジュール用ロールを提供します。run as ロールを確立する必要があるログインモジュールの前に、RunAsLoginModule を設定する必要があります。

表A.22 RunAs オプション

オプション タイプ デフォルト 説明
roleName
ロール名。
nobody
ログイン段階で run as ロールとして使用するロールの名前。

表A.23 Simple

コード
Simple
クラス
org.jboss.security.auth.spi.SimpleServerLoginModule
説明
テスト目的でセキュリティーを素早くセットアップするモジュール。次の単純なアルゴリズムが実装されます。
  • パスワードが null である場合、ユーザーを認証し、guest の ID と guest のロールを割り当てます。
  • パスワードが null でなくユーザーと同じ場合、ユーザー名と同じ ID、admin ロールおよび guest ロールを割り当てます。
  • それ以外の場合は認証に失敗します。
Simple モジュールオプション

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

表A.24 ConfiguredIdentity

コード
ConfiguredIdentity
クラス
org.picketbox.datasource.security.ConfiguredIdentityLoginModule
説明
モジュールオプションで指定されたプリンシパルをモジュールに対して認証されたサブジェクトに関連付けます。使用される Principal クラスのタイプは org.jboss.security.SimplePrincipal です。

表A.25 ConfiguredIdentity モジュールオプション

オプション タイプ デフォルト 説明
principal
プリンシパルの名前。
guest
モジュールに対して認証されるサブジェクトに関連付けられるプリンシパル。

表A.26 SecureIdentity

コード
SecureIdentity
クラス
org.picketbox.datasource.security.SecureIdentityLoginModule
説明
このモジュールは、レガシー対応のために提供されます。このモジュールを使用すると、パスワードを暗号化し、暗号化されたパスワードを最適なプリンシパルで使用します。アプリケーションが SecureIdentity を使用する場合は、パスワード vault メカニズムを代わりに使用することを検討してください。

表A.27 SecureIdentity モジュールオプション

オプション タイプ デフォルト 説明
username
文字列 なし 認証のユーザー名
password
暗号化文字列 なし
認証に使用するパスワード。パスワードを暗号化するには、コマンドラインで直接モジュールを使用します。
java org.picketbox.datasource.security.SecureIdentityLoginModule password_to_encrypt
このコマンドの結果をモジュールオプションの値フィールドに貼り付けます。
managedConnectionFactoryName
JCA リソース なし
データソースの JCA 接続ファクトリーの名前。

表A.28 PropertiesUsers

コード
PropertiesUsers
クラス
org.jboss.security.auth.spi.PropertiesUsersLoginModule
説明
認証用ユーザー名およびパスワードを格納するプロパティーファイルを使用します。認証 (ロールマッピング) は提供されません。このモジュールは、テスト向けのみに限定されます。

表A.29 PropertiesUsers モジュールオプション

オプション タイプ デフォルト 説明
properties
Java プロパティーファイルまたはリソースの完全修飾ファイルパスまたは完全修飾ファイル名。 なし
認証に使用するユーザー名とクリアテキストパスワードを含むプロパティーファイル。

表A.30 SimpleUsers

コード
SimpleUsers
クラス
org.jboss.security.auth.spi.SimpleUsersLoginModule
説明
このログインモジュールは、ユーザー名とクリアテキストパスワードを Java プロパティーファイルに格納します。これは、テスト用に提供され、本番稼働環境には適しません。

表A.31 SimpleUsers モジュールオプション

オプション タイプ デフォルト 説明
username
文字列 なし 認証に使用するユーザー名。
password
文字列 なし 認証に使用するクリアテキストパスワード。

表A.32 LdapUsers

コード
LdapUsers
クラス
org.jboss.security.auth.spi.LdapUsersLoginModule
説明
LdapUsers モジュールは ExtendedLDAP および AdvancedLdap モジュールが導入されたため廃止になりました。

表A.33 Kerberos

コード
Kerberos
クラス
com.sun.security.auth.module.Krb5LoginModule
説明
GSSAPI を使用して Kerberos ログイン認証を実行します。このモジュールは、Sun Microsystems により提供された API のセキュリティーフレームワークの一部です。詳細については、http://docs.oracle.com/javase/1.4.2/docs/guide/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html を参照してください。このモジュールは、認証とロールのマッピングを処理する別のモジュールと組み合わせる必要があります。

表A.34 Kerberos モジュールオプション

オプション タイプ デフォルト 説明
storekey
true または false
false
KerberosKey をサブジェクトのプライベートクレデンシャルに追加するかどうか。
doNotPrompt
true または false
false
true に設定された場合、ユーザーはパスワードを要求されません。
useTicketCache
true または false のブール値
false
true の場合、GTG はチケットキャッシュから取得されます。false の場合、チケットキャッシュは使用されません。
ticketcache
Kerberos チケットキャッシュを表すファイルまたはリソース。
デフォルトは使用するオペレーティングシステムによって異なります。
  • 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 に設定して、認証段階が完了した後に供給状態からユーザー名とパスワードを削除します。

表A.35 SPNEGOUsers

コード
SPNEGOUsers
クラス
org.jboss.security.negotiation.spnego.SPNEGOLoginModule
説明
Microsoft Active Directory サーバーまたは SPNEGO をサポートする他の環境に対して SPNEGO 認証を許可します。SPNEGO は Kerberos クレデンシャルを持つこともできます。このモジュールは、認証とロールのマッピングを処理する別のモジュールと組み合わせる必要があります。

表A.36 SPNEGO モジュールオプション

オプション タイプ デフォルト 説明
storeKey
true または false
false
キーを格納するかどうか。
useKeyTab
true または false
false
キーテーブルを使用するかどうか。
principal
Kerberos 認証のプリンシパルを表す文字列
なし
認証のプリンシパルの名前。
keyTab
キーテーブルを表すファイルまたはリソース。
none
キーテーブルの場所。
doNotPrompt
true または false
false
パスワードを要求するかどうか。
debug
true または false
false
デバッグ目的でより詳細なメッセージを記録するかどうか。

表A.37 AdvancedLdap

コード AdvancedLdap
クラス
org.jboss.security.negotiation.AdvancedLdapLoginModule
説明
SASL や JAAS セキュリティードメインの使用など、追加機能を提供するモジュール。

表A.38 AdvancedLdap モジュールオプション

オプション タイプ デフォルト 説明
bindAuthentication
文字列
なし
ディレクトリサーバーへのバインディングに使用する SASL 認証のタイプ。
jassSecurityDomain
string
なし
使用する JAAS セキュリティードメインの名前。
java.naming.provider.url
string
なし
ディレクトリサーバーの URI。
baseCtxDN
完全修飾識別名 (DN)。
なし
検索の基盤として使用する識別名。
baseFilter
LDAP 検索フィルターを表す文字列。
なし
検索結果を絞り込むために使用するフィルター。
roleAttributeID
LDAP 属性を表す文字列。
なし
承認ロールの名前が含まれる LDAP 属性。
roleAttributeIsDN
true または false
false
ロール属性が識別名 (DN) であるかどうか。
roleNameAttributeID
LDAP 属性を表す文字列。
なし
実際のロール属性が含まれる RoleAttributeId 内に格納された属性。
recurseRoles
true または false
false
ロールに対して RoleAttributeId を再帰的に検索するかどうか。

表A.39 AdvancedADLdap

コード AdvancedADLdap
クラス
org.jboss.security.negotiation.AdvancedADLoginModule
説明
このモジュールは AdvancedLdap ログインモジュールを拡張し、Microsoft Active Directory に関連する追加パラメーターを追加します。

表A.40 UsersRoles

コード UsersRoles
クラス
org.jboss.security.auth.spi.UsersRolesLoginModul
説明
2 つの異なるプロパティーファイルに格納された複数のユーザーおよびユーザーロールをサポートする簡単なログインモジュール。

表A.41 UsersRoles モジュールオプション

オプション タイプ デフォルト 説明
usersProperties
ファイルまたはリソースへのパス。
users.properties
ユーザーからパスワードへのマッピングが含まれるファイルまたはリソース。ファイルの形式は user=hashed-password になります。
rolesProperties
ファイルまたはリソースへのパス。
roles.properties
ユーザーからロールへのマッピングが含まれるファイルまたはリソース。ファイルの形式は username=role1,role2,role3 になります。
password-stacking
useFirstPass または false
false
このログインモジュールが ID を見つけるため LoginContext に格納された情報を最初に探すことを示す useFirstPass の値。このオプションは、他のログインモジュールをこのモジュールとスタックする場合に使用できます。
hashAlgorithm
パスワードをハッシュ化するアルゴリズムを表す文字列。
none
パスワードをハッシュ化するために使用する java.security.MessageDigest アルゴリズムの名前。デフォルト値はないため、ハッシュを有効にするためにこのオプションを明示的に設定する必要があります。hashAlgorithm が指定された場合は、inputPassword 引数として UsernamePasswordLoginModule.validatePassword に渡す前に CallbackHandler から取得されたクリアテキストパスワードがハッシュ化されます。users.properties ファイルに格納されたパスワードも、同様にハッシュ化する必要があります。
hashEncoding
base64 または hex
base64
hashAlgorithm も設定されている場合、ハッシュ化されたパスワードの文字列形式。
hashCharset
文字列
コンテナのランタイム環境に設定されるデフォルトのエンコーディング。
クリアテキストのパスワードをバイトアレイに変換するために使用されるエンコーディング。
unauthenticatedIdentity
プリンシパル名
なし
認証情報を含まない要求に割り当てるプリンシパル名を定義します。これにより、保護されていないサーブレットは特定のロールを必要としない EJB でメソッドを呼び出すことができるようになります。このようなプリンシパルは関連付けられたロールを持たず、unchecked permission 制約に関連付けられたセキュアでない EJB または EJB メソッドにのみアクセスできます。
カスタム認証モジュール

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

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

以下のモジュールは承認サービスを提供します。
コード クラス
DenyAll org.jboss.security.authorization.modules.AllDenyAuthorizationModule
PermitAll org.jboss.security.authorization.modules.AllPermitAuthorizationModule
Delegating org.jboss.security.authorization.modules.DelegatingAuthorizationModule
Web org.jboss.security.authorization.modules.WebAuthorizationModule
JACC org.jboss.security.authorization.modules.JACCAuthorizationModule

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

以下のセキュリティーマッピングロールが JBoss Enterprise Application Platform で提供されます。
コード クラス
PropertiesRoles org.jboss.security.mapping.providers.role.PropertiesRolesMappingProvider
SimpleRoles org.jboss.security.mapping.providers.role.SimpleRolesMappingProvider
DeploymentRoles org.jboss.security.mapping.providers.DeploymentRolesMappingProvider
DatabaseRoles org.jboss.security.mapping.providers.role.DatabaseRolesMappingProvider
LdapRoles org.jboss.security.mapping.providers.role.LdapRolesMappingProvider

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

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

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

はじめに

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

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

使用可能な設定の多くは、アプリケーションの web.ml に設定される要件をローカルリソースへマッピングします。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 に対する要求を満たします。

表A.42 一般的なトップレベル属性

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

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

表A.43 アノテーション設定要素

属性 説明
class-name
アノテーションのクラスの名前。
servlet-security
サーブレットのセキュリティーを表す @ServletSecurity などの要素。
run-as
run-as の情報を表す @RunAs などの要素。
multi-part
マルチパートの情報を表す @MultiPart などの要素。
<listener>

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

表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> と同じ設定要素が含まれます。

A.6. EJB セキュリティーパラメーターについての参考資料

表A.45 EJB セキュリティーパラメーター要素

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

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

この例は、表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>

付録B Revision History

改訂履歴
改訂 1.1-3.405Sun Dec 15 2013Rüdiger Landmann
Rebuild with Publican 4.0.0
改訂 1.1-3 Thu Jul 11 2013 Russell Dickenson
JBoss Enterprise Application Platform 6.1.0 GA Release.

法律上の通知

Copyright © 2013 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.