| # RBAC authorization | |
| This example uses the `StaticInterceptor` and `FileWatcherInterceptor` from the | |
| `google.golang.org/grpc/authz` package. It uses a header based RBAC policy to | |
| match each gRPC method to a required role. For simplicity, the context is | |
| injected with mock metadata which includes the required roles, but this should | |
| be fetched from an appropriate service based on the authenticated context. | |
| ## Try it | |
| Server is expected to require the following roles on an authenticated user to | |
| authorize usage of these methods: | |
| - `UnaryEcho` requires the role `UNARY_ECHO:W` | |
| - `BidirectionalStreamingEcho` requires the role `STREAM_ECHO:RW` | |
| Upon receiving a request, the server first checks that a token was supplied, | |
| decodes it and checks that a secret is correctly set (hardcoded to | |
| `super-secret` for simplicity, this should use a proper ID provider in | |
| production). | |
| If the above is successful, it uses the username in the token to set appropriate | |
| roles (hardcoded to the 2 required roles above if the username matches | |
| `super-user` for simplicity, these roles should be supplied externally as well). | |
| ### Authorization with static policy | |
| Start the server with: | |
| ``` | |
| go run server/main.go | |
| ``` | |
| The client implementation shows how using a valid token (setting username and | |
| secret) with each of the endpoints will return successfully. It also exemplifies | |
| how using a bad token will result in `codes.PermissionDenied` being returned | |
| from the service. | |
| Start the client with: | |
| ``` | |
| go run client/main.go | |
| ``` | |
| ### Authorization by watching a policy file | |
| The server accepts an optional `--authz-option filewatcher` flag to set up | |
| authorization policy by reading a [policy | |
| file](/examples/data/rbac/policy.json), and to look for update on the policy | |
| file every 100 millisecond. Having `GRPC_GO_LOG_SEVERITY_LEVEL` environment | |
| variable set to `info` will log out the reload activity of the policy every time | |
| a file update is detected. | |
| Start the server with: | |
| ``` | |
| GRPC_GO_LOG_SEVERITY_LEVEL=info go run server/main.go --authz-option filewatcher | |
| ``` | |
| Start the client with: | |
| ``` | |
| go run client/main.go | |
| ``` | |
| The client will first hit `codes.PermissionDenied` error when invoking | |
| `UnaryEcho` although a legitimate username (`super-user`) is associated with the | |
| RPC. This is because the policy file has an intentional glitch (falsely asks for | |
| role `UNARY_ECHO:RW`). | |
| While the server is still running, edit and save the policy file to replace | |
| `UNARY_ECHO:RW` with the correct role `UNARY_ECHO:W` (policy reload activity | |
| should now be found in server logs). This time when the client is started again | |
| with the command above, it will be able to get responses just as in the | |
| static-policy example. |