Casbin

Mentors: Student: Yixiang Zhao

The jCasbin needs to enhance the expressiveness of the grammar to meet the diverse needs of the user's policy development. For example, the special syntax of "in", the update of the role manager, etc. At the same time, it is also necessary to maintain and integrate the unique ecology of Java, such as casbin-spring-boot-starter and Play middleware, etc. Performance is also a point of great concern, so it's necessary to benchmark and optimize the performance for policy evaluation on large rule sets. Casdoor also needs to move forward with development. Some features need to be added to match a variety of complex production environments.

Mentors: Student: Resulte

Casbin-dashboard is the official web UI (admin portal) for Casbin models and policies. Casdoor is a centralized authentication / Single-Sign-On (SSO) platform. Problem: 1. A more friendly policy management UI is needed for Casbin-dashboard. And it should be able to handle 10,000+ more rules. 2. Test management page needs to be developed for Casbin-dashboard. A test page to make example requests to Casbin and get responses, like Postman. 3. Authentication and authorization for the Casbin-dashboard itself. Of course authorization will be implemented in Casbin. 4. Casdoor needs to sign up with email without verification by configuring the application edit page. 5. Casdoor needs to support configurable captcha in user flows. It can support different implementations. Solution: 1. We can use more powerful and high-quality UI libraries such as Ant Design to build more friendly web UI. And in order to handle 10,000+ more rules, we can use paging display and virtual list in frontend, and we can use paging query and database index in backend. 2. We can build a test management page, so that we can create and edit our unit test case through the web page. 3. We can build an authorization management page to realize the authorization of the dashboard. We can use Casbin models to control the presentation of every element on the page and control each request of the RESTful API. 4. We can add a rule to control whether the email verification is required.5. We can integrate the different services from cloud captcha providers like gCaptcha, hCaptcha. To save a lot of work, we just only need to integrate the wrapper code. Deliverables: 1. Allow to sign up with Email without verification for Casdoor. - June 7; 2. Support configurable captcha for Casdoor. - June 28; 3. A more friendly policy management UI for Casbin-dashboard. - July 11; 4. Test management page for Casbin-dashboard. - July 23; 5. Authentication and authorization for the Casbin-dashboard itself. - Aug 11;

Mentors: Student: Zhendong Zhou

1. Add etcd adapter and redis adapter to improve compatibility 2. Implement the pycasbin-on-cpp to improve performance and add RBAC API to benchmark the casbin(go version) 3. Introduce Django's various components to make pycasbin easier to use

Mentors: Student: Jiaming Tang

The proposal presented here roughly contains 3 parts. The first part includes refactor of the existing k8s-authz, as well as introducing more rules&policies, kubebuilder3.x, helm support and detailed tests into it. And the second part includes creating a Casbin authorization middleware for Dapr called dapr-casbin-authz. The third part is to push forward the development Casdoor.

Mentors: Student: NoneBack

Currently, Casbin uses golang built-in map structure to maintain policies in the main memory and persist the policies via adapter abstraction. If policies data grows, however, the growing cost of main memory resources and bad performance make the memory management strategy not tolerable anymore. We need to find a better way to manage the casbin in-memory data when data grows. From my point of view, our main goal is to reduce the cost of memory as well as keep good performance handling policies read and write requests. In order to achieve those key goals, we can introduce an experimental tuple storage to get charge of storing those policies, turning the policies management strategy from memory-oriented to disk-oriented. We can even make a better abstraction of the storage layer so that we can use different engines (row, column) for the different workloads. In general, we can take the following parts into consideration to achieve our goals. 1. API for upper layer. 2. workload optimizer. 3. Buffer Pool management. 4. Indexing. 5. Data Storage Structures. 6. Transaction if necessary. And in the end, the deliverables will be : A Casbin built-in embedded disk-oriented tuple storage engine. The Engine should contain ： 1. Carefully designed API for upper Casbin internal module. 2. Storage management. Include file organization and page layout. 3. Buffer pool management. 4. Index management. 5. An workload optimizer for the upper layer. 6. Transaction part if necessary.