We are excited to announce the Developer Community Preview for Auth0 Fine Grained Authorization (FGA), our upcoming SaaS to solve authorization-at-scale for developers.
Read more…
Brought to you by @yenkel1
1 Like
Hey folks! Let us know if you have any questions in the comments below!
While this seems to to support REST resources access control.
I would like to ask about your thoughts on resource attribute filtering vs. FGA, as Alice with admin privilege might be able to see secret attributes, while Bob with support privilege only has access to confidential attributes.
How would FGA support this use case**?**
@robertino.calcaterra could you provide some insight into it? Thank you!
1 Like
Hey @dlehammer! Welcome to the community!
Is the below a good summary of your question?
- You have a certain resource (let’s say Project X)
- Project X can have multiple attributes on it. Let’s say “name” is visible and “estimated_cost” is confidential
- Alice, an admin on Project X should be able to access both the “name” and “estimated_cost” attributes
- Bob, a support engineer on Project X should only be able to access the “name” attribute.
If that is the case, one way to model it using Auth0 FGA could be:
# You have projects
type project
relations
# projects can have admins
define admin as self
# projects can have support engineers
define support_engineer as self
# only admins can edit projects
define editor as admin
# admins and support engineers can view projects
define viewer as support_engineer or admin
# You have attribute visibility (e.g. normal/confidential)
type attribute_visibility
relations
# attribute visibilities belong to a project
define project as self
# attribute visibilities have editors
define editor as self
# attribute visibilities have viewers
define viewer as self or editor
# You have attributes
type attribute
relations
# attributes have a visibility
define visibility as self
# attributes have a project
define project as self
# attributes have an editor
define editor as editor from project and editor from visibility
# attributes have a viewer
define viewer as viewer from project and viewer from visibility
define can_edit as editor
define can_view as viewer
[
// Project X has two attribute visibilities, normal and confidential
{
"user": "project:X",
"relation": "project",
"object": "attribute_visibility:normal"
},
{
"user": "project:X",
"relation": "project",
"object": "attribute_visibility:confidential"
},
// Project X admins can edit and view confidential attributes
{
"user": "project:X#admin",
"relation": "editor",
"object": "attribute_visibility:confidential"
},
// Project X admins can edit and view normal attributes
{
"user": "project:X#admin",
"relation": "editor",
"object": "attribute_visibility:normal"
},
// Project X support engineers can view normal attributes
{
"user": "project:X#support_engineer",
"relation": "viewer",
"object": "attribute_visibility:normal"
},
// Alice is an admin on Project X
{
"user": "alice",
"relation": "admin",
"object": "project:X"
},
// Bob is a support engineer on Project X
{
"user": "bob",
"relation": "support_engineer",
"object": "project:X"
},
// Project X has a name attribute
{
"user": "project:X",
"relation": "project",
"object": "attribute:project-x-name"
},
// Project X has an estimated budget attribute
{
"user": "project:X",
"relation": "project",
"object": "attribute:project-x-estimated-budget"
},
// estimated budget's visibility is confidential
{
"user": "attribute_visibility:confidential",
"relation": "visibility",
"object": "attribute:project-x-estimated-budget"
},
// name's visibility is normal
{
"user": "attribute_visibility:normal",
"relation": "visibility",
"object": "attribute:project-x-name"
},
]
We can check that:
| User | Action | Resource | Allowed? |
|---|---|---|---|
| Alice | View | Project X’s name | Yes |
| Alice | View | Project X’s estimated budget | Yes |
| Bob | View | Project X’s name | Yes |
| Bob | View | Project X’s estimated budget | No |
You can see an interactive version of the model described above on the Auth0 FGA Playground: Auth0 Fine Grained Authorization
Let us know if this helps!
Take a look at the Auth0 FGA documentation: https://docs.fga.dev
Join the Auth0 Lab Discord community: The Auth0 Lab
1 Like
Thanks for the followup @raghd.hamzeh !
Hi @raghd.hamzeh,
Thanks for taking the time to elaborate 
Took a while to decipher the outlined verbose relations configuration manually, as the deep-link https://play.fga.dev/stores/create?id=887f6c81-2e92-45de-ab93-643a0da3eeea results in the below screenshot for me (note how I’m redirected to the default create-page) 
(the default examples provide a great overview, but unfortunately seems unfeasible for the large datasets I’m facing)
Regarding
Is the below a good summary of your question?
…
Almost, I failed to convey the usually dynamic nature of the reality I’m faced with for authorization of resources.
Where there’s millions of resources, one to thousands sharing attributes allowing access for users with matching attribute privileges.
Ie. hard-coding values in the rules seems incompatible with the desire to express general auth-rules for a data-set.
~ Ie. dynamic rules ala; if the user has privilege covering value %X on the “Project” resource-type, then access is permitted for resources matching %X.
(Perhaps something similar-ish to AuthzForce Core - Using Variables (VariableReference) in Target/Match ~ I’m not familiar with that framework, but the wording suggests dynamic support)
Also I’m concerned about the testability of the auth0-fine-grained-authorization approach with regards to automatic coverage, perhaps you’d be able to elaborate ?
So I just wanted reach out and hear your thoughts on the matter 
1 Like