Files
nats-server/server
Matthias Hanel b7ee177497 Adding templates to scoped signing key user permis (#3367)
For security reasons we have introduced scoped signing keys to jwt.
They carry user permissions.
Wich is why jwt issued by those keys are not allowed to carry their own permission.
Instead they are copied from the signing key.
If the scoped signing key gets compromised, an attacker can only issue jwt with the permissions of the key.
With a plain signing key, an attacker can create arbitrary user with permissions.
Because user jwt creation is greatly simplified we added a single utility function to go/java/.net which issues user for such keys.
This is function is documented in ADR-14:

```
/**
 * signingKey, is a mandatory account nkey pair to sign the generated jwt.
 * accountId, is a mandatory public account nkey. Will return error when not set or not account nkey.
 * publicUserKey, is a mandatory public user nkey. Will return error when not set or not user nkey.
 * name, optional human readable name. When absent, default to publicUserKey.
 * expiration, optional but recommended duration, when the generated jwt needs to expire. If not set, JWT will not expire.
 * tags, optional list of tags to be included in the JWT.
 *
 * Returns:
 * error, when issues arose.
 * string, resulting jwt.
 **/
IssueUserJWT(signingKey nkey, accountId string, publicUserKey string, name string, expiration time.Duration, tags []string) (error, string)
```

Currently the only downside of this is that the permissions are static and can't be tailored to the user.

This PR changes that by allowing the user pub/sub permissions to be parameterized with templates.

templates are for entire tokens only and include:
{{name()}} -> username
{{subject()}} -> user subject (nkey)
{{account-name()}} -> users account name
{{account-subject()}} -> user accoutn subject (nkey)

{{tag(arbitrary-prefix)}}
provided the tag "arbitrary-prefix:value" will result in "value"
provided the tags ["arbitrary-prefix:1", "arbitrary-prefix:2"] will result in two subjects "1" & "2"

If the resulting subject is not valid.
Say a tag is not present or name is not set.
This will result in an error for deny subjects
and result in no subject for allow subject.

Signed-off-by: Matthias Hanel <mh@synadia.com>

Signed-off-by: Matthias Hanel <mh@synadia.com>
2022-08-15 12:49:35 -07:00
..
2022-07-05 09:33:12 +01:00
2022-07-28 17:25:37 -06:00
2022-01-21 11:03:19 -08:00
2022-07-06 13:16:13 -07:00
2022-07-06 13:16:13 -07:00
2022-08-12 11:15:38 -06:00
2021-11-15 17:23:08 -07:00
2022-07-05 09:28:00 +01:00
2021-11-15 17:23:08 -07:00
2022-07-05 09:28:00 +01:00
2021-11-15 17:23:08 -07:00
2022-03-17 17:53:06 -06:00
2022-04-01 17:55:33 -06:00
2022-01-21 11:03:19 -08:00
2020-06-12 10:03:47 -06:00
2022-03-17 17:53:06 -06:00
2021-11-15 17:23:08 -07:00
2021-11-15 17:23:08 -07:00
2022-07-05 09:33:12 +01:00
2021-09-01 14:55:26 -07:00
2022-07-05 09:28:00 +01:00
2022-06-24 09:17:12 -07:00
2022-07-28 17:25:37 -06:00
2022-07-28 17:25:37 -06:00
2022-03-25 12:11:55 -06:00

Tests

Tests that run on Travis have been split into jobs that run in their own VM in parallel. This reduces the overall running time but also is allowing recycling of a job when we get a flapper as opposed to have to recycle the whole test suite.

JetStream Tests

For JetStream tests, we need to observe a naming convention so that no tests are omitted when running on Travis.

The script runTestsOnTravis.sh will run a given job based on the definition found in ".travis.yml".

As for the naming convention:

  • All JetStream tests name should start with TestJetStream
  • Cluster tests should go into jetstream_cluster_test.go and start with TestJetStreamCluster
  • Super-cluster tests should go into jetstream_super_cluster_test.go and start with TestJetStreamSuperCluster

Not following this convention means that some tests may not be executed on Travis.