OpenAM/OpenSSO HttpServletRequest.login(user, pass) 失败并显示“无效的传输字符串".这是什么意思? [英] OpenAM / OpenSSO HttpServletRequest.login(user, pass) fails with "Invalid transport string". What does this mean?

问题描述

我有两台 tomcat 服务器，一台带有 OpenAM 12，一台带有主要的 Web 应用程序.已知:HTML 页面可以毫无问题地进行身份验证，使用 OpenAM java SDK 的编程登录在 servlet 内工作.

I have two tomcat servers, one with OpenAM 12, one with the main web applications. Known: HTML pages authenticate without issue, programmatic login using the OpenAM java SDK works from within a servlet.

失败是调用HttpServletRequest.login(username, password)

这是我在 TomEE+ 服务器中的条目:

This is the entry I have within the TomEE+ server:

    <Realm className="com.sun.identity.agents.tomcat.v6.AmTomcatRealm" debug="99"/>

这是我在 AM J2EEAgent 调试日志中看到的错误:

Here is the error I see within the AM J2EEAgent debug log:

amRealm:01/29/2014 02:29:47:497 PM EST: Thread[http-bio-443-exec-3,5,main]
SSOTokenValidator: validate failed with exception
[AgentException Stack]
com.sun.identity.agents.arch.AgentException: Invalid transport string
        at com.sun.identity.agents.util.TransportToken.initializeFromString(TransportToken.java:135)
        at com.sun.identity.agents.util.TransportToken.<init>(TransportToken.java:115)
        at com.sun.identity.agents.common.SSOTokenValidator.validate(SSOTokenValidator.java:99)
        at com.sun.identity.agents.realm.AmRealm.authenticate(AmRealm.java:143)
        at com.sun.identity.agents.tomcat.v6.AmTomcatRealm.authenticate(AmTomcatRealm.java:106)
        at org.apache.catalina.realm.CombinedRealm.authenticate(CombinedRealm.java:146)
        at org.apache.tomee.catalina.TomEERealm.authenticate(TomEERealm.java:43)
        at org.apache.catalina.authenticator.AuthenticatorBase.doLogin(AuthenticatorBase.java:818)
        at org.apache.catalina.authenticator.AuthenticatorBase.login(AuthenticatorBase.java:800)
        at org.apache.catalina.connector.Request.login(Request.java:2621)
        at org.apache.catalina.connector.RequestFacade.login(RequestFacade.java:1065)

推荐答案

request#login 对于用户名/密码组合失败，因为代理在 server.xml 中定义了自己的 Tomcat Realm 定义(AmTomcatRealm).代理的领域不使用用户名/密码组合来验证用户，因为凭据甚至不应该出现在那里(OpenAM 执行身份验证，之后密码在您到达实际受保护的应用程序之前早已消失)，实际上有点令人担忧您仍然可以访问用户的密码.

The request#login fails for the username/password combination, because the agent defines its own Tomcat Realm definition (AmTomcatRealm) in the server.xml. The agent's realm does not use username/password combination for validating users as the credentials shouldn't even be present there (OpenAM performs the authentication and afterwards the password is long gone before you reach the actual protected application), it is actually a bit worrisome that you still have access to the user's password.

由于代理永远不应该真正知道用户的密码，它使用一个传输字符串，其中包含几个信息(在会话 ID 中)，它的格式非常无证，这里是相关源代码的一些链接:https://svn.forgerock.org/openam/trunk/openam-agents/jee-agents/jee-agents-sdk/src/main/java/com/sun/identity/agents/util/TransportToken.java

Since the agent should never actually know the user's password, it uses a transport string, that contains several information (amongst the session ID), it has a quite undocumented format, here is some link to the relevant source code: https://svn.forgerock.org/openam/trunk/openam-agents/jee-agents/jee-agents-sdk/src/main/java/com/sun/identity/agents/util/TransportToken.java

此外，这不是一个鸡蛋问题，因为假设 JAAS 登录是由代理本身执行的，并且并不真正期望应用程序首先调用登录.在代理设置中(当然还有 web.xml - 请参阅容器文档)，有一些方法可以启用 JAAS 表单登录支持，然后代理可以处理 JAAS 集成，而无需了解有关专有传输字符串格式的任何信息.

Also, this is not a chicken-egg problem, as it is assumed that the JAAS login is performed by the agent itself, and it isn't really expected that the application would invoke login in the first place. In the agent settings (and in web.xml of course - see container documentation) there are ways to enable JAAS form login support and then the agent can take care of the JAAS integration without the need of knowing anything about the proprietary transport string format.

这篇关于OpenAM/OpenSSO HttpServletRequest.login(user, pass) 失败并显示“无效的传输字符串".这是什么意思?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！