我已经创建了自己的JDBC领域(使用WildFly 8.2)，如JavaEE7教程第50.3段所述。我的理解是JDBC领域身份验证意味着用户凭据由服务器读取和检查，应用程序甚至不知道身份验证保留数据库的坐标。
对于"新用户注册"，我唯一能想到的就是从我的应用程序内部实现一个经典的解决方案：访问auth DB，检查所选用户名是否已经存在，在表中插入行。。。但这是否违反了"容器管理的身份验证"的整个范式，并可能插入安全漏洞？
是否有一些服务器实现的机制我忽略了？
但这是否违反了"容器管理的身份验证"的整个范式，并可能插入安全漏洞？
是的，或多或少。容器管理的安全概念，即应用程序完全不知道身份验证机制和身份存储(用户数据实际存储的位置)，并没有真正考虑到应用程序具有自己的用户注册/注册功能的用例。
这个想法似乎更倾向于将外部获得的应用程序(例如Sonar或JIRA实例)集成到现有的企业结构中。在那里，用户是由管理员使用LDAP之类的中央系统创建的，在某些情况下甚至是应用程序服务器的管理员UI。
不幸的是，许多典型的公共web应用程序都不是这种类型的。它们是独立的应用程序(不与现有的内部企业基础设施集成)，可以有效地管理自己的用户。
经典的概念在那里是不合适的，这就是为什么Java EE Security EG目前正在探索如何最好地解决这个问题。
同时你基本上有三个"解决方案"：
- 只需定义两次数据库连接详细信息，一次在服务器级别，一次是在应用程序级别。看起来你确实已经在这么做了
- 使用JASPIC，这是一个容器提供的身份验证API，它可以选择让应用程序包含身份验证模块。它可以使用完全相同的数据源和可能的JPA实体管理器，因此应用程序也在使用
- 使用完全在"用户空间"中实现的外部安全框架(例如DeltaSpike security或Shiro)进行安全保护
从Java EE的角度来看，没有一个是真正理想的。第一个有重复的定义，确实有点违反了原则，第二个本身还可以，但JASPIC的级别有点低，而第二个是一个丰富的解决方案，但没有很好地与现有的JavaEE安全集成。