主页
产品
Red Hat JBoss Enterprise Application Platform
8.0
迁移指南
9.3. 迁移身份验证配置

9.3. 迁移身份验证配置

本节提供有关将基于属性的身份验证和授权迁移到 Elytron 的信息。此外，还包括将 LDAP 身份验证配置、kerberos 身份验证配置、kerberos 身份验证、复合存储、JACC 安全性和使用缓存到 Elytron 的安全域的信息。

9.3.1. 将基于 PicketBox Properties 的配置迁移到 Elytron
复制链接

使用以下示例，将基于 PicketBox 属性的身份验证迁移到 Elytron。

示例：基于 PicketBox Properties 的配置命令

/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 Properties 的安全域配置

<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>

9.3.1.1. 将基于属性的身份验证迁移到 Elytron
复制链接

按照以下步骤将基于 PicketBox 属性的身份验证迁移到 Elytron。

前提条件

您计划迁移的部署的 Web 应用程序必须配置为需要基于表单的身份验证。应用程序正在引用 PicketBox 安全域，并使用 UsersRolesLoginModule 从 example-users.properties 和 example-roles.properties 文件中加载用户信息。此流程还假设安全域在传统的 security 子系统中使用以下管理 CLI 命令定义。

确保您从基于 PicketBox 属性的身份验证开始。

流程

在 elytron 子系统中定义引用 PicketBox 属性文件的新安全域。

/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:12.0">
  ...
  <application-security-domains>
    <application-security-domain name="application-security" security-domain="application-security"/>
  </application-security-domains>
  ...
</subsystem>

您必须重新加载服务器或重新部署应用程序，以便新的应用程序安全域映射生效。

身份验证现在配置为等同于 PicketBox 配置。

9.3.2. 将基于旧安全域的属性配置迁移到 Elytron
复制链接

这部分论述了如何在 JBoss EAP 7.4 及更早版本中将用户、密码和组信息从属性文件加载到 Elytron 的传统安全域。这种类型的传统安全域通常用于保护管理接口或远程连接器。

在 JBoss EAP 8.0 中，filesystem-realm 优先于 properties-realm。

先决条件

示例：传统的安全 Realm 命令

/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)

这会生成以下服务器配置。

示例：传统安全 Realm 配置

<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 安全性的原因之一是允许跨服务器使用一致的安全解决方案。将基于属性的传统安全域迁移到 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-authentication-factory，以便传统安全域也可以用于简单身份验证安全层(SASL)身份验证。

/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 身份验证配置 remoting connector，并删除与传统安全域的关联。

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

这会在服务器配置文件的 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>

添加两个身份验证工厂，以使用 Elytron 保护 http-interface。

/subsystem=elytron/http-authentication-factory=application-security-http:add(http-server-mechanism-factory=global, security-domain=application-security, mechanism-configurations=[{mechanism-name=BASIC}])
/core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=application-security-sasl)

这会生成以下配置。

<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。

9.3.3. 使用 filesystem-realm 命令迁移到基于文件系统的安全 Realm
复制链接

使用 elytron.sh 工具的 filesystem-realm 命令将基于文件系统的安全域迁移到 Elytron 中的基于文件系统的域。

基于文件系统的域是 Elytron 用于存储用户身份的基于文件系统的身份存储。filesystem-realm 命令将 properties-realm 文件转换为 filesystem-realm。它还生成将这个域和安全域添加到 elytron 子系统的命令。

流程

迁移属性文件。
您可以一次迁移单个 user-properties 文件，或者批量迁移属性文件。以下示例演示了两种类型的迁移的步骤。
- 要迁移单个属性文件，请执行以下操作：
  以下示例将具有关联 roles-properties 文件的单个 users-properties 文件转换为 filesystem-realm。示例假定旧的安全域具有以下 user-properties 和 role-properties 文件：
  example-users.properties example-roles.properties
  示例： Single 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 文件的用户/操作文件转换为 filesystem-realm。示例假定旧的安全域具有以下属性文件：
  users-1.properties users-2.properties roles-1.properties roles-2.properties
  要批量转换用户角色文件，必须创建一个描述符文件，以便与 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 文件的 users-properties 文件转换为 filesystem-realm。
  示例：模拟迁移
  $./bin/elytron-tool.sh filesystem-realm --bulk-convert example-descriptor-file
  这将创建 filesystem-realm 文件和包含管理 CLI 命令的脚本。脚本存储在描述符文件 output-location 属性中指定的目录中。

使用 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)

9.3.4. 将 LDAP 身份验证配置迁移到 Elytron
复制链接

将旧的 LDAP 身份验证迁移到 Elytron，以便它可以作为身份属性管理信息。

先决条件

在将旧的 LDAP 身份验证迁移到 Elytron 之前，您必须阅读 Migrate Properties-based Authentication and Authorization to 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 Security Realm Configuration 命令

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 Security Realm 配置

<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 命令用于配置 PicketBox 安全域，它使用 LdapExtLoginModule 来验证用户名和密码。

示例：安全域配置命令

/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>

9.3.4.1. 将传统 LDAP 身份验证迁移到 Elytron
复制链接

按照以下步骤，在 JBoss EAP 7.4 及更早版本中将前面的 LDAP 身份验证示例配置迁移到 Elytron。本节适用于迁移传统安全 LDAP 域以及 PicketBox LDAP 安全域。

流程

在 elytron 子系统中定义与 LDAP 的连接。

/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" identity 属性映射到 identity 角色。

从 LDAP 加载的信息现在可以将身份作为属性关联。这些属性可以映射到角色，但也可以加载并用于其他目的。新创建的安全域可以在安全域中使用，方式与在本指南的 Migrate Properties- authentication 和 Authorization to Elytron 部分中描述。

9.3.5. 将数据库身份验证配置迁移到 Elytron
复制链接

将基于 JDBC 数据源的 PicketBox 身份验证迁移到 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)
)

出于身份验证目的，用户名与用户名列中存储的数据匹配，密码应以十六进制编码的 MD5 哈希存储在 password 列中，以及用于授权目的的用户角色存储在 role 列中。

PicketBox 安全域配置为使用 JBDC 数据源从数据库表中检索数据，然后使用它验证用户名和密码，并分配角色。使用以下管理 CLI 命令，假设 PicketBox 安全域已配置：

示例：PicketBox Database LoginModule Configuration Commands

/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 Configuration

<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>

9.3.5.1. 将旧的数据库身份验证迁移到 Elytron
复制链接

对于 JBoss EAP 7.4 及更早版本，您必须定义一个 JDBC 域，以启用 Elytron 的 JDBC 数据源访问，以便将前面的数据库身份验证示例配置迁移到 Elytron。

流程

使用以下管理命令定义 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 比 PicketBox 更高效，因为它使用一个 SQL 查询来获取所有用户属性和凭证，然后从 SQL 结果中提取数据，并创建用于身份验证的属性映射。

9.3.6. 将 Kerberos 身份验证迁移到 Elytron
复制链接

在使用 Kerberos 配置时，JBoss EAP 服务器可以依赖环境中的配置信息，或者使用系统属性来指定密钥配置。

这些系统属性适用于传统配置和迁移的 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>

根据您的身份验证机制，选择以下迁移选项之一：

9.3.6.1. 迁移 Kerberos HTTP 身份验证
复制链接

在传统的安全配置中，您可以定义一个安全域来为 HTTP 管理界面启用 SPNEGO 身份验证，如下所示：

前提条件

以下示例假设 Kerberos 是使用系统属性配置的。

示例：为 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 Realm 配置

<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>

您还可以定义一对传统安全域，以允许应用程序使用 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})

示例：使用安全域对进行配置

<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 机制的安全。

9.3.6.1.1. 将 Kerberos HTTP 身份验证迁移到 Elytron
复制链接

使用安全域和 Kerberos 安全工厂保护 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 管理界面，以引用此配置中定义的 http-authentication-factory。此过程记录在 Migrate Properties- authentication and Authorization to Elytron 中。

9.3.6.2. 迁移 Kerberos 远程 SASL 身份验证
复制链接

使用以下信息迁移 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 Remoting Security Realm 配置

<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>

9.3.6.2.1. 将 Kerberos 远程 SASL 身份验证迁移到 Elytron
复制链接

使用以下步骤将 Kerberos 远程 SASL 身份验证迁移到 Elytron。

流程

定义用于加载身份信息的安全域。

/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 身份验证工厂。

这里定义的两个 Elytron 示例也可以合并为使用共享安全域和安全域，并且只使用 特定于协议的身份验证因素，各自引用自己的 Kerberos 安全工厂。

9.3.7. 将 Composite Stores 迁移到 Elytron
复制链接

本节论述了如何将使用多个身份存储的 PicketBox 或传统的安全域配置迁移到 Elytron Aggregate Security Realm 配置。

使用 PicketBox 或旧的安全域时，可以在其中定义一个配置，当用于授权的信息从不同的存储加载时。迁移到 Elytron 时，可以使用聚合安全域来实现。

以下示例使用 example-users.properties 属性文件执行用户身份验证，然后查询 LDAP 来加载组和角色信息。

注意

显示的配置基于以下部分中的示例，它提供了额外的背景信息：

9.3.7.1. PicketBox Composite Store 配置
复制链接

此情境的 PicketBox 安全域使用以下管理 CLI 命令进行配置。

示例：PicketBox Configuration Commands

/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 Configuration

<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 Aggregate Security Realm Configuration 以了解如何配置聚合安全域。

9.3.7.2. 传统的安全性 Realm Composite Store 配置
复制链接

对于 JBoss EAP 7.4 及更早版本的 releses，使用以下管理 CLI 命令配置旧的安全域配置：

注意

因为旧的安全命令不适用于 JBoss EAP 8，这些命令仅适用于 JBoss EAP 7.4 及更早版本。

示例：传统的安全 Realm 配置命令

/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

这会生成以下服务器配置。

示例：传统安全 Realm 配置

<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 Aggregate Security Realm 配置。

9.3.7.3. Elytron Aggregate Security Realm 配置
复制链接

此情境对应的 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，用于指定用于身份验证的安全域以及用于授权决策的安全域。

9.3.8. 将使用缓存的安全域迁移到 Elytron
复制链接

使用 PicketBox 时，可以定义一个安全域并启用内存缓存来访问。这样，您可以在内存中访问身份数据，并避免额外的直接访问身份存储。可以通过 Elytron 实现类似的配置。本节显示在使用 Elytron 时示例 PicketBox 配置和等同的安全域缓存配置。

9.3.8.1. PicketBox Cached Security Domain Configuration
复制链接

以下命令显示 PicketBox 安全域配置，以便在 JBoss EAP 7.4 及更早版本中启用缓存。

示例：PicketBox Cached Security Domain Commands

/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 Cached Security Domain Configuration

<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 的值来定义。默认 缓存类型是内存缓存。使用 PicketBox 时，您还可以指定 infinispan 的 cache-type，但这种类型不支持 Elytron。

9.3.8.2. 配置 Elytron 缓存安全域
复制链接

按照以下步骤创建使用 Elytron 时缓存安全域的类似的配置。

流程

定义安全域，并将安全域嵌套在缓存域中。然后，缓存域可以在安全域中使用，然后在身份验证工厂中使用。

示例： Elytron Security Realm Configuration 命令

/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)

定义安全域和 HTTP 身份验证工厂，它使用上一步中定义的 cached-ldap 域。

示例：Elytron Security Domain and Authentication Factory Configuration Commands

/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 Cached Security Domain configuration

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

9.3.9. 将 Jakarta 授权安全性迁移到 Elytron
复制链接

默认情况下，JBoss EAP 7.4 及更早版本使用传统的 security 子系统配置 Jakarta 授权策略提供程序和工厂。默认配置映射从 PicketBox 映射到实施。

elytron 子系统根据容器的 Java 授权合同(JACC)规范提供内置的策略提供程序。

有关如何在 elytron 子系统中为容器策略提供程序启用和定义 Java 授权合同的信息，请参阅 JBoss EAP 7.4 开发指南中的 定义 Jakarta 身份验证策略提供程序。

9.3. 迁移身份验证配置

9.3.1. 将基于 PicketBox Properties 的配置迁移到 Elytron
复制链接

9.3.1.1. 将基于属性的身份验证迁移到 Elytron
复制链接

9.3.2. 将基于旧安全域的属性配置迁移到 Elytron
复制链接

9.3.3. 使用 filesystem-realm 命令迁移到基于文件系统的安全 Realm
复制链接

9.3.4. 将 LDAP 身份验证配置迁移到 Elytron
复制链接

9.3.4.1. 将传统 LDAP 身份验证迁移到 Elytron
复制链接

9.3.5. 将数据库身份验证配置迁移到 Elytron
复制链接

9.3.5.1. 将旧的数据库身份验证迁移到 Elytron
复制链接

9.3.6. 将 Kerberos 身份验证迁移到 Elytron
复制链接

9.3.6.1. 迁移 Kerberos HTTP 身份验证
复制链接

9.3.6.1.1. 将 Kerberos HTTP 身份验证迁移到 Elytron
复制链接

9.3.6.2. 迁移 Kerberos 远程 SASL 身份验证
复制链接

9.3.6.2.1. 将 Kerberos 远程 SASL 身份验证迁移到 Elytron
复制链接

9.3.7. 将 Composite Stores 迁移到 Elytron
复制链接

9.3.7.1. PicketBox Composite Store 配置
复制链接

9.3.7.2. 传统的安全性 Realm Composite Store 配置
复制链接

9.3.7.3. Elytron Aggregate Security Realm 配置
复制链接

9.3.8. 将使用缓存的安全域迁移到 Elytron
复制链接

9.3.8.1. PicketBox Cached Security Domain Configuration
复制链接

9.3.8.2. 配置 Elytron 缓存安全域
复制链接

9.3.9. 将 Jakarta 授权安全性迁移到 Elytron
复制链接

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

9.3. 迁移身份验证配置

9.3.1. 将基于 PicketBox Properties 的配置迁移到 Elytron复制链接链接已复制到粘贴板!

9.3.1.1. 将基于属性的身份验证迁移到 Elytron复制链接链接已复制到粘贴板!

9.3.2. 将基于旧安全域的属性配置迁移到 Elytron复制链接链接已复制到粘贴板!

9.3.3. 使用 filesystem-realm 命令迁移到基于文件系统的安全 Realm复制链接链接已复制到粘贴板!

9.3.4. 将 LDAP 身份验证配置迁移到 Elytron复制链接链接已复制到粘贴板!

9.3.4.1. 将传统 LDAP 身份验证迁移到 Elytron复制链接链接已复制到粘贴板!

9.3.5. 将数据库身份验证配置迁移到 Elytron复制链接链接已复制到粘贴板!

9.3.5.1. 将旧的数据库身份验证迁移到 Elytron复制链接链接已复制到粘贴板!

9.3.6. 将 Kerberos 身份验证迁移到 Elytron复制链接链接已复制到粘贴板!

9.3.6.1. 迁移 Kerberos HTTP 身份验证复制链接链接已复制到粘贴板!

9.3.6.1.1. 将 Kerberos HTTP 身份验证迁移到 Elytron复制链接链接已复制到粘贴板!

9.3.6.2. 迁移 Kerberos 远程 SASL 身份验证复制链接链接已复制到粘贴板!

9.3.6.2.1. 将 Kerberos 远程 SASL 身份验证迁移到 Elytron复制链接链接已复制到粘贴板!

9.3.7. 将 Composite Stores 迁移到 Elytron复制链接链接已复制到粘贴板!

9.3.7.1. PicketBox Composite Store 配置复制链接链接已复制到粘贴板!

9.3.7.2. 传统的安全性 Realm Composite Store 配置复制链接链接已复制到粘贴板!

9.3.7.3. Elytron Aggregate Security Realm 配置复制链接链接已复制到粘贴板!

9.3.8. 将使用缓存的安全域迁移到 Elytron复制链接链接已复制到粘贴板!

9.3.8.1. PicketBox Cached Security Domain Configuration复制链接链接已复制到粘贴板!

9.3.8.2. 配置 Elytron 缓存安全域复制链接链接已复制到粘贴板!

9.3.9. 将 Jakarta 授权安全性迁移到 Elytron复制链接链接已复制到粘贴板!

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

9.3.1. 将基于 PicketBox Properties 的配置迁移到 Elytron
复制链接

9.3.1.1. 将基于属性的身份验证迁移到 Elytron
复制链接

9.3.2. 将基于旧安全域的属性配置迁移到 Elytron
复制链接

9.3.3. 使用 filesystem-realm 命令迁移到基于文件系统的安全 Realm
复制链接

9.3.4. 将 LDAP 身份验证配置迁移到 Elytron
复制链接

9.3.4.1. 将传统 LDAP 身份验证迁移到 Elytron
复制链接

9.3.5. 将数据库身份验证配置迁移到 Elytron
复制链接

9.3.5.1. 将旧的数据库身份验证迁移到 Elytron
复制链接

9.3.6. 将 Kerberos 身份验证迁移到 Elytron
复制链接

9.3.6.1. 迁移 Kerberos HTTP 身份验证
复制链接

9.3.6.1.1. 将 Kerberos HTTP 身份验证迁移到 Elytron
复制链接

9.3.6.2. 迁移 Kerberos 远程 SASL 身份验证
复制链接

9.3.6.2.1. 将 Kerberos 远程 SASL 身份验证迁移到 Elytron
复制链接

9.3.7. 将 Composite Stores 迁移到 Elytron
复制链接

9.3.7.1. PicketBox Composite Store 配置
复制链接

9.3.7.2. 传统的安全性 Realm Composite Store 配置
复制链接

9.3.7.3. Elytron Aggregate Security Realm 配置
复制链接

9.3.8. 将使用缓存的安全域迁移到 Elytron
复制链接

9.3.8.1. PicketBox Cached Security Domain Configuration
复制链接

9.3.8.2. 配置 Elytron 缓存安全域
复制链接

9.3.9. 将 Jakarta 授权安全性迁移到 Elytron
复制链接