Supporting Role Based Access Control (RBAC)

[operatorequals]

Hello!
I have been closely checking this project the last week, and I find it really good.
Total, no bullshit, easy to use, not trying to do-everything-all-at-once. Great!

So, I see you are about to add authentication with JWT, which I think is the killer feature! I believe this will make it usable in real world scenarios, even if you don't add anything else.

As after authentication comes authorization, I was wondering if and how you will manage RBAC per HTTP and Endpoint.
Specifically, applications have some kind of way to split authenticated Users into groups that can see and do different things.
Like, "Admins" can use DELETE and PUT, while "Simple" users can do only GET and HEAD.
Also, each user might need to get a different thing by the same Endpoint (such as /self or /profile).

The second case (the /self endpoint), could be implemented as a CustomEndpoint, but the first one could be handled internally and transparently.

I believe that this will differentiate your project from DB to REST projects, like sandman.

---

What I propose is some Global configuration (stored in the DB?), that can be explained by the following JSON:

{
  "/person": {
    "user": [
      "GET",
      "POST"
    ],
    "admin": [
      "GET",
      "POST",
      "PUT",
      "DELETE"
    ]
  }
  "/email": {...}
}

Such config, can be directly searched by the App to serve 403 Errors whenever there is a miss.
Finally, as you are now implementing JWT, you can read the Role of the user (in this example "user" and "admin", but they can be as many as you define), by the JWT claims directly.

Finally, to stay free from chasing logical RBAC Security Bugs (e.g: priv escalations, impersonations), and stay true to your purpose of prototyping a REST API, you can keep this config static.
No user can modify it nor any part of the app can mess with it (unless using reflections - but this offloads the risk from the module to the developer).

---

Overall, I'm impressed by this project and it's simplicity,
and I can't wait to come with an idea that needs a REST API so I can use it!
Keep up the good work!

[iklobato-w]

Hello John @operatorequals !

Setting the configuration in a declarative way would be REALLY great, so that versioning would occur automatically along with a possible build, I really liked it! We only need to think about the data structure and how the endpoints and handlers will relate to each other, so we can reuse common responses.

And my wish would be for each endpoint to be able to act independently of each other, but to continue with the automatic way of creating all REST verbs.

I think we could create something similar to this, where each endpoint could even have its own specific pagination and authentication class. What do you think?

lightapi:
  framework:
    version: 1.0.0

database:
  connections:
    default_postgresql:
      host: global-db-host
      port: 5432
      database_name: global_db
      username: ${DB_USER}
      password: ${DB_PASSWORD}
      driver: postgresql

    users_db:
      host: users-db-host
      port: 5432
      database_name: users_db
      username: ${USERS_DB_USER}
      password: ${USERS_DB_PASSWORD}
      driver: postgresql

    products_db:
      host: products-db-host
      port: 27017
      database_name: products_db
      username: ${PRODUCTS_DB_USER}
      password: ${PRODUCTS_DB_PASSWORD}
      driver: mongodb

pagination:
  default:
    default_page_size: 10
    max_page_size: 100

  large:
    default_page_size: 50
    max_page_size: 200

models:
  UserModel:
    name: UserModel
    auto_create: true

  OrderModel:
    name: OrderModel
    auto_create: true

  ProductModel:
    name: ProductModel
    auto_create: true

endpoints:
  users:
    model: UserModel
    paginate: true
    pagination: large
    authentication_class: TokenAuthentication
    database:
      connection: users_db

  orders:
    model: OrderModel
    paginate: true
    pagination: default
    authentication_class: BasicAuthentication
    database:
      connection: default_postgresql

  products:
    model: ProductModel
    paginate: false
    authentication_class: CustomAuthentication
    database:
      connection: products_db

[operatorequals]

Hey @iklobato-w

I see your idea about the independent endpoints, but I believe that it also goes beyond the needs of prototyping. I'd also move towards other priorities, creating features like Graph, instead of fine-graining the base engine. But, that's just personal taste.