Establishing permissions, or the rights a user has to access data is a granular process. Usually, a user is assigned to a group that represents their permissions level. AuthZ examines tokens using custom logic, predefined rules, or signed requests that have specific policies.
Assigning Groups
The most permissive user group is an “admin” or “superuser,” which gives the user read/write access to the entire data repository. On the other extreme, a user may only have read-only access to a subset of data. For example, a CRM administrator can create data structures, control user permissions, and edit the templates that allow specific user groups to view subsets of data. Or, a sales development rep may only be able to view the leads that are assigned to them, and view phone numbers, emails, tasks, and scripts for conducting their outreach.
These user groups specific to each role need individual policies that govern their read/write access to data. The policies can be quite complicated, especially with B2B use cases, and require careful planning and enforcement.
The Application Layer
Application environments typically have read/write permissions for the entire database, meaning it’s up to the software developers to manage authorization policies that enforce more granular levels of read/write access. A mistake by the software engineer could accidentally provide an anonymous user with read/write permissions for the data repository, highlighting why it’s critical for these policies to be enforced correctly.
Common of AuthZ Use Cases In Different Environments
Here are some examples of activities that are subject to AuthZ policies:
- Web Applications. Viewing specific web pages and updating data within a web application.
- Operating Systems. Processes like running terminal commands, viewing and editing files, launching programs, and updating settings.
- Accessing Network Hardware. The ability to change firewall policies.