Red Hat Training

A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform

第7章 JBoss EAP 7.1 における Elytron への移行

7.1. Elytron の概要

JBoss EAP 7.1 には Elytron が導入されました。Elytron はスタンドアロンサーバーと管理対象ドメインの両方のアクセスを管理および設定できる単一の統合フレームワークです。JBoss EAP サーバーにデプロイされたアプリケーションのセキュリティーアクセスを設定するために使用することもできます。

重要

The architectures of Elytron and the legacy security subsystem that is based on PicketBox are very different. With Elytron, an attempt was made to create a solution that allows you to operate in the same security environments in which you currently operate; however, this does not mean that every PicketBox configuration option has an equivalent configuration option in Elytron.

If you are not able to find information in the documentation to help you achieve similar functionality using Elytron that you had when using the legacy security implementation, you can find help in one of the following ways.

PicketBox ベースのレガシー security サブシステムを使用する JBoss EAP 7.0 サーバー設定およびデプロイメントは、JBoss EAP 7.1 を変更せずに実行できるはずです。PicketBox は継続してセキュリティードメインをサポートするため、アプリケーションは既存のログインモジュールを継続して使用できます。セキュリティーのために管理レイヤーによって使用されるセキュリティーレルムも Elytron に引き継がれ、エミュレートされます。これにより、elytron サブシステムとレガシーの security サブシステムの両方で認証を定義でき、両方のサブシステムを並行して使用できます。アプリケーションが Elytron およびレガシーセキュリティーを使用するよう設定する方法は、『How to Configure Identity Management』の「Configure Web Applications to Use Elytron or Legacy Security for Authentication」を参照してください。

PicketBox 認証のサポートは継続されますが、アプリケーションを移行する準備ができたら Elytron に移行することが推奨されます。Elytron セキュリティーを使用する利点の 1 つは、サーバーとアプリケーション全体で一貫したセキュリティーソリューションを提供することです。Elytron を使用するよう PicketBox の認証および承認を移行する方法については、本ガイドの「認証設定の移行」を参照してください。

elytron サブシステムで使用できる新リソースの概要については、JBoss EAP 『セキュリティーアーキテクチャー』の「Elytron サブシステムのリソース」を参照してください。

重要

デプロイメントでレガシー security サブシステムと Elytron の両方を使用する場合、異なるセキュリティーアーキテクチャーを使用したデプロイメント間での呼び出しはサポートされないため注意してください。

これらのサブシステムを並行して使用する方法は、『How to Configure Identity Management』の「Using Elytron and Legacy Security Subsystems in Parallel」を参照してください。

7.2. セキュアな vault およびプロパティーの移行

7.2.1. クレデンシャルストレージをセキュア化する vault の移行

JBoss EAP 7.0 のレガシー security サブシステムでプレーンテキストの文字列暗号を保存するために使用された vault は、新たに設計されたクレデンシャルストアを使用して文字列を保存する JBoss EAP 7.1 の Elytron と互換性がありません。クレデンシャルストアは、JBoss EAP 設定ファイル外のストレージファイルでクレデンシャルを安全に暗号化します。Elytron によって提供される実装を使用するか、クレデンシャルストア API および SPI を使用して設定をカスタマイズすることができます。各 JBoss EAP サーバーに複数のクレデンシャルストアを含めることができます。

注記

以前 vault 式を使用して機密でないデータをパラメーター化した場合、そのデータを Elytron セキュリティープロパティー に置き換えることが推奨されます。

レガシー security サブシステムの使用を継続する場合、vault データを編集または更新する必要はないはずです。しかし、アプリケーションを移行して Elytron を使用する計画がある場合、既存の vault をクレデンシャルストアに変換し、elytron サブシステムが処理できるようにする必要があります。クレデンシャルストアに関する詳細は、『How to Configure Server Security』の「Credential Stores」を参照してください。

WildFly Elytron Tool を使用した vault データの移行

JBoss EAP に同梱されている WildFly Elytron Tool は、vault の内容をクレデンシャルストアに移行するのに便利な vault コマンドを提供します。EAP_HOME/bin ディレクトリーにある elytron-tool スクリプトを実行してツールを実行します。

$ EAP_HOME/bin/elytron-tool.sh vault VAULT_ARGUMENTS

java -jar コマンドを実行してツールを実行することもできます。

$ java -jar EAP_HOME/bin/wildfly-elytron-tool.jar vault VAULT_ARGUMENTS

以下のコマンドを使用すると、使用できるすべての引数の説明を表示できます。

$ EAP_HOME/bin/elytron-tool.sh vault --help
注記
  • WildFly Elytron Tool は、セキュリティー vault データファイルの最初のバージョンを処理できません。
  • 以下の例のように --keystore-password 引数をマスクされた形式で入力し、単一の vault を移行します (またはクリアテキスト)。
  • --salt および --iteration 引数は、マスクされたパスワードを復号化する情報を提供したり、出力にマスクされたパスワードを生成するために提供されます。--salt および --iteration 引数を省略すると、デフォルトの値が使用されます。
  • --summary 引数は、変換されたクレデンシャルストアを JBoss EAP 設定に追加するために使用できるフォーマットされた管理 CLI コマンドを生成します。プレーンテキストパスワードはサマリー出力でマスクされます。
重要

クレデンシャルストアはパスワードのセキュア化のみに使用できることに注意してください。管理モデルで使用できる vault 式機能をサポートしません。

以下の移行オプションの 1 つを選択します。

単一のセキュリティー vault をクレデンシャルストアに移行

以下は、単一のセキュリティー vault をクレデンシャルストアに変換するために使用されるコマンドの例になります。

$ EAP_HOME/bin/elytron-tool.sh vault --enc-dir vault_data/ --keystore vault-jceks.keystore --keystore-password MASK-2hKo56F1a3jYGnJwhPmiF5 --iteration 34 --salt 12345678 --alias test --location cs-v1.store --summary

このコマンドはセキュリティー vault をクレデンシャルストアに変換し、変換に使用された管理 CLI コマンドの概要を出力します。

Vault (enc-dir="vault_data/";keystore="vault-jceks.keystore") converted to credential store "cs-v1.store"
Vault Conversion summary:
--------------------------------------
Vault Conversion Successful
CLI command to add new credential store:
/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="cs-v1.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5;12345678;34"})
複数のセキュリティー vault を一括でクレデンシャルストアに移行

--bulk-convert 引数を使用して一括変換記述子ファイルを示し、複数の vault をクレデンシャルストアに変換することができます。

ここで使用する例では、以下の一括変換記述子ファイルを使用します。

例: bulk-vault-conversion-descriptor.txt ファイル

keystore:vault-v1/vault-jceks.keystore
keystore-password:MASK-2hKo56F1a3jYGnJwhPmiF5
enc-dir:vault-v1/vault_data/
salt:12345678
iteration:34
location:v1-cs-1.store
alias:test

keystore:vault-v1/vault-jceks.keystore
keystore-password:secretsecret
enc-dir:vault-v1/vault_data/
location:v1-cs-2.store
alias:test

# different vault vault-v1-more
keystore:vault-v1-more/vault-jceks.keystore
keystore-password:MASK-2hKo56F1a3jYGnJwhPmiF5
enc-dir:vault-v1-more/vault_data/
salt:12345678
iteration:34
location:v1-cs-more.store
alias:test

新しい keystore: 行ごとに変換が新たに開始されます。saltiteration、および properties 以外のオプションはすべて必須です。

一括変換を実行し、管理 CLI コマンドをフォーマットする出力を生成するには、以下のコマンドを実行します。

$ EAP_HOME/bin/elytron-tool.sh vault --bulk-convert path/to/bulk-vault-conversion-descriptor.txt --summary

このコマンドは、ファイルに指定されたすべてのセキュリティー vault をクレデンシャルストアに変換し、変換に使用された管理 CLI コマンドの概要を出力します。

Vault (enc-dir="vault-v1/vault_data/";keystore="vault-v1/vault-jceks.keystore") converted to credential store "v1-cs-1.store"
Vault Conversion summary:
--------------------------------------
Vault Conversion Successful
CLI command to add new credential store:
/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="v1-cs-1.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5;12345678;34"})
--------------------------------------

Vault (enc-dir="vault-v1/vault_data/";keystore="vault-v1/vault-jceks.keystore") converted to credential store "v1-cs-2.store"
Vault Conversion summary:
--------------------------------------
Vault Conversion Successful
CLI command to add new credential store:
/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="v1-cs-2.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="secretsecret"})
--------------------------------------

Vault (enc-dir="vault-v1-more/vault_data/";keystore="vault-v1-more/vault-jceks.keystore") converted to credential store "v1-cs-more.store"
Vault Conversion summary:
--------------------------------------
Vault Conversion Successful
CLI command to add new credential store:
/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="v1-cs-more.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5;12345678;34"})
--------------------------------------

7.2.2. セキュリティープロパティーの Elytron への移行

ここの例では、group.name および encoding.algorithm セキュリティープロパティーは以下のようにレガシー security サブシステムで security-properties として定義されていることを仮定します。

例: security サブシステムに定義されたセキュリティープロパティー

<subsystem xmlns="urn:jboss:domain:security:2.0">
    ...
    <security-properties>
        <property name="group.name" value="engineering-group" />
        <property name="encoding.algorithm" value="BASE64" />
    </security-properties>
</subsystem>

同じセキュリティープロパティーを elytron サブシステムで定義するには、以下の管理 CLI コマンドを使用して elytron サブシステムの security-properties 属性を設定します。

/subsystem=elytron:write-attribute(name=security-properties, value={ group.name = "engineering-group", encoding.algorithm = "BASE64" })

これは、サーバー設定ファイルで elytron サブシステムの以下の security-properties を設定します。

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
    <security-properties>
        <security-property name="group.name" value="engineering-group"/>
        <security-property name="encoding.algorithm" value="BASE64"/>
    </security-properties>
    ...
</subsystem>

前のコマンドで使用した write-attribute 操作は、既存のプロパティーを上書きします。他のセキュリティープロパティーに影響を与えずにセキュリティープロパティーを追加または変更するには、管理 CLI コマンドで map 操作を使用します。

/subsystem=elytron:map-put(name=security-properties, key=group.name, value=technical-support)

同様に、map-remove 操作を使用すると特定のセキュリティープロパティーを削除できます。

/subsystem=elytron:map-remove(name=security-properties, key=group.name)

7.3. 認証設定の移行

7.3.1. プロパティーベースの認証および承認の Elytron への移行

7.3.1.1. PicketBox プロパティーベースの設定を Elytron に移行

ここでは、PicketBox プロパティーベースの認証を Elytron に移行する方法を説明します。PicketBox セキュリティードメインのみを Elytron に公開してプロパティーベースの認証を 部分的に移行 するか、または Elytron を使用するようプロパティーベースの認証設定を 完全に移行 するかを選択できます。

以下の手順は、移行を行うデプロイされた web アプリケーションが、フォームベースの認証を必要とするよう設定されていると仮定します。アプリケーションは PicketBox セキュリティードメインを参照し、UsersRolesLoginModule を使用して example-users.properties および example-roles.properties ファイルからユーザー情報をロードします。これらの例では、以下の管理 CLI コマンドを使用してセキュリティードメインがレガシー security サブシステムで定義されたことも仮定します。

例: PicketBox プロパティーベースの設定のコマンド

/subsystem=security/security-domain=application-security:add
/subsystem=security/security-domain=application-security/authentication=classic:add(login-modules=[{code=UsersRoles, flag=Required, module-options={usersProperties=file://${jboss.server.config.dir}/example-users.properties, rolesProperties=file://${jboss.server.config.dir}/example-roles.properties}}])

これにより、サーバーが以下のように設定されます。

例: PicketBox プロパティーベースのセキュリティードメインの設定

<security-domain name="application-security">
  <authentication>
    <login-module code="UsersRoles" flag="required">
      <module-option name="usersProperties" value="file://${jboss.server.config.dir}/example-users.properties"/>
      <module-option name="rolesProperties" value="file://${jboss.server.config.dir}/example-roles.properties"/>
    </login-module>
  </authentication>
</security-domain>

以下の移行オプションの 1 つを選択します。

PicketBox セキュリティードメインを Elytron に公開して部分的に移行

PicketBox セキュリティードメインを Elytron セキュリティーレルムとして公開し、Elytron 設定に結合するすることができますが、これによりレガシー security サブシステムとの依存関係が作成されます。プロパティーベースの認証のみを移行する場合は、アプリケーションを Elytron に完全移行 してレガシー security サブシステムとの不必要な依存関係が作成されないようにすることが推奨されます。しかし、Elytron を使用するようアプリケーションを完全移行できない場合は、部分的な移行で部分的に対処できます。

この手順に従って、既存の PicketBox セキュリティーレルム設定を Elytron セキュリティーレルムとして追加します。

  1. Elytron セキュリティーレルムへのマッピングをレガシー security サブシステム内に追加します。

    /subsystem=security/elytron-realm=application-security:add(legacy-jaas-config=application-security)

    これにより、以下の Elytron セキュリティーレルムがサーバー設定ファイルの security サブシステムに設定されます。

    <subsystem xmlns="urn:jboss:domain:security:2.0">
      ...
      <elytron-integration>
        <security-realms>
          <elytron-realm name="application-security" legacy-jaas-config="application-security"/>
        </security-realms>
      </elytron-integration>
      ...
    </subsystem>
  2. エクスポートされたセキュリティーレルムを参照する elytron サブシステムのセキュリティードメインを定義し、フォームベースの認証をサポートする HTTP 認証ファクトリーを定義します。

    /subsystem=elytron/security-domain=application-security:add(realms=[{realm=application-security}], default-realm=application-security, permission-mapper=default-permission-mapper)
    /subsystem=elytron/http-authentication-factory=application-security-http:add(http-server-mechanism-factory=global, security-domain=application-security, mechanism-configurations=[{mechanism-name=DIGEST,mechanism-realm-configurations=[{realm-name=RealmName}]}]

    これにより、サーバー設定ファイルの elytron サブシステム設定が以下のようになります。

    <subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
      ...
      <security-domains>
        ...
        <security-domain name="application-security" default-realm="application-security" permission-mapper="default-permission-mapper">
          <realm name="application-security"/>
        </security-domain>
      </security-domains>
      ...
      <http>
        ...
        <http-authentication-factory name="application-security-http" http-server-mechanism-factory="global" security-domain="application-security">
          <mechanism-configuration>
            <mechanism mechanism-name="DIGEST">
              <mechanism-realm realm-name="RealmName"/>
            </mechanism>
          </mechanism-configuration>
        </http-authentication-factory>
        ...
      </http>
      ...
    </subsystem>
  3. デプロイメントによって参照されるセキュリティードメインを、undertow サブシステムの新たに定義された HTTP 認証ファクトリーにマップします。

    /subsystem=undertow/application-security-domain=application-security:add(http-authentication-factory=application-security-http)

    これにより、サーバー設定ファイルの undertow サブシステムの設定が以下のようになります。

    <subsystem xmlns="urn:jboss:domain:undertow:4.0">
      ...
      <application-security-domains>
        <application-security-domain name="application-security" http-authentication-factory="application-security-http"/>
      </application-security-domains>
      ...
    </subsystem>
  4. この設定の指定前にアプリケーションがデプロイされた場合、新しいアプリケーションセキュリティードメインマッピングを有効にするにはサーバーのリロードまたはアプリケーションの再デプロイが必要になります。
  5. 以下の管理 CLI コマンドを使用して、マッピングがデプロイメントに適用されたことを確認します。この例で使用されるデプロイメントは HelloWorld.war です。このコマンドの出力は、このデプロイメントが Elytron マッピングを参照していることを表しています。

    /subsystem=undertow/application-security-domain=application-security:read-resource(include-runtime=true)
    {
        "outcome" => "success",
        "result" => {
            "enable-jacc" => false,
            "http-authentication-factory" => "application-security-http",
            "override-deployment-config" => false,
            "referencing-deployments" => ["HelloWorld.war"],
            "setting" => undefined
        }
    }

この段階では、この前に定義されたセキュリティードメインは LoginModule 設定に使用されますが、認証を引き継ぐ Elytron コンポーネントによってラップされます。

プロパティーベースの認証を Elytron に完全移行

以下の手順に従って、PicketBox プロパティーベースの認証を Elytron に完全移行します。この手順は、本セクションの始めで説明したレガシー設定を使用し、前述の 部分的な移行を行っていないことを仮定します。この手順の完了後も、レガシー security サブシステムに存在するセキュリティードメイン定義はすべて Elytron 設定から完全に独立した状態を維持します。

  1. PicketBox プロパティーファイルを参照する新しいレルムを elytron サブシステムに定義します。

    /subsystem=elytron/properties-realm=application-properties:add(users-properties={path=example-users.properties, relative-to=jboss.server.config.dir, plain-text=true, digest-realm-name="Application Security"}, groups-properties={path=example-roles.properties, relative-to=jboss.server.config.dir}, groups-attribute=Roles)
  2. セキュリティードメインサブシステムと HTTP 認証ファクトリーを elytron サブシステムに定義します。

    /subsystem=elytron/security-domain=application-security:add(realms=[{realm=application-properties}], default-realm=application-properties, permission-mapper=default-permission-mapper)
    /subsystem=elytron/http-authentication-factory=application-security-http:add(http-server-mechanism-factory=global, security-domain=application-security, mechanism-configurations=[{mechanism-name=FORM}])

    これにより、サーバー設定ファイルの elytron サブシステム設定が以下のようになります。

    <subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
      ...
      <security-domains>
        ...
        <security-domain name="application-security" default-realm="application-properties" permission-mapper="default-permission-mapper">
          <realm name="application-properties"/>
        </security-domain>
      </security-domains>
      <security-realms>
        ...
        <properties-realm name="application-properties" groups-attribute="Roles">
          <users-properties path="example-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="Application Security" plain-text="true"/>
          <groups-properties path="example-roles.properties" relative-to="jboss.server.config.dir"/>
        </properties-realm>
      </security-realms>
      ...
      <http>
        ...
        <http-authentication-factory name="application-security-http" http-server-mechanism-factory="global" security-domain="application-security">
          <mechanism-configuration>
            <mechanism mechanism-name="FORM"/>
          </mechanism-configuration>
        </http-authentication-factory>
        ...
      </http>
      ...
    </subsystem>
  3. デプロイメントによって参照されるアプリケーションセキュリティードメインを、undertow サブシステムの新たに定義された HTTP 認証ファクトリーにマップします。

    /subsystem=undertow/application-security-domain=application-security:add(http-authentication-factory=application-security-http)

    これにより、サーバー設定ファイルの undertow サブシステム設定が以下のようになります。

    <subsystem xmlns="urn:jboss:domain:undertow:4.0">
      ...
      <application-security-domains>
        <application-security-domain name="application-security" http-authentication-factory="application-security-http"/>
      </application-security-domains>
      ...
    </subsystem>
  4. 新しいアプリケーションセキュリティードメインマッピングを有効にするには、サーバーのリロードまたはアプリケーションの再デプロイが必要になります。

これで、認証が PicketBox 設定と同等になるよう設定されますが、認証には Elytron コンポーネントのみが使用されます。

7.3.1.2. レガシープロパティーベースの設定を Elytron に移行

ここでは、ユーザー、パスワード、およびグループ情報をプロパティーファイルから Elytron にロードするレガシーセキュリティーレルムの移行方法を説明します。通常このタイプのレガシーセキュリティーレルムは、管理インターフェースまたはリモーティングコネクターのいずれかをセキュアするために使用されます。

これらの例では、レガシーセキュリティードメインが以下の管理 CLI コマンドを使用して定義されることを仮定します。

例: レガシーセキュリティーレルムコマンド

/core-service=management/security-realm=ApplicationSecurity:add
/core-service=management/security-realm=ApplicationSecurity/authentication=properties:add(relative-to=jboss.server.config.dir, path=example-users.properties, plain-text=true)
/core-service=management/security-realm=ApplicationSecurity/authorization=properties:add(relative-to=jboss.server.config.dir, path=example-roles.properties)

これにより、サーバーが以下のように設定されます。

例: レガシーセキュリティーレルム設定

<security-realm name="ApplicationSecurity">
  <authentication>
    <properties path="example-users.properties" relative-to="jboss.server.config.dir" plain-text="true"/>
  </authentication>
  <authorization>
    <properties path="example-roles.properties" relative-to="jboss.server.config.dir"/>
  </authorization>
</security-realm>

Elytron セキュリティーをアプリケーションサーバーに追加する理由の 1 つが、サーバー全体で一貫したセキュリティーソリューションを使用できるようにすることです。プロパティーベースのレガシーセキュリティーレルムを Elytron に移行する最初のステップは、PicketBox プロパティーベースの認証を Elytron に移行する方法と似ています。以下の手順に従って、プロパティーベースのレガシーセキュリティーレルムを Elytron に移行します。

  1. プロパティーファイルを参照する新しいレルムを elytron サブシステムに定義します。

    /subsystem=elytron/properties-realm=application-properties:add(users-properties={path=example-users.properties, relative-to=jboss.server.config.dir, plain-text=true, digest-realm-name="Application Security"}, groups-properties={path=example-roles.properties, relative-to=jboss.server.config.dir}, groups-attribute=Roles)
  2. セキュリティードメインサブシステムと HTTP 認証ファクトリーを elytron サブシステムに定義します。

    /subsystem=elytron/security-domain=application-security:add(realms=[{realm=application-properties}], default-realm=application-properties, permission-mapper=default-permission-mapper)
    /subsystem=elytron/http-authentication-factory=application-security-http:add(http-server-mechanism-factory=global, security-domain=application-security, mechanism-configurations=[{mechanism-name=FORM}])

    これにより、Elytron が以下のように設定されます。

    <subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
      ...
      <security-domains>
        ...
        <security-domain name="application-security" default-realm="application-properties" permission-mapper="default-permission-mapper">
          <realm name="application-properties"/>
        </security-domain>
      </security-domains>
      <security-realms>
        ...
        <properties-realm name="application-properties" groups-attribute="Roles">
          <users-properties path="example-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="Application Security" plain-text="true"/>
          <groups-properties path="example-roles.properties" relative-to="jboss.server.config.dir"/>
        </properties-realm>
      </security-realms>
      ...
      <http>
        ...
        <http-authentication-factory name="application-security-http" http-server-mechanism-factory="global" security-domain="application-security">
          <mechanism-configuration>
            <mechanism mechanism-name="FORM"/>
          </mechanism-configuration>
        </http-authentication-factory>
        ...
      </http>
      ...
    </subsystem>
  3. レガシーセキュリティーレルムが SASL (Simple Authentication Security Layer) 認証にも使用されるように、sasl-authentication-factory を定義します。

    /subsystem=elytron/sasl-authentication-factory=application-security-sasl:add(sasl-server-factory=elytron, security-domain=application-security, mechanism-configurations=[{mechanism-name=PLAIN}])

    これにより、Elytron が以下のように設定されます。

    <subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
      ...
      <sasl>
        ...
        <sasl-authentication-factory name="application-security-sasl" sasl-server-factory="elytron" security-domain="application-security">
          <mechanism-configuration>
            <mechanism mechanism-name="PLAIN"/>
          </mechanism-configuration>
        </sasl-authentication-factory>
        ...
      </sasl>
    </subsystem>
  4. SASL 認証のリモーティングコネクターを設定し、レガシーセキュリティーレルムとの関連を削除します。

    /subsystem=remoting/http-connector=http-remoting-connector:write-attribute(name=sasl-authentication-factory, value=application-security-sasl)
    /subsystem=remoting/http-connector=http-remoting-connector:undefine-attribute(name=security-realm)

    これにより、サーバー設定ファイルの remoting サブシステムの設定が以下のようになります。

    <subsystem xmlns="urn:jboss:domain:remoting:4.0">
      ...
      <http-connector name="http-remoting-connector" connector-ref="default" sasl-authentication-factory="application-security-sasl"/>
    </subsystem>
  5. 2 つの認証ファクトリーを追加してレガシーセキュリティーレルムの参照を削除し、 http-interface を Elytron でセキュアにします。

    /core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory, value=application-security-http)
    /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=application-security-sasl)
    /core-service=management/management-interface=http-interface:undefine-attribute(name=security-realm)

    これにより、設定が以下のようになります。

    <management-interfaces>
      <http-interface http-authentication-factory="application-security-http">
        <http-upgrade enabled="true" sasl-authentication-factory="application-security-sasl"/>
        <socket-binding http="management-http"/>
      </http-interface>
    </management-interfaces>
    注記

    管理インターフェースをセキュア化するとき、例で使用されている名前よりも適切な名前を選択してください。

これで、レガシープロパティーベースの設定の Elytron への移行が完了しました。

7.3.2. LDAP 認証設定の Elytron への移行

ここでは、情報をアイデンティティー属性として管理できるようにするために、レガシー LDAP 認証を移行する方法について説明します。特に、セキュリティードメインおよび認証ファクトリーの定義方法と認証のためにこれらをマップする方法に関しては、「プロパティーベースの認証および承認の Elytron への移行」に記載されている多くの情報がここでも適用されます。ここでは、同じ手順は再度説明しないため、「プロパティーベースの認証および承認の Elytron への移行」を読んでから作業を続行してください。

ここで使用する例は、グループまたはロール情報は直接 LDAP からロードされ、レガシー LDAP 認証は以下のとおり設定されることを仮定しています。

  • LDAP サーバーには以下のユーザーおよびグループエントリーが含まれます。

    例: LDAP サーバーユーザーエントリー

    dn: uid=TestUserOne,ou=users,dc=group-to-principal,dc=wildfly,dc=org
    objectClass: top
    objectClass: inetOrgPerson
    objectClass: uidObject
    objectClass: person
    objectClass: organizationalPerson
    cn: Test User One
    sn: Test User One
    uid: TestUserOne
    userPassword: {SSHA}UG8ov2rnrnBKakcARVvraZHqTa7mFWJZlWt2HA==

    例: LDAP サーバーグループエントリー

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

    ユーザー名は認証の目的で uid 属性と照合され、グループ名はグループエントリーの uid 属性から取られます。

  • LDAP サーバーへの接続と関連するセキュリティーレルムは、以下の管理 CLI コマンドを使用して定義されます。

    例: LDAP セキュリティーレルム設定コマンド

    batch
    /core-service=management/ldap-connection=MyLdapConnection:add(url="ldap://localhost:10389", search-dn="uid=admin,ou=system", search-credential="secret")
    
    /core-service=management/security-realm=LDAPRealm:add
    /core-service=management/security-realm=LDAPRealm/authentication=ldap:add(connection="MyLdapConnection", username-attribute=uid, base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org")
    
    /core-service=management/security-realm=LDAPRealm/authorization=ldap:add(connection=MyLdapConnection)
    /core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn=username-filter:add(attribute=uid, base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org")
    /core-service=management/security-realm=LDAPRealm/authorization=ldap/group-search=group-to-principal:add(base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org", iterative=true, prefer-original-connection=true, principal-attribute=uniqueMember, search-by=DISTINGUISHED_NAME, group-name=SIMPLE, group-name-attribute=uid)
    run-batch

    これにより、サーバーが以下のように設定されます。

    例: LDAP セキュリティーレルム設定

    <management>
      <security-realms>
        ...
        <security-realm name="LDAPRealm">
          <authentication>
            <ldap connection="MyLdapConnection" base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org">
              <username-filter attribute="uid"/>
            </ldap>
          </authentication>
          <authorization>
            <ldap connection="MyLdapConnection">
              <username-to-dn>
                <username-filter base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org" attribute="uid"/>
              </username-to-dn>
              <group-search group-name="SIMPLE" iterative="true" group-name-attribute="uid">
                <group-to-principal search-by="DISTINGUISHED_NAME" base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org" prefer-original-connection="true">
                  <membership-filter principal-attribute="uniqueMember"/>
                </group-to-principal>
              </group-search>
            </ldap>
          </authorization>
        </security-realm>
      </security-realms>
      <outbound-connections>
        <ldap name="MyLdapConnection" url="ldap://localhost:10389" search-dn="uid=admin,ou=system" search-credential="secret"/>
      </outbound-connections>
      ...
    </management>

  • 以下の管理 CLI コマンドは、LdapExtLoginModule を使用してユーザー名とパスワードを検証する PicketBox セキュリティードメインの設定に使用されます。

    例: セキュリティードメイン設定コマンド

    /subsystem=security/security-domain=application-security:add
    /subsystem=security/security-domain=application-security/authentication=classic:add(login-modules=[{code=LdapExtended, flag=Required, module-options={ java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.authentication=simple, bindDN="uid=admin,ou=system", bindCredential=secret, baseCtxDN="ou=users,dc=group-to-principal,dc=wildfly,dc=org", baseFilter="(uid={0})", rolesCtxDN="ou=groups,dc=group-to-principal,dc=wildfly,dc=org", roleFilter="(uniqueMember={1})", roleAttributeID="uid" }}])

    これにより、サーバーが以下のように設定されます。

    例: セキュリティードメイン設定

    <subsystem xmlns="urn:jboss:domain:security:2.0">
      ...
      <security-domains>
        ...
        <security-domain name="application-security">
          <authentication>
            <login-module code="LdapExtended" flag="required">
              <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
              <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
              <module-option name="java.naming.security.authentication" value="simple"/>
              <module-option name="bindDN" value="uid=admin,ou=system"/>
              <module-option name="bindCredential" value="secret"/>
              <module-option name="baseCtxDN" value="ou=users,dc=group-to-principal,dc=wildfly,dc=org"/>
              <module-option name="baseFilter" value="(uid={0})"/>
              <module-option name="rolesCtxDN" value="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
              <module-option name="roleFilter" value="(uniqueMember={1})"/>
              <module-option name="roleAttributeID" value="uid"/>
            </login-module>
          </authentication>
        </security-domain>
      </security-domains>
    </subsystem>

7.3.2.1. レガシー LDAP 認証の Elytron への移行

以下の手順に従って、以前の LDAP 認証の設定例を Elytron に移行します。この項は、レガシーセキュリティー LDAP レルム の移行と PicketBox LDAP セキュリティードメイン の移行が対象になります。

  1. LDAP への接続を elytron サブシステムに定義します。

    /subsystem=elytron/dir-context=ldap-connection:add(url=ldap://localhost:10389, principal="uid=admin, ou=system", credential-reference={clear-text=secret})
  2. セキュリティーレルムを作成し、LDAP の検索およびパスワードの検証を行います。

    /subsystem=elytron/ldap-realm=ldap-realm:add(dir-context=ldap-connection, direct-verification=true, identity-mapping={search-base-dn="ou=users, dc=group-to-principal, dc=wildfly, dc=org", rdn-identifier="uid", attribute-mapping=[{filter-base-dn="ou=groups, dc=group-to-principal, dc=wildfly, dc=org", filter="(uniqueMember={1})", from="uid", to="Roles"}]})

これまでの手順によって、サーバー設定ファイルで elytron サブシステムが次のように設定されます。

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-realms>
    ...
    <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true">
      <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org">
        <attribute-mapping>
          <attribute from="uid" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
        </attribute-mapping>
      </identity-mapping>
    </ldap-realm>
  </security-realms>
  ...
  <dir-contexts>
    <dir-context name="ldap-connection" url="ldap://localhost:10389" principal="uid=admin,ou=system">
      <credential-reference clear-text="secret"/>
    </dir-context>
  </dir-contexts>
</subsystem>
注記

デフォルトでは、security-domain に対して定義された role-decoder がない場合は "Roles" アイデンティティー属性がアイデンティティーロールにマップされます。

これで、LDAP からロードされた情報を属性としてアイデンティティーに関連付けることができるようになりました。これらの属性をロールにマップすることができますが、別の目的でロードおよび使用することもできます。新たに作成されたセキュリティーレルムは、本ガイドの「プロパティーベースの認証および承認の Elytron への移行」に記載されている方法と同様にセキュリティードメインで使用できます。

7.3.3. データベース認証設定の Elytron への移行

ここでは、JDBC データソースベースの PicketBox 認証を Elytron に移行する方法について説明します。特に、セキュリティードメインおよび認証ファクトリーの定義方法と認証のためにこれらをマップする方法に関しては、「プロパティーベースの認証および承認の Elytron への移行」に記載されている多くの情報がここでも適用されます。ここでは、同じ手順は再度説明しないため、『プロパティーベースの認証および承認の Elytron への移行』を読んでから作業を続行してください。

ここで使用する例は、以下の例に似た構文を使用して作成されたデータベーステーブルにユーザー認証情報が格納されることを仮定しています。

例: データベースユーザーテーブルを作成するための構文

CREATE TABLE User (
    id BIGINT NOT NULL,
    username VARCHAR(255),
    password VARCHAR(255),
    role ENUM('admin', 'manager', 'user'),
    PRIMARY KEY (id),
    UNIQUE (username)
)

認証の目的で、ユーザー名は username 列に格納されたデータと照合され、パスワードは 16 進エンコードされた MD5 ハッシュとして password 列に格納されることが想定されます。さらに、承認目的のユーザーロールは role 列に格納されます。

PicketBox セキュリティードメインは、データベーステーブルからデータを取得するために JBDC データソースを使用します。それを使用してユーザー名とパスワードを検証し、ロールを割り当てます。PicketBox セキュリティードメインは以下の管理 CLI コマンドを使用して設定されることを仮定します。

例: PicketBox データベース LoginModule 設定コマンド

/subsystem=security/security-domain=application-security:add
/subsystem=security/security-domain=application-security/authentication=classic:add( login-modules=[ { code=Database, flag=Required, module-options={ dsJndiName="java:jboss/datasources/ExampleDS", principalsQuery="SELECT password FROM User WHERE username = ?", rolesQuery="SELECT role, 'Roles' FROM User WHERE username = ?", hashAlgorithm=MD5, hashEncoding=base64 } } ] )

これにより、レガシー security サブシステムの login-module 設定が次のようになります。

例: PicketBox LoginModule 設定

<subsystem xmlns="urn:jboss:domain:security:2.0">
  <security-domains>
    ...
    <security-domain name="application-security">
      <authentication>
        <login-module code="Database" flag="required">
          <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/>
          <module-option name="principalsQuery" value="SELECT password FROM User WHERE username = ?"/>
          <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM User WHERE username = ?"/>
          <module-option name="hashAlgorithm" value="MD5"/>
          <module-option name="hashEncoding" value="base64"/>
        </login-module>
      </authentication>
    </security-domain>
  </security-domains>
</subsystem>

7.3.3.1. レガシーデータベース認証の Elytron への移行

前述のデータベース認証例の設定を Elytron に移行するには、JDBC レルムを定義して Elytron による JDBC データソース へのアクセスを有効にする必要があります。

以下の管理コマンドを使用して jdbc-realm を定義します。

/subsystem=elytron/jdbc-realm=jdbc-realm:add(principal-query=[ { data-source=ExampleDS, sql="SELECT role, password FROM User WHERE username = ?", attribute-mapping=[{index=1, to=Roles } ] simple-digest-mapper={algorithm=simple-digest-md5, password-index=2} } ] )

これにより、サーバー設定ファイルの elytron サブシステムの jdbc-realm 設定が以下のようになります。

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-realms>
    ...
    <jdbc-realm name="jdbc-realm">
      <principal-query sql="SELECT role, password FROM User WHERE username = ?" data-source="ExampleDS">
        <attribute-mapping>
          <attribute to="Roles" index="1"/>
        </attribute-mapping>
        <simple-digest-mapper password-index="2"/>
      </principal-query>
    </jdbc-realm>
    ...
  </security-realms>
  ...
</subsystem>

これで、Elytron は JDBC レルム設定を使用してデータベース認証を管理するようになります。Elytron は 1 つの SQL クエリーを使用してユーザー属性とクレデンシャルをすべて取得し、SQL の結果からデータを抽出して認証に使用する属性のマッピングを作成するため、Elytron は PicketBox よりも効率がよくなります。

7.3.4. Kerberos 認証の Elytron への移行

Kerberos 設定を使用する場合、JBoss EAP サーバーは環境からの設定情報に依存でき、システムプロパティーを使用してキー設定を指定することも可能です。ここでは、Kerberos HTTP および Kerberos SASL 認証の移行方法を説明します。

ここで使用する例では、以下のシステムプロパティーを使用して Kerberos が設定されたことを仮定します。これらのシステムプロパティーは、レガシー設定と移行された Elytron 設定の両方に適用されます。

例: Kerberos システムプロパティーの管理 CLI コマンド

# Enable debugging
/system-property=sun.security.krb5.debug:add(value=true)
# Identify the Kerberos realm to use
/system-property=java.security.krb5.realm:add(value=ELYTRON.ORG)
# Identify the address of the KDC
/system-property=java.security.krb5.kdc:add(value=kdc.elytron.org)

例: Kerberos システムプロパティーのサーバー設定

<system-properties>
  <property name="sun.security.krb5.debug" value="true"/>
  <property name="java.security.krb5.realm" value="ELYTRON.ORG"/>
  <property name="java.security.krb5.kdc" value="kdc.elytron.org"/>
</system-properties>

以下の移行オプションの 1 つを選択します。

Kerberos HTTP 認証の移行

レガシーのセキュリティー設定では、セキュリティーレルムを定義して以下のように HTTP 管理インターフェースの SPNEGO 認証を有効にできます。

例: HTTP 管理インターフェースの SPNEGO 認証の有効化

/core-service=management/security-realm=Kerberos:add
/core-service=management/security-realm=Kerberos/server-identity=kerberos:add
/core-service=management/security-realm=Kerberos/server-identity=kerberos/keytab=HTTP\/test-server.elytron.org@ELYTRON.ORG:add(path=/path/to/test-server.keytab, debug=true)
/core-service=management/security-realm=Kerberos/authentication=kerberos:add(remove-realm=true)

例: Kerberos セキュリティーレルム設定

<security-realms>
  ...
  <security-realm name="Kerberos">
    <server-identities>
      <kerberos>
        <keytab principal="HTTP/test-server.elytron.org@ELYTRON.ORG" path="/path/to/test-server.keytab" debug="true"/>
      </kerberos>
    </server-identities>
    <authentication>
      <kerberos remove-realm="true"/>
    </authentication>
  </security-realm>
</security-realms>

また、2 つのレガシーセキュリティードメインを定義して、アプリケーションが Kerberos HTTP 認証を使用できるようにすることも可能です。

例: 複数のセキュリティードメインの定義

# Define the first security domain
/subsystem=security/security-domain=host:add
/subsystem=security/security-domain=host/authentication=classic:add
/subsystem=security/security-domain=host/authentication=classic/login-module=1:add(code=Kerberos, flag=Required, module-options={storeKey=true, useKeyTab=true, principal=HTTP/test-server.elytron.org@ELYTRON.ORG, keyTab=path/to/test-server.keytab, debug=true}

# Define the second SPNEGO security domain
/subsystem=security/security-domain=SPNEGO:add
/subsystem=security/security-domain=SPNEGO/authentication=classic:add
/subsystem=security/security-domain=SPNEGO/authentication=classic/login-module=1:add(code=SPNEGO, flag=requisite,  module-options={password-stacking=useFirstPass, serverSecurityDomain=host})
/subsystem=security/security-domain=SPNEGO/authentication=classic/login-module=1:write-attribute(name=module, value=org.jboss.security.negotiation)
/subsystem=security/security-domain=SPNEGO/authentication=classic/login-module=2:add(code=UsersRoles, flag=required, module-options={password-stacking=useFirstPass, usersProperties=  /path/to/kerberos/spnego-users.properties, rolesProperties=  /path/to/kerberos/spnego-roles.properties, defaultUsersProperties=  /path/to/kerberos/spnego-users.properties, defaultRolesProperties=  /path/to/kerberos/spnego-roles.properties})

例: 2 つのセキュリティードメインを使用した設定

<subsystem xmlns="urn:jboss:domain:security:2.0">
  <security-domains>
    ...
    <security-domain name="host">
      <authentication>
        <login-module name="1" code="Kerberos" flag="required">
          <module-option name="storeKey" value="true"/>
          <module-option name="useKeyTab" value="true"/>
          <module-option name="principal" value="HTTP/test-server.elytron.org@ELYTRON.ORG"/>
          <module-option name="keyTab" value="/path/to/test-server.keytab"/>
          <module-option name="debug" value="true"/>
        </login-module>
      </authentication>
    </security-domain>
    <security-domain name="SPNEGO">
      <authentication>
        <login-module name="1" code="SPNEGO" flag="requisite" module="org.jboss.security.negotiation">
          <module-option name="password-stacking" value="useFirstPass"/>
          <module-option name="serverSecurityDomain" value="host"/>
        </login-module>
        <login-module name="2" code="UsersRoles" flag="required">
          <module-option name="password-stacking" value="useFirstPass"/>
          <module-option name="usersProperties" value="path/to/kerberos/spnego-users.properties"/>
          <module-option name="rolesProperties" value="  /path/to/kerberos/spnego-roles.properties"/>
          <module-option name="defaultUsersProperties" value="  /path/to/kerberos/spnego-users.properties"/>
          <module-option name="defaultRolesProperties" value="  /path/to/kerberos/spnego-roles.properties"/>
        </login-module>
      </authentication>
    </security-domain>
  </security-domains>
</subsystem>

セキュリティーアプリケーションは、SPNEGO セキュリティードメインを参照してデプロイされ、SPNEGO によってセキュア化されます。

Kerberos HTTP 認証の Elytron への移行

セキュリティーレルムと Kerberos セキュリティーファクトリーを使用すると、管理インターフェースとアプリケーションの両方をセキュアにすることができます。

  1. アイデンティティー情報のロードに使用するセキュリティーレルムを定義します。

    /subsystem=elytron/properties-realm=spnego-properties:add(users-properties={path=path/to/spnego-users.properties, plain-text=true, digest-realm-name=ELYTRON.ORG}, groups-properties={path=path/to/spnego-roles.properties})
  2. サーバーが独自の Kerberos アイデンティティーをロードできるようにする Kerberos セキュリティーファクトリーを定義します。

    /subsystem=elytron/kerberos-security-factory=test-server:add(path=path/to/test-server.keytab, principal=HTTP/test-server.elytron.org@ELYTRON.ORG, debug=true)
  3. ポリシーと認証ポリシーの HTTP 認証ファクトリーを一緒にプルするためにセキュリティードメインを定義します。

    /subsystem=elytron/security-domain=SPNEGODomain:add(default-realm=spnego-properties, realms=[{realm=spnego-properties, role-decoder=groups-to-roles}], permission-mapper=default-permission-mapper)
    /subsystem=elytron/http-authentication-factory=spnego-http-authentication:add(security-domain=SPNEGODomain, http-server-mechanism-factory=global,mechanism-configurations=[{mechanism-name=SPNEGO, credential-security-factory=test-server}])

    これにより、サーバー設定ファイルの elytron サブシステムの設定が以下のようになります。

    例: 移行された Elytron 設定

    <subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
      ...
      <security-domains>
      ...
        <security-domain name="SPNEGODomain" default-realm="spnego-properties" permission-mapper="default-permission-mapper">
          <realm name="spnego-properties" role-decoder="groups-to-roles"/>
        </security-domain>
      </security-domains>
      <security-realms>
        ...
        <properties-realm name="spnego-properties">
          <users-properties path="path/to/spnego-users.properties" digest-realm-name="ELYTRON.ORG" plain-text="true"/>
          <groups-properties path="path/to/spnego-roles.properties"/>
        </properties-realm>
      </security-realms>
      <credential-security-factories>
        <kerberos-security-factory name="test-server" principal="HTTP/test-server.elytron.org@ELYTRON.ORG" path="path/to/test-server.keytab" debug="true"/>
      </credential-security-factories>
      ...
      <http>
        ...
        <http-authentication-factory name="spnego-http-authentication" http-server-mechanism-factory="global" security-domain="SPNEGODomain">
          <mechanism-configuration>
            <mechanism mechanism-name="SPNEGO" credential-security-factory="test-server"/>
          </mechanism-configuration>
        </http-authentication-factory>
        ...
      </http>
      ...
    </subsystem>

  4. アプリケーションをセキュアにするには、undertow サブシステムのアプリケーションセキュリティードメインを定義し、セキュリティードメインをこの http-authentication-factory にマップします。この設定に定義された http-authentication-factory を参照するように、HTTP 管理インターフェースを更新することができます。この手順については、本書の「プロパティーベースの認証および承認の Elytron への移行」に記載されています。
Kerberos リモーティング SASL 認証

ネイティブ管理インターフェースなど、リモーティング認証に使用される Kerberos / GSSAPI SASL 認証のレガシーセキュリティーレルムを定義することが可能です。

例: リモーティング管理 CLI コマンドの Kerberos 認証

/core-service=management/security-realm=Kerberos:add
/core-service=management/security-realm=Kerberos/server-identity=kerberos:add
/core-service=management/security-realm=Kerberos/server-identity=kerberos/keytab=remote\/test-server.elytron.org@ELYTRON.ORG:add(path=path/to/remote-test-server.keytab, debug=true)
/core-service=management/security-realm=Kerberos/authentication=kerberos:add(remove-realm=true)

例: Kerberos リモーティングセキュリティーレルム設定

<management>
  <security-realms>
    ...
    <security-realm name="Kerberos">
      <server-identities>
        <kerberos>
          <keytab principal="remote/test-server.elytron.org@ELYTRON.ORG" path="path/to/remote-test-server.keytab" debug="true"/>
        </kerberos>
      </server-identities>
      <authentication>
        <kerberos remove-realm="true"/>
      </authentication>
    </security-realm>
  </security-realms>
  ...
</management>

Kerberos リモーティング SASL 認証の Elytronへの移行

同等の Elytron 設定を定義する手順は、「Kerberos HTTP 認証の移行」の手順と大変似ています。

  1. アイデンティティー情報のロードに使用するセキュリティーレルムを定義します。

    /path=kerberos:add(relative-to=user.home, path=src/kerberos)
    /subsystem=elytron/properties-realm=kerberos-properties:add(users-properties={path=kerberos-users.properties, relative-to=kerberos, digest-realm-name=ELYTRON.ORG}, groups-properties={path=kerberos-groups.properties, relative-to=kerberos})
  2. サーバーのアイデンティティーの Kerberos セキュリティーファクトリーを定義します。

    /subsystem=elytron/kerberos-security-factory=test-server:add(relative-to=kerberos, path=remote-test-server.keytab, principal=remote/test-server.elytron.org@ELYTRON.ORG)
  3. セキュリティードメインと SASL 認証ファクトリーを定義します。

    /subsystem=elytron/security-domain=KerberosDomain:add(default-realm=kerberos-properties, realms=[{realm=kerberos-properties, role-decoder=groups-to-roles}], permission-mapper=default-permission-mapper)
    /subsystem=elytron/sasl-authentication-factory=gssapi-authentication-factory:add(security-domain=KerberosDomain, sasl-server-factory=elytron, mechanism-configurations=[{mechanism-name=GSSAPI, credential-security-factory=test-server}])

これにより、サーバー設定ファイルの elytron サブシステムの設定が以下のようになります。

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-domains>
    ...
    <security-domain name="KerberosDomain" default-realm="kerberos-properties" permission-mapper="default-permission-mapper">
      <realm name="kerberos-properties" role-decoder="groups-to-roles"/>
    </security-domain>
  </security-domains>
  <security-realms>
   ...
     <properties-realm name="kerberos-properties">
       <users-properties path="kerberos-users.properties" relative-to="kerberos" digest-realm-name="ELYTRON.ORG"/>
       <groups-properties path="kerberos-groups.properties" relative-to="kerberos"/>
     </properties-realm>
   </security-realms>
   <credential-security-factories>
     <kerberos-security-factory name="test-server" principal="remote/test-server.elytron.org@ELYTRON.ORG" path="remote-test-server.keytab" relative-to="kerberos"/>
   </credential-security-factories>
   ...
   <sasl>
     ...
     <sasl-authentication-factory name="gssapi-authentication-factory" sasl-server-factory="elytron" security-domain="KerberosDomain">
       <mechanism-configuration>
         <mechanism mechanism-name="GSSAPI" credential-security-factory="test-server"/>
       </mechanism-configuration>
     </sasl-authentication-factory>
     ...
   </sasl>
 </subsystem>

これで、管理インターフェースまたはリモーティングコネクターが更新され、SASL 認証ファクトリーを参照するようになりました。

ここで定義された 2 つの Elytron の例は、共有されたセキュリティードメインおよびセキュリティーレルムを使用し、各自が独自の Kerberosセキュリティーファクトリーを参照するプロトコル固有の認証ファクトリーを使用するよう組み合わせることも可能です。

7.3.5. 複合ストアの Elytron への移行

ここでは、PicketBox または 複数のアイデンティティーストアを使用する レガシーセキュリティーレルム設定を移行する方法について説明します。PicketBox またはレガシーセキュリティーレルムを使用する場合、承認に使用される情報を 1 つのアイデンティティーストアからロードしながら別のアイデンティティーストアに対して認証を実行する設定を定義することが可能です。Elytron に移行する場合、集約セキュリティーレルムを使用してこれを実現できます。

以下の例は、example-users.properties プロパティーファイルを使用してユーザー認証を実行し、LDAP をクエリーしてグループおよびロール情報をロードします。

注記

ここで提示されている設定は、追加の背景情報を提供する以下のセクションの例を基にしています。

PicketBox 複合ストア設定

この場合の PicketBox セキュリティードメインは、以下の管理 CLI コマンドを使用して設定されます。

例: PicketBox 設定コマンド

/subsystem=security/security-domain=application-security:add

/subsystem=security/security-domain=application-security/authentication=classic:add(login-modules=[ {code=UsersRoles, flag=Required, module-options={ password-stacking=useFirstPass, usersProperties=file://${jboss.server.config.dir}/example-users.properties}} {code=LdapExtended, flag=Required, module-options={ password-stacking=useFirstPass, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.authentication=simple, bindDN="uid=admin,ou=system", bindCredential=secret, baseCtxDN="ou=users,dc=group-to-principal,dc=wildfly,dc=org", baseFilter="(uid={0})", rolesCtxDN="ou=groups,dc=group-to-principal,dc=wildfly,dc=org",roleFilter="(uniqueMember={1})", roleAttributeID="uid" }}])

これにより、サーバーが以下のように設定されます。

例: PicketBox セキュリティードメイン設定

<security-domain name="application-security">
  <authentication>
    <login-module code="UsersRoles" flag="required">
      <module-option name="password-stacking" value="useFirstPass"/>
      <module-option name="usersProperties" value="file://${jboss.server.config.dir}/example-users.properties"/>
    </login-module>
    <login-module code="LdapExtended" flag="required">
      <module-option name="password-stacking" value="useFirstPass"/>
      <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
      <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
      <module-option name="java.naming.security.authentication" value="simple"/>
      <module-option name="bindDN" value="uid=admin,ou=system"/>
      <module-option name="bindCredential" value="secret"/>
      <module-option name="baseCtxDN" value="ou=users,dc=group-to-principal,dc=wildfly,dc=org"/>
      <module-option name="baseFilter" value="(uid={0})"/>
      <module-option name="rolesCtxDN" value="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
      <module-option name="roleFilter" value="(uniqueMember={1})"/>
      <module-option name="roleAttributeID" value="uid"/>
    </login-module>
  </authentication>
</security-domain>

elytron サブシステムで集約セキュリティーレルムを設定してこれを実現する方法については、Elytron 集約セキュリティーレルム設定 を参照してください。

レガシーセキュリティーレルム複合ストア設定

この場合のレガシーセキュリティーレルム設定は、以下の管理 CLI コマンドを使用して設定されます。

例: レガシーセキュリティーレルム設定コマンド

/core-service=management/ldap-connection=MyLdapConnection:add(url="ldap://localhost:10389", search-dn="uid=admin,ou=system", search-credential="secret")

/core-service=management/security-realm=ApplicationSecurity:add
/core-service=management/security-realm=ApplicationSecurity/authentication=properties:add(path=example-users.properties, relative-to=jboss.server.config.dir, plain-text=true)

batch
/core-service=management/security-realm=ApplicationSecurity/authorization=ldap:add(connection=MyLdapConnection)
/core-service=management/security-realm=ApplicationSecurity/authorization=ldap/username-to-dn=username-filter:add(attribute=uid, base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org")
/core-service=management/security-realm=ApplicationSecurity/authorization=ldap/group-search=group-to-principal:add(base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org", iterative=true, prefer-original-connection=true, principal-attribute=uniqueMember, search-by=DISTINGUISHED_NAME, group-name=SIMPLE, group-name-attribute=uid)
run-batch

これにより、サーバーが以下のように設定されます。

例: レガシーセキュリティーレルム設定

<security-realms>
  ...
  <security-realm name="ApplicationSecurity">
    <authentication>
      <properties path="example-users.properties" relative-to="jboss.server.config.dir" plain-text="true"/>
    </authentication>
    <authorization>
      <ldap connection="MyLdapConnection">
        <username-to-dn>
          <username-filter base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org" attribute="uid"/>
        </username-to-dn>
        <group-search group-name="SIMPLE" iterative="true" group-name-attribute="uid">
          <group-to-principal search-by="DISTINGUISHED_NAME" base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org" prefer-original-connection="true">
            <membership-filter principal-attribute="uniqueMember"/>
          </group-to-principal>
        </group-search>
      </ldap>
    </authorization>
  </security-realm>
</security-realms>
<outbound-connections>
  <ldap name="MyLdapConnection" url="ldap://localhost:10389" search-dn="uid=admin,ou=system" search-credential="secret"/>
</outbound-connections>

elytron サブシステムで集約セキュリティーレルムを設定してこれを実現する方法については、Elytron 集約セキュリティーレルム設定 を参照してください。

Elytron 集約セキュリティーレルム設定

この場合の同等の Elytron 設定は、以下の管理 CLI コマンドを使用して設定されます。

例: Elytron 設定コマンド

/subsystem=elytron/dir-context=ldap-connection:add(url=ldap://localhost:10389, principal="uid=admin,ou=system", credential-reference={clear-text=secret})

/subsystem=elytron/ldap-realm=ldap-realm:add(dir-context=ldap-connection, direct-verification=true, identity-mapping={search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org", rdn-identifier="uid", attribute-mapping=[{filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org",filter="(uniqueMember={1})",from="uid",to="Roles"}]})

/subsystem=elytron/properties-realm=application-properties:add(users-properties={path=example-users.properties, relative-to=jboss.server.config.dir, plain-text=true, digest-realm-name="Application Security"})

/subsystem=elytron/aggregate-realm=combined-realm:add(authentication-realm=application-properties, authorization-realm=ldap-realm)

/subsystem=elytron/security-domain=application-security:add(realms=[{realm=combined-realm}], default-realm=combined-realm, permission-mapper=default-permission-mapper)
/subsystem=elytron/http-authentication-factory=application-security-http:add(http-server-mechanism-factory=global, security-domain=application-security, mechanism-configurations=[{mechanism-name=BASIC}])

これにより、サーバーが以下のように設定されます。

例: Elytron 設定

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-domains>
    ...
    <security-domain name="application-security" default-realm="combined-realm" permission-mapper="default-permission-mapper">
      <realm name="combined-realm"/>
    </security-domain>
  </security-domains>
  <security-realms>
    <aggregate-realm name="combined-realm" authentication-realm="application-properties" authorization-realm="ldap-realm"/>
      ...
      <properties-realm name="application-properties">
        <users-properties path="example-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="Application Security" plain-text="true"/>
      </properties-realm>
      <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true">
        <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org">
          <attribute-mapping>
            <attribute from="uid" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
          </attribute-mapping>
        </identity-mapping>
      </ldap-realm>
  </security-realms>
  ...
  <http>
    ...
    <http-authentication-factory name="application-security-http" http-server-mechanism-factory="global" security-domain="application-security">
      <mechanism-configuration>
        <mechanism mechanism-name="BASIC"/>
      </mechanism-configuration>
    </http-authentication-factory>
    ...
  </http>
  ...
  <dir-contexts>
    <dir-context name="ldap-connection" url="ldap://localhost:10389" principal="uid=admin,ou=system">
      <credential-reference clear-text="secret"/>
    </dir-context>
  </dir-contexts>
</subsystem>

elytron サブシステムでは、認証に使用するセキュリティーレルムと承認の決定に使用するセキュリティーレルムを指定するために aggregate-realm が定義されています。

7.3.6. キャッシングを使用するセキュリティードメインの Elytron への移行

PicketBox を使用する場合、セキュリティードメインを定義し、アクセスのためにインメモリーキャッシングを有効にすることが可能です。これにより、ユーザーはメモリーのアイデンティティーデータにアクセスでき、それ以外ではアイデンティティーストアへ直接アクセスできないようにします。同様の設定を Elytronで実現することができます。ここでは、Elytron 使用時のセキュリティードメインキャッシングの設定方法について説明します。

PicketBox のキャッシュ済みセキュリティードメイン設定

以下のコマンドは、キャッシングを有効にする PicketBox セキュリティードメインの設定方法を表しています。

例: PicketBox のキャッシュ済みセキュリティードメインコマンド

/subsystem=security/security-domain=application-security:add(cache-type=default)
/subsystem=security/security-domain=application-security/authentication=classic:add(login-modules=[{code=LdapExtended, flag=Required, module-options={ java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.authentication=simple, bindDN="uid=admin,ou=system", bindCredential=secret, baseCtxDN="ou=users,dc=group-to-principal,dc=wildfly,dc=org", baseFilter="(uid={0})", rolesCtxDN="ou=groups,dc=group-to-principal,dc=wildfly,dc=org", roleFilter="(uniqueMember={1})", roleAttributeID="uid" }}])

これにより、サーバーが以下のように設定されます。

例: PicketBox のキャッシュ済みセキュリティードメイン設定

<subsystem xmlns="urn:jboss:domain:security:2.0">
  <security-domains>
    ...
    <security-domain name="application-security" cache-type="default">
      <authentication>
        <login-module code="LdapExtended" flag="required">
          <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
          <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
          <module-option name="java.naming.security.authentication" value="simple"/>
          <module-option name="bindDN" value="uid=admin,ou=system"/>
          <module-option name="bindCredential" value="secret"/>
          <module-option name="baseCtxDN" value="ou=users,dc=group-to-principal,dc=wildfly,dc=org"/>
          <module-option name="baseFilter" value="(uid={0})"/>
          <module-option name="rolesCtxDN" value="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
          <module-option name="roleFilter" value="(uniqueMember={1})"/>
          <module-option name="roleAttributeID" value="uid"/>
        </login-module>
      </authentication>
    </security-domain>
  </security-domains>
</subsystem>

注記

このコマンドと設定は、「LDAP 認証設定の Elytron への移行」の例と似ていますが、ここでは cache-type 属性が default の値で定義されます。default キャッシュタイプはインメモリーキャッシュです。PicketBox を使用する場合、infinispancache-type を指定することもできますが、このタイプは Elytron ではサポートされません。

Elytron のキャッシュ済みセキュリティードメイン設定

以下の手順に従って、Elytron の使用時にセキュリティードメインをキャッシュする同様の設定を作成します。

  1. セキュリティーレルムを定義し、キャッシングレルムでセキュリティーレルムをラップします。これにより、キャッシングレルムをセキュリティードメインで使用でき、引き続き認証ファクトリーで使用できます。

    例: Elytron セキュリティーレルム設定コマンド

    /subsystem=elytron/dir-context=ldap-connection:add(url=ldap://localhost:10389, principal="uid=admin,ou=system", credential-reference={clear-text=secret})
    /subsystem=elytron/ldap-realm=ldap-realm:add(dir-context=ldap-connection, direct-verification=true, identity-mapping={search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org", rdn-identifier="uid", attribute-mapping=[{filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org",filter="(uniqueMember={1})",from="uid",to="Roles"}]})
    /subsystem=elytron/caching-realm=cached-ldap:add(realm=ldap-realm)

  2. 前述のステップで定義された cached-ldap レルムを使用するセキュリティードメインと HTTP 認証ファクトリーを定義します。

    例: Elytron セキュリティードメインおよび認証ファクトリー設定コマンド

    /subsystem=elytron/security-domain=application-security:add(realms=[{realm=cached-ldap}], default-realm=cached-ldap, permission-mapper=default-permission-mapper)
    /subsystem=elytron/http-authentication-factory=application-security-http:add(http-server-mechanism-factory=global, security-domain=application-security, mechanism-configurations=[{mechanism-name=BASIC}])

    注記

    このステップでは、元のレルムではなくcaching-realm を参照することが重要になります。そうでないとキャッシングは迂回されます。

これらのコマンドにより、サーバー設定に以下が追加されます。

例: Elytron のキャッシュ済みセキュリティードメイン設定

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-domains>
    ...
    <security-domain name="application-security" default-realm="cached-ldap" permission-mapper="default-permission-mapper">
      <realm name="cached-ldap"/>
    </security-domain>
  </security-domains>
  ...
  <security-realms>
    ....
  <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true">
      <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org">
        <attribute-mapping>
          <attribute from="uid" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
        </attribute-mapping>
      </identity-mapping>
    </ldap-realm>
    <caching-realm name="cached-ldap" realm="ldap-realm"/>
  </security-realms>
  ...
  <http>
    ...
    <http-authentication-factory name="application-security-http" http-server-mechanism-factory="global" security-domain="application-security">
      <mechanism-configuration>
        <mechanism mechanism-name="BASIC"/>
      </mechanism-configuration>
    </http-authentication-factory>
    ...
  </http>
   ...
  <dir-contexts>
    <dir-context name="ldap-connection" url="ldap://localhost:10389" principal="uid=admin,ou=system">
      <credential-reference clear-text="secret"/>
    </dir-context>
  </dir-contexts>
  ...

7.3.7. JACC セキュリティーの Elytron への移行

JBoss EAP はデフォルトではレガシー security サブシステムを使用して、JACC (Java Authorization Contract for Containers) ポリシープロバイダーおよびファクトリーを設定します。デフォルト設定は PicketBox から実装へマップします。

elytron サブシステムは、JACC 仕様を基に組み込みのポリシープロバイダーを提供します。サーバーを設定して Elytron が JACC 設定およびその他のポリシーを管理できるようにする前に、以下の管理 CLIコマンドを使用して最初にレガシー security サブシステムの JACC を無効にする必要があります。

/subsystem=security:write-attribute(name=initialize-jacc, value=false)

この作業を怠ると、次のエラーメッセージがサーバーログに出力されます: MSC000004: Failure during stop of service org.wildfly.security.policy: java.lang.StackOverflowError

JACC を有効にする方法や、elytron サブシステムで JACC ポリシープロバイダーを定義する方法に関する詳細は、JBoss EAP『開発ガイド』の「elytron サブシステムを使用した JACC の有効化」を参照してください。

7.4. アプリケーションクライアントの移行

7.4.1. ネーミングクライアント設定の Elytron への移行

ここでは、org.jboss.naming.remote.client.InitialContextFactory クラスによってバックされる org.jboss.naming.remote.client.InitialContext クラスを使用してリモート JNDI ルックアップを実行するクライアントアプリケーションを Elytron に移行する方法について説明します。

以下の例は、ユーザークレデンシャルのプロパティーおよび接続するネーミングプロバイダーの URL のプロパティーを指定して InitialContextFactory クラスが作成されることを仮定します。

例: 以前のリリースで使用された InitialContext コード

Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
properties.put(Context.PROVIDER_URL,"http-remoting://127.0.0.1:8080");
properties.put(Context.SECURITY_PRINCIPAL, "bob");
properties.put(Context.SECURITY_CREDENTIALS, "secret");
InitialContext context = new InitialContext(properties);
Bar bar = (Bar) context.lookup("foo/bar");
...

以下の移行方法の 1 つを選択できます。

7.4.1.1. 設定ファイルを使用したネーミングクライアントの移行

以下の手順に従って、設定ファイルを使用してネーミングクライアントを Elytron に移行します。

  1. クライアントアプリケーションの META-INF/ ディレクトリーに wildfly-config.xml ファイルを作成します。このファイルには、ネーミングプロバイダーへの接続を確立するときに使用されるユーザークレデンシャルが含まれるようにします。

    例: wildfly-config.xml ファイル

    <configuration>
      <authentication-client xmlns="urn:elytron:1.0.1">
        <authentication-rules>
          <rule use-configuration="namingConfig">
            <match-host name="127.0.0.1"/>
          </rule>
        </authentication-rules>
        <authentication-configurations>
          <configuration name="namingConfig">
            <set-user-name name="bob"/>
            <credentials>
              <clear-password password="secret"/>
            </credentials>
          </configuration>
        </authentication-configurations>
      </authentication-client>
    </configuration>

  2. 以下の例のように InitialContext を作成します。InitialContextorg.wildfly.naming.client.WildFlyInitialContextFactory クラスにバックされることに注意してください。

    例: InitialContext コード

    Properties properties = new Properties();
    properties.put(Context.INITIAL_CONTEXT_FACTORY,"org.wildfly.naming.client.WildFlyInitialContextFactory");
    properties.put(Context.PROVIDER_URL,"remote+http://127.0.0.1:8080");
    InitialContext context = new InitialContext(properties);
    Bar bar = (Bar) context.lookup("foo/bar");
    ...

7.4.1.2. プログラミングを使用したネーミングクライアントの移行

この方法では、ネーミングプロバイダーへ接続を確立するために使用されるユーザークレデンシャルを直接アプリケーションコードに提供します。

例: プログラミングを使用したコード

// Create the authentication configuration
AuthenticationConfiguration namingConfig = AuthenticationConfiguration.empty().useName("bob").usePassword("secret");

// Create the authentication context
AuthenticationContext context = AuthenticationContext.empty().with(MatchRule.ALL.matchHost("127.0.0.1"), namingConfig);

// Create a callable that creates and uses an InitialContext
Callable<Void> callable = () -> {
    Properties properties = new Properties();
    properties.put(Context.INITIAL_CONTEXT_FACTORY,"org.wildfly.naming.client.WildFlyInitialContextFactory");
    properties.put(Context.PROVIDER_URL,"remote+http://127.0.0.1:8080");
    InitialContext context = new InitialContext(properties);
    Bar bar = (Bar) context.lookup("foo/bar");
    ...
    return null;
};

// Use the authentication context to run the callable
context.runCallable(callable);

7.4.2. EJB クライアントの Elytron への移行

この移行例は、jboss-ejb-client.properties ファイルを使用してリモートサーバーにデプロイされた EJB を呼び出すようクライアントアプリケーションが設定されていることを仮定します。クライアントアプリケーションの META-INF/ ディレクトリーにあるこのファイルには、リモートサーバーへの接続に必要な以下の情報が含まれています。

例: jboss-ejb-client.properties ファイル

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=127.0.0.1
remote.connection.default.port = 8080
remote.connection.default.username=bob
remote.connection.default.password=secret

クライアントは以下の例と似たコードを使用して EJB を検索し、メソッドの 1 つを呼び出します。

例: リモート EJB を呼び出すクライアントコード

// Create an InitialContext
Properties properties = new Properties();
properties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
InitialContext context = new InitialContext(properties);

// Look up the EJB and invoke one of its methods
RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup(
    "ejb:/ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName());
int sum = statelessRemoteCalculator.add(101, 202);

以下の移行方法の 1 つを選択できます。

7.4.2.1. 設定ファイルを使用した EJB クライアントの移行

以下の手順に従って、設定ファイルを使用してネーミングクライアントを Elytron に移行します。

  1. クライアントアプリケーションの META-INF/ ディレクトリーで wildfly-config.xml ファイルを設定します。このファイルには、ネーミングプロバイダーへの接続を確立するときに使用されるユーザークレデンシャルが含まれるようにします。

    例: wildfly-config.xml ファイル

    <configuration>
      <authentication-client xmlns="urn:elytron:1.0.1">
        <authentication-rules>
          <rule use-configuration="ejbConfig">
            <match-host name="127.0.0.1"/>
          </rule>
        </authentication-rules>
        <authentication-configurations>
          <configuration name="ejbConfig">
            <set-user-name name="bob"/>
            <credentials>
              <clear-password password="secret"/>
            </credentials>
          </configuration>
        </authentication-configurations>
      </authentication-client>
      <jboss-ejb-client xmlns="urn:jboss:wildfly-client-ejb:3.0">
        <connections>
          <connection uri="remote+http://127.0.0.1:8080" />
        </connections>
      </jboss-ejb-client>
    </configuration>

  2. 以下の例のように InitialContext を作成します。InitialContextorg.wildfly.naming.client.WildFlyInitialContextFactory クラスにバックされることに注意してください。

    例: InitialContext コード

    // Create an InitialContext
    Properties properties = new Properties();
    properties.put(Context.INITIAL_CONTEXT_FACTORY,"org.wildfly.naming.client.WildFlyInitialContextFactory");
    InitialContext context = new InitialContext(properties);
    
    // Look up an EJB and invoke one of its methods
    // Note that this code is the same as before
    RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup(
        "ejb:/ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName());
    int sum = statelessRemoteCalculator.add(101, 202);----

  3. 廃止された jboss-ejb-client.properties ファイルは必要がないため、削除できます。

7.4.2.2. プログラミングを使用した EJB クライアントの移行

この方法では、リモートサーバーへの接続に必要な情報を直接アプリケーションコードに提供します。

例: プログラミングを使用したコード

// Create the authentication configuration
AuthenticationConfiguration ejbConfig = AuthenticationConfiguration.empty().useName("bob").usePassword("secret");

// Create the authentication context
AuthenticationContext context = AuthenticationContext.empty().with(MatchRule.ALL.matchHost("127.0.0.1"), ejbConfig);

// Create a callable that invokes the EJB
Callable<Void> callable = () -> {

    // Create an InitialContext
    Properties properties = new Properties();
    properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
    properties.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080");
    InitialContext context = new InitialContext(properties);

    // Look up the EJB and invoke one of its methods
    // Note that this code is the same as before
    RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup(
        "ejb:/ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName());
    int sum = statelessRemoteCalculator.add(101, 202);
    ...
    return null;
};

// Use the authentication context to run the callable
context.runCallable(callable);

廃止された jboss-ejb-client.properties ファイルは必要がないため、削除できます。

7.5. SSL 設定の移行

7.5.1. 簡単な SSL 設定の Elytron への移行

セキュリティーレルムを使用して JBoss EAP サーバーへの HTTP 接続をセキュアにした場合、本セクションの情報を使用してその設定を Elytron に移行できます。

ここで使用する例は、以下の keystoresecurity-realm に設定されていることを仮定します。

例: セキュリティーレルムキーストアを使用した SSL 設定

<security-realm name="ApplicationRealm">
  <server-identities>
    <ssl>
      <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="keystore_password" alias="server" key-password="key_password" />
    </ssl>
  </server-identities>
</security-realm>

以下の手順に従って、Elytron を使用して同じ設定を実現します。

  1. キーストアと暗号化されたパスワードの場所を指定する key-storeelytron サブシステムに設定します。このコマンドは、keytool コマンドを使用してキーストアが生成され、そのタイプが JKS であることを仮定しています。

    /subsystem=elytron/key-store=LocalhostKeyStore:add(path=server.keystore,relative-to=jboss.server.config.dir,credential-reference={clear-text="keystore_password"},type=JKS)
  2. 前のステップで定義された key-store、エイリアス、およびキーのパスワードを指定する key-managerelytron サブシステムに作成します。

    /subsystem=elytron/key-manager=LocalhostKeyManager:add(key-store=LocalhostKeyStore,alias-filter=server,credential-reference={clear-text="key_password"})
  3. 前のステップで定義した key-manager を参照する server-ssl-contextelytron サブシステムに作成します。

    /subsystem=elytron/server-ssl-context=LocalhostSslContext:add(key-manager=LocalhostKeyManager)
  4. https-listener をレガシー security-realm から新規作成された Elytron ssl-context に切り替えます。

    batch
    /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
    /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=LocalhostSslContext)
    run-batch
  5. サーバーをリロードします。

    reload

これにより、サーバー設定ファイルの elytron サブシステム設定が以下のようになります。

<subsystem xmlns="urn:wildfly:elytron:1.2" ...>
  ...
  <tls>
    <key-stores>
      <key-store name="LocalhostKeyStore">
        <credential-reference clear-text="keystore_password"/>
        <implementation type="JKS"/>
        <file path="server.keystore" relative-to="jboss.server.config.dir"/>
      </key-store>
    </key-stores>
    <key-managers>
      <key-manager name="LocalhostKeyManager" key-store="LocalhostKeyStore"  alias-filter="server">
        <credential-reference clear-text="key_password"/>
      </key-manager>
    </key-managers>
    <server-ssl-contexts>
      <server-ssl-context name="LocalhostSslContext" key-manager="LocalhostKeyManager"/>
    </server-ssl-contexts>
  </tls>
</subsystem>

これにより、サーバー設定ファイルの undertow サブシステム設定が以下のようになります。

<https-listener name="https" socket-binding="https" ssl-context="LocalhostSslContext" enable-http2="true"/>

詳細は、『How to Configure Server Security』の 「Elytron Subsystem」および「How to Secure the Management Interfaces」を参照してください。

7.5.2. Client-Cert SSL 認証の Elytron への移行

セキュリティーレルムトラストストアを使用して Client-Cert SSL 認証を設定した場合、本セクションの情報を使用してその設定を Elytron に移行できます。

ここで説明する手順では、以下の truststoresecurity-realm に設定されていると仮定します。

例: セキュリティーレルムトラストストアを使用した SSL 設定

<security-realm name="ApplicationRealm">
  <server-identities>
    <ssl>
      <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="keystore_password" alias="server" key-password="key_password" />
    </ssl>
  </server-identities>
  <authentication>
    <truststore path="server.truststore" relative-to="jboss.server.config.dir" keystore-password="truststore_password" />
    <local default-user="$local"/>
    <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>

重要

ここで説明する手順では、有効な証明書およびプライベートキーを持たないユーザーがサーバーにアクセスできないようにする設定のみを提供します。ユーザーアイデンティティーを設定してサーバーに対する認証を行いません。ユーザーアイデンティティーの認証のために CLIENT-CERT HTTP 認証と外部 SASL 認証がすでに設定されていると仮定します。

以下の手順に従って、有効な証明書とプライベートキーを持たないユーザーが Elytron を使用してサーバーにアクセスしないようにサーバーを設定します。

  1. キーストアと暗号化されたパスワードの場所を指定する key-storeelytron サブシステムに設定します。このコマンドは、keytool コマンドを使用してキーストアが生成され、そのタイプが JKS であることを仮定しています。

    /subsystem=elytron/key-store=LocalhostKeyStore:add(path=server.keystore,relative-to=jboss.server.config.dir,credential-reference={clear-text="keystore_password"},type=JKS)
  2. トラストストアと暗号化されたパスワードの場所を指定する key-storeelytron サブシステムに設定します。このコマンドは、keytool コマンドを使用してキーストアが生成され、そのタイプが JKS であることを仮定しています。

    /subsystem=elytron/key-store=TrustStore:add(path=server.truststore,relative-to=jboss.server.config.dir,credential-reference={clear-text="truststore_password"},type=JKS)
  3. 前のステップで定義された LocalhostKeyStore キーストア、エイリアス、およびキーのパスワードを指定する key-managerelytron サブシステムに作成します。

    /subsystem=elytron/key-manager=LocalhostKeyManager:add(key-store=LocalhostKeyStore,alias-filter=server,credential-reference={clear-text="key_password"})
  4. 前のステップで作成されたトラストストアの key-store を指定する trust-managerelytron サブシステムに作成します。

    /subsystem=elytron/trust-manager=TrustManager:add(key-store=TrustStore)
  5. 前のステップで定義した key-manager の参照、trust-manager 属性の設定、およびクライアント認証の有効化を行う server-ssl-contextelytron サブシステムに作成します。

    /subsystem=elytron/server-ssl-context=LocalhostSslContext:add(key-manager=LocalhostKeyManager,trust-manager=TrustManager,need-client-auth=true)
  6. https-listener をレガシー security-realm から新規作成された Elytron ssl-context に切り替えます。

    batch
    /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
    /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=LocalhostSslContext)
    run-batch
  7. サーバーをリロードします。

    reload

これにより、サーバー設定ファイルの elytron サブシステム設定が以下のようになります。

<subsystem xmlns="urn:wildfly:elytron:1.2" ...>
  ...
  <tls>
    <key-stores>
      <key-store name="LocalhostKeyStore">
        <credential-reference clear-text="keystore_password"/>
        <implementation type="JKS"/>
        <file path="server.keystore" relative-to="jboss.server.config.dir"/>
      </key-store>
      <key-store name="TrustStore">
        <credential-reference clear-text="truststore_password"/>
        <implementation type="JKS"/>
        <file path="server.truststore" relative-to="jboss.server.config.dir"/>
      </key-store>
    </key-stores>
    <key-managers>
      <key-manager name="LocalhostKeyManager" key-store="LocalhostKeyStore" alias-filter="server">
        <credential-reference clear-text="key_password"/>
      </key-manager>
    </key-managers>
    <trust-managers>
      <trust-manager name="TrustManager" key-store="TrustStore"/>
    </trust-managers>
    <server-ssl-contexts>
      <server-ssl-context name="LocalhostSslContext" need-client-auth="true" key-manager="LocalhostKeyManager" trust-manager="TrustManager"/>
    </server-ssl-contexts>
  </tls>
</subsystem>

これにより、サーバー設定ファイルの undertow サブシステム設定が以下のようになります。

<https-listener name="https" socket-binding="https" ssl-context="LocalhostSslContext" enable-http2="true"/>

詳細は、JBoss EAP『How to Configure Server Security』の 「Elytron Subsystem」および 「Using a client-ssl-context」を参照してください。