Websphere LDAP Spring Security 解析错误
我们有一个自定义 Grails 应用程序，它使用 Spring Security 进行 LDAP 身份验证。用户 DN 包含逗号（例如，“CN=Smith\, John,CN=Users,DC=example,DC=com”），但我们的管理员用户的 DN 不包含逗号（例如，“CN=peadmin,CN=Users,DC =示例，DC=com”）。当我从 Grails 服务器（本质上是 Tomcat）运行应用程序时，一切都验证正常。当我构建 WAR 并部署到 WebSphere AS 7 时，我只能使用 admin 用户登录。我们日志中的异常抱怨意外的逗号，这表明应用程序在 WAS 上运行时未正确解析/转义 DN。
升级到 Spring Security 3.0.4 后，这是我们得到的具体异常消息：
2011-04-07 20:58:41,975 [WebContainer : 0] ERROR controller.LoginController - org.springframework.security.authentication.AuthenticationServiceException: Failed to解析DN；嵌套异常是 org.springframework.ldap.core.ParseException: 在第 1 行第 20 列遇到“”。 本来期待： ...
We have a custom Grails application that is using Spring Security for LDAP authentication. The user DNs contain commas (e.g., "CN=Smith\, John,CN=Users,DC=example,DC=com"), but our admin user's DN does not (e.g., "CN=peadmin,CN=Users,DC=example,DC=com"). When I run the application from the Grails server, which is essentially Tomcat, everything authenticates fine. When I build the WAR and deploy to WebSphere AS 7, I can only log in with the admin user. The exception in our log complains about an unexpected comma, which says that the application is not properly parsing/escaping the DN when running on WAS.
After upgrading to Spring Security 3.0.4, here is the specific exception message we get:
2011-04-07 20:58:41,975 [WebContainer : 0] ERROR controller.LoginController - org.springframework.security.authentication.AuthenticationServiceException: Failed to parse DN; nested exception is org.springframework.ldap.core.ParseException: Encountered "" at line 1, column 20.
Was expecting:
...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先你就是在玩火。永远不要使用 DN 作为任何事物的基础，因为它不是用户的稳定属性。 ie 时它会立即中断。在树中移动用户。对于 AD，您应该使用 samAccountName 并使用 TDS（以及其余大部分）uid。这不会导致您当前的问题，但如果这是您希望继续工作的现实生活应用程序，请开始更改内容，否则您稍后会感到抱歉。
其次，如果您坚持在 LDAP 查询中使用带有特殊字符的逗号，您应该根据 RFC 2254 自行转义它。Tomcat 在返回用户时会为您执行此操作，而 WAS 不会。
First off you are playing with fire. Never ever ues DN as basis for anything since it is not a stable attribute of user. It breaks instantly when ie. moving users around in the tree. With AD you should use samAccountName and with TDS (and most of the rest) uid. This does not cause your current problem but if that is a real life application that you wish to keep working please start changing things or you will be sorry later on.
Second, if you insist on using something with commas with is special character in LDAP queries you should yourself escape it as per RFC 2254. Tomcat does this for you when it returns the user, WAS does not.