Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Handle user token alongside claim tokens in the JSON API

See original GitHub issue

Reference design document for the overall user management service: https://docs.google.com/document/d/1o6gAgAVNji5-kR2xX82h4M0gINIJs3pgDj2IDGew-E0/edit

The user management service is described by the gRPC definition added in https://github.com/digital-asset/daml/pull/11818 and refined in https://github.com/digital-asset/daml/pull/11908.

A claim token is a JWT in the current form of tokens accepted by the Ledger API where claims are laid out explicitly in the token itself.

A user token is a JWT in the form expressed by the user management service design document linked above. The sub field (which is a default field in the JWT specification) specifies the user. The user is used to resolve the claims to fill in the necessary fields on the JSON API throught the user management service.

The user management service will need to be mocked until https://github.com/digital-asset/daml/issues/12014 is closed.

The user management service client already exists on the Scala bindings, added as part of https://github.com/digital-asset/daml/issues/12009.

Acceptance criteria

The HTTP-JSON API accepts user tokens, resolve their claims and fill in the fields required
When using the user tokens ~only the primary party of the user is filled in as the actAs party~ the full set of claims resolved for that user is filled in into the request
The actAs and readAs party can otherwise be overridden by the existing mechanism
- the streaming endpoints are not yet capable of overriding actAs and readAs, this is a known limitation and is out of scope as part of this ticket
The old claim tokens are still accepted by the HTTP-JSON API

Issue Analytics

State:
Created 2 years ago
Comments:12 (12 by maintainers)

Top GitHub Comments

2reactions

meiersi-dacommented, Dec 9, 2021

Good point. I believe the validity of the token (against the exp field) will still be checked by the participant just as it does now, but I would like to ask @meiersi-da and @mziolekda for a confirmation.

Yes, the server checks the token’s exp field on every request. In general, the server code remains the same wrt checking token validity. The only thing that changes is that user tokens are supported in addition to the claim tokens, and a user token’s associated rights are resolved by the server before checking a request authorization against these rights.

For reference, I’ve inlined a schematic depiction of the changes on the server side below. User token and user management support in the Ledger API server

0reactions

stefanobaghino-dacommented, Dec 9, 2021

Thanks for confirming, Simon.

Top Results From Across the Web

JSON Web Token Claims

JSON web tokens (JWTs) claims are pieces of information asserted about a subject. For example, an ID token (which is always a JWT...

Securing Node.js RESTful APIs with JSON Web Tokens

It's a way of encrypting a value, in turn creating a unique token that users use as an identifier. This token verifies your...

The Ultimate Guide to handling JWTs on frontend clients ...

JWTs (JSON Web Token, pronounced 'jot') are becoming a popular way of handling auth. This post aims to demystify what a JWT is,...

How to get an access token with JWT Grant

How to get an access token with JWT Grant. This topic demonstrates how to generate an access token manually using JSON Web Token...

JSON Web Token Introduction - jwt.io

Information Exchange: JSON Web Tokens are a good way of securely transmitting information between parties. Because JWTs can be signed—for example, ...