6 posts tagged with "openfga"

MCP agents are becoming capable of calling an increasingly broad range of tools. That creates a corresponding authorization challenge. It is not enough to know whether an agent can call a tool. In many cases, authorization also depends on the request's runtime context.

For example, an agent might be allowed to send Slack messages, but only to the #product-announcements channel.

OpenFGA is well-suited to model relationships between users, groups, roles, agents, tools, and resources. MCP gateways can use those relationships as an enforcement point for deciding which agents are allowed to invoke which tools.

However, highly dynamic policies can be difficult to represent using a traditional OpenFGA model. If every possible runtime constraint requires a schema change, authorization logic becomes harder to maintain, especially when MCP servers and their tools change frequently.

Today, we are introducing Dynamic Conditions, an experimental OpenFGA feature that lets you attach CEL expressions directly to authorization tuples and evaluate them at runtime.

We've added two new optional parameters to the Write API endpoint to improve the experience of writing data to FGA. You can now gracefully "ignore" duplicate writes and missing deletes.

OpenFGA query APIs now allow specifying the desired consistency of query results. By default, OpenFGA does not use a cache. However, when caching is enabled, it applies to all requests. This means that any changes in permissions won't be reflected in authorization checks during the cache TTL period.

The community expressed the need for flexibility in using the cache on a per-request basis. In response, starting with OpenFGA v1.5.7, all query APIs can accept a consistency parameter with the following values:

Today we are launching a new API for OpenFGA: ListUsers.

This API will answer the question "what users have relation X with object Y?". This will be useful, for example, in UIs that want to display the list of users that a resource has been shared with, e.g. the "share" dialog in Google Docs.

You can read more about it in the API docs and the product documentation.

Modular models aims to improve the model authoring experience when multiple teams are maintaining a model, such as:

• A model can grow large and difficult to understand
• As more teams begin to contribute to a model, the ownership boundaries may not be clear and code review processes might not scale

With modular models, a single model can be separated across multiple files allow grouping of types and conditions into modules. This means that a model can be organized more easily in terms of team or organizational structure. Used in conjunction with features such as GitHub, GitLab or Gitea's code owners, it should become easier to ensure the owners of a portion of your model are correctly assigned to review it.

Relationship Tuples are the facts that the OpenFGA evaluates to determine whether a user is permitted to access a resource.

The way tuples are considered when making authorization decisions in OpenFGA is guided by an authorization model, which employs concepts from Relationship-Based Access Control (ReBAC) to establish authorization policies. For instance, you might declare that users are allowed to view a document if they have permission to view its parent folder.

Although ReBAC offers a highly flexible method for structuring permissions, it encounters difficulties with defining permissions based on attributes that are not easily represented as relationships. Attributes such as “parent folder,” “department,” “region,” and “country” can be conceptualized as relationships between two entities. However, attributes like “IP address,” “time of day,” “team size limit,” or “maximum amount for a bank transfer” cannot be easily handled.

In our ongoing efforts to expand OpenFGA’s capacity for articulating a broader range of authorization policies, we are introducing Conditional Relationship Tuples. These allow for the specification of conditions under which a particular tuple is relevant when evaluating an authorization query.