Issue with Auth0 JWT Roles

1

I’m having issues getting authentication by JWT token roles to work.

The second rule is set to always pass, and does so successfully - it logs the user name as expected. The first rule always fails, despite the JWT showing the correct roles per jwt.io - it also fails to log the user name in the USR output field.

I’ve been banging my head on this for a few days, and have exhausted my store of ideas. Any thoughts or suggestions?

Thanks!

ROR v1.17.6
Elastic v6.7.1
Ubuntu 18.04.2 LTS

readonlyrest.yml contents:

readonlyrest:
    access_control_rules:
    - name: sysadmin - full access
      type: allow
      indices: ["*"]
      jwt_auth:
        name: admin_web
        roles: ["admin_web-sysadmin"]
    - name: jwt any
      type: allow
      indices: ["*"]
      jwt_auth:
        name: jwt_auth

    jwt:
    - name: jwt_auth
      signature_algo: RSA
      signature_key: {key}
      user_claim: name
      roles_claim: "https://{domain.tld}/claims/roles"
      header_name: Authorization
2

the “name” under “jwt_auth” is a reference to the name of the connector, not a restriction on what user name should match.

You can simply use the users rule to restrict what username will match.

So it would become:

readonlyrest:
    access_control_rules:
    - name: sysadmin - full access
      type: allow
      indices: ["*"]
      users: ["admin_web"] # <--- added
      jwt_auth:
        name: jwt_auth_connector_1 # <-- reference to connector name
        roles: ["admin_web-sysadmin"]
    - name: jwt any
      type: allow
      indices: ["*"]
      jwt_auth:
        name: jwt_auth

    jwt:
    - name: jwt_auth_connector_1 # <-- connector named a bit more explicitly
      signature_algo: RSA
      signature_key: {key}
      user_claim: name
      roles_claim: "https://{domain.tld}/claims/roles"
      header_name: Authorization
3

Hi, thanks for the response.

I made those changes with no improvement. The first rule continues to fail, and continues to fail to recognize the user name. (USR:[user not logged]).

My initial worry was that it was failing to decode the JWT entirely, or that I was improperly referencing the user/roles claim, but that it recognizes the user name in the second rule alleviated that concern a bit. Is there any further info I can provide that may help?

4

Can you make sure the settings changes are picked up and loaded correctly? Try to change the name of one block and see it reloaded in es logs

5

Changed “jwt any” => “jwt open auth”. No automatic reload (waited ~30 seconds), but restarting ES picked up the change.

6

Does it mean that now it works well?

7

No - the rule’s name changed as expected, but the first rule still fails to pass.

8

Also potentially worth noting - the request is blocked as expected with no token, or an expired token.

9

My gut tells me that it isn’t parsing the role names correctly somehow, but I’m at a loss as to how to prove that - I can’t figure out how to, or even if I’m able to, log the parsed token in any way. I followed the instructions to set the logging level to debug, which is giving quite a bit more information, not all of which is helpful.

10

Are you able to share a sample JWT token and a private key for us to test this?

11

Sure.

JWT:
removed

Key:
removed

13

OK basically, your claim name is mistakenly detected as a JSONPath because it contains a dot.
Can you try avoiding having a whole URL as a claim name?

@coutoPL, can you make JSONPath detection more precise than checking for a dot? I.e.

  def isValidJsonPath(path:String): Boolean = {
    Try(JsonPath.read("{}", path)).isSuccess
  }

Maybe with some optimisation around this because stack traces are expensive.

14

I can’t, first thing I tried - Auth0 requires url namespaces for custom claims (JSON Web Token Claims). Stuck with a url as a name.

15

Upon further experimentation, it looks like I can remove the .{tld} from my Auth0 claim (leaving “https://{domain}/claims/roles”), despite what their docs say they require.

I don’t feel good about this as a long term solution since it’s contradicted by what their docs state is their intended behavior, but it at least works for now, and seems to verify your conclusion that it’s the dot that’s causing the problem.

1 Like
16

sure. I’ve started to work on RORDEV-6, which contains fixes according to json path in this rule. Then we lowered priority of the task. But I see we’ve scheduled it for a next sprint.

1 Like
17

This fix is coming in a matter of days, no worries about it. Thanks for finding this issue!

1 Like
18

Thanks for the reassurance, and for the quick fix <3

1 Like
19

Fixed: fixed: jsonpath lib used as ClaimName by coutoPL · Pull Request #453 · sscarduzio/elasticsearch-readonlyrest-plugin · GitHub. Will be released soon.

1 Like