Authorization

Each permission specifies the subjects the user can publish to and subscribe to. The parser is generous at understanding what the intent is, so both arrays and singletons are processed. For more complex configuration, you can specify a permission object which explicitly allows or denies subjects. The specified subjects can specify wildcards as well. Permissions can make use of variables.

A special field inside the authorization map is default_permissions. When present, it contains permissions that apply to users that do not have permissions associated with them.

The permissions map specify subjects that can be subscribed to or published by the specified client.

The permission map provides additional properties for configuring a permissions map. Instead of providing a list of allowable subjects and optional queues, the permission map allows you to explicitly list those you want toallow or deny. Both lists can be provided. In case of overlap deny has priority.

The allow_responses option dynamically allows publishing to reply subjects and works well for service responders. When set to , only one response is allowed, meaning the permission to publish to the reply subject defaults to only once. The allow_responses map allows you to configure a maximum number of responses and how long the permission is valid.

When allow_responses is set to true, it defaults to the equivalent of { max: 1 } and no time limit.

Important Note When using nsc to configure your users, you can specify the --allow-pub-response and --response-ttl to control these settings.

Here is an example authorization configuration that uses variables which defines four users, three of whom are assigned explicit permissions.

• admin has ADMIN permissions and can publish/subscribe on any subject. We use the wildcard > to match any subject.
• client is a REQUESTOR and can publish requests on subjects req.a or req.b, and subscribe to anything that is a response (_INBOX.>).
• service is a RESPONDER to and req.b requests, so it needs to be able to subscribe to the request subjects and respond to client’s that can publish requests to req.a and req.b. The reply subject is an inbox. Typically inboxes start with the prefix _INBOX. followed by a generated string. The _INBOX.> subject matches all subjects that begin with _INBOX..

Note that in the above example, any client with permissions to subscribe to _INBOX.> can receive all responses published. More sensitive installations will want to add or subset the prefix to further limit subjects that a client can subscribe. Alternatively, allow complete isolation limiting what members of an account can see.

Here’s an example without variables, where the allow and deny options are specified:

Here’s an example with allow_responses:

User a has no restrictions. User b can listen on q for requests and can only publish once to reply subjects. All other subjects will be denied. User c can also listen on q for requests, but is able to return at most 5 reply messages, and the reply subject can be published at most for 1 minute.