#ABAC support
queen oriole
Maybe it's related to this issue in the GitHub repository
If so, do you have an estimation of when it would be released ?
https://github.com/Permify/permify/issues/255
hasty tree
Hi @queen oriole, Thank you for sharing the case. Yes, it is related to attribute-based support, and we are currently in the process of building it. The estimated release date for that is the last week of July.
Meanwhile, we would love to learn more details about your use case and assist in modeling your permission system.
queen oriole
That's really kind,
Basically I try to create a model where user can be one of two types:
- internal_user
- regular_user
A regular_user should have access to different websites inside a system where he could be Admin, Editor, Viewer or NoAccess
An internal_user should have access to the backoffice as well as all the existing sections under the following roles: Admin, Developer, Viewer
Our use case would be to create an access level in which an internal_user under role Developer could have Admin rights on a website if this website is marked to be Test or Demo (so developers won't be able to modify elements on website owned by regular users)
hasty tree
Hi again @queen oriole ,
We tried to model the use case you described by conducting two schemas. One of them was modeled using the current capabilities of our schema language, which means it does not include attributes or ABAC. The other schema incorporates the abilities of our upcoming ABAC support.
Schema (current version, no ABAC):
https://play.permify.co/?s=_voWjOAcY6b6lAz25GzXF
To be honest, although it appears to solve the case, we don’t like it because of its somewhat hacky nature.
Schema with upcoming ABAC support:
entity internaluser {}
entity regularuser {}
entity backoffice {
relation admin @internaluser
relation developer @internaluser
relation viewer @internaluser
permission view = admin or developer or viewer
permission modify = admin or developer
}
entity website {
relation backoffice @backoffice
relation admin @regularuser
relation editor @regularuser
relation viewer @regularuser
attribute status string
permission modify_elements = backoffice.modify and check_status(status)
}
func check_status(status string) {
status == "TEST" || status == "DEMO"
}
I am curious to hear your thoughts on these approaches. Additionally, would you be open to a call ? We would love to gain a better understanding of your use case and other expectations regarding the desired permission system. Here is my calendar: https://meetings-eu1.hubspot.com/ege-aytin/customer-discovery-ege. Feel free to select an available spot.
queen oriole
I was thinking about model more like this:
entity user {}
entity site {
relation backoffice_admin @user
relation backoffice_developer @user
relation backoffice_viewer @user
relation admin @user
relation editor @user
relation viewer @user
// attributes
attribute status string
// actions and permissions
action administrate = admin or backoffice_admin or (backoffice_sales and is_demo_or_test(status))
action edit = administrate or editor
action view = edit or backoffice_sales or backoffice_viewer or viewer
}
func is_demo_or_test(status string) {
status == "TEST" || status == "DEMO"
}
In your solution, the issue is that you define from the start 2 different entities to map the attribute
When in my use case I need those entities to be unified.
hasty tree
Got it. Does this last model you sent solve the attribute issue? Because we are currently building something similar in our ABAC support.
hasty tree
If you have any questions further, feel free to ping us anytime ✌🏻