Skip to content

Authorization : Resource based Policy

Resource-based policy authorization is a method used in many systems to manage access to resources, such as files, databases, or APIs. In this approach, each resource has an associated policy that defines who (user, group, or service) is allowed to perform what actions (read, write, execute, delete, etc.) on that resource.

  • Can a user or client X do an operation Y on a resource Z?

  • Can current user (X) edit (Y) a product (Z) information?

    • Do not allow if product is locked
    • Allow if the product was created by the user
    • Allow if the user has permission to edit products (permissions are managed by admin users)
    • Allow if any of user’s roles has permission to edit products
    • Only allow if the user is working in the department the product belongs to

Resource-based policy authorization offers several benefits:

  • It provides a clear and structured way to manage access to resources.
  • It supports fine-grained access control, allowing for precise control over who can do what on each resource.
  • It can be easily integrated into various systems and APIs.
  • It makes it easier to manage access control as resources and permissions evolve over time.

Examples of systems that use resource-based policy authorization include AWS, Google Cloud Platform, Kubernetes, and many others.

Permission flow overview

The flow goes like this:

  • User requests to view record A.
  • The request is intercepted by the Policy Enforcement Point (PEP). This is asp.net core authorization a middleware in order for the request to stop right there in case it's not authorized, instead of allowing it to travel deeper in the system.
  • PEP makes a request to the Policy Decision Point (PDP) in order to figure out whether or not the request is authorized to move forward. PDP is service that keeps track of roles, permissions and resources and expose an interface in order to query it and get a boolean answer whether or not someone can do something on a resource.
  • PDP needs extra information in order to decide if the request should be allowed or denied so it needs to ask the Policy Information Point (PIP) for that extra information. That extra information going to retrieved from a database. PIP just another service which PDP is used internally.
  • PIP loads the extra information and returns it to the PDP.
  • PDP, in combination with the extra information it got from PIP, evaluates the defined policy (which can be stored at database), and decides whether or not the request has access to the underlying resource based on what the policy says.
  • The answer is returned to PEP, which either allows or denies the request to move forward.

Authorization : Components

Where to force authorization?

  • PEP: Policy Enforcement Point
    • In the API Gateway? In the current service?

Where to perform the authorization logic?

  • PDP: Policy Decision Point
    • In the current process? In a dedicated service?

Where and how to obtain the data to perform the authorization logic?

  • PIP: Policy Information Point
    • Direct database access? Collect on-demand? Pre-duplicate?

Where and how to manage policies and permissions?

  • PAP: Policy Administration Point
    • Typically, on a user interface

External Authorization Service

How to obtain the application data?

  • Directly read from service’s database?
  • Send data on the authorization service call?
  • Pre-duplicate the data into authorization service’s database?

Other problems:

  • Network delays / problems on authorization service call.
  • Authorization service become a bottleneck.

Check on API Gateway

Advantages:

  • Decouple authorization logic from the microservice.
  • Prevent microservice call for unauthorized requests.

Disadvantages:

  • Requires custom logic in API Gateway – restricts gateway technology selection
  • Maps permissions with HTTP details.
  • Can only know the HTTP request details (like route & HTTP method)

Authorization Library

Advantages:

  • Decouple authorization logic from the microservice logic.
  • Application data is available.
  • Custom authorization logic is possible.

Disadvantages:

  • Can be a problem if you have microservices developed with different platforms (.NET, Java, Phyton…)

PSS®X Authorization

This section describes how PSS®X platform perform authorization using the OAuth 2.0 authorization code flow.

It's used to perform authentication and authorization in the majority of app types, including single page apps, web apps, and natively installed apps.

At a high level, the entire authentication flow for an application looks like this:

A permission is a simple policy that is granted or prohibited for a particular user, role or client permission value providers.

Reference

https://www.alexanderlolis.com/authorization-in-a-microservices-world#authorization-flow-overview