Question

我（仍在）学习JASPIC，通过简单的项目进行一些实验：this one。当我通过ServerAuthModule调用受保护资源validateRequest检查凭据并返回AuthStatus.SUCCESS时。 HTTP响应为200但它是空的。我使用这两个curl命令来测试：

curl -H "Content-Type: application/json" -X POST -d '{"username":"xxx","password":"xxx"}' http://localhost:8080/JaspicWeb/services/user/login
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJleHAiOjE0NzE0NzE1ODcsInN1YiI6InVzZXJBIn0.Gyf7w2192vlz3uSwjwtf8z1p9n9k3IqtQMQrubA7oYI" -X GET http://localhost:8080/JaspicWeb/services/user/userA

第一个命令是获取第二个中使用的令牌。我正在使用Jaspic和Wildfly10以及RestEasy。

更新我更新了链接的项目。现在它是一个完整的Jaspic示例。

Answer 1

SAM CallbackHandler是造成麻烦的原因。

首先it.jaspic.sec.TokenConfigProvider忽略运行时传递给它的处理程序：

public ServerAuthConfig getServerAuthConfig(String layer, String appContext, CallbackHandler handler) throws AuthException {
  return serverAuthConfig;
}

然后it.jaspic.sec.TokenServerConfig使用自己的处理程序，它基本上什么都不做：

public TokenServerConfig() throws AuthException {
  // ...
  handler = new CallbackHandler() {
    @Override
    public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
      // just logs its arguments
    }
  };
}

因此，it.jaspic.sec.TokenSAM#validateRequest无法将调用者的身份传达给运行时。因为它仍然错误地返回AuthStatus.SUCCESS，所以从那时起它几乎是未定义的行为，至少就JASPIC而言。有趣的是，好像Servlet容器在这种情况下试图让双方都感到高兴，一方面也尊重SAM AuthStatus建议成功的身份验证消息交换，以及作为应用程序的<security-constraint>在另一方面。不可否认，401，403或者更好的500回复 - 表明认证机制不遵守合同 - 可能不那么容易混淆。

显而易见的解决方案是将运行时提供的处理程序传递给SAM。 API显然没有多大帮助，但对于单个消息层/单个应用程序/单个身份验证机制用例，仅使用懒惰地实例化ServerAuthConfig 就足够了处理程序，当运行时首次通过getServerAuthConfig调用请求它时：

public synchronized ServerAuthConfig getServerAuthConfig(String layer, String appContext, CallbackHandler handler) { if (serverAuthConfig == null) { serverAuthConfig = new TokenServerConfig(handler); } return serverAuthConfig; }

当然，上面调用的新构造函数（只需存储处理程序参数）必须引入it.jaspic.sec.TokenServerConfig。

这两个更改应该使/services/user/userA端点可以访问。

Jaspic：处理对受保护资源的访问

1 个答案: