I am testing full mTLS, JWT lockdown for Canton. I see the following errors whilst running Navigator in the Participant console based on the JWT provided.
Errors:
WARN c.d.l.a.a.Authorizer - PERMISSION_DENIED(7,0): Claims are only valid for applicationId ‘navigator’, actual applicationId is ‘Navigator-3d8d44de-c786-4c04-a0c9-f98a50c21dc0#d339ffd69621ad9b’, context: {participant: “participant1”, err-context: “{location=Authorizer.scala:218}”}
WARN c.d.l.a.a.Authorizer - PERMISSION_DENIED(7,0): Claims are only valid for applicationId ‘navigator’, actual applicationId is ‘Navigator-3d8d44de-c786-4c04-a0c9-f98a50c21dc0#d339ffd69621ad9b’, context: {participant: “participant1”, err-context: “{location=Authorizer.scala:218}”}
WARN c.d.l.a.a.Authorizer - PERMISSION_DENIED(7,0): Claims are only valid for applicationId ‘navigator’, actual applicationId is ‘Navigator-3d8d44de-c786-4c04-a0c9-f98a50c21dc0#d339ffd69621ad9b’, context: {participant: “participant1”, err-context: “{location=Authorizer.scala:218}”}
JWT:
./decode-jwt.sh ./certs/participant1/jwt/navigator.token
{
“alg”: “RS256”,
“typ”: “JWT”,
“kid”: “GZbwkEIQc5l3FfHqN_VozbjDyA_TaL3ww9OmWSO7E2A”
}
{
“exp”: 1660597397,
“scope”: “daml_ledger_api”,
“iss”: “local-jwt-provider”,
“iat”: 1660510997,
“sub”: “navigator”,
“aud”: “participant1::1220fce212426c4f261683f236c6cc56afeada8a72d9242835a1a6e634316adcad8a”
}
Expiry Date: 08/15/2022:17:03:17
Questions/Comments:
- Is it possible to set an application-id for Navigator (don’t see in command line options)?
- What is the format of the UUID and how does this get set?
- These errors appear every so often so seems that a refresh process must be running in background.
- Is there a way to set an Application-ID in a User based JWT token or is the audience seen as the application?
- If I want to see transactions that the participant is executing (Admin flows like ping or dar sharing), do I just need to set primaryParty to the Participant Id?
Thanks
Hi @nycnewman,
I’ll answer some of your questions, leaving others to fill in the blanks.
Is it possible to set an application-id for Navigator (don’t see in command line options)?
What is the format of the UUID and how does this get set?
As far as I can see that is not possible. The application ID is generated with s"Navigator-${UUID.randomUUID().toString}" in https://github.com/digital-asset/daml/blob/32dca5b398c93e1fc76cd13b141a3738a0b24d8c/navigator/backend/src/main/scala/com/digitalasset/navigator/NavigatorBackend.scala#L20
The UUID is random, the string format of the UUID follows from https://docs.oracle.com/javase/7/docs/api/java/util/UUID.html#toString()
These errors appear every so often so seems that a refresh process must be running in background.
I’m assuming this is the participant complaining about the calls that navigator makes, the navigator actively makes requests to the ledger and also subscribes to it.
Is there a way to set an Application-ID in a User based JWT token or is the audience seen as the application?
The application ID is generated as shown above, the application ID is not taken from the token.
Cheers,
Ray
So the core question is how is the JWT token claiming it is “navigator” app and yet Navigator is create a separate app ID for itself. Seems Navigator can see contracts for the user but cannot act on them.
Token is user based to a “navigator” User which then has ParticipantAdmin and CanActAs rights for one or more local parties. No primary party is set on User.
navigator comes from the token you’re passing in. The application id is not something that Navigator derives from the token, it generates a random app id using the code @Raymond_Roestenburg linked to.
But the ledger API does not require an application id for all requests. The main thing it’s used for is command submissions. It is not used for reads. So for reads, your token is perfectly fine. For writes, it’ll blow up because there is a mismatch between Navigator’s randomly generated application id and the one in your token.
I think your best option is to use the custom claims token for now and omit the applicationId field. That means the ledger will not check your app id against your token at all so the requests should go through.
The real fix imho is to adjust navigator to use the application id from the token/rely on app id defaulting.
I can try this. However the confusion is why it is getting any App-id from the token. Seems that the user name is also the app-id which is counter-intuituve.
That’s expected behavior. The user id is used as application id for auth purposes and you can even omit the application id in requests when running with auth and the ledger API server infers it from the token (that’s what is called “app id defaulting”).