0

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

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

Payara Micro 实现了一个过滤器，可以激活@RolesAllowedJAX-RS 资源上的注释（通常只对 EJB 可用）。我正在利用此注释来识别 JWT 的声明，使用JsonWebTokenMP JWT auth 规范中的接口来确定是否允许用户发出 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 的 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 的源代码后，我发现这里收到了这个响应。

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

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

4

1 回答 1

1

对于可能遇到此问题的任何人，在查看了Payara 的 SignedJWTIdentityStore 的源代码后，我意识到META-INF/microprofile-config.propertiesPayara 并未扫描该文件以验证颁发者和公钥。虽然Payara 的 MP JWT Auth 激活指南没有明确说明这一点，但您无法从该文件配置颁发者或公钥位置。要配置您接受的发行者，您必须在目录中放置一个payara-mp-jwt.properties带有键accepted.issuer和预期值（例如accepted.issuer = someDomain.com）的src/main/resources文件。此外，要配置您的公钥，您必须将调用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 的文档会费心包含其他文件配置选项。

于 2019-08-09T03:49:21.877 回答