accounts
map. The contents of an account entry includes:users
exports
imports
accounts
list is a map, where the keys on the map are an account name.In the most straightforward configuration above you have an account namedA
which has a single user identified by the usernamea
and the passworda
, and an account namedB
with a user identified by the usernameb
and the passwordb
.These two accounts are isolated from each other. Messages published by users inA
are not visible to users inB
.
username/password nkeys and add permissionsWhile 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.
exports
configuration list enable you to define the services and streams that others can import. Exported services and streams are expressed as an Export configuration map. The imports
configuration lists the services and streams that an Account imports. Imported services and streams are expressed as an Import configuration map.service
or stream
and optionally defines specific accounts that can import the stream or service. Here are the supported configuration properties:stream
service
)service
stream
)accounts
response_type
service
request consists of a single
or a stream
of messages. Possible values are: single
or stream
. (Default value is singleton
)A
is exporting:puba.>
pubq.>
B
on the wildcard subject b.>
B
on the subject q.b
stream
service
prefix
stream
)to
service
)prefix
and to
options are optional and allow you to remap the subject that is used locally to receive stream messages from or publish service requests to. This way the importing account does not depend on naming conventions picked by another. Currently, a service import can not make use of wildcards, which is why the import subject can be rewritten. A stream import may make use of wildcards. To retain information contained in the subject, it can thus only be prefixed with prefix
...account
and subject
of the export being imported. This map is embedded in the import configuration map:account
subject
B
imports:A
that only B
can receive on b.>
A
that only B
can send requests on q.b
C
imports the public service and stream from A
, but also:puba.>
stream to be locally available under from_a.puba.>
. The messages will have their original subjects prefixed by from_a
.pubq.C
service to be locally available under Q
. Account C
only needs to publish to Q
locally.puba.>
from A
is visible to all external accounts that imports the stream.pubq.>
from A
is available to all external accounts so long as they know the full subject of where to send the request. Typically an account will export a wildcard service but then coordinate with a client account on specific subjects where requests will be answered. On our example, account C
access the service on pubq.C
(but has mapped it for simplicity to Q
).b.>
is private, only account B
can receive messages from the stream.q.b
is private; only account B
can send requests to the service.C
publishes a request to Q
, local C
clients will see Q
messages. However, the server will remap Q
to pubq.C
and forward the requests to account A
.a
within account A
.Please note that theno_auth_user
will not work with nkeys. The user referenced can also be part of the authorization block.Despiteno_auth_user
being set, clients still need to communicate that they will not be using credentials. The authentication timeout applies to this process as well. When your connection is slow, you may run into this timeout and the resultingAuthentication Timeout
error, despite not providing credentials.