Issues configuring JWT ACL #14530

sssmc · 2025-01-12T05:58:43Z

sssmc
Jan 12, 2025

I am currently trying to implement a basic JWT ACL. I am able to successfully authenticate to the broker using the JWT. I have included the following claim in the JWT:

    "acl": [
      {
        "action": "all",
        "permission": "allow",
        "topic": "testing/#"
      }
    ],
    "exp": 1736742202,
    "username": "auth0|6780a2d9d25eaaea97f7fe1b"
  },

I would expect that this would allow the authenticated users to subscribe/publish to topics testing/# such as testing/foo. However, I get Failed to Subscribe testing/foo, Error: Not authorized(Code: 135). when trying to subscribe to testing/foo (using MQTTX).

Here is the log trace of the login and the subscription attempt:

2025-01-12T05:42:57.089138+00:00 [MQTT] mqttx_5d343101@70.66.168.229:12610 msg: mqtt_packet_received, packet: CONNECT(Q0, R0, D0, ClientId=mqttx_5d343101, ProtoName=MQTT, ProtoVsn=5, CleanStart=true, KeepAlive=60, Username=auth0|6780a2d9d25eaaea97f7fe1b, Password=******), username: auth0|6780a2d9d25eaaea97f7fe1b
2025-01-12T05:42:57.090285+00:00 [AUTHN] mqttx_5d343101@70.66.168.229:12610 msg: authenticator_result, authenticator: jwt, result: {ok,#{client_attrs => #{},is_superuser => false,expire_at => 1736744380000,acl => #{rules => #{<<"acl">> => [#{<<"action">> => <<"all">>,<<"permission">> => <<"allow">>,<<"topic">> => <<"testing/#">>}],<<"exp">> => 1736742202,<<"username">> => <<"auth0|6780a2d9d25eaaea97f7fe1b">>},expire => 1736744380,source_for_logging => jwt}}}, username: auth0|6780a2d9d25eaaea97f7fe1b
2025-01-12T05:42:57.090963+00:00 [AUTHN] mqttx_5d343101@70.66.168.229:12610 msg: authentication_result, reason: chain_result, result: {stop,{ok,#{client_attrs => #{},is_superuser => false,expire_at => 1736744380000,acl => #{rules => #{<<"acl">> => [#{<<"action">> => <<"all">>,<<"permission">> => <<"allow">>,<<"topic">> => <<"testing/#">>}],<<"exp">> => 1736742202,<<"username">> => <<"auth0|6780a2d9d25eaaea97f7fe1b">>},expire => 1736744380,source_for_logging => jwt}}}}, username: auth0|6780a2d9d25eaaea97f7fe1b
2025-01-12T05:42:57.092404+00:00 [WS-MQTT] mqttx_5d343101@70.66.168.229:12610 msg: mqtt_packet_sent, packet: CONNACK(Q0, R0, D0, AckFlags=0, ReasonCode=0), username: auth0|6780a2d9d25eaaea97f7fe1b
2025-01-12T05:42:57.093524+00:00 [debug] clientid: mqttx_5d343101, msg: insert_channel_info, peername: 70.66.168.229:12610, username: auth0|6780a2d9d25eaaea97f7fe1b
2025-01-12T05:43:04.584024+00:00 [debug] tag: MQTT, clientid: 582befc7-72c1-438e-bd8e-c5917af453c2, msg: raw_bin_received, peername: 70.66.168.229:12534, username: auth0|6780a2d9d25eaaea97f7fe1b, size: 2, type: hex, bin: C000
2025-01-12T05:43:04.584720+00:00 [WS-MQTT] 582befc7-72c1-438e-bd8e-c5917af453c2@70.66.168.229:12534 msg: mqtt_packet_received, packet: PINGREQ(Q0, R0, D0), username: auth0|6780a2d9d25eaaea97f7fe1b
2025-01-12T05:43:04.585140+00:00 [WS-MQTT] 582befc7-72c1-438e-bd8e-c5917af453c2@70.66.168.229:12534 msg: mqtt_packet_sent, packet: PINGRESP(Q0, R0, D0), username: auth0|6780a2d9d25eaaea97f7fe1b
2025-01-12T05:43:13.289993+00:00 [debug] tag: MQTT, clientid: mqttx_5d343101, msg: raw_bin_received, peername: 70.66.168.229:12610, username: auth0|6780a2d9d25eaaea97f7fe1b, size: 1, type: hex, bin: 82
2025-01-12T05:43:13.290560+00:00 [debug] tag: MQTT, clientid: mqttx_5d343101, msg: raw_bin_received, peername: 70.66.168.229:12610, username: auth0|6780a2d9d25eaaea97f7fe1b, size: 1, type: hex, bin: 11
2025-01-12T05:43:13.290940+00:00 [debug] tag: MQTT, clientid: mqttx_5d343101, msg: raw_bin_received, peername: 70.66.168.229:12610, username: auth0|6780a2d9d25eaaea97f7fe1b, size: 2, type: hex, bin: FE8C
2025-01-12T05:43:13.291431+00:00 [debug] tag: MQTT, clientid: mqttx_5d343101, msg: raw_bin_received, peername: 70.66.168.229:12610, username: auth0|6780a2d9d25eaaea97f7fe1b, size: 1, type: hex, bin: 00
2025-01-12T05:43:13.295309+00:00 [debug] tag: MQTT, clientid: mqttx_5d343101, msg: raw_bin_received, peername: 70.66.168.229:12610, username: auth0|6780a2d9d25eaaea97f7fe1b, size: 2, type: hex, bin: 000B
2025-01-12T05:43:13.295986+00:00 [debug] tag: MQTT, clientid: mqttx_5d343101, msg: raw_bin_received, peername: 70.66.168.229:12610, username: auth0|6780a2d9d25eaaea97f7fe1b, size: 11, type: hex, bin: 74657374696E672F666F6F
2025-01-12T05:43:13.296384+00:00 [debug] tag: MQTT, clientid: mqttx_5d343101, msg: raw_bin_received, peername: 70.66.168.229:12610, username: auth0|6780a2d9d25eaaea97f7fe1b, size: 1, type: hex, bin: 00
2025-01-12T05:43:13.296933+00:00 [WS-MQTT] mqttx_5d343101@70.66.168.229:12610 msg: mqtt_packet_received, packet: SUBSCRIBE(Q1, R0, D0, PacketId=65164 TopicFilters=[testing/foo(#{nl => 0,qos => 0,rap => 0,rh => 0})]), username: auth0|6780a2d9d25eaaea97f7fe1b
2025-01-12T05:43:13.297355+00:00 [AUTHZ] mqttx_5d343101@70.66.168.229:12610 msg: authorization_matched_deny, action: SUBSCRIBE(Q0), authorize_type: client_info, module: emqx_authz_client_info, topic: testing/foo, username: auth0|6780a2d9d25eaaea97f7fe1b
2025-01-12T05:43:13.297834+00:00 [warning] tag: AUTHZ, clientid: mqttx_5d343101, msg: authorization_permission_denied, peername: 70.66.168.229:12610, username: auth0|6780a2d9d25eaaea97f7fe1b, topic: testing/foo, source: jwt, action: SUBSCRIBE(Q0)
2025-01-12T05:43:13.298421+00:00 [WS-MQTT] mqttx_5d343101@70.66.168.229:12610 msg: mqtt_packet_sent, packet: SUBACK(Q0, R0, D0, PacketId=65164, ReasonCodes=[135]), username: auth0|6780a2d9d25eaaea97f7fe1b

I do not have any other authorization methods enabled.

Is my acl claim formatted correctly? Is there any other debugging steps I can take?

Answered by savonarola

Jan 14, 2025

From the logs, it looks like the JWT's ACL had double nesting, like

JWT = {
...
  "acl":
     {
      "acl": [
          {
            "action": "all",
            "permission": "allow",
            "topic": "testing/#"
          }
      ],
      "exp": 1736742202,
      "username": "auth0|6780a2d9d25eaaea97f7fe1b"
    },
...
}.

Could you verify?

These fields should be on the top level of the JWT payload:

"acl": [
    {
      "action": "all",
      "permission": "allow",
      "topic": "testing/#"
    }
],
"exp": 1736742202

View full answer

id · 2025-01-13T06:48:45Z

id
Jan 13, 2025
Maintainer

@sssmc the authorizer that triggered was client_info, not jwt. Do you also have "Client Info" authentication configured?

5 replies

sssmc Jan 13, 2025
Author

@id Thank you for your quick reply. I don't believe I have Client Info authentication enable. I had not considered as an option as I am using the open-source version and I was under the impression that it was an enterprise version only feature. I have not configured it in the dashboard:

and here is the contents of my cluster.hocon

authentication = [
  {
    backend = built_in_database
    bootstrap_file = "${EMQX_ETC_DIR}/auth-built-in-db-bootstrap.csv"
    bootstrap_type = plain
    enable = false
    mechanism = password_based
    password_hash_algorithm {name = sha256, salt_position = suffix}
    user_id_type = username
  },
  {
    disconnect_after_expire = true
    enable = true
    endpoint = "https://dev-xk74bsamhi6vyn3g.ca.auth0.com/.well-known/jwks.json"
    from = password
    headers {}
    mechanism = jwt
    refresh_interval = 300
    ssl {
      ciphers = []
      depth = 10
      enable = true
      hibernate_after = "5s"
      log_level = notice
      reuse_sessions = true
      secure_renegotiate = true
      verify = verify_none
      versions = [
        "tlsv1.3",
        "tlsv1.2"
      ]
    }
    use_jwks = true
    verify_claims {
      aud = "emqx.projectfishworks.ca"
    }
  }
]
authorization {
  cache {
    enable = false
    excludes = []
    max_size = 32
    ttl = "1m"
  }
  deny_action = ignore
  no_match = allow
  sources = []
}

and the contents of base.hocon, cluster.hocon, emqx.conf and my environment variables do not contain any authentication configuration.

id Jan 14, 2025
Maintainer

Right. May be @savonarola or @zmstone know what's going on.

savonarola Jan 14, 2025
Collaborator

Hi! I will try to investigate.

savonarola Jan 14, 2025
Collaborator

From the logs, it looks like the JWT's ACL had double nesting, like

JWT = {
...
  "acl":
     {
      "acl": [
          {
            "action": "all",
            "permission": "allow",
            "topic": "testing/#"
          }
      ],
      "exp": 1736742202,
      "username": "auth0|6780a2d9d25eaaea97f7fe1b"
    },
...
}.

Could you verify?

These fields should be on the top level of the JWT payload:

"acl": [
    {
      "action": "all",
      "permission": "allow",
      "topic": "testing/#"
    }
],
"exp": 1736742202

Answer selected by sssmc

sssmc Jan 15, 2025
Author

Yes, this was the issue. Working great now. Thanks @savonarola @id for you help.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Issues configuring JWT ACL #14530

{{title}}

Replies: 1 comment 5 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

Select a reply

Issues configuring JWT ACL #14530

sssmc Jan 12, 2025

Replies: 1 comment · 5 replies

id Jan 13, 2025 Maintainer

sssmc Jan 13, 2025 Author

id Jan 14, 2025 Maintainer

savonarola Jan 14, 2025 Collaborator

savonarola Jan 14, 2025 Collaborator

sssmc Jan 15, 2025 Author

sssmc
Jan 12, 2025

Replies: 1 comment 5 replies

id
Jan 13, 2025
Maintainer

sssmc Jan 13, 2025
Author

id Jan 14, 2025
Maintainer

savonarola Jan 14, 2025
Collaborator

savonarola Jan 14, 2025
Collaborator

sssmc Jan 15, 2025
Author