Question

尝试将我们的Web应用程序从GlassFish2（GF）迁移到Tomcat7（TC）。

在GF中，我们使用AuthContext方法（如在this example中）使用PolicyAgent3（PA）登录用户，之后我们在下一个请求中收到了带有角色的UserPrincipal。

在TC中，同样的方法还没有奏效。我可以登录用户，但我没有在下一个请求中获得UserPrincipal。我设法使PA的sampleapp工作，但它使用表单身份验证（通过OpenAM），这不适合我们。

是否可以在TC中使用AuthContext方法？因为比较GF和TC中的agent.jar实现，我得出的结论是它可能不受支持。在GF的PA中有IJ2EEAuthenticationHandler（com.sun.identity.agents.appserver.v81.AmASJ2EEAuthHandler）的实现，它对用户进行身份验证并在过程中设置UserPrincipal，但在TC的PA中只有默认实现处理程序（com.sun.identity.agents.filter.J2EEAuthenticationHandler），它没有设置UserPrincipal，它的authenticate方法只返回true。

Tomcat是否支持AuthContext方法？如何以编程方式对OpenAM用户进行身份验证并获取UserPrincipals？

Answer 1

使用AuthContext API进行身份验证不会填充Java EE声明性角色。为了获得那些填充，你必须登录Java EE领域，这应该有几种方式：

执行基于表单的登录（相应地配置web.xml，然后修改代理配置文件设置，以便它知道登录和错误端点）。
不是我测试过的东西，但我认为HttpServletRequest＃login也可以正常工作。
使用容器执行程序化身份验证的方法。

您需要注意的是，Java EE代理不会基于用户名/密码登录用户，而是存在复杂的String结构（在代码库中称为传输字符串），其中包含用户＆＃39; s SSOTokenID，用于确定用户的姓名和角色。

另请注意，容器倾向于以不同方式实现声明性安全性。在过去，我发现Tomcat需要添加相当多的web.xml才能启用代理的声明性安全性。对我来说，获得声明性安全性的最低要求是：

<security-constraint>
 <web-resource-collection>
  <web-resource-name>matchall</web-resource-name>
  <url-pattern>/*</url-pattern>
 </web-resource-collection>
 <auth-constraint>
  <role-name>AUTHENTICATED_USERS</role-name>
 </auth-constraint>
</security-constraint>

如何以编程方式在Tomcat中对用户进行OpenAM身份验证？

1 个答案: