authz-casbin

    Name

    For detailed documentation on how to create model and policy, refer .

    NOTE: You must either specify model_path, policy_path and username in plugin config or specify model, policy and username in the plugin config for the configuration to be valid. Or if you wish to use a global Casbin configuration, you can first specify model and policy in the plugin metadata and only username in the plugin configuration, all routes will use the plugin metadata configuration in this way.

    Metadata

    NameTypeRequirementDefaultValidDescription
    modelstringrequiredThe Casbin model configuration in text format.
    policystringrequiredThe Casbin policy in text format.

    You can enable the plugin on any route either by using the model/policy file paths or directly using the model/policy text.

    This will create a Casbin enforcer from the model and policy files at your first request.

    1. curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{    "plugins": {        "authz-casbin": {            "model": "[request_definition]            r = sub, obj, act
    2.             [policy_definition]            p = sub, obj, act
    4.             [policy_effect]            e = some(where (p.eft == allow))
    5.             [matchers]            m = (g(r.sub, p.sub) || keyMatch(r.sub, p.sub)) && keyMatch(r.obj, p.obj) && keyMatch(r.act, p.act)",
    6.             "policy": "p, *, /, GET            p, admin, *, *            g, alice, admin",
    7.             "username": "user"        }    },    "upstream": {        "nodes": {            "127.0.0.1:1980": 1        },        "type": "roundrobin"    },    "uri": "/*"}'

    First, send a PUT request to add the model and policy text to the plugin’s metadata using the Admin API. All routes configured in this way will use a single Casbin enforcer with plugin metadata configuration. You can also update the model/policy this way, the plugin will automatically update itself with the updated configuration.

    1. [policy_definition]p = sub, obj, act
    2. [role_definition]g = _, _
    3. [policy_effect]e = some(where (p.eft == allow))
    4. [matchers]m = (g(r.sub, p.sub) || keyMatch(r.sub, p.sub)) && keyMatch(r.obj, p.obj) && keyMatch(r.act, p.act)",
    5. "policy": "p, *, /, GETp, admin, *, *g, alice, admin"}'

    Then add this plugin on a route by sending the following request. Note, there is no requirement for model/policy now.

    NOTE: The plugin route configuration has a higher precedence than the plugin metadata configuration. Hence if the model/policy configuration is present in the plugin route config, the plugin will use that instead of the metadata config.

    Test Plugin

    We defined the example model as:

    2. [policy_definition]p = sub, obj, act
    3. [role_definition]g = _, _
    4. [policy_effect]e = some(where (p.eft == allow))
    5. [matchers]m = (g(r.sub, p.sub) || keyMatch(r.sub, p.sub)) && keyMatch(r.obj, p.obj) && keyMatch(r.act, p.act)
    1. p, *, /, GETp, admin, *, *g, alice, admin

    This means that anyone can access the homepage (/) using GET request method while only users with admin permissions can access other pages and use other request methods.

    For example, here anyone can access the homepage with the GET request method and the request proceeds normally:

    If some unauthorized user bob tries to access any other page, they will get a 403 error:

    1. curl -i http://127.0.0.1:9080/res -H 'user: bob' -X GETHTTP/1.1 403 Forbidden

    But someone with admin permissions like alicecan access it:

      Examples

      Checkout examples for model and policy conguration .