Skip to content

Sprint 3 Demo & Presentation

Jump to bottom
Ahmed Gamal edited this page Sep 11, 2023 · 1 revision

Problem Statement

Ever Since Dstny Engage has opted for a microservices architecture, they have decided to use authorization as a service. Authorization is how you control who can do what in your application. Authorization as a service means using a third-party service to handle authorization in an app, and can make your app more resilient and easier to deploy.

Dstny's authorization service is based on OPA. The Open Policy Agent is an open-source, general-purpose policy engine that unifies policy enforcement across the stack. OPA decouples policy decision-making from policy enforcement and application logic. It provides major flexibility, and allows writing policies as code. This has produced a three-fold problem:

  1. OPA is written using Rego, a declarative query language, and thus requires a developer to modify policy code.
  2. Since policy is written as code, any change to the policy will require redeployment. Not only is this inefficient, but the OPA now represents a single point of failure, which may cause the entire system to fail.
  3. The authorization service cannot be productized, as it entirely relies on code modifications.

Market Survey Brief

We have already conducted a detailed market survey here, but will now discuss two major competitors.

KeyCloak

Keycloak provides user federation, strong authentication, user management, fine-grained authorization, and is already employed by Dstny Engage for authentication. However, it is not based on OPA, so it does not offer as much flexibility and granularity, and is difficult in redployment of permissions.

Permit.io

Permit.io offer solutions for no-code policy management. They offer GUI support for only two types of policies, RBAC and ABAC.

Our solution

Throughout this project, we have designed an authorization service that provide five major requirements:

  1. Based on OPA
  2. Allows real-time policy modifications
  3. Allows policy editing through the GUI
  4. Automated policy testing and verification on each modification
  5. Rollback in case of failure

Next Plans

Most of the requirements we have first envisioned for our project have been implemented, the following are the features we will work on next, sorted by importance from highest priority to lowest priority:

  1. Add SSO (Single Sign-On)
  2. Add an IDE to allow writing policy code of any type
  3. Save checkpoints (tags) through our project to the release branch
  4. Project deployment
Clone this wiki locally