Directory Store

NATS Account Server Configuration

OperatorJWTPath: "/users/synadia/.nsc/nats/AAA/AAA.jwt",
http {
    port: 9090
},
store {
    dir: "/tmp/as_store",
    readonly: false,
    shard: true
}

The server configuration specifies the OperatorJWTPath which is used to validate accounts submitted to the server. If an account is not signed by the specified operator, the update is rejected.

Starting the server:

> nats-account-server -c nas.conf
2019/05/31 12:35:23.430128 [INF] loading configuration from "/Users/synadia/Desktop/nats_jwt_doc/as_dir/nas.conf"
2019/05/31 12:35:23.430417 [INF] starting NATS Account server, version 0.0-dev
2019/05/31 12:35:23.430434 [INF] server time is Fri May 31 12:35:23 CDT 2019
2019/05/31 12:35:23.430462 [INF] loading operator from /users/synadia/.nsc/nats/AAA/AAA.jwt
2019/05/31 12:35:23.430919 [INF] creating a store at /tmp/as_store
2019/05/31 12:35:23.430948 [INF] NATS is not configured, server will not fire notifications on update
2019/05/31 12:35:23.437938 [INF] http listening on port 9090
2019/05/31 12:35:23.437953 [INF] nats-account-server is running
2019/05/31 12:35:23.437956 [INF] configure the nats-server with:
2019/05/31 12:35:23.437966 [INF]   resolver: URL(http://localhost:9090/jwt/v1/accounts/)

On a new store, the server doesn't have any JWTs. This means that any nats-server that attempts to resolve accounts will fail. To add JWTs to the server, you can use a tool like curl to post request. But it is much easier if you use nsc to update the nats-account-server.

Using NSC to Add or Update Accounts

The nsc tool has built-in facilities to push JWTs related to an operator. The tool also performs validation of your JWTs to ensure that you push JWTs that will validate correctly.

If your operator doesn't have any entities, now it is a good time to add some:

> nsc add account -n A
Generated account key - private key stored "~/.nkeys/AAA/accounts/A/A.nk"
Success! - added account "A"

> nsc add user -n u1
Generated user key - private key stored "~/.nkeys/AAA/accounts/A/users/u1.nk"
Generated user creds file "~/.nkeys/AAA/accounts/A/users/u1.creds"
Success! - added user "u1" to "A"

> nsc add user -n u2
Generated user key - private key stored "~/.nkeys/AAA/accounts/A/users/u2.nk"
Generated user creds file "~/.nkeys/AAA/accounts/A/users/u2.creds"
Success! - added user "u2" to "A"

> nsc add account -n B
Generated account key - private key stored "~/.nkeys/AAA/accounts/B/B.nk"
Success! - added account "B"

With the account and a couple of users in place, let's push all the accounts to the nats-account-server:

> nsc push -A
successfully pushed all accounts [A,B]

Quick checking of the store directory, shows that the JWTs have been sharded by their public keys:

> tree as_store
as_store
├── 27
│   └── ACVEO3LPVRGE5W262FCYF3OMGQFJIW252AX75FEE6BUY752BFVDADN27.jwt
└── TY
    └── ADDVBX4VPWSNEDLWH5Y6ITASMXS3QY3L6KRNZ6VIQJ6Q3FRGR43NFHTY.jwt

Quick check on nsc to verify the ids of the accounts on nsc, match the files:

> nsc list accounts -W
╭─────────────────────────────────────────────────────────────────╮
│                            Accounts                             │
├──────┬──────────────────────────────────────────────────────────┤
│ Name │ Public Key                                               │
├──────┼──────────────────────────────────────────────────────────┤
│ A    │ ACVEO3LPVRGE5W262FCYF3OMGQFJIW252AX75FEE6BUY752BFVDADN27 │
│ B    │ ADDVBX4VPWSNEDLWH5Y6ITASMXS3QY3L6KRNZ6VIQJ6Q3FRGR43NFHTY │
╰──────┴──────────────────────────────────────────────────────────╯

Using Curl to Add or Update Accounts

> curl -i -X POST localhost:9090/jwt/v1/accounts/AC7PO3MREV26U3LFZFP5BN3HAI32X3PKLBRVMPAETLEHWPQEUG7EJY4H --data-binary @/Users/synadia/.nsc/nats/Test/accounts/TestAccount/TestAccount.jwt -H "Content-Type: text/text"

Note that the @ before the file name is required for curl to read the specified file, and use it as the payload. Otherwise, it will simply post the path specified, which will result in an update error.

Curl can also be used to inspect JWTs.