第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.
- If you have a Red Hat Development subscription, you have access to Support Cases, Solutions, and Knowledge Articles on the Red Hat Customer Portal. You can also open a case with Technical Support and get help from the WildFly community as described below.
- If you do not have a Red Hat Development subscription, you can still access Knowledge Articles on the Red Hat Customer Portal. You can also join the user forums and live chat to ask questions of the WildFly community. The WildFly community offerings are actively monitored by the Elytron engineering team.
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:
行ごとに変換が新たに開始されます。salt
、iteration
、および 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 セキュリティーレルムとして追加します。
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>
エクスポートされたセキュリティーレルムを参照する
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>
デプロイメントによって参照されるセキュリティードメインを、
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>
- この設定の指定前にアプリケーションがデプロイされた場合、新しいアプリケーションセキュリティードメインマッピングを有効にするにはサーバーのリロードまたはアプリケーションの再デプロイが必要になります。
以下の管理 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 設定から完全に独立した状態を維持します。
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)
セキュリティードメインサブシステムと 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>
デプロイメントによって参照されるアプリケーションセキュリティードメインを、
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>
- 新しいアプリケーションセキュリティードメインマッピングを有効にするには、サーバーのリロードまたはアプリケーションの再デプロイが必要になります。
これで、認証が 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 に移行します。
プロパティーファイルを参照する新しいレルムを
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)
セキュリティードメインサブシステムと 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>
レガシーセキュリティーレルムが 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>
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>
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 セキュリティードメイン の移行が対象になります。
LDAP への接続を
elytron
サブシステムに定義します。/subsystem=elytron/dir-context=ldap-connection:add(url=ldap://localhost:10389, principal="uid=admin, ou=system", credential-reference={clear-text=secret})
セキュリティーレルムを作成し、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 セキュリティーファクトリーを使用すると、管理インターフェースとアプリケーションの両方をセキュアにすることができます。
アイデンティティー情報のロードに使用するセキュリティーレルムを定義します。
/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})
サーバーが独自の 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)
ポリシーと認証ポリシーの 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>
-
アプリケーションをセキュアにするには、
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 認証の移行」の手順と大変似ています。
アイデンティティー情報のロードに使用するセキュリティーレルムを定義します。
/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})
サーバーのアイデンティティーの 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)
セキュリティードメインと 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 を使用する場合、infinispan
の cache-type
を指定することもできますが、このタイプは Elytron ではサポートされません。
Elytron のキャッシュ済みセキュリティードメイン設定
以下の手順に従って、Elytron の使用時にセキュリティードメインをキャッシュする同様の設定を作成します。
セキュリティーレルムを定義し、キャッシングレルムでセキュリティーレルムをラップします。これにより、キャッシングレルムをセキュリティードメインで使用でき、引き続き認証ファクトリーで使用できます。
例: 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)
前述のステップで定義された
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 に移行します。
クライアントアプリケーションの
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>
以下の例のように
InitialContext
を作成します。InitialContext
はorg.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 に移行します。
クライアントアプリケーションの
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>
以下の例のように
InitialContext
を作成します。InitialContext
はorg.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);----
-
廃止された
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 に移行できます。
ここで使用する例は、以下の keystore
が security-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 を使用して同じ設定を実現します。
キーストアと暗号化されたパスワードの場所を指定する
key-store
をelytron
サブシステムに設定します。このコマンドは、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)
前のステップで定義された
key-store
、エイリアス、およびキーのパスワードを指定するkey-manager
をelytron
サブシステムに作成します。/subsystem=elytron/key-manager=LocalhostKeyManager:add(key-store=LocalhostKeyStore,alias-filter=server,credential-reference={clear-text="key_password"})
前のステップで定義した
key-manager
を参照するserver-ssl-context
をelytron
サブシステムに作成します。/subsystem=elytron/server-ssl-context=LocalhostSslContext:add(key-manager=LocalhostKeyManager)
https-listener
をレガシーsecurity-realm
から新規作成された Elytronssl-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
サーバーをリロードします。
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 に移行できます。
ここで説明する手順では、以下の truststore
が security-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 を使用してサーバーにアクセスしないようにサーバーを設定します。
キーストアと暗号化されたパスワードの場所を指定する
key-store
をelytron
サブシステムに設定します。このコマンドは、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)
トラストストアと暗号化されたパスワードの場所を指定する
key-store
をelytron
サブシステムに設定します。このコマンドは、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)
前のステップで定義された
LocalhostKeyStore
キーストア、エイリアス、およびキーのパスワードを指定するkey-manager
をelytron
サブシステムに作成します。/subsystem=elytron/key-manager=LocalhostKeyManager:add(key-store=LocalhostKeyStore,alias-filter=server,credential-reference={clear-text="key_password"})
前のステップで作成されたトラストストアの
key-store
を指定するtrust-manager
をelytron
サブシステムに作成します。/subsystem=elytron/trust-manager=TrustManager:add(key-store=TrustStore)
前のステップで定義した
key-manager
の参照、trust-manager
属性の設定、およびクライアント認証の有効化を行うserver-ssl-context
をelytron
サブシステムに作成します。/subsystem=elytron/server-ssl-context=LocalhostSslContext:add(key-manager=LocalhostKeyManager,trust-manager=TrustManager,need-client-auth=true)
https-listener
をレガシーsecurity-realm
から新規作成された Elytronssl-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
サーバーをリロードします。
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」を参照してください。