主页
产品
Red Hat JBoss Enterprise Application Platform
7.4
Migration Guide
7.3. 迁移身份验证配置

7.3. 迁移身份验证配置

7.3.1. 将基于属性的身份验证和授权迁移到 Elytron
复制链接

7.3.1.1. 将基于 PicketBox Properties 的配置迁移到 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 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>

选择以下迁移选项之一：

通过公开 PicketBox Security Domain to Elytron 的部分迁移

您可以将 PicketBox 安全域公开为 Elytron 安全域，以便它可以进入 Elytron 配置中；但是，这样做会为旧 安全 子系统创建依赖项。如果您只迁移基于属性的身份验证，建议您完全将应用程序迁移到 Elytron，以避免对旧 安全 子系统的不必要的依赖。但是，当无法完全迁移应用程序以使用 Elytron 时，部分迁移可以是中间解决方案。

按照以下步骤，将现有的 PicketBox 安全域配置添加为 Elytron 安全域。

添加到旧安全子系统中 Elytron 安全域 的映射。

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

这会在服务器配置文件的 security 子系统中配置以下 Elytron 安全域：

<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 服务中，为保护 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 配置。

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

注意

在当前的 Web 服务中，为保护 Web 服务端点和 Elytron 安全域名指定的安全域的名称必须相同。

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

身份验证现在被配置为等同于 PicketBox 配置，但 Elytron 组件现在专门用于身份验证。

7.3.1.2. 将基于传统属性的配置迁移到 Elytron
复制链接

这部分论述了如何将加载用户、密码和组信息的传统安全域从属性文件迁移到 Elytron。这种类型的传统安全域通常用于保护管理接口或重新移动连接器。

这些示例假定使用下列管理 CLI 命令定义传统安全域：

示例：传统安全性 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)

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

示例：传统安全域配置

<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)
/subsystem=remoting/http-connector=http-remoting-connector:undefine-attribute(name=security-realm)

这会在服务器配置文件的 remoting subsystem 中生成以下配置：

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

/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 命令迁移到基于文件系统的安全 Realm
复制链接

这部分论述了如何使用 elytron.sh 工具的 filesystem-realm 命令，将传统的基于属性的安全域迁移到 Elytronon 中的基于文件系统的域。

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

将基于属性的身份验证迁移到基于文件系统的身份验证的步骤如下：

迁移属性文件。
您可以一次迁移单个 user-properties 文件，或者批量迁移属性文件。以下示例演示了这两种迁移的步骤。
- 迁移单个属性文件。
  以下示例将关联 roles-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 文件的用户/操作文件转换为 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
  描述符文件中的一个空行用于分隔各个用户/不可操作的文件的操作。
  以下示例将两个用户/操作文件与关联的 role-properties 文件转换为 filesystem-realm。
  示例：Bulk migration
  $./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 命令用于配置 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>

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

按照以下步骤将之前的 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-based Authentication and Authorization to Elytron 部分相同。

7.3.4. 将数据库身份验证配置迁移到 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 数据源从数据库表中检索数据，然后使用它来验证用户名和密码，再分配角色。假定 PicketBox 安全域使用以下管理 CLI 命令进行配置。

示例：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 子系统中生成以下 登录模块 配置。

示例：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>

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

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>

选择以下迁移选项之一：

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

您还可以定义一对旧的安全域，以允许应用程序使用 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 机制的安全。

将 Kerberos HTTP 身份验证迁移到 Elytron

通过使用安全域和 Kerberos 安全因素，管理接口和应用程序都可以在 Elytron 中进行保护。

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

/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 部分。

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

此处定义的两个 Elytron 示例也可以合并使用共享安全域和安全域，且仅使用特定于协议的身份验证因素，每个都引用其自己的 Kerberos 安全工厂。

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

本节论述了如何将 PicketBox 或旧安全域配置迁移到 Elytron。在使用 PicketBox 或传统的安全域时，可以定义针对一个身份存储进行身份验证的配置，同时从不同的存储中加载用于授权的信息。迁移到 Elytron 时，可以使用聚合安全域来实现。

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

注意

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

Picketbox Composite Store Configuration

此情境的 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 Aggregate Security Realm Configuration，了解如何在 elytron 子系统中配置聚合安全域，以完成此操作。

传统的安全性 Realm Composite Store 配置

此情境的传统安全域配置使用下列管理 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 Aggregate Security Realm Configuration，了解如何在 elytron 子系统中配置聚合安全域，以完成此操作。

Elytron Aggregate Security Realm 配置

此情境对应的 Elytron 配置使用以下管理 CLI 命令进行配置。

示例： Elytron 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/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 Cached Security Domain configuration

以下命令显示如何配置启用缓存的 PicketBox 安全域。

示例：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。

Elytron Cached 安全域配置

按照以下步骤创建使用 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 域。

示例：在安全域和验证因素配置命令

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

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

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

elytron 子系统根据 Jakarta 授权规范提供内置的策略提供程序。在将服务器配置为允许 Elytron 管理 Jakarta Authorization 配置和其他策略之前，您必须首先使用以下管理 CLI 命令 在旧安全 子系统中禁用 Jakarta Authorization。

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

如果不这样做，则会在服务器日志中包括以下信息：MSC000004: Failure during stop of service org.wildfly.security.policy: java.lang.StackOverflowError。

有关如何启用 Jakarta 授权并在 elytron 子系统中定义 Jakarta 授权策略提供程序的信息，请参阅 JBoss EAP 开发指南中的 启用 Jakarta 授权。

7.3. 迁移身份验证配置

7.3.1. 将基于属性的身份验证和授权迁移到 Elytron
复制链接

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

通过公开 PicketBox Security Domain to Elytron 的部分迁移

完全将基于属性的身份验证迁移到 Elytron

7.3.1.2. 将基于传统属性的配置迁移到 Elytron
复制链接

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

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

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

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

7.3.4.1. 将传统数据库身份验证迁移到 Elytron
复制链接

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

迁移 Kerberos HTTP 身份验证

将 Kerberos HTTP 身份验证迁移到 Elytron

迁移 Kerberos 远程 SASL 身份验证

将 Kerberos 远程 SASL 身份验证迁移到 Elytron

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

Picketbox Composite Store Configuration

传统的安全性 Realm Composite Store 配置

Elytron Aggregate Security Realm 配置

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

Picketbox Cached Security Domain configuration

Elytron Cached 安全域配置

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

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

7.3. 迁移身份验证配置

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

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

通过公开 PicketBox Security Domain to Elytron 的部分迁移

完全将基于属性的身份验证迁移到 Elytron

7.3.1.2. 将基于传统属性的配置迁移到 Elytron复制链接链接已复制到粘贴板!

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

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

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

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

7.3.4.1. 将传统数据库身份验证迁移到 Elytron复制链接链接已复制到粘贴板!

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

迁移 Kerberos HTTP 身份验证

将 Kerberos HTTP 身份验证迁移到 Elytron

迁移 Kerberos 远程 SASL 身份验证

将 Kerberos 远程 SASL 身份验证迁移到 Elytron

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

Picketbox Composite Store Configuration

传统的安全性 Realm Composite Store 配置

Elytron Aggregate Security Realm 配置

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

Picketbox Cached Security Domain configuration

Elytron Cached 安全域配置

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

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

7.3.1. 将基于属性的身份验证和授权迁移到 Elytron
复制链接

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

7.3.1.2. 将基于传统属性的配置迁移到 Elytron
复制链接

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

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

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

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

7.3.4.1. 将传统数据库身份验证迁移到 Elytron
复制链接

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

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

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

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