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
サブシステムのセキュリティードメインを定義します。/subsystem=elytron/security-domain=application-security:add(realms=[{realm=application-security}], default-realm=application-security, permission-mapper=default-permission-mapper)
これにより、サーバー設定ファイルの
elytron
サブシステム設定が以下のようになります。<subsystem xmlns="urn:wildfly:elytron:4.0" 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> ... </subsystem>
undertow
サブシステムにて、デプロイメントによって参照されるアプリケーションセキュリティードメインを新たに定義されたセキュリティードメインにマップします。/subsystem=undertow/application-security-domain=application-security:add(security-domain=application-security)
これにより、サーバー設定ファイルの
undertow
サブシステム設定が以下のようになります。<subsystem xmlns="urn:wildfly:elytron:4.0"> ... <application-security-domains> <application-security-domain name="application-security" security-domain="application-security"/> </application-security-domains> ... </subsystem>
注記- この設定の指定前にアプリケーションがデプロイされた場合、新しいアプリケーションセキュリティードメインマッピングを有効にするにはサーバーのリロードまたはアプリケーションの再デプロイが必要になります。
- 現在の Web サービス/Elytron 統合では、Web サービスエンドポイントと Elytron セキュリティードメイン名をセキュアにするために指定されたセキュリティードメインの名前が同じである必要があります。
以下の管理 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" => undefined, "override-deployment-config" => false, "referencing-deployments" => ["HelloWorld.war"], "security-domain" => "application-security", "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)
elytron
サブシステムでセキュリティードメインサブシステムを定義します。/subsystem=elytron/security-domain=application-security:add(realms=[{realm=application-properties}], default-realm=application-properties, permission-mapper=default-permission-mapper)
これにより、サーバー設定ファイルの
elytron
サブシステム設定が以下のようになります。<subsystem xmlns="urn:wildfly:elytron:4.0" 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> ... </subsystem>
デプロイメントによって参照されるアプリケーションセキュリティードメインを、
undertow
サブシステムの新たに定義された HTTP 認証ファクトリーにマップします。/subsystem=undertow/application-security-domain=application-security:add(security-domain=application-security)
これにより、サーバー設定ファイルの
undertow
サブシステム設定が以下のようになります。<subsystem xmlns="urn:jboss:domain:undertow:10.0"> ... <application-security-domains> <application-security-domain name="application-security" security-domain="application-security"/> </application-security-domains> ... </subsystem>
注記現在の Web サービス/Elytron 統合では、Web サービスエンドポイントと Elytron セキュリティードメイン名をセキュアにするために指定されたセキュリティードメインの名前が同じである必要があります。
- 新しいアプリケーションセキュリティードメインマッピングを有効にするには、サーバーのリロードまたはアプリケーションの再デプロイが必要になります。
これで、認証が 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)
elytron
サブシステムでセキュリティードメインサブシステムを定義します。/subsystem=elytron/security-domain=application-security:add(realms=[{realm=application-properties}], default-realm=application-properties, permission-mapper=default-permission-mapper)
これにより、Elytron が以下のように設定されます。
<subsystem xmlns="urn:wildfly:elytron:4.0" 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> ... </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:4.0" 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. filesystem-realm コマンドを使用したファイルシステムベースのセキュリティーレルムへの移行
本項では、elytron.sh
ツールの filesystem-realm
コマンドを使用して、レガシープロパティーベースのセキュリティーレルムを Elytron のファイルシステムベースのレルムに移行する方法について説明します。
ファイルシステムベースのレルムは、ユーザー ID を保存するための、Elytron で使用されるファイルシステムベースのアイデンティティーストアです。filesystem-realm
コマンドは、properties-realm
ファイルを filesystem-realm
に変換します。また、このレリムとセキュリティードメインを elytron
サブシステムに追加するためのコマンドも生成します。
プロパティーベースの認証をファイルシステムベースの認証に移行する手順は次のとおりです。
プロパティーファイルを移行します。
一度に 1 つずつ user-properties ファイルを移行することも、プロパティーファイルを一括で移行することもできます。以下の例は、両方のタイプの移行の手順を示しています。
単一のプロパティーファイルを移行します。
次の例は、関連付けられた roles-properties ファイルとともに単一の users-properties ファイルを
filesystem-realm
変換します。この例では、レガシーセキュリティードメインに user-properties および role-properties ファイルがあることを前提としています。example-users.properties example-roles.properties
例: 単一の user-property ファイルの移行
$./bin/elytron-tool.sh filesystem-realm --users-file example-users.properties --roles-file example-roles.properties --output-location realms/example
これにより、filesystem-realm ファイルと管理 CLI コマンドを含むスクリプトが作成されます。このスクリプトは realms/example ディレクトリーに保存されます。
複数のプロパティーファイルの移行
次の例は、関連付けられた roles-properties ファイルとともに users-properties ファイルを一括で
filesystem-realm
に変換します。この例では、レガシーセキュリティードメインに以下のプロパティーファイルがあることを前提としています。users-1.properties users-2.properties roles-1.properties roles-2.properties
一括で users-roles ファイルを変換するには、
filesystem-realm
コマンドで使用する記述子ファイルを作成する必要があります。この例では、/bin
ディレクトリーにある記述子ファイルexample-descriptor-file
が以下の内容で作成されます。例: 記述子ファイル
users-file:/full/path/to/users-1.properties roles-file:/full/path/to/roles-1.properties output-location:./realms/bulk-1-example filesystem-realm-name:exampleFileSystemRealm1 security-domain-name:exampleSecurityDomain1 users-file:/full/path/to/users-2.properties roles-file:/full/path/to/roles-2.properties output-location:./realms/bulk-2-example filesystem-realm-name:exampleFileSystemRealm2 security-domain-name:exampleSecurityDomain2
記述子ファイルの空白行は、各 users-properties ファイルの操作を分けするために使用されます。
次の例では、記述子ファイルを使用して、割り当てられた roles-properties ファイルとともに、2 つのユーザープロパティーファイルを
filesystem-realm
に変換します。例: 一括移行
$./bin/elytron-tool.sh filesystem-realm --bulk-convert example-descriptor-file
これにより、
filesystem-realm
ファイルおよび管理 CLI コマンドが含まれるスクリプトが作成されます。このスクリプトは、記述子ファイルのoutput-location
属性で指定されたディレクトリーに保存されます。
ファイルシステムセキュリティーレルムを Elytron に追加します。
ファイルの移行後に、Elytron ツールで生成された CLI コマンドを使用して新しいセキュリティーレルムとセキュリティードメインを
elytron
サブシステムに追加します。例: filesystem-realm の追加
/subsystem=elytron/filesystem-realm=converted-properties-filesystem-realm:add(path=/full/path/to/realms/example) /subsystem=elytron/security-domain=converted-properties-security-domain:add(realms=[{realm=converted-properties-filesystem-realm}],default-realm=converted-properties-filesystem-realm,permission-mapper=default-permission-mapper)
7.3.3. 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.3.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:4.0" 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.4. データベース認証設定の 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.4.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:4.0" 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.5. 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:4.0" 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:4.0" 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.6. 複合ストアの Elytron への移行
ここでは、PicketBox または 複数のアイデンティティーストアを使用する レガシーセキュリティーレルム 設定を Elytron に移行する方法について説明します。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:4.0" 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.7. キャッシングを使用するセキュリティードメインの 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:4.0" 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.8. 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 の有効化
を参照してください。