セキュリティーガイド

JBoss Enterprise Application Platform 6.2

Red Hat JBoss Enterprise Application Platform 6 向け

エディッション 1

Sande Gilda

Darrin Mison

David Ryan

Misty Stanley-Jones

Tom Wells

概要

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

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

第1章 はじめに

1.1. Red Hat JBoss Enterprise Application Platform 6 (JBoss EAP 6) の概要

Red Hat JBoss Enterprise Application Platform 6 (JBoss EAP 6) は、オープンな標準に基づき構築され、Java Enterprise Edition 6 の仕様に準拠する、高速でセキュアな高性能ミドルウェアプラットフォームです。高可用性クラスタリング、強力なメッセージング、分散キャッシングなどの技術を JBoss Application Server 7 と統合し、安定したスケーラブルな高速プラットフォームを作り上げます。
新しいモジュラー構造により、必要な時だけサービスを有効にできるため、起動速度が大幅に向上します。管理コンソールと管理コマンドラインインターフェースを使用すると、XML 設定ファイルを手作業で編集する必要がなくなるため、スクリプトを作成して作業を自動化することが可能です。さらに、API と開発フレームワークも含まれており、これらを使用して堅牢で拡張性のある、セキュアな Java EE アプリケーションを迅速に開発することができます。
バグを報告する

1.2. JBoss Enterprise Application Platform 6 のセキュア化

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

第2章 セキュリティーの概要

2.1. 宣言的セキュリティー

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

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

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

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

Enterprise Java Bean (EJB) およびサーブレットは、1 つまたは複数の <security-role-ref> 要素を宣言できます。
セキュリティーロール参照モデル図

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

この要素は、コンポーネントが <role-name> 要素の role-nameType 属性値を isCallerInRole(String) メソッドへの引数として使用することを宣言します。isCallerInRole メソッドを使用すると、コンポーネントは <security-role-ref> または <role-name> 要素で宣言されたロールに呼び出し元があるかどうかを検証できます。<role-name> 要素の値は、<role-link> 要素を介して <security-role> へリンクする必要があります。通常、isCallerInRole は、ロールベースの <method-permissions> 要素を使用して定義できないセキュリティーチェックを実行するために使用されます。

例2.1 ejb-jar.xml 記述子の一部

  
  <!-- A sample ejb-jar.xml fragment -->
    <ejb-jar>
      <enterprise-beans>
        <session>
          <ejb-name>ASessionBean</ejb-name>
          ...
          <security-role-ref>
            <role-name>TheRoleICheck<role-name>
              <role-link>TheApplicationRole</role-link>
          </security-role-ref>
        </session>
      </enterprise-beans>
    ...
    </ejb-jar>

注記

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

例2.2 web.xml 記述子の一部


<web-app>
  <servlet>
    <servlet-name>AServlet</servlet-name>
    ...
    <security-role-ref>
      <role-name>TheServletRole</role-name>
      <role-link>TheApplicationRole</role-link>
    </security-role-ref>
  </servlet>
    ...
</web-app>
バグを報告する

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

Enterprise Java Bean (EJB) は、<security-identity> 要素を使用してコンポーネント上でメソッドを呼び出すときに使用する必要がある、別の EJB の ID を指定できます。
J2EE セキュリティーアイデンティティーデータモデル図

図2.2 J2EE セキュリティーアイデンティティーデータモデル

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

<ejb-jar>
    <enterprise-beans>
        <session>
            <ejb-name>ASessionBean</ejb-name>
            <!-- ... -->
            <security-identity>
                <use-caller-identity/>
            </security-identity>
        </session>
        <session>
            <ejb-name>RunAsBean</ejb-name>
            <!-- ... -->
            <security-identity>
                <run-as>
                    <description>A private internal role</description>
                    <role-name>InternalRole</role-name>
                </run-as>
            </security-identity>
        </session>
    </enterprise-beans>
    <!-- ... -->
</ejb-jar>
<run-as> を使用して特定のロールを発信呼び出しへ割り当てると、anonymous という名前のプリンシパルがすべての発信呼び出しへ割り当てられます。別のプリンシパルを呼び出しに関連付けるには、<run-as-principal> を jboss.xml ファイルの Bean に関連付けます。以下の断片は、internal という名前のプリンシパルを前例の RunAsBean に関連付けます。 

<session>
    <ejb-name>RunAsBean</ejb-name>
    <security-identity>
        <run-as-principal>internal</run-as-principal>
    </security-identity>
</session>
<run-as> 要素は、web.xml ファイルのサーブレット定義にもあります。以下の例は、InternalRole ロールをサーブレットに割り当てる方法を示しています。 

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

  <servlet>
    <servlet-name>AServlet</servlet-name>
    <run-as-principal>internal</run-as-principal>
  </servlet>
バグを報告する

2.1.4. セキュリティーロール

security-role-ref または security-identity 要素によって参照されるセキュリティーロール名は、アプリケーションの宣言済みロールの 1 つへマップする必要があります。アプリケーションアセンブラーは、security-role 要素を宣言して論理セキュリティーロールを定義します。role-name の値は、論理アプリケーションロール名になります (Administrator、Architect、SalesManager など)。
J2EE 仕様には、デプロイメント記述子のセキュリティーロールはアプリケーションの論理セキュリティービューを定義するために使用されることを考慮することが重要であると記載されています。J2EE デプロイメント記述子に定義されるロールを、ユーザーグループ、ユーザー、プリンシパル、および目的企業の操作環境に存在するその他の概念と混同してはなりません。デプロイメント記述子ロールは、アプリケーションドメイン固有の名前を持つアプリケーションコンストラクトです。たとえば、銀行取引のアプリケーションでは BankManager、Teller、Customer などをロール名として使用することがあります。
JBoss EAP では、security-role 要素は security-role-ref/role-name の値をコンポーネントロールが参照する論理ロールへマップためだけに使用されます。ユーザーの割り当てられたロールは、アプリケーションのセキュリティーマネージャーの動的関数です。JBoss では、メソッドパーミッションの宣言に security-role の定義は必要ありません。しかし、アプリケーションサーバーにまたがる移植性を維持し、デプロイメント記述子を保持するため、security-role 要素を指定することが推奨されます。

例2.3 security-role 要素の使用を示す ejb-jar.xml 記述子の断片

<!-- A sample ejb-jar.xml fragment --><ejb-jar><assembly-descriptor><security-role><description>The single application role</description><role-name>TheApplicationRole</role-name></security-role></assembly-descriptor></ejb-jar>

例2.4 security-role 要素の使用を示す web.xml 記述子の断片の例

<!-- A sample web.xml fragment --><web-app><security-role><description>The single application role</description><role-name>TheApplicationRole</role-name></security-role></web-app>
バグを報告する

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

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

図2.3 J2EE メソッドパーミッション要素

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

図2.4 J2EE メソッド要素

メソッド要素宣言のサポートされるスタイルは 3 つあります。
1 つ目のスタイルは、名前付きエンタープライズ Bean のホームおよびコンポーネントインターフェースメソッドをすべて参照するために使用されます。 
<method><ejb-name>EJBNAME</ejb-name><method-name>*</method-name></method>
2 つ目のスタイルは、名前付きエンタープライズ Bean のホームまたはコンポーネントインターフェースの指定されたメソッドを参照するために使用されます。 
  <method><ejb-name>EJBNAME</ejb-name><method-name>METHOD</method-name></method>
同じオーバーロードされた名前を持つ複数のメソッドがある場合、このスタイルはすべてのオーバーロードされたメソッドを参照します。
3 つ目のスタイルは、オーバーロードされた名前を持つメソッドのセット内で指定されたメソッドを参照するために使用されます。 
<method><ejb-name>EJBNAME</ejb-name><method-name>METHOD</method-name><method-params><method-param>PARAMETER_1</method-param><!-- ... --><method-param>PARAMETER_N</method-param></method-params></method>
メソッドは指定されたエンタープライズ Bean のホームまたはリモートインターフェースに定義する必要があります。method-param 要素の値は、対応するメソッドパラメータータイプの完全修飾名です。同じオーバーロードされたシグネチャーを持つメソッドが複数ある場合、パーミッションは一致するオーバーロードされたメソッドすべてに適用されます。
任意の method-intf 要素は、エンタープライズ Bean のホームおよびリモートインターフェースの両方に定義された同じ名前やシグネチャーを持つメソッドを区別するために使用されます。
method-permission 要素の完全な使用例は、例2.5「method-permission 要素の使用を説明する ejb-jar.xml 記述子の断片」 を参照してください。

例2.5 method-permission 要素の使用を説明する ejb-jar.xml 記述子の断片

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

2.1.6. エンタープライズ Bean セキュリティーアノテーション

エンタープライズ Bean はアノテーションを使用し、アプリケーションのセキュリティーやその他の情報をデプロイヤーへ渡します。アノテーションまたはデプロイメント記述子に指定された場合、デプロイヤーはアプリケーションに対して適切なエンタープライズ Bean セキュリティーポリシーを設定できます。
アノテーションの値は、デプロイメント記述子に明示的に指定されたメソッドの値によって上書きされます。メソッドの値がデプロイメント記述子に指定されていない場合、アノテーションを使用して設定された値が使用されます。粒度の上書きはメソッドごとに行われます。
セキュリティーに対応し、エンタープライズ Bean で使用できるアノテーションには以下が含まれます。
@DeclareRoles
コードに宣言された各セキュリティーロールを宣言します。ロールの設定に関する詳細情報は、『Java EE 5 Tutorial』 の Declaring Security Roles Using Annotations を参照してください。
@RolesAllowed、@PermitAll、および @DenyAll
アノテーションのメソッドパーミッションを指定します。アノテーションメソッドパーミッションの設定に関する詳細は、『Java EE 5 Tutorial』 の Specifying Method Permissions Using Annotations を参照してください。
@RunAs
コンポーネントの伝播されたセキュリティーアイデンティティーを設定します。伝播されたセキュリティーアイデンティティーをアノテーションを使用して設定する方法については、『Java EE 5 Tutorial』 の Configuring a Component’s Propagated Security Identity を参照してください。
バグを報告する

2.1.7. Web コンテンツのセキュリティー制約

Web アプリケーションでは、保護されたコンテンツを識別する URL パターンよりコンテンツへのアクセスが許可されるロールによってセキュリティーが定義されます。この情報セットは、web.xml security-constraint 要素を使用して宣言されます。
Web コンテンツのセキュリティー制約の図

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

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

図2.6 Web ログインの設定

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

例2.6 web.xml 記述子の断片

<web-app>
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>Secure Content</web-resource-name>
            <url-pattern>/restricted/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>AuthorizedUser</role-name>
        </auth-constraint>
        <user-data-constraint>
            <transport-guarantee>NONE</transport-guarantee>
        </user-data-constraint>
    </security-constraint>
    <!-- ... -->
    <login-config>
        <auth-method>BASIC</auth-method>
        <realm-name>The Restricted Zone</realm-name>
    </login-config>
    <!-- ... -->
    <security-role>
        <description>The role required to access restricted content </description>
        <role-name>AuthorizedUser</role-name>
    </security-role>
</web-app>
バグを報告する

2.1.8. フォームベース認証の有効化

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

注記

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

注記

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

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

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

第3章 JAAS とは

3.1. JAAS

JBossSX フレームワークは、 JAAS API を基盤としています。JBossSX の実装詳細を理解するには、JAAS API の基本要素を理解する必要があります。以下の項では、本ガイドの後半で説明する JBossSX アーキテクチャーを理解するために必要な JAAS の基礎知識について取り上げます。
JAAS 1.0 API は、ユーザー認証および承認のために作成された Java パッケージのセットで構成されます。API は、標準のプラグ可能な認証モジュール (PAM) フレームワークの Java バージョンを実装し、ユーザーベースの承認をサポートするよう Java 2 Platform のアクセス制御アーキテクチャーを拡張します。
当初、JAAS は JDK 1.3 の拡張パッケージとしてリリースされました。現在は JDK 1.5 にバンドルされています。JBossSX フレームワークは JAAS の認証機能のみを使用し、宣言型のロールベース J2EE セキュリティーモデルを実装するため、ここではその機能を中心に取り上げます。
JAAS 認証は、プラグ可能な状態で実行されます。これにより、Java アプリケーションは基盤の認証技術に依存せず、JBossSX セキュリティーマネージャーは異なるセキュリティーインフラストラクチャーで動作できます。JBossSX セキュリティーマネージャーの実装を変更せずに、セキュリティーインフラストラクチャーとの統合を実現できます。JAAS が使用する認証スタックの設定のみを変更する必要があります。
バグを報告する

3.2. JAAS コアクラス

JAAS コアクラスは共通、認証、および承認の 3 つのコアクラスに分類できます。本章で取り上げる JBossSX の機能を実装するために使用されるクラスは共通および認証クラスであるため、以下の一覧にはこの 2 つのクラスのみが記載されています。
共通クラスは次のとおりです。
  • Subject (javax.security.auth.Subject)
認証クラスは次のとおりです。
  • Configuration (javax.security.auth.login.Configuration)
  • LoginContext (javax.security.auth.login.LoginContext)
関連するインターフェースは次のとおりです。
  • Principal (java.security.Principal)
  • Callback (javax.security.auth.callback.Callback)
  • CallbackHandler (javax.security.auth.callback.CallbackHandler)
  • LoginModule (javax.security.auth.spi.LoginModule)
バグを報告する

3.3. サブジェクトおよびプリンシパルクラス

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

3.4. サブジェクトの認証

サブジェクトの認証には JAAS ログインが必要です。ログイン手順は次のようになります。
  1. アプリケーションは LoginContext をインスタンス化し、ログイン設定の名前と CallbackHandler を渡して、設定 LoginModule が必要とする Callback オブジェクトを追加します。
  2. LoginContext は、名前付きログイン設定に含まれるすべての LoginModules をロードするため Configuration を確認します。このような名前付き設定が存在しない場合は、other 設定がデフォルトで使用されます。
  3. アプリケーションによって、LoginContext.login メソッドが呼び出されます。
  4. ログインメソッドはロードされたすべての LoginModule を呼び出します。各 LoginModule はサブジェクトを認証するため、関連する LoginModule でハンドルメソッドを呼び出し、認証プロセスに必要な情報を取得します。必要な情報は、Callback オブジェクトのアレイの形式でハンドルメソッドに渡されます。認証に成功すると、LoginModule は関連のプリンシパルとクレデンシャルをサブジェクトに関連付けします。
  5. LoginContext は認証ステータスをアプリケーションに返します。ログインメソッドから返されると認証が成功したことになります。ログインメソッドによって LoginException がスローされると認証に失敗したことになります。
  6. 認証に成功すると、アプリケーションは LoginContext.getSubject メソッドを使用して認証されたサブジェクトを取得します。
  7. サブジェクトの認証が完了した後に LoginContext.logout メソッドを呼び出すと、login メソッドによりサブジェクトに関連付けられたすべてのプリンシパルおよび関連情報を削除できます。
LoginContext クラスは、サブジェクト認証の基本メソッドを提供し、基礎となる認証技術に依存しないアプリケーションを開発する方法を提供します。LoginContext は、特定のアプリケーション向けに設定された認証サービスを決定するため Configuration を確認します。LoginModule クラスは認証サービスを表します。そのため、アプリケーション自体を変更しなくても、異なるログインモジュールをアプリケーションにプラグ可能です。次のコードは、アプリケーションがサブジェクトを認証するために必要となる手順を示しています。 
CallbackHandler handler = new MyHandler();
LoginContext lc = new LoginContext("some-config", handler);

try {
    lc.login();
    Subject subject = lc.getSubject();
} catch(LoginException e) {
    System.out.println("authentication failed");
    e.printStackTrace();
}
                        
// Perform work as authenticated Subject
// ...

// Scope of work complete, logout to remove authentication info
try {
    lc.logout();
} catch(LoginException e) {
    System.out.println("logout failed");
    e.printStackTrace();
}
                        
// A sample MyHandler class
class MyHandler 
    implements CallbackHandler
{
    public void handle(Callback[] callbacks) throws
        IOException, UnsupportedCallbackException
    {
        for (int i = 0; i < callbacks.length; i++) {
            if (callbacks[i] instanceof NameCallback) {
                NameCallback nc = (NameCallback)callbacks[i];
                nc.setName(username);
            } else if (callbacks[i] instanceof PasswordCallback) {
                PasswordCallback pc = (PasswordCallback)callbacks[i];
                pc.setPassword(password);
            } else {
                throw new UnsupportedCallbackException(callbacks[i],
                                                       "Unrecognized Callback");
            }
        }
    }
}
開発者は、LoginModule インターフェースの実装を作成することで、認証技術を統合します。これにより、管理者は異なる認証技術を 1 つのアプリケーションにプラグできます。複数の LoginModule をチェーン化し、複数の認証技術を認証プロセスに加えることが可能です。たとえば、1 つの LoginModule がユーザー名およびパスワードベースの認証を行い、別の LoginModule をスマートカードリーダや生体認証などのハードウェアデバイスへ接続するインターフェースとすることが可能です。
LoginModule のライフサイクルは、クライアントがログインメソッドを作成し公開するLoginContext オブジェクトによって決定されます。このプロセスには 2 つのフェーズがあり、プロセスの手順は次のようになります。
  • LoginContext は引数のないパブリックコンストラクターを使用して、設定された LoginModule を作成します。
  • 各 LoginModule は、初期化メソッドへの呼び出しによって初期化されます。Subject 引数は null 以外になることが保証されます。初期化メソッドのシグネチャーは public void initialize(Subject subject, CallbackHandler callbackHandler, Map sharedState, Map options) です。
  • login メソッドは、認証プロセスを開始するために呼び出されます。たとえば、あるメソッド実装はユーザーにユーザー名とパスワードの入力を求め、NIS や LDAP などのネーミングサービスに保存されたデータに対してこの情報を検証することがあります。別の実装は、スマートカードや生体認証デバイスにインターフェースとして接続したり、基礎となるオペレーティングシステムからユーザー情報を抽出したりすることがあります。各 LoginModule によるユーザーアイデンティティーの検証は、JAAS 認証のフェーズ 1 とみなされます。login メソッドのシグネチャーは boolean login() throws LoginException です。LoginException は失敗を意味します。true の戻り値はメソッドが成功したことを示し、false の戻り値はログインモジュールが無視されることを示します。
  • LoginContext の全体的な認証が成功すると、各 LoginModule で commit が呼び出されます。フェーズ 1 が LoginModule に対して成功すると、コミットメソッドはフェーズ 2 を続行し、関連するプリンシパル、パブリッククレデンシャル、プライベートクレデンシャルをサブジェクトに関連付けます。フェーズ 1 が LoginModule に対して失敗すると、commit はユーザー名やパスワードなどの以前保存した認証状態をすべて削除します。commit メソッドのシグネチャーは boolean commit() throws LoginException です。LoginException がスローされると、コミットフェーズの完了に失敗したことを示します。true が返されるとメソッドが成功したことを示し、false が返されるとログインモジュールが無視されることを示します。
  • LoginContext の全体的な認証が失敗すると、各 LoginModule で abort メソッドが呼び出されます。abort メソッドはログインまたは初期化メソッドによって作成されたすべての認証状態を削除または破棄します。abort メソッドのシグネチャーは boolean abort() throws LoginException です。LoginException がスローされると abort フェーズの完了に失敗したことを示します。true が返されるとメソッドが成功したことを示し、false が返されるとログインモジュールが無視されることを示します
  • ログイン成功後に認証状態を削除するため、アプリケーションは LoginContext で logout を呼び出します。これにより、各 LoginModule で logout メソッドが呼び出されます。logout メソッドは、commit 操作中に当初サブジェクトに関連付けられていたプリンシパルとクレデンシャルを削除します。クレデンシャルは削除時に破棄されるはずです。logout メソッドのシグネチャーは boolean logout() throws LoginException です。LoginException がスローされるとログアウトプロセスの完了に失敗したことを示します。true が返されるとメソッドが成功したことを示し、false が返されるとログインモジュールが無視されることを示します。
LoginModule がユーザーと通信して認証情報を取得する必要がある場合、CallbackHandler オブジェクトを使用します。アプリケーションは、 CallbackHandler インターフェースを実装して LoginContext に渡し、基礎となるログインモジュールに直接認証情報を送信します。
ログインモジュールは、CallbackHandler を使用して、パスワードやスマートカード PIN などのユーザー入力による情報を取得したり、ステータスなどの情報をユーザーに提供したりします。アプリケーションによる CallbackHandler の指定を可能にすることで、基礎となる LoginModule がアプリケーションとユーザーが対話するさまざまな方法に依存しないようにします。たとえば、GUI アプリケーションの CallbackHandler の実装は、ウィンドウを表示してユーザーの入力を求めることがあります。一方でアプリケーションサーバーなどの GUI でない環境の CallbackHandler 実装は、アプリケーションサーバー API を使用してクレデンシャル情報を取得することがあります。 CallbackHandler インターフェースには実装するメソッドが 1 つあります。 
void handle(Callback[] callbacks)
    throws java.io.IOException, 
           UnsupportedCallbackException;
最後に説明する認証クラスは Callback インターフェースです。これは複数のデフォルト実装が提供されているタグ付けインターフェースで、前述の例で使用した NameCallback と PasswordCallback が含まれます。LoginModule は Callback を使用し、認証メカニズムで必要となる情報を要求します。LoginModule は認証のログインフェーズの間に Callback のアレイを直接 CallbackHandler.handle メソッドに渡します。callbackhandler がハンドルメソッドに渡された Callback オブジェクトの使用方法が分からない場合は、UnsupportedCallbackException をスローしてログイン呼び出しを中止します。
バグを報告する

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

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

4.1. セキュリティーサブシステム

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

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

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

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

セキュリティードメイン

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

バグを報告する

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

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

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

<subsystem xmlns="urn:jboss:domain:security:1.2">
	<security-management>
		...
	</security-management>
	<security-domains>
        <security-domain name="other" cache-type="default">
            <authentication>
                <login-module code="Remoting" flag="optional">
                    <module-option name="password-stacking" value="useFirstPass"/>
                </login-module>
                <login-module code="RealmUsersRoles" flag="required">
                    <module-option name="usersProperties" value="${jboss.domain.config.dir}/application-users.properties"/>
                    <module-option name="rolesProperties" value="${jboss.domain.config.dir}/application-roles.properties"/>
                    <module-option name="realm" value="ApplicationRealm"/>
                    <module-option name="password-stacking" value="useFirstPass"/>
                </login-module>
            </authentication>
        </security-domain>
        <security-domain name="jboss-web-policy" cache-type="default">
            <authorization>
                <policy-module code="Delegating" flag="required"/>
            </authorization>
        </security-domain>
        <security-domain name="jboss-ejb-policy" cache-type="default">
            <authorization>
                <policy-module code="Delegating" flag="required"/>
            </authorization>
        </security-domain>
    </security-domains>
    <vault>
    	...
    </vault>
</subsystem>
<security-management>、 <subject-factory>、および <security-properties> 要素はデフォルト設定では存在しません。<subject-factory> および <security-properties> 要素は JBoss EAP 6.1 およびそれ以降のバージョンで廃止になりました。
バグを報告する

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

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

セキュリティーサブシステムの設定には、管理 CLI または Web ベースの管理コンソールを使用することができます。
セキュリティーサブシステム内の各トップレベル要素には、セキュリティー設定の異なる情報が含まれています。セキュリティーサブシステムの設定例は 「セキュリティーサブシステムの構造」 を参照してください。
<security-management>
このセクションはセキュリティーサブシステムのハイレベルの挙動を上書きします。各設定は任意です。ディープコピーサブジェクトモード以外で、これらの設定を変更することはほとんどありません。
オプション 説明
deep-copy-subject-mode
スレッドの安全性を高めるため、セキュリティートークンへコピーまたはリンクするかどうかを指定します。
authentication-manager-class-name
使用する代替の AuthenticationManager 実装クラス名を指定します。
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 クラスに設定されるプロパティーの名前と値が含まれます。
バグを報告する

4.3.2. セキュリティー管理

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

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

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

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

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

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

    通常、管理コンソールは http://127.0.0.1:9990/ のような URL で使用できます。環境に合わせて適切な URL を使用してください。

  2. 管理対象ドメイン: 適切なプロファイルを選択します。

    管理対象ドメインではプロファイルごとにセキュリティーサブシステムが設定されているため、各プロファイルに対して個別にディープコピーセキュリティーモードを有効または無効にできます。
    プロファイルを選択するには、コンソール表示の右上にある Profiles ラベルをクリックし、左上にある Profiles 選択ボックスより変更したいプロファイルを選択します。

  3. Security Subsystem 設定メニューを開きます。

    管理コンソールの右にある Security メニュー項目を展開し、Security Subsystem リンクをクリックします。

  4. deep-copy-subject-mode の値を変更します。

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

管理 CLI を使用してこのオプションを有効にしたい場合、以下のコマンドの 1 つを使用します。

例4.2 管理対象ドメイン

/profile=full/subsystem=security:write-attribute(name=deep-copy-subject-mode,value=TRUE)

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

/subsystem=security:write-attribute(name=deep-copy-subject-mode,value=TRUE)
バグを報告する

4.3.3. セキュリティードメイン

4.3.3.1. セキュリティードメイン

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

4.3.3.2. Picketbox

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

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

6.1. Java Security Manager

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

6.2. Java Security Manager のポリシー

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

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

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

要件

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

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

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

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

    • 管理対象ドメイン

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

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

6.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 EAP 6 で提供される追加のパーミッションについてのみ説明します。

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

  1. policytool を起動します。

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

    • Red Hat Enterprise Linux

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

    • Microsoft Windows Server

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

  2. ポリシーを作成します。

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

  3. 既存のポリシーを編集します。

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

  4. 既存のポリシーを削除します。

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

JBoss EAP 6 固有のパーミッション

org.jboss.security.SecurityAssociation.getPrincipalInfo
org.jboss.security.SecurityAssociation. getPrincipal() メソッドと getCredential() メソッドにアクセスを提供します。このランタイムパーミッションを使用すると、現在のスレッド呼び出し元とクレデンシャルが見られるというリスクが発生します。
org.jboss.security.SecurityAssociation.getSubject
org.jboss.security.SecurityAssociation. getSubject() メソッドにアクセスを提供します。
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.SecurityAssociation. accessContextInfo および 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)
バグを報告する

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

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

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

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

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

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

バグを報告する

第7章 セキュリティーレルム

7.1. セキュリティーレルム

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

7.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)
結果

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

バグを報告する

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

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

    ターミナルを開き、EAP_HOME/bin/ ディレクトリーへ移動します。Red Hat Enterprise Linux や他の UNIX 系のオペレーティングシステムを稼働している場合は、add-user.sh を実行します。Microsoft Windows Server を稼働している場合は add-user.bat を実行します。

  2. 管理ユーザーかアプリケーションユーザーのどちらを追加するか選択します。

    この手順では b を入力し、アプリケーションユーザーを追加します。

  3. ユーザーが追加されるレルムを選択します。

    デフォルトでは、ApplicationRealm のみが選択可能です。カスタムレルムが追加されている場合はその名前を入力します。

  4. 入力を促されたらユーザー名、パスワード、ロールを入力します。

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

第8章 暗号化

8.1. 暗号化

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

8.2. SSL 暗号化

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

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

はじめに

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

要件

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

注記

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

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

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

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

    例8.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/) へコピーされることを前提としています。

    例8.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 暗号化接続を使用します。
バグを報告する

8.4. 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 コマンドに特有の説明は範囲外となります。

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

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

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

    注記

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

  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 接続を暗号化するために使用できます。

バグを報告する

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

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

表8.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 EAP 6 を実行しているユーザーのホームディレクトリー内にある .keystore ファイルになります。keystoreType がファイルを使用しない場合は、パラメーターを空の文字列に設定します。 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=certificate-key-file,value=../domain/configuration/server.keystore)
certificate-file
OpenSSL 暗号化を使用する場合は、このパラメーターの値を、サーバー証明書を含むファイルに対するパスに設定します。 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=certificate-file,value=server.crt)
password
トラストストアおよびキーストアのパスワード。以下の例では、PASSWORD を実際のパスワードに置き換えます。 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=password,value=PASSWORD)
protocol
使用する SSL プロトコルのバージョン。サポートされる値には、SSLv2、SSLv3、TLSv1、SSLv2+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
キーストア内のサーバー証明書に使用されるエイリアス。以下の例では、KEY_ALIAS を実際の証明書のエイリアスに置き換えます。 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=key-alias,value=KEY_ALIAS)
truststore-type
トラストストアのタイプ。PKCS12 や Java の標準 JKS など、さまざまなタイプのキーストアが使用可能です。 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=truststore-type,value=jks)
keystore-type
キーストアのタイプ。PKCS12 や Java の標準 JKS など、さまざまなタイプのキーストアが使用可能です。 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=keystore-type,value=jks)
ca-certificate-file
CA 証明書が含まれるファイル。JSSE の場合、これは truststoreFile であり、キーストアと同じパスワードを使用します。クライアント証明書を検証するには、ca-certificate-file ファイルが使用されます。 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=certificate-file,value=ca.crt)
ca-certificate-password
ca-certificate-file の証明書パスワード。以下の例では、MASKED_PASSWORD を実際のマスクされたパスワードに置き換えます。 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=ca-certificate-password,value=MASKED_PASSWORD)
ca-revocation-url
呼び出しリストが含まれるファイルまたは URL。JSSE の場合は、crlFile を参照し、SSL の場合は、SSLCARevocationFile を参照します。 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=ca-revocation-url,value=ca.crl)
session-cache-size
SSLSession キャッシュのサイズ。この属性は、JSSE コネクターへのみ適用されます。デフォルト値は 0 で、無制限のキャッシュサイズが指定されます。 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=session-cache-size,value=100)
session-timeout
キャッシュされた SSLSession が期限切れになるまでの秒数。この属性は JSSE コネクターへのみ適用されます。デフォルト値は 86400 秒 (24 時間) です。 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=session-timeout,value=43200)
バグを報告する

8.6. FIPS 140-2 準拠の暗号化

8.6.1. FIPS 140-2 の準拠

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

8.6.2. FIPS 140-2 準拠のパスワード

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

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

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

要件

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

  1. データベースの作成

    jboss ユーザーが所有するディレクトリーに NSS データベースを作成します。 
    $ mkdir -p  /usr/share/jboss-as/nssdb
$ chown jboss /usr/share/jboss-as/nssdb 
$ modutil -create -dbdir /usr/share/jboss-as/nssdb

  2. NSS 設定ファイルの作成

    次の内容が含まれる nss_pkcsll_fips.cfg という名前の新しいテキストファイルを /usr/share/jboss-as ディレクトリーに作成します。 
    name = nss-fips
nssLibraryDirectory=/usr/lib64
nssSecmodDirectory=/usr/share/jboss-as/nssdb
nssModule = fips
    NSS 設定ファイルには以下が指定されている必要があります。
    • 名前
    • NSS ライブラリーが存在するディレクトリ
    • 手順 1 に従って作成された NSS データベースが存在するディレクトリー
    Red Hat Enterprise Linux 6 の 64 ビットバージョンを実行していない場合は、/usr/lib64 の代わりに /usr/lib を nssLibraryDirectory に設定します。

  3. SunPKCS11 プロバイダーの有効化

    JRE ($JAVA_HOME/jre/lib/security/java.security) の java.security 設定ファイルを編集し、次の行を追加します。 
    security.provider.1=sun.security.pkcs11.SunPKCS11  /usr/share/jboss-as/nss_pkcsll_fips.cfg
    この行に指定されている設定ファイルは手順 2 で作成されたファイルであることに注意してください。
    このプロバイダーを優先するため、このファイルにある他の security.provider.X 行の値 (X) に 1 を足す必要があります。

  4. NSS ライブラリーに対して FIPS モードを有効にする

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

  5. FIPS トークンのパスワードの変更

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

  6. NSS ツールを使用した証明書の作成

    次のコマンドを入力し、NSS ツールを使用して証明書を作成します。 
    certutil -S -k rsa -n jbossweb  -t "u,u,u" -x -s "CN=localhost, OU=MYOU, O=MYORG, L=MYCITY, ST=MYSTATE, C=MY" -d /usr/share/jboss-as/nssdb

  7. PKCS11 キーストアを使用するよう HTTPS コネクターを設定する

    JBoss CLI ツールで次のコマンドを使用し、HTTPS コネクターを追加します。 
    /subsystem=web/connector=https/:add(socket-binding=https,scheme=https,protocol=HTTP/1.1,secure=true)
    次に、以下のコマンドを使用して SSL 設定を追加します。PASSWORD を 手順 5 の FIPS 準拠のパスワードに置き換えます。 
    /subsystem=web/connector=https/ssl=configuration:add(name=https,password=PASSWORD,keystore-type=PCKS11,
cipher-suite="SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_anon_WITH_AES_128_CBC_SHA,
TLS_ECDH_anon_WITH_AES_256_CBC_SHA")

  8. 検証

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

例8.3 FIPS 140-2 に準拠した HTTPS コネクターの XML 設定

<connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true">
  <ssl name="https" password="****" 
      cipher-suite="SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
         TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
         TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,
         TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
         TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
         TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,
         TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
         TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,
         TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
         TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
         TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_anon_WITH_AES_128_CBC_SHA,
         TLS_ECDH_anon_WITH_AES_256_CBC_SHA"
      keystore-type="PKCS11"/>
</connector>
読みやすくするため、cipher-suite 属性には改行が挿入されていることに注意してください。
バグを報告する

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

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

概要

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

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

9.2. JBoss EAP 6 が使用するネットワークインターフェースの指定

概要

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

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

警告

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

  1. JBoss EAP 6 を停止します。

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

  2. バインドアドレスを指定して JBoss EAP 6 を再起動します。

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

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

    EAP_HOME/bin/domain.sh -b 10.1.1.1

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

    EAP_HOME/bin/domain.sh -bmanagement=10.1.1.1

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

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

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

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

9.3. JBoss EAP 6 で動作可能なネットワークファイアウォールの設定

概要

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

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

要件

  • 開く必要があるポートを判断します。
  • ファイアウォールソフトウェアについて理解する必要があります。この手順では、Red Hat Enterprise Linux 6 の system-config-firewall コマンドを使用します。Microsoft Windows Server には、ファイアウォールが組み込まれ、各プラットフォーム用の複数のサードパーティー製ファイアウォールソリューションが利用可能です。
前提

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

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

手順9.1 ネットワークファイアウォールと JBoss EAP 6 が連携するための管理

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

    管理コンソールにログインします。デフォルトでは、http://localhost:9990/console/ で実行されます。

  2. ソケットバインディンググループが使用するソケットバインディングを決定します。

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

    注記

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

  3. 開く必要があるポートを判断します。

    特定ポートの機能および環境の要件によっては、一部のポートをファイアウォール上で開く必要がある場合があります。

  4. JBoss EAP 6 にトラフィックを転送するようファイアウォールを設定します。

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

  5. JBoss EAP 6 ホストでファイアウォールを設定します。

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

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

バグを報告する

9.4. JBoss EAP 6 により使用されるネットワークポート

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

注記

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

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

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

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

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

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

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

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

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

概要

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

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

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

はじめに

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

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

    注記

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

10.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 EAP 6 の管理を許可されているユーザーの認証と認証を行います。

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

注記

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

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

管理インターフェース

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

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

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

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

注記

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

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

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

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

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

/host=master/core-service=management/management-interface=http-interface:add(console-enabled=true,interface=management,port="${jboss.management.http.port:9990}",security-realm=ManagementRealm)
バグを報告する

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

概要

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

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

例10.4 security-realm の local 要素の例

<security-realms>
    <security-realm name="ManagementRealm">
        <authentication>
            <local default-user="$local"/>
            <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
        </authentication>
    </security-realm>
    <security-realm name="ApplicationRealm">
        <authentication>
            <local default-user="$local" allowed-users="*"/>
            <properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
        </authentication>
        <authorization>
            <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
        </authorization>
    </security-realm>
</security-realms>

要件

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

手順10.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
結果

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

バグを報告する

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

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

注記

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

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

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

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

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

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

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

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

例10.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 というセキュリティレルムを作成し、関連するプロパティーファイルのディレクトリーを設定します。

例10.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)
管理インターフェースへのセキュリティーレルムの適用

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

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

/host=master/core-service=management/management-interface=http-interface/:write-attribute(security-realm=TestRealm)
バグを報告する

10.8. HTTPS 向け管理コンソールのスタンドアロンモードでの設定

手順10.2

  1. management-https を追加し、management-http を削除して、管理コンソールがインターフェースに対する HTTPS へバインドするようにします。
    これを行うには、standalone.xml ファイルを編集するか (非推奨)、次の CLI インタフェースコマンドを使用します。 
    /core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)
    /core-service=management/management-interface=http-interface:undefine-attribute(name=socket-binding)

  2. 任意設定:

    カスタム socket-binding グループを使用している場合は、management-https バインディングが定義されているようにしてください (このバインディングはデフォルトで存在し、ポート 9443 へバインドされます)。 
     <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        <socket-binding name="management-native" interface="management" port="${jboss.management.native.port:9999}"/>
        <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
        <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9443}"/>
  3. 「SSL 暗号化キーおよび証明書の生成」の説明に従って、キーペアを生成します。
  4. server-identities 要素を、インストールの standalone.xml 設定ファイルにある security-realm セクションに追加します。
    この要素内に、プロトコル、キーストアパス、キーストアパスワードおよびキーペアのエイリアスを定義します。
    例の値を実際の値に置き換え、以下の CLI コマンドを実行します。この例では、キーストアはサーバー設定ディレクトリー (スタンドアロンサーバーでは EAP_HOME/standalone/configuration/) へコピーされることを想定しています。 
    /core-service=management/security-realm=ManagementRealm/server-identity=ssl:add(keystore-path=server.keystore,keystore-relative-to=jboss.server.config.dir, keystore-password=SECRET, alias=KEY_ALIAS)
  5. スタンドアロンサーバーを再起動します。
バグを報告する

10.9. HTTPS 向け管理コンソールのドメインモードでの設定

手順10.3

  1. 「SSL 暗号化キーおよび証明書の生成」の説明に従って、キーペアを生成します。
  2. server-identities 要素を、インストールの host.xml. にある security-realm ブロックへ追加します。
    この要素内に、プロトコル、キーストアパス、キーストアパスワードおよびキーペアのエイリアスを定義します。
    例の値を実際の値に置き換え、以下の CLI コマンドを実行します。この例では、キーストアはサーバー設定ディレクトリー (管理対象ドメインでは EAP_HOME/domain/configuration/) へコピーされることを想定しています。 
    /host=master/core-service=management/security-realm=ManagementRealm/server-identity=ssl:add(protocol=TLSv1, keystore-path=server.keystore,keystore-relative-to=jboss.domain.config.dir, keystore-password=SECRET, alias=KEY_ALIAS)
  3. secure-port を追加し、ポート設定を削除して、management-interface セクション内のソケット要素を変更します。
    以下のコマンドを使用します。 
    /host=master/core-service=management/management-interface=http-interface:write-attribute(name=secure-port,value=9443) 
    /host=master/core-service=management/management-interface=http-interface:undefine-attribute(name=port)
  4. ドメインを再起動します。
バグを報告する

10.10. 管理インターフェースおよび CLI に対する双方向 SSL の使用

このトピックでは、以下の慣例が使用されます。

HOST1
JBoss サーバーホスト名 （例: jboss.redhat.com)。
HOST2
クライアントに適した名前 (例: myclient)。実際のホスト名でないことがあります。
CA_HOST1
HOST1 証明書に使用する DN (識別名)(例:cn=jboss,dc=redhat,dc=com)。
CA_HOST2
HOST2 証明書に使用する DN (識別名)(例:cn=myclient,dc=redhat,dc=com)。

手順10.4

  1. ストアを生成します。 
    keytool -genkeypair -alias HOST1_alias -keyalg RSA -keysize 1024 -validity 365 -keystore host1.keystore.jks -dname "CA_HOST1" -keypass secret -storepass secret
    keytool -genkeypair -alias HOST2_alias -keyalg RSA -keysize 1024 -validity 365 -keystore host2.keystore.jks -dname "CA_HOST2" -keypass secret -storepass secret
  2. 証明書をエクスポートします。 
    keytool -exportcert  -keystore HOST1.keystore.jks -alias HOST1_alias -keypass secret -storepass secret -file HOST1.cer

    keytool -exportcert  -keystore HOST2.keystore.jks -alias HOST2_alias -keypass secret -storepass secret -file HOST2.cer
  3. 証明書を反対のトラストストアにインポートします。 
    keytool -importcert -keystore HOST1.truststore.jks -storepass secret -alias HOST2_alias -trustcacerts -file HOST2.cer

    keytool -importcert -keystore HOST2.truststore.jks -storepass secret -alias HOST1_alias -trustcacerts -file HOST1.cer
  4. インストールの設定に CertificateRealm を定義し (host.xml または standalone.xml)、インターフェースがそれを示すようにします。
    これを行うには、設定ファイルを手作業で編集するか (非推奨)、以下のコマンドを使用します。 
    /core-service=management/security-realm=CertificateRealm:add()
    /core-service=management/security-realm=CertificateRealm:add/server-identity=ssl:add(keystore-path=/path/to/HOST1.keystore.jks,keystore-password=secret, alias=HOST1_alias)
    /core-service=management/security-realm=CertificateRealm/authentication=truststore:add(keystore-path=/path/to/HOST1.truststore.jks,keystore-password=secret)
  5. JBOSS_HOME/bin/jboss-cli.xml を編集し、SSL 設定を追加します (変数には適切な値を使用します)。 
    <ssl>
  <alias>$HOST2alias</alias>
  <key-store>/path/to/HOST2.keystore.jks</key-store>
  <key-store-password>secret</key-store-password>
  <trust-store>/path/to/HOST2.truststore.jks</trust-store>
  <trust-store-password>secret</trust-store-password>
  <modify-trust-store>true</modify-trust-store>
</ssl>
バグを報告する

10.11. 機密性の高い文字列のパスワード vault

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

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

警告

JBoss EAP 6 で Vault セキュリティー機能を使用すると、問題が発生することがあります。vault.keystore によって生成される Sun/Oracle キーツールは、IBM JDK では無効なキーストアであることが判明しました。これは、JCEKS キーストア実装は Java のベンダーによって異なることが原因です。
この問題は、Oracle Java によって生成されたキーストアが IBM Java インストールの JBoss EAP インスタンスで使用されると発生します。この場合、サーバーが起動されず、以下の例外がスローされます。 
java.io.IOException: com.sun.crypto.provider.SealedObjectForKeyProtector
現在、IBM Java 実装を使用する環境で Oracle キーツールによって生成されたキーストアを使用しないことが唯一の回避方法になります。
バグを報告する

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

要件

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

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

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

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

  2. keytool で使用するパラメーターを決定します。

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

  3. keystore コマンドが尋ねる質問の回答を決定します。

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

  4. keytool コマンドを実行し、収集した情報を提供します。

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

    $ keytool -genseckey -alias vault -storetype jceks -keyalg AES -keysize 128 -storepass vault22 -keypass vault22 -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 EAP 6 のパスワードなど、暗号化された文字列を格納するために使用される vault という 1 つのキーがこのファイルに保存されます。

バグを報告する

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

要件

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

    EAP_HOME/bin/vault.sh を実行します。0 を入力して新しい対話セッションを開始します。

  2. 暗号化されたファイルが保存されるディレクトリーを入力します。

    このディレクトリはある程度保護されている必要がありますが、JBoss EAP 6 がアクセスできなければなりません。「機密性が高い文字列を格納する 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. 対話コンソールを終了します。

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

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

バグを報告する

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

概要

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

要件

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

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

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

  2. 管理 CLI を使用してパスワード vault を有効にします。

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

    注記

    Microsoft Windows Server を使用する場合は、ファイル名またはディレクトリーパスにある / 文字を、4 つの \ 文字に置き換えます。 これは、2 つの \ 文字がそれぞれエスケープされるからです。ファイル名およびディレクトリーパス以外の / 文字を置き換える必要はありません。

    • 管理対象ドメイン

      /host=YOUR_HOST/core-service=vault:add(vault-options=[("KEYSTORE_URL" => "PATH_TO_KEYSTORE"), ("KEYSTORE_PASSWORD" => "MASKED_PASSWORD"), ("KEYSTORE_ALIAS" => "ALIAS"), ("SALT" => "SALT"),("ITERATION_COUNT" => "ITERATION_COUNT"), ("ENC_FILE_DIR" => "ENC_FILE_DIR")])

    • スタンドアロンサーバー

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

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

バグを報告する

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

概要

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

要件

手順10.7 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
Configuration should be done as follows:
VAULT::ds_ExampleDS::password::1
********************************************

  10. 設定で暗号化された文字列を使用します。

    プレーンテキストの文字列の代わりに、前の設定手順の文字列を使用します。以下は、上記の暗号化されたパスワードを使用するデータソースになります。 
    ...
  <subsystem xmlns="urn:jboss:domain:datasources:1.0">
    <datasources>
      <datasource jndi-name="java:jboss/datasources/ExampleDS" enabled="true" use-java-context="true" pool-name="H2DS">
        <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
        <driver>h2</driver>
        <pool></pool>
        <security>
          <user-name>sa</user-name>
          <password>${VAULT::ds_ExampleDS::password::1}</password>
        </security>
      </datasource>
      <drivers>
         <driver name="h2" module="com.h2database.h2">
            <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
         </driver>
      </drivers>
    </datasources>
  </subsystem>
...
    式が許可されるドメインまたはスタンドアロン設定ファイルであれば、どこでも暗号化された文字列を使用することができます。

    注記

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

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

概要

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

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

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

例10.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
Configuration should be done as follows:
VAULT::DS::thePass::1
********************************************

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

例10.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::1",
        className = "org.h2.jdbcx.JdbcDataSource",
        url = "jdbc:h2:tcp://localhost/mem:test"
)
@WebServlet(name = "MyTestServlet", urlPatterns = { "/my/" }, loadOnStartup = 1)
public class MyTestServlet  extends HttpServlet {
 
    private static final long serialVersionUID = 1L;
 
 
    @Resource(lookup = "java:jboss/datasources/LoginDS")
    private DataSource ds;
 
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        Writer writer = resp.getWriter();
        writer.write((ds != null) + "");
    }
}
これでサーブレットが vault された文字列を解決できるようになります。
バグを報告する

10.12. LDAP

10.12.1. LDAP

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

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

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

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

表10.1 LDAP 送信接続の属性

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

例10.13 LDAP 送信接続の追加

この例では、以下のプロパティーセットを使用して送信接続を追加します。
  • DN の検索: cn=search,dc=acme,dc=com
  • 証明情報の検索: myPass
  • URL: ldap://127.0.0.1:389
最初のコマンドによってセキュリティーレルムが追加されます。 
/host=master/core-service=management/security-realm=ldap_security_realm:add
2 つ目のコマンドによって、LDAP 接続が追加されます。 
/host=master/core-service=management/ldap-connection=ldap_connection/:add(search-credential=myPass,url=ldap://127.0.0.1:389,search-dn="cn=search,dc=acme,dc=com")
LDAP 対応セキュリティーレルムの作成

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

LDAP のセキュリティーレルムが機能するには、以下の属性と要素が必要です。
connection
<outbound-connections> に定義されている接続の名前。LDAP ディレクトリーへの接続に使用します。
base-dn
ユーザー検索を開始するためのコンテキストの識別名
recursive
LDAP ディレクトリーツリー全体にわたって再帰的に検索を行うか、指定のコンテキストのみを検索するかを指定します。デフォルトでは false に設定されています。
user-dn
識別名を保持するユーザーの属性。これは、後で認証のテストに使用されます。デフォルトでは dn に設定されています。
子要素として username-filter または advanced-filter のいずれか
username-filter は attribute という単一の属性を取り、値は userName や sambaAccountName などのユーザー名を持つ LDAP 属性の名前です。
advanced-filter は filter と呼ばれる単一の属性を取ります。この属性には、標準的な 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))

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

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

警告

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

例10.15 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 ダイジェスト認証用のセキュリティーレルムを使用します。

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

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

管理対象ドメイン内のホストを設定して、Microsoft Active Directory に対して認証を行うには、次の手順に従います。この手順では JAAS 認証を使用し、セキュリティードメインを作成して、ロールを Active Directory グループへマップします。Microsoft Active Directory では空のパスワードでバインディングできるため、この作業が必要になります。これにより、アプリケーションプラットフォーム内で空のパスワードが使用されないようにします。

この手順を実行する前に、ホストコントローラーの名前を確認する必要があります。この例では、ホストコントローラーの名前が master であることを仮定します。

  1. ldap_security_realm という名前の新しい <security-realm> を追加し、JAAS を使用するように設定します。

    以下の管理 CLI コマンドは、新しいセキュリティーレルムを追加し、認証メカニズムを設定します。必要な場合はホスト名を変更してください。 
    /host=master/core-service=management/security-realm=ldap_security_realm/:add
    /host=master/core-service=management/security-realm=ldap_security_realm/authentication=jaas/:add(name=managementLDAPDomain)

  2. 新しいセキュリティーレルムを使用するように <http-interface> を設定します。

    以下の管理 CLI コマンドは HTTP インターフェースを設定します。 
    /host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=ldap_security_realm)

  3. JBoss EAP を設定し、カスタム JAAS 設定を起動パラメーターに追加します。

    EAP_HOME/bin/domain.conf ファイルを編集します。HOST_CONTROLLER_JAVA_OPTS 変数を探します。ここに、JBoss EAP が起動する前に必要となる JVM のディレクティブを追加します。以下に、このパラメーターのデフォルトコンテンツの例を示します。 
    HOST_CONTROLLER_JAVA_OPTS="$JAVA_OPTS"
    以下のディレクティブを -Djava.security.auth.login.config=/opt/jboss-eap-6.0/domain/configuration/jaas.conf" に追加します。
    編集後、この行は次のようになります。 
    -Djava.security.auth.login.config=/opt/jboss-eap-6.0/domain/configuration/jaas.conf"

  4. ログインモジュールをモジュールオプションに追加します。

    同じファイル内で、以下が含まれる行を見つけます。 
    JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman"
    その行を次のように変更します。余分な空白を挿入しないようにしてください。 
    JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman,com.sun.security.auth.login"
    domain.conf ファイルを保存し、閉じます。

  5. クラスパスに追加される JAAS 設定を作成します。

    新しいファイルを EAP_HOME/domain/configuration/jaas.conf に作成します。
    このファイルには以下の内容が含まれている必要があります。環境に合わせてパラメーターを編集します。 
    managementLDAPDomain {
    org.jboss.security.auth.spi.LdapExtLoginModule required
        java.naming.factory.initial="com.sun.jndi.ldap.LdapCtxFactory"
        java.naming.provider.url="ldap://your_active_directory_host:389"
        java.naming.security.authentication="simple"
        bindDN="cn=Administrator,cn=users,dc=domain,dc=your_company,dc=com"
        bindCredential="password"
        baseCtxDN="cn=users,dc=domain,dc=redhat,dc=com"
        baseFilter="(&(sAMAccountName={0})(|(memberOf=cn=Domain Guests,cn=Users,dc=domain,dc=acme,dc=com)(memberOf=cn=Domain Admins,cn=Users,dc=domain,dc=acme,dc=com)))"
        allowEmptyPasswords="false"
        rolesCtxDN="cn=users,dc=domain,dc=acme,dc=com"
        roleFilter="(cn=no such group)"
        searchScope="SUBTREE_SCOPE";
};
  6. JBoss EAP を再起動すると、HTTP インターフェースは認証に LDAP サーバーを使用するようになります。
バグを報告する

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

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

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

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

異なる固定パーミッションを持つ 7 つのロールが事前定義されています。事前定義されたロールは Monitor、Operator、Maintainer、Deployer、Auditor、Administrator、および SuperUser です。各管理ユーザーに 1 つ以上のロールが割り当てられ、サーバー管理時にユーザーが許可される項目は、割り当てられたロールによって指定されます。
バグを報告する

11.2. GUI および CLI でのロールベースアクセス制御

ロールベースアクセス制御 (RBAC) が有効になっている場合、ユーザーに割り当てられたロールによっては、ユーザーが操作の一部を実行できなかったり、リソースの一部を読み取りできなかったりすることがあります。また、管理モデルの一部を全く閲覧できないこともあります。
管理コンソール

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

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

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

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

jboss-cli.sh ツールを使用したり、API を直接使用する場合、RBAC が有効になっていると API の挙動が若干異なります。

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

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

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

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

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

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

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

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

11.4. 標準のロール

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

Monitor ロールのユーザーは、最も少ないパーミッションを持ち、現在の設定およびサーバーの状態のみを読み取りできます。これは、サーバーのパフォーマンスを追跡し、報告する必要があるユーザー向けのロールです。

Monitor はサーバー設定を変更したり、機密データおよび操作にアクセスしたりできません。
Operator

Operator ロールは、サーバーのランタイム状態を変更する機能を追加して、Monitor ロールを拡張します。これにより、Operator はサーバーをリロードおよびシャットダウンでき、JMS 宛先を一時停止および再開できます。Operator ロールは、アプリケーションサーバーの物理または仮想ホストを管理するユーザーに向いており、必要時にサーバーが正しくシャットダウンおよび再起動されるようにします。

Operator はサーバー設定を変更したり、機密データおよび操作にアクセスしたりできません。
Maintainer

Maintainer ロールは、機密データおよび操作以外のすべての設定と、ランタイム状態を表示および変更できます。Maintainer ロールは、機密データおよび操作へアクセスできない汎用のロールです。Maintainer ロールは、パスワードやその他の機密情報へのアクセス権限を付与せずに、ユーザーがサーバーをほぼ完全に管理できるようにします。

Maintainer は機密データまたは操作へアクセスできません。
Administrator

Administrator ロールは、監査ロギングシステムを除くサーバー上のすべてのリソースおよび操作へ無制限にアクセスできます。Administrator は、機密データおよび操作へアクセスできるロールです。このロールはアクセス制御システムを設定することも可能です。Administrator ロールは、機密データを処理する場合や、ユーザーとロールを設定する場合のみ必要です。

Administrator は監査ロギングシステムへアクセスできず、Administrator 自身を Auditor または SuperUser ロールへ変更できません。
SuperUser

SuperUser ロールには制限がなく、監査ロギングシステムを含むサーバーのすべてのリソースおよび操作へ完全にアクセスできます。このロールは、以前のバージョンの JBoss EAP 6 (6.0 および 6.1) での管理者ユーザーと同等です。RBAC が無効である場合、すべての管理ユーザーは SuperUser ロールと同等のパーミッションを持ちます。
Deployer

Deployer ロールは Monitor と同じパーミッションを持ちますが、デプロイメントの設定や状態を変更でき、アプリケーションリソースとして有効になっている他のリソースタイプも変更できます。
Auditor

Auditor ロールは Monitor ロールと同じパーミッションを持ちますが、機密データを表示でき (変更はできません)、監査ロギングシステムへ完全にアクセスできます。Auditor ロールは SuperUser ロール以外で唯一監査ログインシステムへアクセスできるロールです。

Auditor は機密データやリソースを変更できません。読み取りアクセスのみ許可されます。
バグを報告する

11.5. ロールパーミッション

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

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

Monitor

Operator

Maintainer

Deployer

Auditor

Administrator

SuperUser

設定と状態の読み取り

○

○

○

○

○

○

○

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

○

○

○

機密データの変更 [2]

○

○

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

○

○

ランタイム状態の変更

○

○

○[1]

○

○

永続化設定の変更

○

○[1]

○

○

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

○

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

11.6. 制約

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

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

アプリケーション制約は、Deployer ロールのユーザーがアクセスできるリソースおよび属性のセットを定義します。デフォルトでは、有効になっているアプリケーション制約は、デプロイメントやデプロイメントオーバーレイが含まれるコアのみです。また、アプリケーション制約はデータソース、ロギング、メール、メッセージング、ネーミング、リソースアダプター、およびセキュリティーに対しても含まれますが、デフォルトでは有効になっていません。これらの制約により、Deployer ユーザーはアプリケーションをデプロイできるだけでなく、これらのアプリケーションが必要とするリソースを設定および維持できます。

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

機密性制約は、「機密」とされるリソースのセットを定義します。通常、機密リソースとは、パスワードなどの秘密のリソースや、ネットワーキング、JVM 設定、システムプロパティーなどのサーバー操作に深刻な影響を与えるリソースのことを言います。アクセス制御システム自体も機密であると考慮されます。

機密リソースへの書き込みを許可されるロールは、Administrator と SuperUser のみです。Auditor ロールは、機密リソースの読み取りのみ可能です。他のロールは機密リソースへアクセスできません。

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

vault 式制約は、vault 式の読み取りまたは書き込みが機密操作としてみなされるかどうかを定義します。デフォルトでは、vault 式の読み書き両方が機密操作とみなされます。

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

制約は管理コンソールでは設定できません。
バグを報告する

11.7. JMX およびロールベースアクセス制御

ロールベースアクセス制御は、次の 3 つの方法で JMX に適用されます。

  1. JBoss EAP 6 の管理 API は JXM 管理 Bean として公開されます。これらの管理 Bean は「コア MBean」と呼ばれ、コア MBean へのアクセスは基盤の管理 API と全く同じように制御およびフィルターされます。

  2. JMX サブシステムは、書き込みパーミッションが「機密」で設定されます。そのため、Administrator および SuperUser ロールのユーザーのみがそのサブシステムに変更を追加できます。Auditor ロールのユーザーはこのサブシステムの設定を読み取りできます。

  3. デフォルトでは、デプロイされたアプリケーションおよびサービスによって登録された管理 Bean (コアでない MBean) へすべての管理ユーザーがアクセスできますが、Maintainer、Operator、Administrator、および SuperUser ロールのユーザーのみが書き込み可能です。
バグを報告する

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

11.8.1. RBAC 設定タスクの概要

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

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

デフォルトでは、ロールベースアクセス制御 (RABC) システムは無効になっています。有効にするには、プロバイダー属性を simple から rbac に変更します。この変更を行うには jboss-cli.sh ツールを使用しますが、サーバーがオフラインの場合はサーバー設定 XML ファイルを編集して変更できます。RBAC が稼働中のサーバー上で無効または有効になっている場合は、サーバー設定をリロードして変更を反映する必要があります。
RBAC を有効にすると、無効にできるのは Administrator または SuperUser ロールのユーザーのみです。デフォルトでは、jboss-cli.sh がサーバーと同じマシン上で実行されていると SuperUser ロールとして実行されます。

手順11.1 RBAC の有効化

  • jboss-cli.sh を用いて RBAC を有効にするには、アクセス承認リソースの write-attribute 操作を使用して、プロバイダー属性を rbac に設定します。 
    /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
    [standalone@localhost:9999 /] /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
[standalone@localhost:9999 /] /:reload
{
    "outcome" => "success",
    "result" => undefined
}
[standalone@localhost:9999 /]

手順11.2 RBAC の無効化

  • jboss-cli.sh を用いて RBAC を無効にするには、アクセス承認リソースの write-attribute 操作を使用して、プロバイダー属性を simple に設定します。 
    /core-service=management/access=authorization:write-attribute(name=provider, value=simple)
    [standalone@localhost:9999 /] /core-service=management/access=authorization:write-attribute(name=provider, value=simple)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
[standalone@localhost:9999 /] /:reload
{
    "outcome" => "success",
    "result" => undefined
}
[standalone@localhost:9999 /]
サーバーがオフラインの場合は、XML 設定を編集して RBAC を有効または無効にできます。これを行うには、管理要素のアクセス制御要素にある provider 属性を編集します。有効にする場合は値を rbac に設定し、無効にする場合は simple に設定します。 
<management>

        <access-control provider="rbac">
            <role-mapping>
                <role name="SuperUser">
                    <include>
                        <user name="$local"/>
                    </include>
                </role>
            </role-mapping>
        </access-control>

    </management>
バグを報告する

11.8.3. パーミッション組み合わせポリシーの変更

パーミッション組み合わせポリシーは、ユーザーに複数のロールが割り当てられている場合にどのようにパーミッションを判断するかを決定します。このポリシーは、permissive または rejecting に設定できます。デフォルトは permissive です。
permissive に設定されると、アクションを許可するロールがユーザーに割り当てられている場合に、そのアクションが許可されます。
rejecting に設定されると、アクションを許可する複数のロールがユーザーに割り当てられている場合に、そのアクションは許可されません。
ポリシーが rejecting に設定されている場合は、各ユーザーに 1 つのロールのみが割り当てられるようにします。ポリシーが rejecting に設定されていると、複数のロールが割り当てられたユーザーは管理コンソールや jboss-cli.sh ツールを使用できません。
パーミッション組み合わせポリシーを設定するには、permission-combination-policy 属性を permissive または rejecting に設定します。これは、jboss-cli.sh ツールを使用して設定できますが、サーバーがオフラインの場合はサーバー設定 XML ファイルを編集して設定できます。

手順11.3 パーミッション組み合わせポリシーの設定

  • アクセス承認リソースの write-attribute 操作を使用して permission-combination-policy 属性を必要なポリシー名に設定します。 
    /core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=POLICYNAME)
    有効なポリシー名は rejecting と permissive です。 
    [standalone@localhost:9999 /] /core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=rejecting)
{"outcome" => "success"}
[standalone@localhost:9999 access=authorization]
サーバーがオフラインの場合は、XML 設定を編集してパーミッション組み合わせポリシーの値を変更できます。これを行うには、アクセス制御要素の permission-combination-policy 属性を編集します。 
<access-control provider="rbac" permission-combination-policy="rejecting">
  <role-mapping>
    <role name="SuperUser">
      <include>
        <user name="$local"/>
      </include>
    </role>
  </role-mapping>
</access-control>
バグを報告する

11.9. ロールの管理

11.9.1. ロールメンバーシップ

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

以下の場合に、ロールがユーザーに割り当てられたとみなされます。

  1. ユーザーが以下のいずれかである場合。

    • ロールに含まれるユーザーとしてリストされている。

    • ロールに含まれるとリストされているグループのメンバーである。

  2. ユーザーが以下のいずれかに該当しない場合。

    • ロールから除外されるユーザーとしてリストされている。

    • ロールから除外されるとリストされているグループのメンバーである。

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

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

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

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

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

以下の手順で、管理コンソールのユーザーロール設定を確認します。

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

  2. Administration タブをクリックします。

  3. 左側の Access Control 項目を開き、Role Assignment を選択します。

  4. USERS タブを選択します。
管理コンソールにおけるユーザーロール管理のスクリーンショット

図11.1 管理コンソールのユーザーロール管理

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

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

    図11.2 Add User ダイアログ

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

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

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

    図11.3 Selection Edit ビュー

    ここで、ユーザーに割り当てられたロールや除外されたロールを追加および削除できます。

    1. 割り当てられたロールを追加するには、左側の使用可能なロールのリストからロールを選択し、割り当てられたロールリストの横にある、右矢印のボタンをクリックします。ロールが、使用可能なロールのリストから割り当てられたロールのリストに移動します。

    2. 割り当てられたロールを削除するには、割り当てられたロールのリストからロールを選択し、割り当てられたロールリストの横にある左矢印のボタンをクリックします。ロールが、割り当てられたロールのリストから使用可能なロールのリストへ移動します。

    3. 除外されたロールを追加するには、左側の使用可能なロールのリストからロールを選択し、除外されたロールリストの横にある、右矢印のボタンをクリックします。ロールが、使用可能なロールのリストから除外されたロールのリストに移動します。

    4. 除外されたロールを削除するには、除外されたロールのリストからロールを選択し、除外されたロールリストの横にある左矢印のボタンをクリックします。ロールが、除外されたロールのリストから使用可能なロールのリストへ移動します。
  5. Save をクリックします。
    正常に保存されると、編集ビューが閉じられます。ユーザーのリストが更新され、変更内容が反映されます。正常に保存されなかった場合は、「Failed to save role assignment」メッセージが表示されます。

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

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

重要

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

11.9.3. jboss-cli.sh を用いたユーザーロール割り当ての設定

include (含まれる) および exclude (除外) されるユーザーロールは、管理コンソールおよび jboss-cli.sh ツールで設定できます。ここでは、jboss-cli.sh ツールを使用した設定のみを説明します。
ユーザーおよびグループをロールへマッピングする設定は、管理 API の role-mapping 要素とする /core-service=management/access=authorization にあります。
SuperUser または Administrator ロールのユーザーのみがこの設定を行えます。

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

  1. :read-children-names 操作を使用して、設定されたロールの完全リストを取得します。 
    /core-service=management/access=authorization:read-children-names(child-type=role-mapping)
    [standalone@localhost:9999 access=authorization] :read-children-names(child-type=role-mapping)
{
    "outcome" => "success",
    "result" => [
        "ADMINISTRATOR",
        "DEPLOYER",
        "MAINTAINER",
        "MONITOR",
        "OPERATOR",
        "SuperUser"
    ]
}
  2. 指定されたロールマッピングの read-resource 操作を使用して、特定ロールの完全詳細を取得します。 
    /core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)
    [standalone@localhost:9999 access=authorization] ./role-mapping=ADMINISTRATOR:read-resource(recursive=true)
{
    "outcome" => "success",
    "result" => {
        "include-all" => false,
        "exclude" => undefined,
        "include" => {
            "user-theboss" => {
                "name" => "theboss",
                "realm" => undefined,
                "type" => "USER"
            },
            "user-harold" => {
                "name" => "harold",
                "realm" => undefined,
                "type" => "USER"
            },
            "group-SysOps" => {
                "name" => "SysOps",
                "realm" => undefined,
                "type" => "GROUP"
            }
        }
    }
}
[standalone@localhost:9999 access=authorization]

手順11.8 新規ロールの追加

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

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

この手順では、ユーザーをロールの include されたリストに追加する方法を説明します。
ロールの設定が行われていない場合は、最初にロールマッピングエントリーの設定を行う必要があります。
  • add 操作を使用して、ユーザーエントリーをロールの include リストに追加します。 
    /core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=USERNAME, type=USER)
    ROLENAME は設定されたロールの名前です。
    ALIAS はこのマッピングの一意名です。Red Hat は、user-USERNAME などのエイリアスに命名規則を使用することを推奨します。
    USERNAME は、include リストに追加されたユーザーの名前です。 
     [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/include=user-max:add(name=max, type=USER)
{"outcome" => "success"}
[standalone@localhost:9999 access=authorization]

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

この手順では、ユーザーをロールの exclude されたリストに追加する方法を説明します。
ロールの設定が行われていない場合は、最初にロールマッピングエントリーの設定を行う必要があります。
  • add 操作を使用して、ユーザーエントリーをロールの exclude リストに追加します。 
    /core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=USERNAME, type=USER)
    ROLENAME は設定されたロールの名前です。
    USERNAME は、exclude リストに追加されたユーザーの名前です。
    ALIAS はこのマッピングの一意名です。Red Hat は、user-USERNAME などのエイリアスに命名規則を使用することを推奨します。 
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/exclude=user-max:add(name=max, type=USER)
{"outcome" => "success"}
[standalone@localhost:9999 access=authorization]

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

この手順では、ロールマッピングからユーザー include エントリーを削除する方法を説明します。
  • remove 操作を使用してエントリーを削除します。 
    /core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
    ROLENAME は設定されたロールの名前です。
    ALIAS はこのマッピングの一意名です。Red Hat は、user-USERNAME などのエイリアスに命名規則を使用することを推奨します。 
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/include=user-max:remove
{"outcome" => "success"}
[standalone@localhost:9999 access=authorization]
    include リストからユーザーを削除しても、ユーザーはシステムから削除されず、ロールがユーザーに割り当てられなくなる保証はありません。ロールはグループメンバーシップを基に割り当てられる可能性があります。

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

この手順では、ロールマッピングからユーザー exclude エントリーを削除する方法を説明します。
  • remove 操作を使用してエントリーを削除します。 
    /core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
    ROLENAME は設定されたロールの名前です。
    ALIAS はこのマッピングの一意名です。Red Hat は、user-USERNAME などのエイリアスに命名規則を使用することを推奨します。 
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/exclude=user-max:remove
{"outcome" => "success"}
[standalone@localhost:9999 access=authorization]
    exclude リストからユーザーを削除しても、ユーザーはシステムから削除されず、ロールがユーザーに割り当てられる保証はありません。ロールはグループメンバーシップを基に除外される可能性があります。
バグを報告する

11.9.4. ロールとユーザーグループ

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

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

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

図11.4 管理コンソールのグループロール管理

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

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

    図11.5 Add Group ダイアログ

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

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

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

    図11.6 Selection ビュー編集モード

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

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

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

11.9.6. jboss-cli.sh でのグループロール割り当ての設定

ロールに include (含まれる) または exclude (除外) されるグループは、管理コンソールおよび jboss-cli.sh ツールで設定できます。ここでは、jboss-cli.sh ツールを使用した設定のみを説明します。
ユーザーおよびグループをロールへマッピングする設定は、管理 API の role-mapping 要素とする /core-service=management/access=authorization にあります。
この設定を行えるのは、SuperUser または Administrator ロールのユーザーのみです。

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

  1. read-children-names 操作を使用して、設定されたロールの完全リストを取得します。 
    /core-service=management/access=authorization:read-children-names(child-type=role-mapping)
    [standalone@localhost:9999 access=authorization] :read-children-names(child-type=role-mapping)
{
    "outcome" => "success",
    "result" => [
        "ADMINISTRATOR",
        "DEPLOYER",
        "MAINTAINER",
        "MONITOR",
        "OPERATOR",
        "SuperUser"
    ]
}
  2. 指定されたロールマッピングの read-resource 操作を使用して、特定ロールの完全詳細を取得します。 
    /core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)
    [standalone@localhost:9999 access=authorization] ./role-mapping=ADMINISTRATOR:read-resource(recursive=true)
{
    "outcome" => "success",
    "result" => {
        "include-all" => false,
        "exclude" => undefined,
        "include" => {
            "user-theboss" => {
                "name" => "theboss",
                "realm" => undefined,
                "type" => "USER"
            },
            "user-harold" => {
                "name" => "harold",
                "realm" => undefined,
                "type" => "USER"
            },
            "group-SysOps" => {
                "name" => "SysOps",
                "realm" => undefined,
                "type" => "GROUP"
            }
        }
    }
}
[standalone@localhost:9999 access=authorization]

手順11.17 新規ロールの追加

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

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

この手順では、グループをロールの include されたリストに追加する方法を説明します。
ロールの設定が行われていない場合は、最初にロールマッピングエントリーの設定を行う必要があります。
  • add 操作を使用して、グループエントリーをロールの include リストに追加します。 
    /core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=GROUPNAME, type=GROUP)
    ROLENAME は設定されたロールの名前です。
    GROUPNAME は、include リストに追加されたグループの名前です。
    ALIAS はこのマッピングの一意名です。Red Hat は、group-GROUPNAME などのエイリアスに命名規則を使用することを推奨します。 
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/include=group-investigators:add(name=investigators, type=GROUP)
{"outcome" => "success"}
[standalone@localhost:9999 access=authorization]

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

この手順では、グループをロールの exclude されたリストに追加する方法を説明します。
ロールの設定が行われていない場合は、最初にロールマッピングエントリーを作成する必要があります。
  • add 操作を使用して、グループエントリーをロールの exclude リストに追加します。 
    /core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=GROUPNAME, type=GROUP)
    ROLENAME は設定されたロールの名前です。
    GROUPNAME は、include リストに追加されたグループの名前です。
    ALIAS はこのマッピングの一意名です。Red Hat は、group-GROUPNAME などのエイリアスに命名規則を使用することを推奨します。 
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/exclude=group-supervisors:add(name=supervisors, type=USER)
{"outcome" => "success"}
[standalone@localhost:9999 access=authorization]

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

この手順では、ロールマッピングからグループ include エントリーを削除する方法を説明します。
  • remove 操作を使用してエントリーを削除します。 
    /core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
    ROLENAME は設定されたロールの名前です。
    ALIAS はこのマッピングの一意名です。Red Hat は、group-GROUPNAME などのエイリアスに命名規則を使用することを推奨します。 
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/include=group-investigators:remove
{"outcome" => "success"}
[standalone@localhost:9999 access=authorization]
    include リストからグループを削除しても、グループはシステムから削除されず、このグループのユーザーにロールが割り当てられなくなる保証はありません。ロールは、グループのユーザーへ個別に割り当てられる可能性があります。

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

この手順では、ロールマッピングからグループ exclude エントリーを削除する方法を説明します。
  • remove 操作を使用してエントリーを削除します。 
    /core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
    ROLENAME は設定されたロールの名前です。
    ALIAS はこのマッピングの一意名です。Red Hat は、group-GROUPNAME などのエイリアスに命名規則を使用することを推奨します。 
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/exclude=group-supervisors:remove
{"outcome" => "success"}
[standalone@localhost:9999 access=authorization]
    exclude リストからグループを削除しても、グループはシステムから削除されず、ロールがグループのメンバーに割り当てられる保証はありません。ロールはグループメンバーシップを基に除外される可能性があります。
バグを報告する

11.9.7. LDAP での承認とグループローディング

LDAP ディレクトリー内では、ユーザーアカウント用のエントリーとグループ用のエントリーがあり、属性を使用してこれらのエントリーが相互参照されることが想定されます。これらのエントリーを相互参照するために使用される属性は、ユーザーアカウントからグループエントリーへの参照や、グループのメンバーであるユーザーを参照するグループ上の属性などです。サーバーによっては、これらの相互参照が両方存在することがあります。

また、グループメンバーシップ情報を検索する場合、簡単なユーザー名を使用してユーザーがサーバーに対して認証することも一般的です。使用中のディレクトリーサーバーに応じて、検索はこの簡単な名前を使用して実行されたり、ディレクトリーのユーザーエントリーの識別名を使用して実行されたりします。

ユーザーが最初にサーバーと認証された後、ユーザーに関連するグループがロードされます。認証手順と承認手順の両方がレルムに含まれる LDAP サーバーへの接続を使用するため、すべての接続が認証に使用した最適化がグループローディング手順に再使用されます。以下の設定手順のとおり、承認セクション内でルールを定義し、ユーザーの簡単なユーザー名を識別名に変換できます。これは、認証中に発生した検索を複製する可能性があるため、ユーザー名からの識別名の検索がすでに実行された場合は、その検索の結果がキャッシュされ、繰り返しを必要とせずに再使用されます。 
<authorization>
    <ldap connection="...">
       <username-to-dn> <!-- OPTIONAL -->
           <!-- Only one of the following. -->
           <username-is-dn />
           <username-filter base-dn="..." recursive="..." user-dn-attribute="..." attribute="..." />
           <advanced-filter base-dn="..." recursive="..." user-dn-attribute="..." filter="..." />
        </username-to-dn>
       <group-search group-name="..." iterative="..." group-dn-attribute="..." group-name-attribute="..." >
           <!-- One of the following -->
           <group-to-principal base-dn="..." recursive="..." search-by="...">
               <membership-filter principal-attribute="..." />
           </group-to-principal>
           <principal-to-group group-attribute="..." />
       </group-search>
    </ldap>
</authorization>

重要

これらの例の一部では、デフォルト値を使用する属性が指定されます。これらは、例を分かりやすくするために示されています。デフォルト値が含まれる属性は、サーバーによって永続化されると設定より削除されます。

username-to-dn

上記のとおり、LDAP ディレクトリー内のエントリーの識別名に対して認証されたユーザーが提供したユーザー名からマップする方法を承認設定内で定義する必要があることがあります。これは username-to-dn 要素によって定義され、以下の両方の条件に見合う場合のみ必要となります。

  • LDAP に対する認証手順ではなかった。

  • グループ検索に識別名が使用される。

以下の例を見ると、認証設定が複製されています。認証に LDAP のみを使用する場合は、識別名が認証中に取得されるため、これは必要ありません。
1:1 username-to-dn

これは最も基本的な設定形式で、リモートユーザーによって入力されたユーザー名はユーザーの識別名であると指定するために使用されます。 
<username-to-dn>
   <username-is-dn />
</username-to-dn>

これは 1:1 マッピングを定義しているため、追加の設定はできません。
username-filter

次のオプションは、前述の認証手順の簡単なオプションと似ていますが、属性が指定され、指定されたユーザー名が検索されます。 
<username-to-dn>
    <username-filter base-dn="dc=people,dc=harold,dc=example,dc=com" recursive="false" attribute="sn" user-dn-attribute="dn" />
</username-to-dn>

設定可能な属性は次のとおりです。

  • base-dn: 検索を開始するコンテキストの識別名。

  • recursive: サブコンテキストが検索対象となるかどうか。デフォルトは false です。

  • attribute: 指定のユーザー名に対して一致されるユーザーエントリーの属性。デフォルトは uid です。

  • user-dn-attribute: ユーザーの識別名を取得するために読み取る属性。デフォルトは dn です。
advanced-filter

詳細フィルターを指定するオプションです。認証セクションでは、カスタムフィルターを使用してユーザーの識別名を見つけられます。 
<username-to-dn>
    <advanced-filter base-dn="dc=people,dc=harold,dc=example,dc=com" recursive="false" filter="sAMAccountName={0}" user-dn-attribute="dn" />
</username-to-dn>

username-filter のものと一致する属性は、その意味とデフォルト値が同じであるためここでは取り上げません。そのため、残りは以下の属性のみになります。

  • filter: ユーザー名が {0} プレースホルダーで置き換えられる、ユーザーエントリーの検索に使用されるカスタムフィルター。

重要

フィルターの定義後も XML が有効である必要があるため、& などの特殊文字が使用される場合は、適切な形式が使用されるようにしてください。たとえば、& 文字には &amp; を使用します。

グループ検索

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

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

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

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

この例では、ユーザー TestUserOne は GroupOne のメンバーで、 GroupOne は GroupFive のメンバーです。グループメンバーシップは、memberOf 属性を使用して表されます。memberOf 属性は、ユーザー (またはグループ) がメンバーであるグループの識別名に設定されます。

ここには示されていませんが、ユーザーは複数の memberOf 属性のセットを持つことも可能です (ユーザーが直接メンバーであるグループごとに 1 つ)。 
dn: uid=TestUserOne,ou=users,dc=principal-to-group,dc=example,dc=org
objectClass: extensibleObject
objectClass: top
objectClass: groupMember
objectClass: inetOrgPerson
objectClass: uidObject
objectClass: person
objectClass: organizationalPerson
cn: Test User One
sn: Test User One
uid: TestUserOne
distinguishedName: uid=TestUserOne,ou=users,dc=principal-to-group,dc=example,dc=org
memberOf: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
memberOf: uid=Slashy/Group,ou=groups,dc=principal-to-group,dc=example,dc=org
userPassword:: e1NTSEF9WFpURzhLVjc4WVZBQUJNbEI3Ym96UVAva0RTNlFNWUpLOTdTMUE9PQ==

dn: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
objectClass: extensibleObject
objectClass: top
objectClass: groupMember
objectClass: group
objectClass: uidObject
uid: GroupOne
distinguishedName: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
memberOf: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org

dn: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org
objectClass: extensibleObject
objectClass: top
objectClass: groupMember
objectClass: group
objectClass: uidObject
uid: GroupFive
distinguishedName: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org

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

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

グループメンバーシップの相互参照に使用される属性は繰り返しが可能で、GroupFive を確認すると、別のユーザー TestUserFive への参照があります (ここでは示されていません)。 
dn: uid=TestUserOne,ou=users,dc=group-to-principal,dc=example,dc=org
objectClass: top
objectClass: inetOrgPerson
objectClass: uidObject
objectClass: person
objectClass: organizationalPerson
cn: Test User One
sn: Test User One
uid: TestUserOne
userPassword:: e1NTSEF9SjR0OTRDR1ltaHc1VVZQOEJvbXhUYjl1dkFVd1lQTmRLSEdzaWc9PQ==

dn: uid=GroupOne,ou=groups,dc=group-to-principal,dc=example,dc=org
objectClass: top
objectClass: groupOfUniqueNames
objectClass: uidObject
cn: Group One
uid: GroupOne
uniqueMember: uid=TestUserOne,ou=users,dc=group-to-principal,dc=example,dc=org

dn: uid=GroupFive,ou=subgroups,ou=groups,dc=group-to-principal,dc=example,dc=org
objectClass: top
objectClass: groupOfUniqueNames
objectClass: uidObject
cn: Group Five
uid: GroupFive
uniqueMember: uid=TestUserFive,ou=users,dc=group-to-principal,dc=example,dc=org
uniqueMember: uid=GroupOne,ou=groups,dc=group-to-principal,dc=example,dc=org

一般的なグループ検索

前述の 2 つの方法の例を確認する前に、両方の方法に共通する属性を定義する必要があります。 
<group-search group-name="..." iterative="..." group-dn-attribute="..." group-name-attribute="..." >
    ...
</group-search>

  • group-name: この属性は、ユーザーがメンバーであるグループのリストとして返されるグループ名に使用される形式を指定するために使用されます。単純なグループ名またはグループの識別名になります。識別名が必要な場合、この属性は DISTINGUISHED_NAME に設定されます。デフォルトは SIMPLE です。

  • iterative: ユーザーがメンバーであるグループを特定した後に、グループがメンバーであるグループを特定するため、グループを基に反復検索するかどうかを指定するために使用される属性です。反復検索が有効であると、他のグループのメンバーでないグループが見つかるか、サイクルが検出されるまで検索を続行します。デフォルトは false です。

巡回のグループメンバーシップは問題ではありません。検索済みグループの再検索を防ぐため、各検索の記録が保存されます。

重要

反復検索が正しく実行されるようにするには、ユーザーがメンバーであるグループを特定するために使用された同じ方法で、グループがメンバーであるグループを特定し、グループエントリーとユーザーエントリーが同じに見える必要があります。これは、グループからグループへのメンバーシップで相互参照に使用される属性の名前が変更されたり、参照の方向が変更されたりする場合は不可能です。

  • group-dn-attribute: 属性が識別名であるグループのエントリーです。デフォルトは dn です。

  • group-name-attribute: 属性が単純名であるグループのエントリーです。デフォルトは uid です。

例11.3 プリンシパルからグループへの設定例

前述の LDIF の例を基にした、ユーザーグループを反復的にロードする設定の例は次のとおりです。相互参照に使用される属性はユーザーの memberOf 属性です。 
<authorization>
    <ldap connection="LocalLdap">
        <username-to-dn>
            <username-filter base-dn="ou=users,dc=principal-to-group,dc=example,dc=org" recursive="false" attribute="uid" user-dn-attribute="dn" />
        </username-to-dn>
        <group-search group-name="SIMPLE" iterative="true" group-dn-attribute="dn" group-name-attribute="uid">
            <principal-to-group group-attribute="memberOf" />
        </group-search>
    </ldap>
</authorization>

この設定で最も重要なことは、principal-to-group 要素が単一の属性で追加されていることです。

  • group-attribute: ユーザーがメンバーであるグループの識別名と一致する、ユーザーエントリー上の属性名。デフォルトは memberOf です。

例11.4 グループからプリンシパルへの設定例

この例は、前述のグループからプリンシパルへの LDIF の例に対する反復検索を示しています。 
<authorization>
      <ldap connection="LocalLdap">
          <username-to-dn>
              <username-filter base-dn="ou=users,dc=group-to-principal,dc=example,dc=org" recursive="false" attribute="uid" user-dn-attribute="dn" />
          </username-to-dn>
          <group-search group-name="SIMPLE" iterative="true" group-dn-attribute="dn" group-name-attribute="uid">
              <group-to-principal base-dn="ou=groups,dc=group-to-principal,dc=example,dc=org" recursive="true" search-by="DISTINGUISHED_NAME">
                  <membership-filter principal-attribute="uniqueMember" />
              </group-to-principal>
          </group-search>
      </ldap>
  </authorization>

ここでは、group-to-principal 要素が追加されています。この要素は、ユーザーエントリーを参照するグループの検索がどのように実行されるかを定義するために使用されます。以下の属性が設定されます。

  • base-dn: 検索を開始するために使用するコンテキストの識別名。

  • recursive: サブコンテキストも検索されるかどうか。デフォルトは false です。

  • search-by: 検索で使用されるロール名の形式です。有効な値は SIMPLE および DISTINGUISHED_NAME です。デフォルトは DISTINGUISHED_NAME です。

group-to-principal 要素内に、相互参照を定義する membership-filter 要素があります。

  • principal-attribute: ユーザーエントリーを参照する、グループエントリー上の属性名。デフォルトは member です。
バグを報告する

11.9.8. スコープ指定ロール

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

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

スコープ指定ロールは 5 つの特性によって定義されます。

  1. 一意名。

  2. ベースになる標準ロール。

  3. サーバーグループまたはホストへ適用されるかどうか。

  4. スコープ指定ロールが制限されるサーバーグループまたはホストのリスト。

  5. すべてのユーザーが自動的に含まれるかどうか。デフォルトは false です。

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

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

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

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

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

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

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

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

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

管理コンソールのスコープ指定ロール設定は、以下の手順で確認できます。

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

  2. Administration タブをクリックします。

  3. 左側の Access Control 項目を開き、Role Assignment を選択します。

  4. ROLES タブを選択し、そのタブ内にある Scoped Roles タブを選択します。
管理コンソールのスコープ指定ロール設定

図11.7 管理コンソールのスコープ指定ロール設定

管理コンソールのスコープ指定ロールセクションは、現在設定されているスコープ指定ロールのリストが含まれるテーブルと、テーブルで現在選択されているロールの詳細を表示する選択パネルの 2 つの主なエリアで構成されます。
スコープ指定ロールの設定タスクを実行する手順は次のとおりです。

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

  1. 管理コンソールへログインします。
  2. Roles タブの Scoped Roles エリアに移動します。
  3. Add ボタンをクリックします。Add Scoped Role ダイアログが表示されます。
    Add Scoped Role ダイアログ

    図11.8 Add Scoped Role ダイアログ

  4. 次の詳細を指定します。

    • Name: 新しいスコープ指定ロールの一意名。

    • Base Role: このロールのパーミッションがベースとなるロール。

    • Type: このロールがホストまたはサーバーグループに制限されるかどうか。

    • Scope: ロールが制限されるホストまたはサーバーグループのリスト。複数のエントリーを選択できます。

    • Include All: このロールにすべてのユーザーが自動的に含まれるかどうか。デフォルトは no です。
  5. Save ボタンをクリックすると、ダイアログが閉じられ、新規作成されたロールがテーブルに表示されます。

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

  1. 管理コンソールへログインします。
  2. Roles タブの Scoped Roles エリアに移動します。
  3. テーブル上で編集するスコープ指定ロールをクリックします。ロールの詳細がテーブルの下の Selection パネルに表示されます。
    ロールの選択

    図11.9 ロールの選択

  4. Selection パネルの Edit リンクをクリックします。Selection パネルが編集モードになります。
    編集モードの Selection パネル

    図11.10 編集モードの Selection パネル

  5. 変更する必要がある詳細を変更し、Save ボタンをクリックします。Selection パネルが以前の状態に戻ります。Selection パネルとテーブルの両方に、新たに更新された詳細が表示されます。

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

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

    図11.11 ロールメンバーシップダイアログ

  4. 情報を確認した後、Done ボタンをクリックします。

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

重要

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

11.10. 制約の設定

11.10.1. 機密性制約の設定

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

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

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

機密性の制約を設定するには、write-attribute 操作を使用して configured-requires-read、configured-requires-write、または configured-requires-addressable 属性を設定します。操作のタイプを機密にするには、true を値として設定します。機密にしない場合は false を設定します。デフォルトではこれらの属性は設定されておらず、default-requires-read、default-requires-write、および default-requires-addressable の値が使用されます。configured 属性の値が設定されると、デフォルトの代わりにその値が使用されます。デフォルト値は変更できません。

例11.5 読み取りシステムプロパティーを機密操作にする

[domain@localhost:9999 /] cd /core-service=management/access=authorization/constraint=sensitivity-classification/type=core/classification=system-property
[domain@localhost:9999 classification=system-property] :write-attribute(name=configured-requires-read, value=true)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {"main-server-group" => {"host" => {"master" => {
        "server-one" => {"response" => {"outcome" => "success"}},
        "server-two" => {"response" => {"outcome" => "success"}}
    }}}}
}
[domain@localhost:9999 classification=system-property] :read-resource
{
    "outcome" => "success",
    "result" => {
        "configured-requires-addressable" => undefined,
        "configured-requires-read" => true,
        "configured-requires-write" => undefined,
        "default-requires-addressable" => false,
        "default-requires-read" => false,
        "default-requires-write" => true,
        "applies-to" => {
            "/host=master/system-property=*" => undefined,
            "/host=master/core-service=platform-mbean/type=runtime" => undefined,
            "/server-group=*/system-property=*" => undefined,
            "/host=master/server-config=*/system-property=*" => undefined,
            "/host=master" => undefined,
            "/system-property=*" => undefined,
            "/" => undefined
        }
    }
}
[domain@localhost:9999 classification=system-property]

どのロールがどの操作を実行できるかは、表11.2「機密性制約の設定結果」 に説明されている属性の設定によって異なります。

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

値 requires-read requires-write requires-addressable

true

読み取りは機密です。

Auditor、Administrator、SuperUser のみ読み取りできます。

書き込みは機密です。

Administrator と SuperUser のみ書き込みできます。

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

Auditor、Administrator、および SuperUser のみアドレス指定できます。

false

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

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

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

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

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

すべての管理ユーザーがアドレス指定できます。
バグを報告する

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

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

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

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

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

アプリケーションリソースを有効にするには、write-attribute 操作を使用して、分類の configured-application attribute を true に設定します。アプリケーションリソースを無効にするには、この属性を false に設定します。デフォルトでは、この属性は設定されていないため、default-application attribute の値が使用されます。デフォルトの値は変更できません。

例11.6 logger-profile アプリケーションリソースの分類を有効にする

[domain@localhost:9999 /] cd /core-service=management/access=authorization/constraint=application-classification/type=logging/classification=logging-profile
[domain@localhost:9999 classification=logging-profile] :write-attribute(name=configured-application, value=true)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {"main-server-group" => {"host" => {"master" => {
        "server-one" => {"response" => {"outcome" => "success"}},
        "server-two" => {"response" => {"outcome" => "success"}}
    }}}}
}
[domain@localhost:9999 classification=logging-profile] :read-resource 
{
    "outcome" => "success",
    "result" => {
        "configured-application" => true,
        "default-application" => false,
        "applies-to" => {"/profile=*/subsystem=logging/logging-profile=*" => undefined}
    }
}
[domain@localhost:9999 classification=logging-profile]

重要

アプリケーションリソース制約は、設定に一致するすべてのリソースに適用されます。たとえば、Deployer ユーザーに、あるデータソースリソースへのアクセスを許可し、他のデータソースリソースへのアクセスを拒否することはできません。このような分離レベルが必要な場合は、リソースを異なるサーバーグループに設定し、各グループに対して異なるスコープ指定の Deployer ロールを作成することが推奨されます。
バグを報告する

11.10.3. Vault 式制約の設定

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

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

vault 式の制約を設定するには、write-attribute 操作を使用して configured-requires-write および configured-requires-read 属性を true または false に設定します。デフォルトでは、これらの属性は設定されていないため、default-requires-read および default-requires-write の値が使用されます。デフォルトの値は変更できません。

例11.7 vault 式への書き込みを非機密操作にする

[domain@localhost:9999 /] cd /core-service=management/access=authorization/constraint=vault-expression
[domain@localhost:9999 constraint=vault-expression] :write-attribute(name=configured-requires-write, value=false)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {"main-server-group" => {"host" => {"master" => {
        "server-one" => {"response" => {"outcome" => "success"}},
        "server-two" => {"response" => {"outcome" => "success"}}
    }}}}
}
[domain@localhost:9999 constraint=vault-expression] :read-resource
{
    "outcome" => "success",
    "result" => {
        "configured-requires-read" => undefined,
        "configured-requires-write" => false,
        "default-requires-read" => true,
        "default-requires-write" => true
    }
}
[domain@localhost:9999 constraint=vault-expression]

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

表11.3 vault 式制約の設定結果

値 requires-read requires-write

true

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

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

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

Administrator と SuperUser のみ書き込みできます。

false

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

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

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

Monitor、Administrator、および SuperUser が書き込みできます。vault 式がアプリケーションリソースにある場合は Deployer も書き込みできます。
バグを報告する

11.11. 制約に関する参考情報

11.11.1. アプリケーションリソース制約に関する参考情報

タイプ: core

分類: deployment-overlay

  • デフォルト: true
    PATH 属性 操作

    /deployment-overlay=*

    /deployment=*

    /

    upload-deployment-stream、 full-replace-deployment、 upload-deployment-url、 upload-deployment-bytes

タイプ: datasources

分類: datasource

  • デフォルト: false
    PATH 属性 操作

    /deployment=*/subdeployment=*/subsystem=datasources/data-source=*

    /subsystem=datasources/data-source=*

    /subsystem=datasources/data-source=ExampleDS

    /deployment=*/subsystem=datasources/data-source=*
分類: jdbc-driver

  • デフォルト: false
    PATH 属性 操作

    /subsystem=datasources/jdbc-driver=*
分類: xa-data-source

  • デフォルト: false
    PATH 属性 操作

    /subsystem=datasources/xa-data-source=*

    /deployment=*/subsystem=datasources/xa-data-source=*

    /deployment=*/subdeployment=*/subsystem=datasources/xa-data-source=*

タイプ: logging

分類: logger

  • デフォルト: false
    PATH 属性 操作

    /subsystem=logging/logger=*

    /subsystem=logging/logging-profile=*/logger=*
分類: logging-profile

  • デフォルト: false
    PATH 属性 操作

    /subsystem=logging/logging-profile=*

タイプ: mail

分類: mail-session

  • デフォルト: false
    PATH 属性 操作

    /subsystem=mail/mail-session=*

タイプ: naming

分類: binding

  • デフォルト: false
    PATH 属性 操作

    /subsystem=naming/binding=*

タイプ: resource-adapters

分類: resource-adapters

  • デフォルト: false
    PATH 属性 操作

    /subsystem=resource-adapters/resource-adapter=*

タイプ: security

分類: security-domain

  • デフォルト: false
    PATH 属性 操作

    /subsystem=security/security-domain=*
バグを報告する

11.11.2. 機密性制約に関する参考情報

タイプ: core

分類: access-control

  • requires-addressable: true

  • requires-read: true

  • requires-write: true
    PATH 属性 操作

    /core-service=management/access=authorization

    /subsystem=jmx

    non-core-mbean-sensitivity
分類: credential

  • requires-addressable: false

  • requires-read: true

  • requires-write: true
    PATH 属性 操作

    /subsystem=mail/mail-session=*/server=pop3

    username, password

    /subsystem=mail/mail-session=*/server=imap

    username, password

    /subsystem=datasources/xa-data-source=*

    user-name, recovery-username, password, recovery-password

    /subsystem=mail/mail-session=*/custom=*

    username, password

    /subsystem=datasources/data-source=*"

    user-name, password

    /subsystem=remoting/remote-outbound-connection=*"

    username

    /subsystem=mail/mail-session=*/server=smtp

    username, password

    /subsystem=web/connector=*/configuration=ssl

    key-alias, password

    /subsystem=resource-adapters/resource-adapter=*/connection-definitions=*"

    recovery-username, recovery-password
分類: domain-controller

  • requires-addressable: false

  • requires-read: false

  • requires-write: true
    PATH 属性 操作
分類: domain-names

  • requires-addressable: false

  • requires-read: false

  • requires-write: true
    PATH 属性 操作
分類: extensions

  • requires-addressable: false

  • requires-read: false

  • requires-write: true
    PATH 属性 操作

    /extension=*
分類: jvm

  • requires-addressable: false

  • requires-read: false

  • requires-write: true
    PATH 属性 操作

    /core-service=platform-mbean/type=runtime

    input-arguments, boot-class-path, class-path, boot-class-path-supported, library-path
分類: management-interfaces

  • requires-addressable: false

  • requires-read: false

  • requires-write: true
    PATH 属性 操作

    /core-service=management/management-interface=native-interface

    /core-service=management/management-interface=http-interface
分類: module-loading

  • requires-addressable: false

  • requires-read: false

  • requires-write: true
    PATH 属性 操作

    /core-service=module-loading
分類: patching

  • requires-addressable: false

  • requires-read: false

  • requires-write: true
    PATH 属性 操作

    /core-service=patching/addon=*

    /core-service=patching/layer=*"

    /core-service=patching
分類: read-whole-config

  • requires-addressable: false

  • requires-read: true

  • requires-write: true
    PATH 属性 操作

    /

    read-config-as-xml
分類: security-domain

  • requires-addressable: true

  • requires-read: true

  • requires-write: true
    PATH 属性 操作

    /subsystem=security/security-domain=*
分類: security-domain-ref

  • requires-addressable: true

  • requires-read: true

  • requires-write: true
    PATH 属性 操作

    /subsystem=datasources/xa-data-source=*

    security-domain

    /subsystem=datasources/data-source=*

    security-domain

    /subsystem=ejb3

    default-security-domain

    /subsystem=resource-adapters/resource-adapter=*/connection-definitions=*

    security-domain, recovery-security-domain, security-application, security-domain-and-application
分類: security-realm

  • requires-addressable: true

  • requires-read: true

  • requires-write: true
    PATH 属性 操作

    /core-service=management/security-realm=*
分類: security-realm-ref

  • requires-addressable: true

  • requires-read: true

  • requires-write: true
    PATH 属性 操作

    /subsystem=remoting/connector=*

    security-realm

    /core-service=management/management-interface=native-interface

    security-realm

    /core-service=management/management-interface=http-interface

    security-realm

    /subsystem=remoting/remote-outbound-connection=*

    security-realm
分類: security-vault

  • requires-addressable: false

  • requires-read: false

  • requires-write: true
    PATH 属性 操作

    /core-service=vault
分類: service-container

  • requires-addressable: false

  • requires-read: false

  • requires-write: true
    PATH 属性 操作

    /core-service=service-container
分類: snapshots

  • requires-addressable: false

  • requires-read: false

  • requires-write: false
    PATH 属性 操作

    /

    take-snapshot, list-snapshots, delete-snapshot
分類: socket-binding-ref

  • requires-addressable: false

  • requires-read: false

  • requires-write: false
    PATH 属性 操作

    /subsystem=mail/mail-session=*/server=pop3

    outbound-socket-binding-ref

    /subsystem=mail/mail-session=*/server=imap

    outbound-socket-binding-ref

    /subsystem=remoting/connector=*

    socket-binding

    /subsystem=web/connector=*

    socket-binding

    /subsystem=remoting/local-outbound-connection=*

    outbound-socket-binding-ref

    /socket-binding-group=*/local-destination-outbound-socket-binding=*

    socket-binding-ref

    /subsystem=remoting/remote-outbound-connection=*

    outbound-socket-binding-ref

    /subsystem=mail/mail-session=*/server=smtp

    outbound-socket-binding-ref

    /subsystem=transactions

    process-id-socket-binding, status-socket-binding, socket-binding
分類: socket-config

  • requires-addressable: false

  • requires-read: false

  • requires-write: true
    PATH 属性 操作

    /interface=*

    resolve-internet-address

    /core-service=management/management-interface=native-interface

    port, interface, socket-binding

    /socket-binding-group=*

    /core-service=management/management-interface=http-interface

    port, secure-port, interface, secure-socket-binding, socket-binding

    /

    resolve-internet-address

    /subsystem=transactions

    process-id-socket-max-ports
分類: system-property

  • requires-addressable: false

  • requires-read: false

  • requires-write: true
    PATH 属性 操作

    /core-service=platform-mbean/type=runtime

    system-properties

    /system-property=*

    /

    resolve-expression

タイプ: datasources

分類: data-source-security

  • requires-addressable: false

  • requires-read: true

  • requires-write: true
    PATH 属性 操作

    /subsystem=datasources/xa-data-source=*

    user-name, security-domain, password

    /subsystem=datasources/data-source=*

    user-name, security-domain, password

タイプ: jdr

分類: jdr

  • requires-addressable: false

  • requires-read: false

  • requires-write: true
    PATH 属性 操作

    /subsystem=jdr

    generate-jdr-report

タイプ: jmx

分類: jmx

  • requires-addressable: false

  • requires-read: false

  • requires-write: true
    PATH 属性 操作

    /subsystem=jmx

タイプ: mail

分類: mail-server-security

  • requires-addressable: false

  • requires-read: false

  • requires-write: true
    PATH 属性 操作

    /subsystem=mail/mail-session=*/server=pop3

    username, tls, ssl, password

    /subsystem=mail/mail-session=*/server=imap

    username, tls, ssl, password

    /subsystem=mail/mail-session=*/custom=*

    username, tls, ssl, password

    /subsystem=mail/mail-session=*/server=smtp

    username, tls, ssl, password

タイプ: naming

分類: jndi-view

  • requires-addressable: false

  • requires-read: true

  • requires-write: true
    PATH 属性 操作

    /subsystem=naming

    jndi-view
分類: naming-binding

  • requires-addressable: false

  • requires-read: false

  • requires-write: false
    PATH 属性 操作

    /subsystem=naming/binding=*

タイプ: remoting

分類: remoting-security

  • requires-addressable: false

  • requires-read: true

  • requires-write: true
    PATH 属性 操作

    /subsystem=remoting/connector=*

    authentication-provider, security-realm

    /subsystem=remoting/remote-outbound-connection=*

    username, security-realm

    /subsystem=remoting/connector=*/security=sasl

タイプ: resource-adapters

分類: resource-adapter-security

  • requires-addressable: false

  • requires-read: true

  • requires-write: true
    PATH 属性 操作

    /subsystem=resource-adapters/resource-adapter=*/connection-definitions=*

    security-domain, recovery-username, recovery-security-domain, security-application, security-domain-and-application, recovery-password

タイプ: security

分類: misc-security

  • requires-addressable: false

  • requires-read: true

  • requires-write: true
    PATH 属性 操作

    /subsystem=security

    deep-copy-subject-mode

タイプ: web

分類: web-access-log

  • requires-addressable: false

  • requires-read: false

  • requires-write: false
    PATH 属性 操作

    /subsystem=web/virtual-server=*/configuration=access-log
分類: web-connector

  • requires-addressable: false

  • requires-read: false

  • requires-write: false
    PATH 属性 操作

    /subsystem=web/connector=*
分類: web-ssl

  • requires-addressable: false

  • requires-read: true

  • requires-write: true
    PATH 属性 操作

    /subsystem=web/connector=*/configuration=ssl
分類: web-sso

  • requires-addressable: false

  • requires-read: true

  • requires-write: true
    PATH 属性 操作

    /subsystem=web/virtual-server=*/configuration=sso
分類: web-valve

  • requires-addressable: false

  • requires-read: false

  • requires-write: false
    PATH 属性 操作

    /subsystem=web/valve=*
バグを報告する

第12章 トランザクションサブシステムの設定

12.1. JTS トランザクション

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

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

注記

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

手順12.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 部分を省略します。

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

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

例12.2 JTS 用 ORB の有効化

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

例12.3 JacORB サブシステムでのトラザクションの有効化

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

例12.4 トランザクションサブシステムでの JTS の有効化

/subsystem=transactions:write-attribute(name=jts,value=true)
バグを報告する

12.1.2. JMS の設定

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

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

例12.5 例

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

表12.1 HornetQ 属性

属性 サンプル値 タイプ
allow-failback true BOOLEAN
async-connection-execution-enabled true BOOLEAN
backup false BOOLEAN
cluster-password セキュアな値 STRING
mask-password true BOOLEAN
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 の値が、サーバーへ送信されたメッセージのサイズよりも大きくないと、サーバーはメッセージを格納できません。
バグを報告する

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

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

概要

mod_cluster ワーカーノードは、JBoss EAP サーバーから構成されます。このサーバーは、管理対象ドメインまたはスタンドアロンサーバーのサーバーグループの一部になることができます。JBoss EAP 内では、クラスターのすべてのノードを管理する別のプロセスが実行されます。これはマスターと呼ばれます。ワーカーノードの概念については、JBoss EAP 6.1『管理および設定ガイド』の「ワーカーノード」を参照してください。HTTPD 負荷分散の概要については、『管理および設定ガイド』の「HTTP コネクターの概要」を参照してください。

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

ワーカーノード設定

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

注記

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

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

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

    デフォルトでは、ネットワークインターフェースがすべて 127.0.0.1 に設定されます。スタンドアロンサーバーまたはサーバーグループ内の 1 つまたは複数のサーバーをホストする各物理ホストでは、インターフェースが他のサーバーが見つけることができるパブリック IP アドレスを使用するよう設定する必要があります。
    JBoss EAP 6 ホストの IP アドレスを変更するには、ホストをシャットダウンし、設定ファイルを直接編集する必要があります。これは、管理コンソールと管理 CLI を駆動する管理 API は固定管理アドレスに依存するためです。
    クラスター内の各サーバーの IP アドレスをマスターのパブリック IP アドレスに変更するには、次の手順を実行します。
    1. サーバーを完全にシャットダウンします。
    2. EAP_HOME/domain/configuration/ 内にある管理対象ドメイン用の host.xml または EAP_HOME/standalone/configuration/ 内にあるスタンドアロンサーバー用の standalone-ha.xml を編集します。
    3. <interfaces> 要素を見つけます。management、public、および 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/bin/add-user.sh コマンドを実行します。同じユーザー名を持つユーザーをスレーブとして ManagementRealm に追加します。このユーザーが外部 JBoss AS インスタンスに対して認証する必要があるかどうか尋ねられた場合は、yes と回答します。パスワード changeme を使用した、slave1 という名前のスレーブに対するコマンドの入力および出力の例は以下のとおりです。 
    user:bin user$ ./add-user.sh

What type of user do you wish to add? 
 a) Management User (mgmt-users.properties) 
 b) Application User (application-users.properties)
(a): a

Enter the details of the new user to add.
Realm (ManagementRealm) : 
Username : slave1
Password : changeme
Re-enter Password : changeme
About to add user 'slave1' for realm 'ManagementRealm'
Is this correct yes/no? yes
Added user 'slave1' to file '/home/user/jboss-eap-6.0/standalone/configuration/mgmt-users.properties'
Added user 'slave1' to file '/home/user/jboss-eap-6.0/domain/configuration/mgmt-users.properties'
Is this new user going to be used for one AS process to connect to another AS process e.g. slave domain controller?
yes/no? yes
To represent the user add the following to the server-identities definition <secret value="Y2hhbmdlbWU=" />

  3. add-user.sh の出力から Base64 でエンコードされた <secret> 要素をコピーします。

    認証に Base64 でエンコードされたパスワード値を指定したい場合、add-user.sh の出力の最終行より <secret> 要素値をコピーします。次の手順でこの値が必要になります。

  4. 新しい認証を使用するようスレーブホストのセキュリティーレルムを変更します。

    1. スレーブホストの 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 の出力より返された秘密の値に置き換えます。

      • ホストを設定し、vault よりパスワードを取得します。

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

          注記

          vault でパスワードを作成する場合、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. サーバーを再起動します。

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

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

バグを報告する

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

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

JBoss EAP 6 のパッチメカニズムにより、JBoss EAP 6 の特定の「マイナー」バージョン (JBoss EAP 6.2 など) で利用可能なアップデートが適用されます。パッチには、1 回限りのアップデート、セキュリティーアップデート、または累積アップデートが含まれます。
JBoss EAP のメジャーリリースとマイナーリリース間のアップグレード (6.1 から 6.2 へのアップグレードなど) には、異なるプロセスが必要です。
バグを報告する

14.2. パッチングの仕組み

JBoss のパッチは 2 つの形式でリリースされます。
  • 随時の更新: 既存製品の通常の更新サイクル以外にリリースされる 1 回限りのパッチ。これらには、セキュリティーパッチや、Red Hat Global Support Services (GSS) が特定の問題を修正するために提供する 1 回限りのパッチなどがあります。
  • 計画された更新: これらには、累積パッチと、既存製品のマイクロアップグレード、マイナーアップグレード、またはメジャーアップグレードなどがあります。累積パッチには、製品の該当バージョンに対してすでに開発された随時の更新がすべて含まれます。
パッチが計画された更新の一部としてリリースされるか、または随時の更新としてリリースされるかは、修正される問題の深刻度によって決まります。通常、深刻度が低い問題は先送りされ、対象製品の次の累積パッチまたはマイナーリリースで解決されます。深刻度が中程度以上の問題は、対象製品の随時の更新で重要度の高い順に解決されます (特定の問題の修正のみが含まれます)。
JBoss 製品の累積パッチとセキュリティーパッチは、zip (全製品) と RPM (製品のサブセット) の 2 つの形式で配布されます。

重要

JBoss 製品のインストールは、必ず zip または RPM パッチのいずれかの方法を使用して更新する必要があります。
JBoss 製品のセキュリティー更新はエラータによって提供されます (zip および RPM の両方)。エラータは、解決された欠陥、それらの深刻度、影響する製品、欠陥の詳細、およびパッチへの参照が含まれるリストをカプセル化します。バグ修正の更新はエラータによって通知されません。
JBoss セキュリティーの欠陥に対する Red Hat の評価の詳細については、「JBoss セキュリティーパッチの深刻度および影響度」を参照してください。
Red Hat は、セキュリティー関連の欠陥をサブスクライバーに通知するメーリングリストを管理しています。「パッチメーリングリストへのサブスクライブ」を参照してください。
バグを報告する

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

概要

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

要件

  • なし

手順14.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 パッチメーリングリストへのサブスクライブが完了し、セキュリティー関連の通知を受け取るようになります。

バグを報告する

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

14.4.1. patch コマンド

patch コマンドは、ダウンロードされた zip パッチを単一の JBoss EAP 6 サーバーインスタンスに適用するために使用されます。管理対象ドメイン全体で JBoss EAP 6 サーバーインスタンスにパッチを自動的に適用するためには使用できませんが、管理対象ドメインの個々のサーバーインスタンスには個別にパッチを適用できます。

重要

RPM を使用してインストールされた JBoss EAP 6 サーバーインスタンスは、patch コマンドを使用して更新できません。RPM でインストールされた JBoss EAP 6 サーバーを更新するには、「RPM 形式のパッチのインストール」を参照してください。

注記

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

表14.1 patch コマンドの引数とスイッチ

引数またはスイッチ 説明
apply パッチを適用します。
--override-all 競合がある場合に、パッチ操作によりユーザーの変更が上書きされます。
--override-modules モジュールが変更された結果、競合が発生した場合、このスイッチにより、これらの変更がパッチ操作の内容で上書きされます。
--override=path(,path) 指定されたその他のファイルの場合は、競合する変更済みファイルがパッチ操作のファイルで上書きされます。
--preserve=path(,path) 指定されたその他のファイルの場合は、競合する変更済みファイルが保持されます。
info 現在インストールされているパッチに関する情報を返します。
rollback パッチのアプリケーションがロールバックします。
--reset-configuration=TRUE|FALSE ロールバックに必要です。ロールバック操作の一部としてサーバー設定ファイルを復元するかどうかを指定します。
バグを報告する

14.4.2. patch コマンドを使用した Zip 形式パッチのインストール

概要

このタスクでは、patch コマンドを使用して zip 形式の JBoss EAP 6 用パッチをインストールする方法を示します。

重要

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

要件

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

手順14.2 patch コマンドを使用して zip パッチを JBoss EAP 6 サーバーインスタンスに適用する

警告

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

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

バグを報告する

14.4.3. patch コマンドを使用した Zip 形式パッチ適用のロールバック

概要

このタスクでは、patch コマンドを使用して、JBoss EAP 6 に以前に適用された zip 形式のパッチの適用をロールバックする方法を示します。

警告

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

重要

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

要件

  • patch コマンドを使用して以前に適用したパッチ。
  • サーバーインスタンス用の管理 CLI にアクセスします。『管理および設定ガイド』の「管理 CLI の起動」を参照してください。

手順14.3 patch コマンドを使用してパッチを JBoss EAP 6 サーバーインスタンスからロールバックする

  1. 管理 CLI から patch info コマンドを使用して、ロールバックするパッチの ID を見つけます。
    • 累積パッチの場合、パッチ ID は patch info 出力に表示された最初の cumulative-patch-id の値です。
    • 1 回限りのセキュリティーまたはバグ修正 ID は、patch info 出力に表示された最初の patches の値としてリストされます (最も最近に適用された 1 回限りのパッチが最初にリストされます)。
  2. 管理 CLI から、以前の手順の適切なパッチ ID を持つパッチをロールバックします。

    警告

    --reset-configuration スイッチの値を指定するときは注意してください。
    TRUE に設定された場合、パッチロールバックプロセスにより JBoss EAP 6 サーバー設定ファイルがパッチ適用前の状態にロールバックされます。パッチの適用後に JBoss EAP 6 サーバー設定ファイルに行われたすべての変更は失われます。
    FALSE に設定された場合、サーバー設定ファイルはロールバックされません。この状況では、ネームスペースなどの設定がパッチにより変更され (設定は有効でなくなり、手動で修正する必要があります)、ロールバック後にサーバーを起動できないことがあります。 
    [standalone@localhost:9999 /] patch rollback PATCH_ID --reset-configuration=TRUE
    patch ツールは、パッチをロールバックするときに競合が発生したかどうかを警告します。競合を解決する場合にコマンドの再実行で利用可能なスイッチについては、「patch コマンド」を参照してください。
  3. パッチのロールバックを反映するために、JBoss EAP 6 サーバーインスタンスを再起動します。 
    [standalone@localhost:9999 /] shutdown --restart=true
結果

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

バグを報告する

14.5. RPM 形式のパッチのインストール

概要

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

要件

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

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

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

警告

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

    重要

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

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

バグを報告する

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

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

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

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

例14.1 CVSS v2 の影響スコア

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

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

Red Hat は、JBoss EAP ディストリビューションの一部であるすべてのコンポーネントに対してセキュリティーパッチを提供します。しかし、JBoss EAP ユーザーの多くは、JBoss EAP ディストリビューションの一部として提供されるコンポーネントのみを使用せずに、独自の依存関係をバンドルするアプリケーションをデプロイします。たとえば、デプロイされた WARファイルの依存関係 JAR が WEB-INF/lib/ ディレクトリーに含まれることがあります。これらの JAR は、Red Hat が提供するセキュリティーパッチの範囲外となります。JBoss EAP にデプロイされたアプリケーション内に依存関係がバンドルされている場合、これらの依存関係のセキュリティー更新を管理するのは、アプリケーションのメインテナーの責任です。以下のツールやデーターソースを使用できますが、サポートや保証はありません。

ツールとデータソース

JBoss パッチメーリングリスト
JBoss パッチのメーリングリストをサブスクライブすると、JBoss 製品で修正されたセキュリティー上の欠陥について通知されるため、デプロイされたアプリケーションが脆弱性のあるバージョンのコンポーネントをバンドルするかどうかを確認できます。
バンドルされたコンポーネントのセキュリティーアドバイザリーページ
オープンソースコンポーネントの多くは、独自のセキュリティーアドバイザリーページを持っています。たとえば、既知のセキュリティー問題が多い struts 2 は一般的に使用されるコンポーネントですが、JBoss EAP ディストリビューションの一部として提供されません。struts 2 プロジェクトには、アップストリームのセキュリティーアドバイザリーページがあります。デプロイされたアプリケーションによって struts 2 がバンドルされる場合は、このページを監視する必要があります。商用コンポーネントの多くも、セキュリティーアドバイザリーページがあります。
既知の脆弱性に対してデプロイされたアプリケーションを定期的にスキャンする
これを行う商用ツールは複数あります。また、Red Hat の社員によって開発された Victims というオープンソースツールもありますが、このツールに対するサポートや保証はありません。Victims は複数のビルドおよび統合ツールにプラグインを提供し、既知の脆弱性がある依存関係のバンドルに対して自動的にアプリケーションをスキャンします。Maven、Ant、および Jenkins 用のプラグインがあります。Victims ツールの詳細は、https://victi.ms/about.html を参照してください。

関連トピック:

バグを報告する

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

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

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

アプリケーションの開発者はアプリケーションをセキュアにすることが多面的で重要であることを認識しています。JBoss EAP 6 は以下のような機能が含まれる、セキュアなアプリケーションの作成に必要なツールをすべて提供します。
「アプリケーションでのセキュリティードメインの使用」 も参照してください。
バグを報告する

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

概要

記述子プロパティー置換の限定的な制御が、jboss-as-ee_1_1.xsd に導入されました。このタスクには、記述子ベースのプロパティー置換を設定するのに必要な手順が含まれます。

要件

  • JBoss Enterprise Application Platform インスタンスを起動します。
  • 管理 CLI を起動します。
記述子ベースのプロパティー置換フラグはブール値を持ちます。
  • true に設定された場合は、プロパティー置換が有効になります。
  • false に設定された場合は、プロパティー置換が無効になります。

手順15.1 jboss-descriptor-property-replacement

jboss-descriptor-property-replacement は、次の記述子でプロパティー置換を有効または無効にするために使用されます。
  • jboss-ejb3.xml
  • jboss-app.xml
  • jboss-web.xml
  • *-jms.xml
  • *-ds.xml
jboss-descriptor-property-replacement のデフォルト値は true です。
  1. 管理 CLI では、次のコマンドを実行して jboss-descriptor-property-replacement の値を決定します。 
    /subsystem=ee:read-attribute(name="jboss-descriptor-property-replacement")
  2. 次のコマンドを実行して動作を設定します。 
    /subsystem=ee:write-attribute(name="jboss-descriptor-property-replacement",value=VALUE)

手順15.2 spec-descriptor-property-replacement

spec-descriptor-property-replacement は、次の記述子でプロパティー置換を有効または無効にするために使用されます。
  • ejb-jar.xml
  • persistence.xml
spec-descriptor-property-replacement のデフォルト値は false です。
  1. 管理 CLI では、次のコマンドを実行して spec-descriptor-property-replacement の値を確認します。 
    /subsystem=ee:read-attribute(name="spec-descriptor-property-replacement")
  2. 次のコマンドを実行して動作を設定します。 
    /subsystem=ee:write-attribute(name="spec-descriptor-property-replacement",value=VALUE)
結果

記述子ベースのプロパティー置換が正常に設定されます。

バグを報告する

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

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

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

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

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

例15.2 パスワード vault の例

<security>
  <user-name>admin</user-name>
  <password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password>
</security>
バグを報告する

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

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

15.4.1.1. EJB のセキュリティーアイデンティティー

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

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

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

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

特定のロールにセキュリティーアイデンティティーを設定するには、<security-identity> タグの中に <run-as> および <role-name> タグを使用します。 
<ejb-jar>
  <enterprise-beans>
	 <session>
		<ejb-name>RunAsBean</ejb-name>
		<!-- ... -->
		<security-identity>
		  <run-as>
			 <description>A private internal role</description>
			 <role-name>InternalRole</role-name>
		  </run-as>
		</security-identity>
	 </session>
  </enterprise-beans>
  <!-- ... -->
</ejb-jar>
デフォルトでは、<run-as> を使用すると anonymous という名前のプリンシパルが発信呼び出しへ割り当てられます。違うプリンシパルを割り当てる場合は <run-as-principle> を使用します。 
<session>
    <ejb-name>RunAsBean</ejb-name>
    <security-identity>
        <run-as-principal>internal</run-as-principal>
    </security-identity>
</session>

注記

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

以下も参照してください。

バグを報告する

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

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

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

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

概要

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

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

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

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

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

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

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

例15.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>
バグを報告する

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

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

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

15.4.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 を使用してロールを指定すると、メソッドが常にそのロールとして実行されるようにします。

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

@Stateless
@RolesAllowed({"admin"})
@SecurityDomain("other")
public class WelcomeEJB implements Welcome {
	@PermitAll
	public String WelcomeEveryone(String msg) {
		return "Welcome to " + msg;
	}
	@RunAs("tempemployee")
	public String GoodBye(String msg) {
	    return "Goodbye, " + msg;
	}
	public String GoodbyeAdmin(String msg) {
		return "See you later, " + msg;
	}
}
このコードでは、すべてのロールが WelcomeEveryone メソッドにアクセスできます。呼び出し時、GoodBye メソッドは tempemployee ロールを使用します。GoodbyeAdmin メソッドおよびセキュリティーアノテーションのない他のメソッドにできるのは admin ロールのみです。
バグを報告する

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

15.4.4.1. リモートメソッドアクセス

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

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

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

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

アーキテクチャーの概要

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

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

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

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

15.4.4.2. Remoting コールバック

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

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

プッシュコールバック

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

バグを報告する

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

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

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

概要

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

注記

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

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

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

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

ネットワークインターフェース
remoting サブシステムによって使用されるネットワークインターフェースは domain/configuration/domain.xml または standalone/configuration/standalone.xml で定義される unsecure インターフェースです。 
<interfaces>
   <interface name="management"/>
   <interface name="public"/>
   <interface name="unsecure"/>
</interfaces>
unsecure インターフェースのホストごとの定義は domain.xml または standalone.xml と同じディレクトリーにある host.xml で定義されます。また、このインターフェースは複数の他のサブシステムによっても使用されます。変更する場合は十分注意してください。 
<interfaces>
   <interface name="management">
      <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
   </interface>
   <interface name="public">
      <inet-address value="${jboss.bind.address:127.0.0.1}"/>
   </interface>
   <interface name="unsecure">
      <!-- Used for IIOP sockets in the standard configuration.
         To secure JacORB you need to setup SSL -->
      <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
   </interface>
</interfaces>
socket-binding
remoting サブシステムによって使用されるデフォルトの socket-binding は TCP ポート 4777 へバインドします。この設定を変更する必要がある場合はソケットバインディングとソケットバインディンググループに関するドキュメントを参照してください。
EJB の リモーティングコネクター参照
EJB サブシステムにはリモートメソッド呼び出しに対するリモーティングコネクターへの参照が含まれています。デフォルト設定は次のとおりです。 
<remote connector-ref="remoting-connector" thread-pool-name="default"/>
セキュアなトランスポート設定
Remoting はクライアントの要求があれば StartTLS を使用して安全な接続 (HTTPS、Secure Servlet など) を使用します。安全な接続と安全でない接続の両方で同じソケットバインディング (ネットワークポート) が使用されるため、サーバー側に追加の設定をする必要はありません。クライアントはニーズに従って安全なトランスポートまたは安全でないトランスポートを要求します。EJB、ORB、JMS プロバイダーなどの Remoting を使用する JBoss EAP のコンポーネントはデフォルトで安全なインターフェースを使用します。

警告

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

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

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

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

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

表15.2 コネクターの属性

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

表15.3 コネクター要素

属性 説明 CLI コマンド
sasl
SASL (Simple Authentication and Security Layer) 認証メカニズムのエンクロージング要素です。
N/A
プロパティー
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 属性を取り、認証に使用します。

表15.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 属性が含まれます。 
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=strength,value=["medium"])
reuse-session
ブール値である value 属性が含まれます。true の場合、セッションの再使用を試みます。 
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=reuse-session,value=false)
server-auth
ブール値である value 属性が含まれます。true の場合、サーバーはクライアントに対して認証します。 
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=server-auth,value=false)
policy
以下の要素がゼロ個以上含まれ、各要素が単一の value を取るエンクロージング要素です。
  • forward-secrecy – メカニズムによる前方秘匿性 (forward secrecy) の実装が必要であるかどうか (あるセッションが侵入されても、その後のセッションへの侵入に関する情報は自動的に提供されません)。
  • no-active – 辞書攻撃でない攻撃を受けやすいメカニズムを許可するかどうか。値が false の場合は許可し、 true の場合は許可しません。
  • no-anonymous – 匿名ログインを許可するメカニズムを許可するかどうか。値が false の場合は許可し、 true の場合は許可しません。
  • no-dictionary – 受動的な辞書攻撃を受けやすいメカニズムを許可するかどうか。値が false の場合は許可し、 true の場合は許可しません。
  • no-plain-text – 単純で受動的な辞書攻撃を受けやすいメカニズムを許可するかどうか。値が false の場合は許可し、 true の場合は許可しません。
  • pass-credentials – クライアントのクレデンシャルを渡すメカニズムを許可するかどうか。 
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:add
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=forward-secrecy,value=true)
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-active,value=false)
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-anonymous,value=false)
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-dictionary,value=true)
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-plain-text,value=false)
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=pass-credentials,value=true)
プロパティー
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)

例15.11 設定例

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

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

  • JIDI および マルチキャスト自動検出
バグを報告する

15.4.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 をデプロイします。
バグを報告する

15.4.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)
結果

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

バグを報告する

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

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

    ターミナルを開き、EAP_HOME/bin/ ディレクトリーへ移動します。Red Hat Enterprise Linux や他の UNIX 系のオペレーティングシステムを稼働している場合は、add-user.sh を実行します。Microsoft Windows Server を稼働している場合は add-user.bat を実行します。

  2. 管理ユーザーかアプリケーションユーザーのどちらを追加するか選択します。

    この手順では b を入力し、アプリケーションユーザーを追加します。

  3. ユーザーが追加されるレルムを選択します。

    デフォルトでは、ApplicationRealm のみが選択可能です。カスタムレルムが追加されている場合はその名前を入力します。

  4. 入力を促されたらユーザー名、パスワード、ロールを入力します。

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

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

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

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

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

概要

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

警告

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

手順15.3 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>
結果

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

例15.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>
バグを報告する

15.5.2. アノテーションを使用した JAX-RS Web サービスのセキュア化

概要

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

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

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

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

16.1. Web アプリケーションのシングルサインオン (SSO)

概要

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

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

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

SSO の仕組み

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

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

SSO の制限

サードパーティー境界にまたがる伝搬がない
JBoss EAP 6 のコンテナ内にデプロイされたアプリケーションの間でのみ 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 アプリケーション全体で一貫していなければなりません。
すべてのセキュリティー統合が同じクレデンシャル (ユーザー名やパスワードなど) を許可しなければなりません。
バグを報告する

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

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

16.3. 適切な SSO 実装の選択

JBoss EAP 6 は 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 EAP 6 上で実行されているエンタープライズアプリケーションを透過的に認証することができます。

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

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

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

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

バグを報告する

16.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 部分を削除するため、コマンドを変更することもできます。

    例16.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 になります。存在しない場合は追加する必要があります。

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

    例16.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 は存在しません。

    例16.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 には永続データのクラスタリングレプリケーションを制御する cacheConfig や processExpiresInterval、 maxEmptyLife パラメーターが含まれています。

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

表16.1 SSO 設定のオプション

オプション 説明
cookieDomain
SSO クッキーに使用するホストドメインです。デフォルトは / です。app1.xyz.com と app2.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() を呼び出し、プログラムを用いてセッションを無効化することができます。

バグを報告する

16.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 環境でも使用されています。
バグを報告する

16.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 プロバイダーと動作します。
バグを報告する

16.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)。
バグを報告する

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

はじめに

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

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

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

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

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

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

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

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

  2. Web アプリケーションやアプリケーションをセキュアにするため、2 つ目のセキュリティードメインを設定します。必要な場合はシステムプロパティーを設定します。

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

  3. web.xml の security-constraint と login-config を指定します。

    web.xml 記述子にはセキュリティー制約とログイン設定に関する情報が含まれています。セキュリティー制約とログイン情報の値の例は次の通りです。 
    <security-constraint>
   <display-name>Security Constraint on Conversation</display-name>
   <web-resource-collection>
      <web-resource-name>examplesWebApp</web-resource-name>
      <url-pattern>/*</url-pattern>
   </web-resource-collection>
   <auth-constraint>
   <role-name>RequiredRole</role-name>
   </auth-constraint>
</security-constraint>

<login-config>
   <auth-method>SPNEGO</auth-method>
   <realm-name>SPNEGO</realm-name>
</login-config>
 
<security-role>
   <description> role required to log in to the Application</description>
   <role-name>RequiredRole</role-name>
</security-role>

  4. jboss-web.xml 記述子にセキュリティードメインと他の設定を指定します。

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

バグを報告する

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

17.1. セキュリティー拡張アーキテクチャー

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

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

JAAS の主な実装は、AuthenticationManager インターフェースと RealmMapping インターフェースを実装する org.jboss.security.plugins.JaasSecurityManager です。JaasSecurityManager は、対応するコンポーネントデプロイメント記述子の <security-domain> 要素を基に、EJB レイヤーと Web コンテナレイヤーに統合します。
JAAS に関する詳細は 「Java 認証承認サービス (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 やその他の暗号化のユースケースをサポートするため KeyStore、KeyManagerFactory、および TrustManagerFactory の概念を追加する、JaasSecurityManager の拡張です。

詳細情報

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

バグを報告する

17.2. Java 認証承認サービス (JAAS)

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

17.3. Java Authentication and Authorization Service (JAAS)

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

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

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

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

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

Java 認証承認サービス (JAAS) はプラグ可能認証モジュール (PAM) を使用した、 Java アプリケーションのユーザーレベルのセキュリティーに対するフレームワークです。JAAS は Java ランタイム環境 (JRE) に統合されます。JBoss EAP 6 では、コンテナ側のコンポーネントは 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 の認証手順

図17.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.Group。org.jboss.security.SimplePrincipal タイプのオブジェクトはロール名を表します。これらのロールは、ejb-jar.xml と EJBContext.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 を呼び出し、プリンシパルの認証を行います。これにより、確実にユーザーロールがプリンシパルオブジェクトへ関連付けられているようにします。
バグを報告する

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

概要

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

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

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

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

    • サーバーの設定ファイルへセキュリティードメインを設定

      セキュリティードメインは、サーバーの設定ファイルの security サブシステムに設定されます。JBoss EAP 6 インスタンスが管理対象ドメインで実行されている場合、domain/configuration/domain.xml ファイルになります。JBoss EAP 6 インスタンスがスタンドアロンサーバーとして実行されている場合は standalone/configuration/standalone.xml ファイルになります。
      other、jboss-web-policy、および jboss-ejb-policy セキュリティードメインはデフォルトとして JBoss EAP 6 に提供されます。次の XML の例は、サーバーの設定ファイルの security サブシステムよりコピーされました。 
      <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 EAP 6 Quickstarts バンドルの ejb-security クイックスタートを参照してください。
バグを報告する

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

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

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

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

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

    web.xml の <servlet-mapping> 要素を使用して各サーブレットを URL パターンへマッピングします。次の例は DisplayOpResult と呼ばれるサーブレットを URL パターン /DisplayOpResult にマッピングします。 
    <servlet-mapping>
    <servlet-name>DisplayOpResult</servlet-name>
    <url-pattern>/DisplayOpResult</url-pattern>
</servlet-mapping>

  2. URL パターンにセキュリティー制約を追加します。

    URL パターンをセキュリティー制約へマッピングするには、<security-constraint> を使用します。次の例は、URL パターン /DisplayOpResult のアクセスを、ロール eap_admin を持つプリンシパルのみに許可します。セキュリティードメインにロールが存在していなければなりません。 
    <security-constraint>
	<display-name>Restrict access to role eap_admin</display-name>
	<web-resource-collection>
		<web-resource-name>Restrict access to role eap_admin</web-resource-name>
		<url-pattern>/DisplayOpResult/*</url-pattern>
	</web-resource-collection>
	<auth-constraint>
		<role-name>eap_admin</role-name>
	</auth-constraint>	
</security-constraint>	

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


<login-config>
    <auth-method>BASIC</auth-method>
</login-config>
    認証メソッドを指定する必要があります。BASIC、FORM、DIGEST、CLIENT-CERT、SPNEGO のいずれかを指定できます。この例では BASIC 認証を使用します。

  3. WAR の jboss-web.xml にセキュリティードメインを指定します。

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

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

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

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

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

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

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

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

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

</web-app>
バグを報告する

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

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

注記

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

例17.2 基本的な認証バルブ

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

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

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

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

例17.4 GenericHeaderAuthenticator.java

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

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

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

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

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

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

  protected boolean trace = log.isTraceEnabled();

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

  private String sessionCookieForSSOAuth = null;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第18章 移行

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

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

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

重要

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

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

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

バグを報告する

付録A 参考資料

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

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

認証モジュール

表A.1 ログインモジュール

コード クラス 説明
Client クラス このログインモジュールは、JBoss EAP 6 がクライアントとして動作するときに呼び出し元 ID とクレデンシャルを確立するよう設定されています。これは、実際のサーバー認証に使用されるセキュリティードメインの一部として使用しないでください。
Remoting N/A Remoting ログインモジュールは、現在認証中の要求が Remoting 接続上で受信された要求であるかどうかを確認するために使用されます。Remoting 接続上で受信された要求である場合、認証処理中に作成された ID が使用され、現在の要求に関連付けされます。要求が Remoting 接続上で受信されなかった場合は、このモジュールは何もせず、JAAS ベースのログインは次のモジュールへ続行されます。
RealmDirect N/A 現在の要求が Remoting ログインモジュールで発生しなかった場合、RealmDirect ログインモジュールは、セキュリティーレルムを使用して現在の要求を認証し、レルムを使用してユーザーのロールをロードします。デフォルトでは、このログインモジュールは、ApplicationRealm という名前のレルムの使用が想定されますが、他の名前の上書きが可能です。この手法の利点は、セキュリティードメインをレルムへ委譲する状態で、すべてのバッキングストアの設定をレルム内に保持できることです。

表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
none、simple、または SASL メカニズムの名前。
simple
LDAP サーバーにバインドするために使用するセキュリティーレベル。
java.naming.security.protocol
トランスポートプロトコル
指定されない場合は、プロバイダーによって決定されます。
SSL などの、セキュアアクセスに使用するトランスポートプロトコル。
java.naming.security.principal
文字列
なし
サービスに対する呼び出し元を認証するプリンシパルの名前。これは、以下に示された他のプロパティーから構築されます。
java.naming.security.credentials
クレデンシャルタイプ
なし
認証スキームにより使用されるクレデンシャルのタイプ。一部の例には、ハッシュ化されたパスワード、クリアテキストパスワード、キー、または証明書が含まれます。このプロパティーが指定されない場合は、動作がサービスプロバイダーにより決定されます。
principalDNPrefix
文字列
なし
ユーザー DN を形成するユーザー名に追加されるプレフィックス。ユーザーにユーザー名の指定を要求したり、principalDNPrefix および principalDNSuffix を使用して完全修飾 DN を構築したりできます。
principalDNSuffix
文字列
ユーザー DN を形成するユーザー名に追加されるサフィックス。ユーザーにユーザー名の指定を要求したり、principalDNPrefix および principalDNSuffix を使用して完全修飾 DN を構築したりできます。
useObjectCredential
true または false
false
JAAS PasswordCallback を使用した char[] パスワードではなく Callback の org.jboss.security.auth.callback.ObjectCallback タイプを使用した不透明なオブジェクトとしてクレデンシャルを取得するかどうか。これにより、non-char[] クレデンシャル情報を LDAP サーバーに渡すことができるようになります。
rolesCtxDN
完全修飾 DN
なし
ユーザーロールを検索するコンテキストの完全修飾 DN。
userRolesCtxDNAttributeName
属性
なし
ユーザーロールを検索するコンテキストの DN を含むユーザーオブジェクトの属性。これは、rolesCtxDN と異なるため、ユーザーのロールを検索するコンテキストは各ユーザーに対して一意になることがあります。
roleAttributeID
属性
roles
ユーザーロールを含む属性の名前。
roleAttributeIsDN
true または false
false
roleAttributeID にロールオブジェクトの完全修飾 DN が含まれるかどうか。false の場合は、コンテキスト名の roleNameAttributeId 属性の値からロール名が取得されます。Microsoft Active Directory などの特定のディレクトリースキーマでは、この属性を true に設定する必要があります。
roleNameAttributeID
属性
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 に対してプレーンテキストで保存されたパスワード、または EXT コマンドを使用して外部でロードされたパスワード。このパスワードは vault メカニズムを使用して暗号化できます。以下の形式を使用できます。
  • {EXT}... where the ... is the required external command. Example: {EXT}cat /mysecretpasswordfile
  • {EXTC[:expiration_in_millis]}... の ... は、プラットフォームコマンドの 1 つを実行するため Runtime.exec(String) メソッドに渡されるコマンドです。コマンド出力の最初の行がパスワードとして使用されます。
    EXTC の亜種は、expiration_in_millis の値 (ミリ秒) の間パスワードをキャッシュします。デフォルトでは、キャッシュの期限切れは 0 (無限) になります。
  • {CLASS}classname[:ctorargs] の [:ctorargs] は、クラス名 ctor へ渡されるクラス名が : によって区切られる任意の文字列です。ctorargs 自体は文字列のコンマ区切りリストです。
    char[] toCharArray() メソッドが見つかった場合は、char[] toCharArray() を呼び出してクラス名よりパスワードが取得されます。このメソッドが見つからなかった場合は、String toString() が使用されます。
機密性の高い文字列の暗号化については、「機密性が高い文字列を格納する Java キーストアの作成」 を参照してください。
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
プリンシパルの名前。
none
モジュールに対して認証されるサブジェクトに関連付けられるプリンシパル。

表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 SimpleUsers

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

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

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

表A.31 LdapUsers

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

表A.32 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.33 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.34 SPNEGOUsers

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

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

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

表A.36 AdvancedLdap

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

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

オプション タイプ デフォルト 説明
bindAuthentication
文字列
なし
ディレクトリサーバーへのバインディングに使用する SASL 認証のタイプ。
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.38 AdvancedADLdap

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

表A.39 UsersRoles

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

表A.40 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 メソッドにのみアクセスできます。
カスタム認証モジュール

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

バグを報告する

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

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

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

以下のセキュリティーマッピングロールが JBoss EAP 6 で提供されます。
コード クラス
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 EAP 6 はセキュリティー監査プロバイダーを 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.xml に設定される要件をローカルリソースへマッピングします。web.xml の設定に関する説明は http://docs.oracle.com/cd/E13222_01/wls/docs81/webapp/web_xml.html を参照してください。

たとえば、web.xml に jdbc/MyDataSource が必要な場合、jboss-web.xml はグローバルデータソース java:/DefaultDS をマッピングして要件を満たすことがあります。WAR はグローバルデータソースを使用して jdbc/MyDataSource に対する要求を満たします。

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

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

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

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

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

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

表A.43 リスナー設定要素

属性 説明
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.44 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.44「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 改訂履歴

改訂履歴
改訂 1.0.0-1Wed Apr 16 2014CS Builder Robot
Built from Content Specification: 14876, Revision: 564067

法律上の通知

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