wolf-rbac

Authorizes requests with wolf role-based access control.

Category AuthenticationAdd it to Route, Service, Global rule, Plugin configEngine plugin wolf-rbacPriority 2555

What it does

wolf-rbac checks each request against the permissions a Wolf server holds, a role-based access control service of your own. The users, their roles and what each role may call live on the Wolf server, under the application named by App ID. The client sends an rbac token that names that application, and the gateway finds the consumer whose own copy of wolf-rbac carries the same App ID.

The plugin goes on the route and on that consumer, and at every request the settings are read from the consumer's copy, not the route's. The user's id, username and nickname reach the backend in headers that start with the Header prefix. Authentication shows how consumers fit in.

When to use it

• An administrator keeps the roles of an orders portal in Wolf, and the gateway applies them to every call without a copy of them.
• Several applications share one Wolf server, each under its own App ID, and each route is checked against the permissions of its own application.
• The backend needs to know who called, and reads the user's id and name from the headers the gateway adds.

Not for rules by user, path and method kept on the gateway itself — see authz-casbin (Authorizes requests with a Casbin model and policy), permissions kept in Keycloak's authorization services — see authz-keycloak (Authorizes requests with Keycloak's authorization services) or a decision an authorization service of your own makes over plain HTTP — see forward-auth (Delegates authentication to an external service).

Set it up

Check each request against the permissions a Wolf server holds for the application

Set Server to http://wolf.internal:12180, set App ID to orders-portal and leave Header prefix at X-.

wolf-rbac · as the console saves it

{
  "server": "http://wolf.internal:12180",
  "appid": "orders-portal",
  "header_prefix": "X-"
}

Things to know

• Server — Checked at the write and then read from the consumer's own copy at every request: keep the values here and on the consumer the same.
• Server — The gateway also serves sign-in, change-password and user-info endpoints of its own, and they call the address the consumer's copy carries.
• Header prefix — The headers are set on the request to the backend and on the answer to the client alike.
• SSL verify — The engine gives this key no default: unwritten, no certificate is checked, and the value read at every request is the consumer's own copy, not this one.
• AdviceWrite the same values on the route and on each consumer's copy of wolf-rbac, and change them in both places together.

Settings

The fields as the console shows them, section by section.

Serverserverstringdefault http://127.0.0.1:12180

The address of the wolf server, such as http://wolf.example.internal:12180. The gateway also serves sign-in, change-password and user-info endpoints of its own, and they call the address the consumer carries.

App IDappidstringdefault unset

The rbac token carries this name and the engine finds the consumer whose own copy of this plugin carries it.

Header prefixheader_prefixstringdefault X-

Put in front of the user id, username and nickname headers, as X- gives X-Userid; the consumer's copy is the one used. The headers are set on the request to the upstream and on the answer to the client.

SSL verifyssl_verifyboolean

Every plugin also has Enabled, Priority, Filter, Error response and Pre-function: see Plugin execution settings.