Findings about user management and JWT

Questions
1

Hi team,

I am testing the two types of JWTs per document here.

The user access token is working well.

When I tried the Custom Daml claims access tokens, I found that the applicationId becomes significant and is linked to the userId.

Below is my findings. I am using the daml new project the sample Daml code, using Sandbox, script Main:setup, and JSON-API for testing.

if I used this

{
   "https://daml.com/ledger-api": {
     "ledgerId": null,
     "participantId": "sandbox",
     "applicationId": null,
     "admin": false,
     "actAs": ["Alice::1220a0ca8969b5cdef3572e27ee6ca6cd227efb85fc4e289b1971590fc2520b4f6ba"]
   },
   "exp": 1963027803
}

I got this error

{
    "errors": [
        "This user token contains no applicationId/userId"
    ],
    "status": 401
}

From the error message it seems applicationId is relevant to userId.

Then I tried to use the userId (alice and bob) on applicationId, that is, alice and bob. It works fine even without the actAs. I also tried to use charlie which is not a valid userId, then I received this error message.

{
    "errors": [
        "NOT_FOUND: USER_NOT_FOUND(11,0): list user rights failed for unknown user \"charlie\""
    ],
    "status": 404
}

Is this a design intent linking the userId to applicationId? It seems this is not what’s described in the doc.

Many thanks in advance.

kc

1 Like
2

We’re in a transition phase in which we are slowly moving towards using user tokens over claim tokens (with the latter still staying for the foreseeable future).

My recommendation is to use user tokens if you can and fall back to claim tokens only if you really have to.

If for any reason you need to work in an environment where the IAM needs to issue claim tokens but your ledger supports user tokens, than yes: we will use the applicationId as the userId in this circumstance. Ideally this should only be a transition and the IAM should align itself with the new user management feature that got into Daml 2.0.

The new format doesn’t have custom claims and by using standard ones we hope it to be easier to deal with. In particular, it allows to fine tune user access control on the ledger without unloading the weight on the IAM by requiring very complex tokens.

Would you mind pointing me at the documentation page you found confusing and/or misleading? Happy to have a look and see if we can improve it.

1 Like
3

Thanks @stefanobaghino-da for your prompt reply.

I agree that using user token is much better. The document I mentioned is more about applicationId (link) relevant to userId. If it is just in transition, then it should be ok.

Thanks again.

kc

4

Are you using the Ledger API directly or through the HTTP JSON API?

5

For this test I’m using JSON-API.

6

Ok, then a clarification: what I said applies specifically to the HTTP JSON API, not the Ledger API.