Casbin-server issues for enterprise deployments

[Leonardo-Ferreira]

The ideia of casbin is perfect, but for a enterprise scenario, casbin-server lacks a couple of features:

1. Authenticated requests
   Casbin-server needs to have a self-contained authentication mech, or rely on a 3rd party to validate that the client is in-fact authorized to do so. This can be "basic" like a shared-secret between parties, but ideally, it has to be more robust (like a signed JWT token)
2. Auditing Enterprises needs to be able to audit their application. Casbin-server can only become a (core) component of such an organization stack if it obliges to such scrutiny. There are two types of auditing workflows: mandatory and desired. They differ on a key aspect: On the mandatory setting, the response can only be provided AFTER the auditing log has been perpetuated (wether to a file, database, event hub or message queue)

Are there any plans on this area? if not can I draft some?

[casbin-bot]

@tangyang9464 @closetool @sagilio

[hsluoyz]

@Leonardo-Ferreira I think what you want may be Casdoor: https://github.com/casbin/casdoor . It's a centralized authentication and authorization service. For authentication, it supports OAuth, SAML (in future) and also HTTP basic auth based on JWT. For auditing, it contains log recording. Casbin will be integrated into it to act as a component.

[nodece]

@hsluoyz I think this issue means that add authentication to casbin-server, and support log the enforce result to a storage container(like file, db and so on).

[Leonardo-Ferreira]

hummmm I don't think so, casbin-server looks more fitting...
Take a look at my scenario:

1. I have about 130 Microservices that consume forgerock (which I believe is a direct competitor of casdoor) as a Authentication and/or Authorization provider
2. Forgerock will be decommissioned.
3. The Authentication part will go to Azure AAD B2C (and that's not open for debate)
4. I was hoping to use casbin-server to do Authorization

The microservice, when handling a request, would extract the user from the JWT (present at Authorization header), then contact casbin-server using the high performance gRPC and enforce that request.

My first concern here is about the client, not the end-user: how can casbin-server trust that the request being made is in fact coming from a authorized party? in simpler terms, "should casbin-server enforce the whichever request that arrives?". I'd advocate that casbin-server and casbin-client should exchange a secret and casbin-server would validate even request.

• "oh but my network is 100% secure and infallible and etc" -> ok, just turn it off...
• "what would this secret look like?" -> at first, it can be a static token but later on this can be hardened

It's easier to think of it this way: in how much trouble would you be if your casbin-server got erroneously exposed to the DMZ?

[hsluoyz]

@Leonardo-Ferreira casbin-server is originally designed for intranet. But we are also OK to add a slim layer of JWT token verification. It should be designed as optional and doesn't affect existing usage. Proposal and PR are welcome!

[Leonardo-Ferreira]

@hsluoyz great! please take a look at this new config file at let me know what you think

[hsluoyz]

Closed as stale