A high performance and flexible authorization/permission engine built for developers and inspired by Google Zanzibar
[BREAKING] this release introduced protobuf API changes to the gRPC API to accommodate changes for the up and coming Conditional Relationship Tuples feature. No changes to the OpenAPI specification for the HTTP API have changed. gRPC clients that are referencing the old protobuf definitions are not compatible with this release and future releases >= v1.3.8. To upgrade to this release please update your existing OpenFGA gRPC clients to the latest protobuf API definitions. Failing to do so can lead to message and field level incompatibilities with existing clients.
Experimental support for ABAC Conditional Relationships.
To enable experimental support for ABAC Conditional Relationships you can pass the enable-conditions experimental flag. For example, openfga run --experimentals=enable-conditions. The upcoming v1.4.0 release will introduce official support for this new feature. For more information please see our official blog post. The v1.4.0 release will have more official documentation on openfga.dev.
⚠️ If you enable experimental support for ABAC and introduce models and/or relationship tuples into the system and then choose to rollback to a prior release, then you may experience unintended side-effects. Care should be taken!
Read on for more information.
If you introduce a model with a condition defined in a relation's type restriction(s) and then rollback to a prior OpenFGA release, then the model will be treated as though the conditioned type restriction did not exist.
model
schema 1.1
type user
type document
relations
define viewer: [user with somecondition]
condition somecondition(x: int) {
x < 100
}
and then you rollback to v1.3.7 or earlier, then the model above will be treated equivalently to
model
schema 1.1
type user
type document
relations
define viewer: [user]
Likewise, if you write a relationship tuple with a condition and then rollback to a prior release, then the tuple will be treated as an unconditioned tuple.
- document:1#viewer@user:jon, {condition: "somecondition"}
will be treated equivalently to document:1#viewer@user:jon in v1.3.7 or earlier. That is, Check(document:1#viewer@user:jon) would return {allowed: true} even though at the tuple was introduced it was conditioned.
Minimum datastore schema revision check in the server's health check (#1166)
Each OpenFGA release from here forward will explicitly reference a minimum datastore schema version that is required to run that specific release of OpenFGA. If OpenFGA operators have not migrated up to that revision then the server's health checks will fail.
Username/password configuration overrides for the openfga migrate entrypoint (#1133). Thanks for the contribution @martin31821!
Similar to the server's main entrypoint openfga run, you can now override the datastore username and password with environment variables. when running the openfga migrate utility.
Healthcheck definitions in Dockerfile (#1134). Thanks @Siddhant-K-code!
Database iterators yielded by the RelationshipTupleReader storage interface now accept a context parameter which allows iteration to be promptly terminated (#1055)
We have noticed improvements in query performance by adding this because once a resolution path has been found we more quickly cancel any further evaluation by terminating the iterators promptly.
Improved tuple validation peformance with precomputation of TTUs (#1171)
Refactored the commands in the pkg/server/commands package to uniformly use the Options builder pattern (#1142). Thanks for the contribution @ilaleksin!
Upgraded to Go 1.21.4 (#1143). Thanks @tranngoclam!
The v1.4.0-rc1 release is an experimental release candidate that introduces new support for ABAC Conditions in OpenFGA.
For more information, take a look at our blog post Conditional Relationship Tuples for OpenFGA. This blog post talks more about the feature and how to make use of it.
Export metrics from MySQL and Postgres (#1023). Thanks @matoous!
To export datastore metrics, set OPENFGA_METRICS_ENABLED=true and OPENFGA_DATASTORE_METRICS_ENABLED=true.
OPENFGA_LIST_OBJECTS_MAX_RESULTS=0 (#1067)Write Authorization Models in a single database row (#1030)
:warning: In order to avoid downtime, we recommend upgrading to at least v1.3.3 before upgrading to v1.3.5.
This is the second of a series of releases that will progressively introduce changes via code and database migrations that will allow authorization models to be stored in a single database row.
check-query-cache experimental flag is turned on (#1059)Configurable size limit for Authorization Models (#1032)
We've introduced a new size limit for authorization models, providing a consistent behavior across datastores, which defaults to 256KB. This can be configured by using the --max-authorization-model-size-in-bytes flag.
Persist Authorization Models serialized protobuf in the database (#1028)
In the next series of releases will progressively introduce changes via code and database migrations that will allow authorization models to be stored in a single database row.
Patches CVE-2023-43645 - see the CVE for more details
[BREAKING] If your model contained cycles or a relation definition that has the relation itself in its evaluation path, then Checks and queries that require evaluation will no longer be evaluated on v1.3.2+ and will return errors instead. You will need to update your models to remove the cycles.