Splitting permissions and resources
Eventually your software and therefore Authress account will get to a point where you will need to introduce a new permission.
Scenario
A simple example is that today you have a single permission called read:✶ and tomorrow you are thinking about introducing the permission read:projects.
In this case, you probably have a role Viewer and while that role does not need to be changed, an existing new Role would need to be created Project Reader, so that just the new permission could be assigned to new access records.
New permissions should be aligned with your user personas. In Authress these are the user roles. Normally, when user records are created when users signup or are invited, it's these Personas/Authress Roles that should be automatically assigned.
Strategy
Because all existing users with the Viewer role access does not need to change. We only need to create new Role Project Reader and we are done with the Authress role configuration. The full set of steps are:
- Create a new role that represents the new persona, with the appropriate permissions.
- Update your UIs and applications to support users' ability to assign that role.
- Update your services using the Authress Authorization Check to ensure that check now checks for the new permission
read:projects.
And that's it.
Because Authress let's you assign Roles to Access Records, this provides the critical abstraction making it easy to dynamically change roles without needing to update any access records.
After that, it would be up to your users to decide how to best make use of the new role.
Splitting a resource
Consider a similar scenario, but one in which today the resources an admin has access is your only application called Chat. In general the admin of your each of your customers should have an access record similar to the following:
No matter what the future might hold, this user will have access to everything. Some other users likely will only need to have access to the Chat application and no future applications. Creating this distinction is a product level concern, and you should ask
In the future when we create a new type of application should existing non-admins also have access to that application
Most of the time, the answer is no, but sometimes the answer is yes.
In the former case, consider creating access records limiting admin's future capabilities:
A record like this explicitly says "This admin user does not have access to /v1/projects nor /v2/projects nor any future resources we might add, and It's an explicit choice."
What's important here is that resources cascade automatically. Access to /v1/chats/* grants access to all sub resources of chats. No matter how many types of sub-chat resources are created, the admin user will still have access to all of them. This allows for splitting resources in a similar way as roles without needing to update any access access records. Check out Cascading resource permissions.
Extending the model
We should take it a bit further, and consider that most users will have permissions scoped to a particular tenant or customer:
With this pattern, users would be restricted to all the resources of one specific customer. But that user in this way would have access to everything in the chat application, irrespective of what additional resources are added in the future.
Explicit expand edge cases
There is an edge case here, the desire to split an existing resource.
New permissions, permission updates, splitting of permissions, as well as new resources all work with the above paradigm out of the box. However, splitting a resource in two, does not have an out of the box strategy. For instance, if you had one product called Chat and users had access as above, and then one day decided to convert this one product into two products, there is indeed no good way to update all users from the above to something like this:
in this case the required migration based would require you to update every access record to include access to the new application and its resources. This is why it is important when assigning permissions to consider whether access is being assigned at the customer/tenant level or for just one particular application.
The good news is that this is a rare occurrence, and if you find this scenario to be one you have encountered, please reach out to us. Usually this is the result of mis-designed access model rather than expected in your usage of access records. If you find you are in this scenario and it is a one off activity, please reach out to us so that we can both refine our expectations and more explicitly provide assistance to help you achieve that migration. Fundamentally, internally, we have tools in place to achieve migrations at scale far beyond what could be capable with a public API.