gogrlx/nats-server
1
0
Fork 0
mirror of https://github.com/gogrlx/nats-server.git synced 2026-04-02 03:38:42 -07:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #673 from nats-io/update-readme-authorization

Browse Source 
Update to gnatsd/README.md fixing authorization section - Resolves #662
This commit is contained in:
Derek Collison
2018-05-22 14:47:02 -07:00
committed by GitHub
parent 99b6bb30d0 504ae06ad6
commit a45ef57aa3
1 changed files with 20 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
README.md
View File

@@ -521,9 +521,10 @@ For example:
authorization {
PASS: abcdefghijklmnopqrstuvwxwz0123456789
users = [
{user: alice, password: foo, permissions: $ADMIN}
{user: bob, password: bar, permissions: $REQUESTOR}
{user: joe, password: $PASS}
{user: joe, password: foo, permissions: $ADMIN}
{user: alice, password: bar, permissions: $REQUESTOR}
{user: bob, password: $PASS, permissions: $RESPONDER}
{user: charlie, password: bar}
]
}
```
@@ -545,7 +546,7 @@ authorization {
}
```
Here is an example authorization configuration that defines three users, two of whom are assigned explicit permissions.
Here is an example authorization configuration that defines four users, three of whom are assigned explicit permissions.
```
authorization {
@@ -555,7 +556,11 @@ authorization {
}
REQUESTOR = {
publish = ["req.foo", "req.bar"]
subscribe = "_INBOX.*"
subscribe = "_INBOX.>"
}
RESPONDER = {
subscribe = ["req.foo", "req.bar"]
publish = "_INBOX.>"
}
DEFAULT_PERMISSIONS = {
publish = "SANDBOX.*"
@@ -564,20 +569,23 @@ authorization {
PASS: abcdefghijklmnopqrstuvwxwz0123456789
users = [
{user: alice, password: foo, permissions: $ADMIN}
{user: bob, password: bar, permissions: $REQUESTOR}
{user: joe, password: $PASS}
{user: joe, password: foo, permissions: $ADMIN}
{user: alice, password: bar, permissions: $REQUESTOR}
{user: bob, password: $PASS, permissions: $RESPONDER}
{user: charlie, password: bar}
]
}
```
Since Alice is an ADMIN she can publish/subscribe on any subject. We use the wildcard “>” to match any subject.
Since Joe is an ADMIN he can publish/subscribe on any subject. We use the wildcard “>” to match any subject.
Bob is REQUESTOR and can publish requests on subjects "req.foo" or "req.bar", and subscribe to anything that is a response ("_INBOX.*").
Alice is a REQUESTOR and can publish requests on subjects "req.foo" or "req.bar", and subscribe to anything that is a response ("_INBOX.>").
Joe has no permission grant and therefore inherits the default permission set. You set the inherited default permissions by assigning them to the `default_permissions` entry inside of the `authorization` configuration block.
Charlie has no permissions granted and therefore inherits the default permission set. You set the inherited default permissions by assigning them to the default_permissions entry inside of the authorization configuration block.
Note that `_INBOX.*` subscribe permissions must be granted in order to use the request APIs in Apcera supported clients. If an unauthorized client publishes or attempts to subscribe to a subject, the action fails and is logged at the server, and an error message is returned to the client.
Bob is a RESPONDER to any of Alice's requests, so Bob needs to be able to subscribe to the request subjects and respond to Alice's reply subject which will be an _INBOX.>.
Important to note, NATS Authorizations are whitelist only, meaning in order to not break request/reply patterns you need to add rules as above with Alice and Bob for the _INBOX.> pattern. If an unauthorized client publishes or attempts to subscribe to a subject that has not been whitelisted, the action fails and is logged at the server, and an error message is returned to the client.
### TLS