将 JWT 承载传递给受保护的 JAX-RS 资源时，Payara Micro 返回 AuthenticationStatus.SEND_FAILURE

Question

我对 Java 编程比较陌生，所以请多多包涵。我正在开发一个部署在 Payara Micro 上的微服务。为了安全起见，我使用的是 JWT。因为 Payara Micro 是 MicroProfile 的实现，所以我尝试利用 MicroProfile JWT auth 规范（Payara Micro 实现规范 1.1）。按照规范，我用@LoginConfig注释了JAX-RS配置类：

@ApplicationScoped
@LoginConfig(authMethod = "MP-JWT")
@DeclareRoles({"admin", "standard", "premium"})
@ApplicationPath("/*")
public class IdentityService extends Application {}

Payara Micro 实现了一个过滤器，可以激活 JAX-RS 资源上的 @RolesAllowed 注释（通常只对 EJB 可用）。我正在利用此注释来识别 JWT 的声明，使用 MP JWT auth 规范中的 JsonWebToken 接口来确定是否允许用户发出 GET 请求以根据声明中的 id 访问用户的信息：

@RolesAllowed({"admin", "standard", "premium"})
@RequestScoped
@Path("/users")
@Produces(MediaType.APPLICATION_JSON)
public class UserEndpoint {

    @Inject
    private JsonWebToken jwtPrincipal;

    @Inject
    private UserRepository userRepo;

    @Path("/{id}")
    @GET
    public Response get(@PathParam("id") String id) {
        if (!jwtPrincipal.getSubject().equalsIgnoreCase(id))
            return Response.status(Response.Status.FORBIDDEN).build();
        User user;
        user = userRepo.get(UUID.fromString(id));
        return Response.status(Response.Status.OK).entity(user).build();
    }

此外，根据Payara's MP JWT auth activation guide，我在我的META-INF/microprofile-config.properties 文件中提供以下配置属性供Payara 验证：

mp.jwt.verify.issuer = com.someDomain
mp.jwt.verify.publickey.location = jwtPublic.pem

应该注意的是，我根据用户登录信息通过单独的@PermitAll 端点出售我自己的 JWT。然而，这些似乎是正确构造的，因为它们可以很容易地被调试并且签名在jwt.io的调试器中得到验证（不提供验证密钥，因为问题已经足够长了）：

ew0KICAidHlwIiA6ICJKV1QiLA0KICAiYWxnIiA6ICJSUzI1NiINCn0=.ew0KICAiaXNzIiA6ICJjb20uc29tZURvbWFpbiIsDQogICJzdWIiIDogIjA5M2EzYzRlLWRiZTItNGI2YS05NzU4LTI5YjM2NjU1MTljOSIsDQogICJleHAiIDogMTU2NTM1Mjc2OCwNCiAgImlhdCIgOiAxNTY1MzA5NTY4LA0KICAidXBuIiA6ICJzb21lRW1haWxAZW1haWwuY29tIiwNCiAgImp0aSIgOiAiYmU0OTNhMTgtOGZiOS00NmM3LTgwMmEtNDY1YjFhYmM2YmZlIiwNCiAgImdyb3VwcyIgOiBbICJzdGFuZGFyZCIgXSwNCiAgInByZWZlcnJlZF91c2VybmFtZSIgOiAiY2FtZXJvbjIiDQp9.F97KMZbkPNuMATlYm0pLKalvadf_aAoxgPiNR-V-Y8toeYNqAm-w1WwnttQCeBuWvXjvPCm70y-HDGGv2tB-KuzHFxKxreyDue11db1fQ6o7QtYWSYvu_1y8bhOnB-MUz3MWnhRSHj8GpCQkrYXNACW9VSv8poqgyhyctEhi98LHGCFLyg1JNrzZw2J7fCdOYeoVZlgo-I9F4XA7FIXSQxgUii1T5RcGkky3tBKVUZ8jIigW68LXtYlq12lfo3PDATxou7c5ybMijLYuwPi7A6rb5bvsqAdsO-mSP6M6t42mUYGJuJ9dx_GmhWOpYzfgFaynMHElpuV58q7pXP5_JRvMx37yHMuA0Z_dj9ruSBqqH-lN0gV3CDheuHICbxAwqFvCEgVG7ZC4S3JNkSTqofifw_iXfTJX-v8cfWI3kfH7PrZmSmrMApGQLt5bQw_HIcIWfbHuA9_r-YksdIzJRsW-2JpSEHxRPeGvq5BlXlMSWu4BoefGcTbj6OKj6Gz_Zb5O8l8mOxQAT3wElN3DRxj3M_jxRM6kg-C-DlEFAxFivNQGbpE4CSKnLaY8XnTeL3j3Pq7tnYm1kG4PWeHCppr9CKgITjfrzzY3UNQX56WwDuRFTfgmY2Tnji4xqmLxxVCGE8ahM8mnxouIiwlPjlixkRXJfkxYb8YaQSMjIGw=

但是，@RolesAllowed 注释的行为似乎出乎意料。当我在将 JWT 不记名令牌作为授权 HTTP 标头传递时向端点发送 curl 时：

curl -i --header "Authorization: Bearer ew0KICAidHlwIiA6ICJKV1QiLA0KICAiYWxnIiA6ICJSUzI1NiINCn0=.ew0KICAiaXNzIiA6ICJjb20uc29tZURvbWFpbiIsDQogICJzdWIiIDogIjA5M2EzYzRlLWRiZTItNGI2YS05NzU4LTI5YjM2NjU1MTljOSIsDQogICJleHAiIDogMTU2NTM1Mjc2OCwNCiAgImlhdCIgOiAxNTY1MzA5NTY4LA0KICAidXBuIiA6ICJzb21lRW1haWxAZW1haWwuY29tIiwNCiAgImp0aSIgOiAiYmU0OTNhMTgtOGZiOS00NmM3LTgwMmEtNDY1YjFhYmM2YmZlIiwNCiAgImdyb3VwcyIgOiBbICJzdGFuZGFyZCIgXSwNCiAgInByZWZlcnJlZF91c2VybmFtZSIgOiAiY2FtZXJvbjIiDQp9.F97KMZbkPNuMATlYm0pLKalvadf_aAoxgPiNR-V-Y8toeYNqAm-w1WwnttQCeBuWvXjvPCm70y-HDGGv2tB-KuzHFxKxreyDue11db1fQ6o7QtYWSYvu_1y8bhOnB-MUz3MWnhRSHj8GpCQkrYXNACW9VSv8poqgyhyctEhi98LHGCFLyg1JNrzZw2J7fCdOYeoVZlgo-I9F4XA7FIXSQxgUii1T5RcGkky3tBKVUZ8jIigW68LXtYlq12lfo3PDATxou7c5ybMijLYuwPi7A6rb5bvsqAdsO-mSP6M6t42mUYGJuJ9dx_GmhWOpYzfgFaynMHElpuV58q7pXP5_JRvMx37yHMuA0Z_dj9ruSBqqH-lN0gV3CDheuHICbxAwqFvCEgVG7ZC4S3JNkSTqofifw_iXfTJX-v8cfWI3kfH7PrZmSmrMApGQLt5bQw_HIcIWfbHuA9_r-YksdIzJRsW-2JpSEHxRPeGvq5BlXlMSWu4BoefGcTbj6OKj6Gz_Zb5O8l8mOxQAT3wElN3DRxj3M_jxRM6kg-C-DlEFAxFivNQGbpE4CSKnLaY8XnTeL3j3Pq7tnYm1kG4PWeHCppr9CKgITjfrzzY3UNQX56WwDuRFTfgmY2Tnji4xqmLxxVCGE8ahM8mnxouIiwlPjlixkRXJfkxYb8YaQSMjIGw=" "localhost:8080/users/093a3c4e-dbe2-4b6a-9758-29b3665519c9"

我收到以下回复：

HTTP/1.1 401 Unauthorized
Server: Payara Micro #badassfish
WWW-Authenticate: Authentication resulted in SEND_FAILURE

翻遍了Payara的源代码，发现这个回复是here收到的。

显然，当从SecurityContext 接收到的Principal 为空并且在 JAX-RS 资源中存在@RolesAllowed 注释时，就会发生这种情况。然后显然调用了容器提供的身份验证模块，在 Payara 的例子中是 BASIC 身份验证：https://github.com/payara/Payara/issues/2326#issuecomment-367855133。但是，当我指定 @LoginConfig(authMethod="MP-JWT") 并且我提供 JWT 作为授权标头时，我不明白为什么要使用 BASIC 身份验证。 github上有与此相关的问题，但我无法找到有关修复内容的明确答案。

所以，我的问题是，我是否错误地解释了如何让 Payara 生成调用者的可注射 JsonWebToken？如何解决此 SEND_FAILURE 响应？

Answer 1

对于可能遇到此问题的任何人，在查看source code for Payara's SignedJWTIdentityStore 后，我意识到 Payara 不会扫描 META-INF/microprofile-config.properties 文件以验证发行者和公钥。虽然Payara's guide to activating MP JWT Auth 没有明确说明这一点，但您无法从该文件配置颁发者或公钥位置。要配置您接受的颁发者，您必须在 src/main/resources 目录中放置一个名为 payara-mp-jwt.properties 的文件，其密钥为 accepted.issuer 和预期值（例如 accepted.issuer = someDomain.com）。此外，要配置您的公钥，您必须将名为 publicKey.pem 的公钥放在同一目录中。 Payara 将仅扫描这些文件，不会扫描 META-INF/microprofile.config 以获取您配置的公钥和接受的颁发者值：

public SignedJWTIdentityStore() {
        config = ConfigProvider.getConfig();

        Optional<Properties> properties = readVendorProperties();
        acceptedIssuer = readVendorIssuer(properties)
                .orElseGet(() -> config.getOptionalValue(ISSUER, String.class)
                .orElseThrow(() -> new IllegalStateException("No issuer found")));

        jwtTokenParser = new JwtTokenParser(readEnabledNamespace(properties), readCustomNamespace(properties));
    }

private Optional<Properties> readVendorProperties() {
        URL mpJwtResource = currentThread().getContextClassLoader().getResource("/payara-mp-jwt.properties");
        Properties properties = null;
        if (mpJwtResource != null) {
            try {
                properties = new Properties();
                properties.load(mpJwtResource.openStream());
            } catch (IOException e) {
                throw new IllegalStateException("Failed to load Vendor properties from resource file", e);
            }
        }
        return Optional.ofNullable(properties);
    }

包含这些将导致JsonWebToken 被正确注入。如果没有扫描，我不确定为什么 Payara 的文档会费心包含其他文件配置选项。