Flagr RBAC Design

[fenriskiba]

We are looking to contribute RBAC via Casbin, and we were hoping to review our design with the community before we get started.

At a high level, our plan is to:

• Build it on top of the JWT Auth Flagr already supports
• Require users using Casbin to provide a Model Config to enable any of Casbin's supported Auth Models
• Provide APIs to dynamically set specific Policies

Configurations

We'll add three configs to env.go:

• JWTCasbinEnabled - A bool to enable Casbin
• JWTCasbinPassJWTData - A bool to pass the user data from the JWT into the Casbin requests
• JWTCasbinModelFile - Location of a mounted Model Config

Model Config

In addition to the ENV configs, users will need to provide a Model Config, which will follow syntax defined by Casbin to define the following:

• Request Definition - Defines the inputs the application using Casbin will provide to determine if an action in allowed.
  • It this case, it will need to be set to r = sub, obj, act, with the following being passed to Casbin:
    • sub - The username from JWTAuthUserProperty
    • obj - The URL of the request
    • act - The HTTP Method of the request
  • If JWTCasbinPassJWTData is set to true, jwt will need to be added to the Request Definition and the JWT user data will be passed in as well.
• Policy Definition - Defines the format of the policies used to determine what actions user are/are not allowed to perform.
  • The common pattern for this is to use the same sub, obj, act format as the Request Definition to describe actions users are allowed to perform.
  • Special Policy Definitions can also be used to define groups of users as a "Group Policy".
    • Ex. There can be a policy stating that User 1 is in a Read group and User 2 is in a Write group.
• Policy Effect - Defines how to manage conflicts when a Request matches multiple Policies
  • Ex. A user matches multiple policies, one allows them to perform the requested action and the other denies them access. The Policy Effect determines which to use.
• Matchers - Defines relationship between Request Definition and Policy Definition. By default, requests from the application using Casbin are allowed if the Request matches the Policy and is denied if not.

This config will be loaded into Casbin at startup to initialize the Casbin Enforcer.

Policies

While the Model Config defines the format of the Policies, the specific policies will be stored in a database table created using Casbin's GORM Adapter.

We will then create the following API's to manage the policies. These APIs will be one-to-one with the APIs that Casbin provides for managing policies, so their inputs will be based on those APIs.

Name	Casbin API	Method	Path
createPolicy	AddPolicy	POST	/auth/policies
putPolicy	UpdatePolicy	PUT	/auth/policies
deletePolicy	RemovePolicy	DELETE	/auth/policies
findPolicies	GetFilteredPolicy	GET	/auth/policies
createGroup	AddGroupingPolicy	POST	/auth/groups
putGroup	UpdateGroupingPolicy	PUT	/auth/groups
deleteGroup	RemoveGroupingPolicy	DELETE	/auth/groups
findGroups	GetFilteredGroupingPolicy	GET	/auth/groups

Enforcement

We'll add a middleware function based on Casbin's negroni-authz library that will pass information from the HTTP Request into Casbin and either allow the action or return an HTTP 401.

The middleware will first check if the request matches the JWTAuthPrefixWhitelistPaths or JWTAuthExactWhitelistPaths and allow any that do.

If the path is not in one of the whitelists, then it passes the username from JWTAuthUserProperty, the URL, and the HTTP Method of the request to Casbin's Enforce API and allow or deny the request based on the result.
If JWTCasbinPassJWTData is set to true, it will also send all the user data in the Authorization JWT to the API.

[fenriskiba]

@zhouzhuojie @marceloboeira I would love to get your feedback on this design.