Realm 配置

DataSourceRealm 是 Tomcat Realm 接口的一个实现， 通过名为 JDBC DataSource 的 JNDI 访问关系数据库中查找用户。 只要数据库结构符合以下要求，就可以灵活地适应现有的表和列名称：

要设置 Tomcat 以使用 DataSourceRealm，需要执行以下步骤：

要配置 DataSourceRealm，需要创建一个<Realm>元素并将其嵌套在 $CATALINA_BASE/conf/server.xml 文件中， 如上所述。DataSourceRealm 的属性在 Realm 配置文档中定义。

用于创建所需表的示例 SQL 脚本可能如下所示（根据特定数据库的需要调整语法）：

下面是一个使用名为 “authority” 的 MySQL 数据库的示例，该数据库配置了上述表， 并使用名为 “java：/comp/env/jdbc/authority” 的 JNDI JDBC DataSource 进行访问。

DataSourceRealm 根据以下规则运行：

JNDIRealm 是 Tomcat Realm 接口的一种实现，用于查找 JNDI 提供程序 （通常是 JNDI API 类提供的标准 LDAP 提供程序）访问的 LDAP 目录服务器中的用户。 该领域支持使用目录进行身份验证的多种方法。

领域与目录的连接由 connectionURL 配置属性定义。 这是一个 URL，其格式由 JNDI 提供者定义。 它通常是一个 LDAP URL，用于指定要连接到的目录服务器的域名， 以及所需的根命名上下文的端口号和专有名称 （DN）（可选）。

如果有多个提供商，则可以配置 alternateURL。 如果无法在 connectionURL 处与提供程序建立套接字连接，则将尝试使用 alternateURL。

在建立连接以搜索目录并检索用户和角色信息时， 领域将使用 connectionName 和 connectionPassword 属性指定的用户名和密码向目录验证自身。 如果未指定这些属性，则连接是匿名的。这在许多情况下就足够了。

每个可以进行身份验证的用户都必须在目录中由一个单独的条目表示， 该条目对应于由 connectionURL 属性定义的初始 DirContext 中的元素。 此用户条目必须具有一个属性，其中包含用于身份验证的用户名。

通常，用户条目的专有名称包含用于身份验证的用户名，但对于所有用户来说都是相同的。 在这种情况下，userPattern 属性可用于指定 DN，其中 “{0}” 标记应替换用户名的位置。

否则，领域必须搜索目录以查找包含 username 的唯一条目。以下属性配置此搜索：

默认情况下，领域通过使用该用户条目的 DN 和用户提供的口令绑定到目录来验证用户。 如果此简单绑定成功，则认为用户已经过身份验证。

出于安全原因，目录可能会存储用户密码的摘要，而不是明文版本（有关更多信息，请参见摘要密码）。 在这种情况下，作为简单绑定操作的一部分，目录会自动计算用户提供的纯文本密码的正确摘要， 然后再根据存储的值进行验证。因此，在 bind 模式下，领域不参与摘要处理。 digest 属性未被使用，如果设置，将被忽略。

或者，领域可以从目录中检索存储的密码，并将其与用户提供的值显式进行比较。 通过将 userPassword 属性设置为包含密码的用户条目中的 directory 属性的名称来配置此模式。

比较模式有一些缺点。首先，必须配置 connectionName 和 connectionPassword 属性以允许领域读取目录中的用户密码。 出于安全原因，这通常是不可取的;事实上，许多目录实现甚至不允许目录管理器读取这些密码。 此外，领域必须自行处理密码摘要，包括所用算法的变化以及在目录中表示密码哈希的方法。 但是，领域有时可能需要访问存储的密码，例如支持 HTTP 摘要访问身份验证 （RFC 2069）。 （请注意，HTTP 摘要身份验证不同于如上所述在存储库中存储密码摘要以获取用户信息）。

目录领域支持两种方法来表示目录中的角色：

角色可以由显式目录条目表示。角色条目通常是 LDAP 组条目， 其中一个属性包含角色的名称，另一个属性的值是该角色中用户的专有名称或用户名。 以下属性配置目录搜索以查找与经过身份验证的用户关联的角色名称：

角色名称也可以作为用户目录条目中某个属性的值保存。使用 userRoleName 指定此属性的名称。

可以使用两种方法的组合来表示角色。

要将 Tomcat 设置为使用 JNDIRealm，需要执行以下步骤：

要配置 JNDIRealm，需要创建一个<Realm>元素并将其嵌套在 $CATALINA_BASE/conf/server.xml 文件中，如上所述。 JNDIRealm 的属性在 Realm 配置文档中定义。

在目录服务器中创建适当的架构超出了本文档的范围，因为它对于每个目录服务器实现都是唯一的。 在下面的示例中，假设使用的是 OpenLDAP 目录服务器的发行版（版本 2.0.11 或更高版本）， 该发行版可从 https://www.openldap.org 下载。 假设 slapd.conf 文件包含以下设置（以及其他设置）：

对于 connectionURL，将假设目录服务器与 Tomcat 运行在同一台计算机上。 有关配置和使用 JNDI LDAP 提供程序的更多信息， 请参见 http://docs.oracle.com/javase/7/docs/technotes/guides/jndi/index.html。

接下来，假设此目录服务器已填充了如下所示的元素（LDIF 格式）：

如上所述配置的 OpenLDAP 目录服务器的 Realm 元素示例可能如下所示， 假设用户使用他们的 uid（例如 jjones）登录应用程序，并且匿名连接足以搜索目录并获取角色信息：

使用此配置，领域将通过将用户名替换为 userPattern 来确定用户的可分辨名称， 通过使用此 DN 和从用户处收到的密码绑定到目录来进行身份验证，并搜索目录以查找用户的角色。

现在假设用户在登录时需要输入他们的电子邮件地址而不是他们的 userid。 在这种情况下，领域必须在目录中搜索用户的条目。 （当用户条目保存在可能对应于不同组织单位或公司位置的多个子树中时，也需要进行搜索）。

此外，假设除了组条目之外，还希望使用用户条目的属性来保存角色。 现在，Janet Jones 的条目可能如下所示：

此领域配置将满足新要求：

现在，当 Janet Jones 以 “j.jones@mycompany.com” 身份登录时， 领域将在目录中搜索以该值作为其 mail 属性的唯一条目， 并尝试使用给定的口令以 uid=jjones，ou=people，dc=mycompany，dc=com 身份绑定到该目录。 如果身份验证成功，则会为他们分配三个角色：“role2”和“role3”， 即其目录条目中“memberOf”属性的值，以及“tomcat”， 即他们所属的唯一组条目中的“cn”属性的值。

最后，要通过从目录中检索密码并在领域中进行本地比较来验证用户， 可以使用如下领域配置：

但是，如上所述，身份验证的默认绑定模式通常是首选。

JNDIRealm 根据以下规则运行：

UserDatabaseRealm 是 Tomcat Realm 接口的一种实现，它使用 JNDI 资源来存储用户信息。 默认情况下，JNDI 资源由 XML 文件提供支持。它不是为大规模生产使用而设计的。 在启动时，UserDatabaseRealm 从一个 XML 文档加载有关所有用户及其相应角色的信息 （默认情况下，这个文档是从 $CATALINA_BASE/conf/tomcat-users.xml 加载的）。 用户、他们的密码和他们的角色都可能动态编辑，通常是通过 JMX 进行的。 更改可能会被保存并反映在 XML 文件中。

要配置 UserDatabaseRealm，需要创建一个<Realm>元素并将其嵌套在 $CATALINA_BASE/conf/server.xml 文件中，如上所述。 UserDatabaseRealm 的属性在 Realm 配置文档中定义。

对于基于 XML 文件的 UserDatabase，users 文件使用与 MemoryRealm 相同的格式。

Tomcat 的默认安装配置了嵌套在元素 <Engine> 内的 UserDatabaseRealm ， 以便它适用于所有虚拟主机和 Web 应用程序。 conf/tomcat-users.xml 文件的默认内容为：

UserDatabaseRealm 根据以下规则运行：

MemoryRealm 是 Tomcat Realm 接口的简单演示实现。它不是为生产用途而设计的。 在启动时，MemoryRealm 从 XML 文档加载有关所有用户及其相应角色的信息 （默认情况下，此文档从 $CATALINA_BASE/conf/tomcat-users.xml 加载）。 在重新启动 Tomcat 之前，无法识别对此文件中的数据的更改。

要配置 MemoryRealm，需要创建一个<Realm>元素并将其嵌套在 $CATALINA_BASE/conf/server.xml 文件中， 如上所述。MemoryRealm 的属性在 Realm 配置文档中定义。

用户文件（默认情况下， conf/tomcat-users.xml 必须是 XML 文档，具有 root 元素 <tomcat-users>。 嵌套在根元素内的将是 <user> 每个有效用户的一个元素，由以下属性组成：

MemoryRealm 根据以下规则运行：

JAASRealm是Tomcat Realm接口的一种实现，通过Java认证和授权服务（JAAS）框架验证用户， 该框架现在已作为标准Java SE API的一部分提供。

使用 JAASRealm 使开发人员能够将几乎任何可以想象的安全领域与 Tomcat 的 CMA 相结合。

JAASRealm 是 J2EE v1.4 的基于 JAAS 的 J2EE 身份验证框架的 Tomcat 原型， 基于 JCP 规范请求 196，以增强容器管理的安全性并促进“可插拔”身份验证机制，其实现将与容器无关。

基于 JAAS 登录模块和主体（请参见`javax.security.auth.spi.LoginModule` 和 javax.security.Principal）， 可以开发自己的安全机制或包装另一个第三方机制，以便与 Tomcat 实现的 CMA 集成。

要将 Tomcat 设置为将 JAASRealm 与自己的 JAAS 登录模块一起使用，需要执行以下步骤：

要像上面的步骤 6 一样配置 JAASRealm，需要创建一个<Realm>元素并将其嵌套 在节点内的 $CATALINA_BASE/conf/server.xml 文件中<Engine>。 JAASRealm 的属性在 Realm 配置文档中定义。

下面是 server.xml 代码段的外观示例。

登录模块负责创建并保存表示用户主体的 User 和 Role 对象 （javax.security.auth.Subject）。 如果登录模块没有创建用户对象，但也没有引发登录异常，则 Tomcat CMA 将中断， 将被留在 http://localhost:8080/myapp/j_security_check URI 或其他未指定的位置。

JAAS 方法的灵活性有两个方面：

CombinedRealm 是 Tomcat Realm 接口的一种实现， 它通过一个或多个子 Realm 对用户进行身份验证。

使用 CombinedRealm 使开发人员能够组合相同或不同类型的多个 Realm。 这可用于针对不同的源进行身份验证，在一个 Realm 失败时提供回退， 或者用于需要多个 Realm 的任何其他目的。

子 Realm 是通过将 Realm 元素嵌套在定义 CombinedRealm 的 Realm 元素中来定义的。 将按照每个 Realm 的列出顺序尝试对每个 Realm 进行身份验证。 针对任何 Realm 的身份验证都足以对用户进行身份验证。

要配置 CombinedRealm，需要创建一个<Realm>元素并将其嵌套在 $CATALINA_BASE/conf/server.xml 文件中的 <Engine> 或 <Host>中。还可以嵌套在 <Context> context.xml 文件中的节点内。

下面是一个示例，说明 server.xml 代码片段应该如何使用 UserDatabase Realm 和 DataSource Realm。

LockOutRealm 是 Tomcat Realm 接口的实现，它扩展了 CombinedRealm 以提供锁定功能， 以便在给定时间段内身份验证尝试失败次数过多时提供用户锁定机制。

为了确保正确操作，此 Realm 中存在合理程度的同步。

此 Realm 不需要修改底层 Realm 或相关的用户存储机制。 通过记录所有失败的登录来实现此目的，包括不存在的用户的登录。 为了防止 DOS 通过考虑向无效用户发出请求（从而导致此缓存增长）来防止 DOS，验证失败的用户列表的大小是有限的。

子 Realm 是通过将 Realm 元素嵌套在定义 LockOutRealm 的 Realm 元素中来定义的。、将按照每个 Realm 的列出顺序尝试对每个 Realm 进行身份验证。针对任何 Realm 的身份验证都足以对用户进行身份验证。

要配置 LockOutRealm，需要创建一个<Realm>元素并将其嵌套在 $CATALINA_BASE/conf/server.xml 文件中的 <Engine> 或 <Host>中。 还可以嵌套在 <Context> context.xml 文件中的节点内。 LockOutRealm 的属性在 Realm 配置文档中定义。

下面是一个示例，展示了`server.xml`代码段如何向 UserDatabase Realm 添加锁定功能。