This question is meant to gather information on how to start a simple Sandbox (without Navigator nor JSON-API) that will support a token like a real Ledger does.
Hi
When starting the sandbox you shall provide a configuration file that includes the type and the path of your certificate. The sample file can be seen in your attached screenshot. Then your sandbox start command will look like this:
You may find other types of certification possibilities here.
The generated .crt file’s path should be put into the config file that you pass in as an argument when starting the sandbox.
Every client method has an overload that allows a token to be passed
This way the Ledger API requests will be required to include a JWT token for interacting with the ledger. Here is an example of that if you are using the Java bindings.
Regarding your second question, I can not give you a definitive answer as it depends on your use case.
You may use HMAC RS 256, but for production, it is not considered safe. It is mentioned under a warning section in the documentation.
canton.participants.sandbox.ledger-api.auth-services = [{ type = unsafe-jwt-hmac-256 secret = "not-safe-for-production" }]
Bests,
József
For some reason his response is pending at the moment, will get that fixed later! but trying to get this to you asap, hope it helps!
When starting the sandbox you shall provide a configuration file that includes the type and the path of your certificate. The sample file can be seen in your attached screenshot. Then your sandbox start command will look like this:
You may find other types of certification possibilities here.
The generated .crt file’s path should be put into the config file that you pass in as an argument when starting the sandbox.
Every client method has an overload that allows a token to be passed
This way the Ledger API requests will be required to include a JWT token for interacting with the ledger. Here is an example of that if you are using the Java bindings.
Regarding your second question, I can not give you a definitive answer as it depends on your use case.
You may use HMAC RS 256, but for production, it is not considered safe. It is mentioned under a warning section in the documentation.
canton.participants.sandbox.ledger-api.auth-services = [{
type = unsafe-jwt-hmac-256
secret = "not-safe-for-production"
}]
I want to start the sandbox with the less strict approach which you mentioned lastly in your reply (shared secret) :
canton.participants.sandbox.ledger-api.auth-services = [{
type = unsafe-jwt-hmac-256
secret = "XXX"
}]
My question is not how to do so since it’s fairly straight forward (just create a token with the same secret in auth.conf) but rather on the concept itself:
Once i create the JWT token with a secret XXX and provide an auth.conf as above (containing same secret), how do i leverage it when starting a sandbox?
I mean, do i pass the auth.conf path to the command as shown below and then my Sandbox will accept all secured API’s with every possible token as long as those tokens generated with XXX secret?
e.g All JSON-API, damlhub and gRPC based requests which pass a token to the Ledger will be authenticated as long as the token used with it was generated with XXX secret?
Yes, if you use the secret Sandbox will accept all tokens as valid that are signed with the given secret. The token being valid doesn’t mean that your request is properly authorized though, e.g., consider a token with actAs = alice and you send a request that requires actAs = bob. Your request will still get rejected.
So the secret controls whether the token is a valid token but the ledger still checks the claims within the token as usual.
Will this token based on shared secret can be used to create/allocate parties so upon exercising a command on their behalf will be accepted (regardless on their actAs and readAs prevliges which you explained)?
