Added accounts, clarified jwt authentication.

SUMMARY.md

@@ -81,7 +81,8 @@
       * [Username/Password](nats_server/username_password.md)
       * [TLS Authentication](nats_server/tls_mutual_auth.md)
       * [NKeys](nats_server/nkey_auth.md)
-      * [Accounts](nats_server/jwt_auth.md)
+      * [Accounts](nats_server/accounts.md)
+      * [JWTs](nats_server/jwt_auth.md)
       * [Authentication Timeout](nats_server/auth_timeout.md)
     * [Authorization](nats_server/authorization.md)
   * [Clustering](nats_server/clustering.md)

nats_server/auth_intro.md

@@ -6,7 +6,8 @@ The NATS server provides various ways of authenticating clients:
 - [Username/Password credentials](username_password.md)
 - [TLS Certificate](tls_mutual_auth.md)
 - [NKEY with Challenge](nkey_auth.md)
-- [JWTs with Challenge](jwt_auth.md)
+- [Accounts](accounts.md)
+- [JWTs](jwt_auth.md)
 
 Authentication deals with allowing a NATS client to connect to the server.
 Except for JWT authentication, authentication and authorization are configured in the `authorization` section of the configuration.

nats_server/installation.md

@@ -1,6 +1,46 @@
 ## NATS Server Installation
 
-NATS philosophy is simplicity. Installation is just decompressing a zip file and copying the binary to an appropriate directory; you can also use your favorite package manager.
+NATS philosophy is simplicity. Installation is just decompressing a zip file and copying the binary to an appropriate directory; you can also use your favorite package manager. Here's a list of different ways you can install or run NATS:
+
+- [Docker](#installing-via-docker)
+- [Kubernetes](#installing-on-kubernetes-with-nats-operator)
+- [Package Manager](#installing-via-a-package-manager)
+- [Release Zip](#downloading-a-release-build)
+- [Development Build](installing-from-the-source)
+
+
+### Installing via Docker
+
+With docker you can install the server easily without scattering binaries and other artifacts on your system. Only pre-requisite is to [install docker](https://docs.docker.com/install).
+
+```
+> docker pull nats:latest
+latest: Pulling from library/nats
+Digest: sha256:0c98cdfc4332c0de539a064bfab502a24aae18ef7475ddcc7081331502327354
+Status: Image is up to date for nats:latest
+docker.io/library/nats:latest
+```
+
+To run nats on docker:
+
+```
+> docker run -p 4222:4222 -ti nats:latest
+[1] 2019/05/24 15:42:58.228063 [INF] Starting nats-server version #.#.#
+[1] 2019/05/24 15:42:58.228115 [INF] Git commit [#######]
+[1] 2019/05/24 15:42:58.228201 [INF] Starting http monitor on 0.0.0.0:8222
+[1] 2019/05/24 15:42:58.228740 [INF] Listening for client connections on 0.0.0.0:4222
+[1] 2019/05/24 15:42:58.228765 [INF] Server is ready
+[1] 2019/05/24 15:42:58.229003 [INF] Listening for route connections on 0.0.0.0:6222
+```
+
+More information on [containerized NATS is available here](/nats_docker/README.md).
+
+
+### Installing on Kubernetes with NATS Operator
+
+Installation via the NATS operator is beyond this tutorial. You can read about the [NATS
+operator](https://github.com/nats-io/nats-operator) here.
+
 
 ### Installing via a Package Manager
 
@@ -14,12 +54,18 @@ On Mac OS:
 > brew install nats-server
 ```
 
-Via Docker:
+To test your installation (provided the executable is visible to your shell):
+
 ```
-> docker pull nats-server:latest
+> nats-server
+[41634] 2019/05/13 09:42:11.745919 [INF] Starting nats-server version 2.0.0
+[41634] 2019/05/13 09:42:11.746240 [INF] Listening for client connections on 0.0.0.0:4222
+...
+[41634] 2019/05/13 09:42:11.746249 [INF] Server id is NBNYNR4ZNTH4N2UQKSAAKBAFLDV3PZO4OUYONSUIQASTQT7BT4ZF6WX7
+[41634] 2019/05/13 09:42:11.746252 [INF] Server is ready
 ```
 
-### Installing A Release Build
+### Downloading A Release Build
 
 You can find the latest release of nats-server [here](https://github.com/nats-io/nats-server/releases/latest).
 
@@ -49,10 +95,7 @@ If you have go installed, installing the binary is easy:
 
 This mechanism will install a build of [master](https://github.com/nats-io/nats-server), which almost certainly will not be a released version. If you are a developer and want to play with the latest, this is the easiest way of obtaining it. 
 
-
-## Testing Your Installation
-
-To test your installation (provided the executable is visible to your shell):
+To test your installation (provided the $GOPATH/bin is set):
 
 ```
 > nats-server
@@ -63,3 +106,4 @@ To test your installation (provided the executable is visible to your shell):
 [41634] 2019/05/13 09:42:11.746252 [INF] Server is ready
 ```
 
+

nats_server/jwt_auth.md

@@ -1,18 +1,9 @@
 
 ## Accounts
 
-_Accounts_ expand on the [NKEY](nkey_auth.md) authentication foundation and recasts client authentication and authorization from a server configuration to a distributed and delegated authentication and authorization model.
+_Accounts_ expand on [Accounts](accounts.md) and [NKeys](nkey_auth.md) authentication foundation to create a decentralized authentication and authorization model.
 
-With other authentication mechanisms, all clients can publish and subscribe to anything unless explicitly configured otherwise. To protect clients and information, you have to carefully carve the subject space and permission clients.
-
-Each account is *isolated* from other accounts, thus enabling *multi-tenancy* in the server. With accounts, the subject space is not globally shared, greatly simplifying the messaging environment. Instead of devising complicated subject name carving patterns, clients can use short subjects without explicit authorization rules.
-
-Messaging exchange between different accounts is enabled by _exporting_ streams and services from one account and _importing_ them into another. When an export is sensitive, the export can require a constraint that authorization for its import be provided. Thus it is easy to audit exporters and limit importers. Best of all, each account is in full control of what is exported or imported and from whom.
-
-> While the name _account_ implies one or more users, it is much simpler and enlightening to think of one account as a messaging container for one application. Users in the account are simply the minimum number of services that must work together to provide some functionality. 
-> In simpler terms, more accounts with few (even one) clients is a better design topology than a large account with many users with complex authorization configuration.
-
-Accounts leverage [JSON Web Tokens (JWT)](https://jwt.io/) to describe the various entities supported. When a client connects, servers query for account JWTs and validate a trust chain. Users are not directly tracked by the server, but rather verified as belonging to an account. This enables the managing of users without requiring server configuration updates.
+With other authentication mechanisms, configuration for identifying an user or an account is in the server configuration file. JWT authentication leverage [JSON Web Tokens (JWT)](https://jwt.io/) to describe the various entities supported. When a client connects, servers query for account JWTs and validate a trust chain. Users are not directly tracked by the server, but rather verified as belonging to an account. This enables the managing of users without requiring server configuration updates.
 
 Effectively, Accounts provide for a distributed configuration paradigm. Previously each user (or client) needed to be known and authorized a priori in the server’s configuration requiring an administrator to modify and update server configurations. Accounts eliminate these chores.
 

nats_server/nkey_auth.md

@@ -2,7 +2,7 @@
 
 NKeys are a new, highly secure public-key signature system based on [Ed25519](https://ed25519.cr.yp.to/).
 
-With NKeys the server can verify identities without ever storing secrets on the server. The authentication system works by requiring a connecting client to provide its public key and digitally sign a challenge with its private key. The server generates a random challenge with every connection request, making it immune to playback attacks. The generated signature is validated against the provided public key, thus proving the identity of the client. If the public key is known to the server, authentication succeeds.
+With NKeys the server can verify identities without ever storing or ever seeing private keys. The authentication system works by requiring a connecting client to provide its public key and digitally sign a challenge with its private key. The server generates a random challenge with every connection request, making it immune to playback attacks. The generated signature is validated against the provided public key, thus proving the identity of the client. If the public key is known to the server, authentication succeeds.
 
 > NKey is an excellent replacement for token authentication because a connecting client will have to prove it controls the private key for the authorized public key.
 

nats_tools/nsc/streams.md

@@ -66,7 +66,7 @@ With the required information, we can add an import to the public stream.
 Success! - added stream import "a.b.c.>"
 ```
 
-> Note we did fancy things here: The remote stream publishes messages as `a.b.c.>`, but we changed the prefix to be something else in the importing account’s subject space. We changed it to `abc.>`. Subscribers in our account can listen to `abc.>` to get the messages.
+> Note we did fancy things here: The remote stream publishes messages as `a.b.c.>`, but we changed the prefix to be something else in the importing account’s subject space. We changed it to `abc.>`. Subscribers in our account can listen to `abc.>` to get the messages. The message will be delivered as `abc.a.b.c.>`.
 
 And verifying it: