Rich Contextual Caveats

[RichiCoder1]

Just became introduced to this project and think it's looking amazing already! However, I did run into a concern when I was reading over the documentation on contextual authorization (https://openfga.dev/docs/modeling/contextual-time-based-authorization).

Reviewing it, contextual tuples seem like an amazing and powerful tool! However, they fall a bit short in that they force business context to be forced into static "tuple" shape to really work. I normally wouldn't have thought much more of it, but another project I've been reviewing has an interesting answer that I think OpenFGA should take a peek at: caveats and rich context.

With that, consumer could provide less strict context and more flexible authorization policies that make more sense (like for example pass in the raw ip and see if it meets a cidr check).

It doesn't need to be implemented the same way (though I do think the CEL-based implementation is awesome!). An alternative could be caveats based on the Open Policy Agents Go API, which would provide access to rego (an awesome policy lang) and it's incredible rich set of built ins.

I'm not sure how either would integrate with the existing Authorization Model language, possibly they'd have to have their own store/api and would be referenced from the DSL.

[aaguiarz]

Hi @RichiCoder1

Thanks for the feedback. It's a feature we are considering, but it's not planned yet. We see value in it, but it does not replace Contextual Tuples, as those can solve problems that caveats cannot.

For example, when a user logs-in with their corporate Identity Provider, they usually get the groups they belong to in the access token, e.g.

{
"sub": "1234567890",
"name": "John Doe",
"groups": ["admins", "developers"]
}

You can provide contextual tuples that establish that group membership relation, instead of having to synchronize the user<->group relationship from your corporate directory to the FGA store.

[RichiCoder1]

Absolutely! I do consider them complementary, not either or.

[aaguiarz]

We added this to our backlog openfga/roadmap#32