We currently support issuing checks in batch in the OpenFGA SDKs. This works by issuing checks in parallel, and we believe it's a good approach in general.

When you deploy OpenFGA with multiple nodes, the load can be spread across nodes, and the total response time would be close to the response time of the most expensive check call.

However, when the number of checks is too large, it could be useful to resolve all the checks in the server with a single roundtrip.

Related to spring-projects/spring-security#14121

We want to build a reference application that can be used to explain/demo OpenFGA.

OpenFGA provides support for some basic ABAC scenarios with contextual tuples.

We want to explore additional options, that could be:

• Specifying conditions when writing a tuple (e.g. this tuple is only valid if condition X)
• Support storing/referring to resource attributes (e.g. write a resource attribute like "feature:X status = 'in-development'" and refer to it in the model)
• Support conditional functions in the DSL that can be called from the model
• Grant access for a specific period of time, e.g. 10 minutes after the permission was granted.
• Allow implementing entitlements scenarios that restrict based on usage data (e.g. max number of collaborators)
• IP-based filtering, where the IP ranges can be coded in the DSL

Related conversations:
https://github.com/orgs/openfga/discussions/114

Early POC was demoed here https://youtu.be/sFqk42fJy_E?t=667

Implement a per-node sub-problem cache.

It should cache 'Check' results in-memory. This will speed up check queries that traverse the same paths more than once and check queries that are frequently used.

There a different scenarios where developers could want to make multiple calls to the check API.

OpenFGA does not provide a batch check API, but we want to simplify the developer experience by providing a way to make multiple Check calls in parallel from the SDKs.

We'll eventually add it to the backend after we understand value and usage patterns.

Developers want to have a simple way to know which relations a user has with a specific object.

To build the UI below:

developers could use the Read endpoint if all of those relations are direct relations. However, if some of them are indirect relations, they'll need to call Check for each one.

To simplify this use case, we can provide an API like

const response = await fgaClient.listRelations({
  users: "user:123"
  object: "document:pricing"
  relations: ["can_view", "can_edit"]
});

// returns response.relations : [ "can_view"]

This API can be implemented on the SDKs, by calling multiple checks in Batch, or in the server. We'll start by implementing it in the client to better understand its value/usage, and eventually implement it in the server later.

OpenFGA's is currently optimized to offer low latency for models with up to 2 nested levels.

In order to provide that latency for models with more nested levels we need to implement a Zanzibar feature called “Leopard indexes”.

The following is the definition in Google's Zanzibar paper:

Leopard is an indexing system used to optimize operations on large and deeply nested sets. It reads periodic snapshots of ACL data and watches for changes between snapshots. It performs transformations on that data, such as denormalization, and responds to requests from aclservers.

We haven't open sourced the FGA Playground. We believe it should be part of the OpenFGA project and we'll open source it.

Create an SDK for Python

OpenFGA currently enables importing tuples from a JSON/YAML/CSV file with the CLI.

There's an opportunity to build a more reliable importing process that would:

• Report progress
• Retry errors
• Provide a final report with # of tuples imported, tuples with error

This feature is already shipped and documented here https://openfga.dev/docs/interacting/relationship-queries#listobjects

See https://github.com/orgs/openfga/discussions/64

In the same way we provide a ListObjects endpoint that list all resources for a specific user & relation, We should provide a way to list which users have a specific relationship with a specific resource, for example:

const response = await fgaClient.listUsers({
object: "document:pricing",
relation: "reader",
type: "document"
});

// returns response.users : ["user:jon", "user:maria"]

There's a PR for the RFC here.

We want to provide tooling/guidance on how to use OpenFGA with GraphQL.

There's a relevant conversation here

OpenFGA has a per-node cache (#38).

It is possible to improve performance by taking advantage of a distributed caching or an external cache service.

OpenFGA currently supports pre-shared keys and ODIC for authenticating calls to the APIs. Those credentials are global, and allow performing any action in any store.

We want to provide more granularity for authorizing calls to the OpenFGA API. Some scenarios:

• Different credentials for each FGA store.
• Different credentials with different permissions per FGA store (e.g. some credentials can perform writes while others cannot).
• Different credentials with different permissions for different types in the FGA store (e.g. some credentials allow writing tuples for documents and others allow writing tuples for users, or define those permissions per module)

This RFC discusses different alternatives in more depth openfga/rfcs#10

To address Search with Permissions scenarios, developers might need to create a local index for specific user-type, object, relations.

For example, if they have a model like:

model 
  schema 1.1
type user
type document
   relations
     define owner : [user]
     define can_view : [user] or owner

You could want to have a document_viewers table with a user_id, document_id schema, that has a record for all the documents a user can view.

We want to simplify how to let OpenFGA users create such a table.

In some scenarios like filtering or auditing, developers need to answer queries like "list all documents that user:X can read".

Depending on the use case, the problem can be solved with the existing APIs, as described in our Search with Permissions documentation, but sometimes having a new API would be more practical.

The API would look like:

Lookup(objectType, relation, user) --> List<ObjectID>

Tuples can only be deleted individually.

If you want to delete a set of tuples, you need to first find them (by using the read API, or by construct them from data in your databases), and then call the write API with a set of tuples to delete.

We should provide a way to batch delete tuples, based on different conditions. Conditions should be consistent with the ones we have in the Read API.

This would be an async API, where you'd be able to query for status or get notified after it finishes.

Open questions:

• How should be the async behavior be modeled? Callback Webhook? Polling? Streaming callback?
• What should the API return? Number of tuples deleted + tuples with errors? All deleted tuples?
• Should we have a filter called 'Invalid Tuples' so I can delete all invalid tuples?

This was done, to learn more check https://openfga.dev/docs/getting-started/setup-openfga/docker#telemetry

The authorization policies for a specific application need to be maintained by the application team. In organizations with multiple teams, it would be optimal to let each team maintain their own authorization model.

OpenFGA currently supports a single model per store, and we don't plan to change that, but we want to provide a way to enable each team maintain their models.

A possible solution would be to split the OpenFGA in multiple 'modules':

base.fga

module base
 
type user

type role
  relations
    define member : [user]

document_management.fga

module document_management
include "base.fga"

type folder
    define viewer : [user, group#member]

The files would need to be combined before saving them to the OpenFGA store, e.g.

fga model compose base.fga document_management.fga --target model.fga
fga model write --file model.fga

We can display the relations that were not checked directly in tests, directly or indirectly, and report if there were tests for which the relation returned allowed = true, and allowed = false, as tests should cover both.

For example, for the tests below:

model: |
  model 
    schema 1.1

  type user
  type document
    relations
      define viewer : [user]
      define writer : [user]
      define can_view : viewer or writer
      define can_edit: writer

tuples:
  - user: user:anne
    relation: viewer
    object: document:1

tests:
    - check:
        - user : user:anne
          object : document:1
          assertions:
            can_view : true

We could report that the relation can_edit and writer were not covered at all, and the viewer, can_view were only tested for positive results.

OpenFGA's ListObjects implementation does not perform well when relations are defined using the and or but not operators.

As a user authoring an authorization model, I want to be able to freely define types and later define its relationships.

Right now we require types to have at least one relation, which is enforced at the API-level.

We could enable types without relationship, which would simplify prototyping, e.g. when asking users to start working on their model, they can start listing the types, saving and then go through them as they update the relations.

We'll need to:

• Update the validation logic to allow a single type in the API JSON
• Update our DSL to allow empty types

As a developer writing a model, I'd want to add comments to better explain it.

The OpenFGA DSL and the Store API do not support comments.

To address this issue, we need to:

1. Update the API JSON to add a field for comments for relations and types
2. Update the DSL and the parser to translate comments typed and send them to the API and interpreting them back

We should also update the documentation to add descriptive comments for complex models.

Add a storage adapter for AWS DynamoDB

The current implementation of the Read API lets you filter read tuples in a few ways:

• With no filters (read all tuples)
• By object-id (e.g. tuples for document:document-1)
• By object-id and relation (e.g. tuples for 'document:-1' with the 'read' relationship)
• By user id and object-type (e.g. tuples for all documents for user-1)
• By user and object (e.g. tuples for user-1 and document-1
• By user, object, relation (e.g. tuples for user-1 document-1 with read relationship)

However, there are several scenarios where you need more flexibility:

• By object-type (e.g. when deleting a type from the model, I want to delete all tuples for a specific type)
• By object-type and relation (e.g. when deleting a relation from the model, I want to delete all tuples for a specific type)
• By user (e.g. when deleting a user, you want to delete all tuples for a user)
• Filters based on the object_id, e.g. if objects have a structure like permission:{org}/read, I want to filter by org.

As a developer that is leveraging Open Policy Agent I want to use OpenFGA for fine grained authorization.

When using OPA, the data that the policy needs to use is provided by whoever is enforcing the policy. For example, if the policy says that it an only be used by members of a specific group, the group information need to provided to the policy. It can be obtained from an identity token, or by making a call to a service/database to obtain it.

We want to allow OPA users to easily call the OpenFGA ‘check’ API as part of the policy decision. In that way, OpenFGA can be utilized as another Policy Information Point along other pieces of information. This allows existing OPA users to leverage OpenFGA.

To achieve that we need to integrate OpenFGA with “Rego”, the language used to define policies in OPA.

Given there's already a third party OPA integration https://github.com/thomasdarimont/custom-opa-openfga, it's not clear if we should invest on this in the near future.

The are already a couple of OpenFGA CLIs written in Javascript that provide useful functionality

https://github.com/rhamzeh/openfga-cli
https://github.com/ArcticGizmo/fga-cli

We want to provide an official one, written in Go to minimize runtime dependencies.

Given a .fga.yaml file with models + tuples defined, whenever we write a test, we can auto-suggest the tuples values.

For example, if there's a tuple that has user = employee:anne, whenever I write a check test and I type employee: I should get anne as an option.

It could be useful to provide Terraform modules so adopters can deploy OpenFGA in different cloud providers.

However, given we already have support for deploying to Kubernetes with through our Helm Charts, and that customers will still need to heavily customize the terraform module for their production environments, it's not clear this is worth doing.

This repository has a simple terraform module that can be used to deploy to AWS https://github.com/craigpastro/terraform-aws-openfga.

As a developer I want to reuse the user/groups relationships already defined in a user directory

SCIM provides a way to synchronize directory data across applications.

When deploying OpenFGA, you would want to have the relationships between users/groups that exist in the user directory to be in sync with the FGA Store.

This can be achieved by implementing a SCIM adapter that can subscribe to changes in a SCIM-enabled directory (e.g. Okta's).

These projects can serve as an inspiration:

• https://github.com/andreihava-okta/sample-node-scim-server
• https://github.com/elimity-com/scim
• https://github.com/auth0/scim

OpenFGA can benefit from multiple layers of cache. One of them is at the client-level.

We want to simplify client-side caching by implementing it on the SDKs.

Even if we are happy with the current state of the Postgres adapter, and customers have been reporting that they are using it in production without issues, we want to perform additional performance/stress testing.

• Implement a language service for Visual Studio Code that provides syntax highlighting, autocompletion, etc.
• Provide simple way to declare assertions.
• Provide a way to easily run assertions, or run a batch of check() calls, to verify that the model still works as expected.