2

我创建了自己的 JDBC 领域（使用 WildFly 8.2），如JavaEE 7 教程的第50.3段所述。我的理解是 JDBC 领域身份验证意味着服务器读取和检查用户凭据，应用程序甚至不知道 auth-reserved DB 的坐标。

对于“新用户注册”，我唯一能想象的就是从我的应用程序内部实现一个经典解决方案：访问 auth DB，检查选择的用户名是否已经存在，在表中插入行......但没有这是否违反了“容器管理身份验证”的整个范式，并且可能会插入安全漏洞？

是否有一些我忽略的服务器实现的机制？

4

1 回答 1

3

但这是否违反了“容器管理身份验证”的整个范式，并且可能会插入安全漏洞？

是的，或多或少。容器管理的安全概念，其中应用程序完全不知道身份验证机制和身份存储（用户数据实际存储的位置）并没有真正考虑应用程序有自己的用户注册/注册功能。

这个想法似乎更倾向于将外部获得的应用程序（例如 Sonar 或 JIRA 实例）集成到现有的企业结构中。那里的用户是由管理员使用像 LDAP 这样的中央系统创建的，或者在某些情况下甚至是应用程序服务器的管理 UI。

不幸的是，许多典型的公共 Web 应用程序并不属于这种类型。它们是独立的应用程序（不与现有的内部企业基础架构集成），并且可以有效地管理自己的用户。

经典的概念在这里并不合适，这就是为什么 Java EE Security EG 目前正在探索如何最好地解决这个问题。

您基本上同时拥有三个“解决方案”：

  1. 只需定义您的数据库连接详细信息两次，一次在服务器级别，一次在应用程序。看起来你确实已经这样做了。
  2. 使用 JASPIC，这是一个容器提供的身份验证 API，它可以让应用程序包含身份验证模块。它可以使用完全相同的数据源和可能的 JPA 实体管理器，并且应用程序也在使用它。
  3. 使用完全在“用户空间”中实现的外部安全框架，例如 DeltaSpike Security 或 Shiro，确保您的安全。

从 Java EE 的角度来看，没有一个是真正理想的。第一个有重复的定义，确实有点违反原则，第二个本身还可以，但是 JASPIC 级别有点低，第二个是一个丰富的解决方案，但与现有的 Java EE 安全性没有很好的集成。

于 2015-05-06T07:25:58.500 回答