First – Simply Stated – Authorization is hard – This post is intended to help break it down into several easier to understand concepts
- High Level Definition
- Policies
- Requirements
High Level Definition
Authorization is granting permissions, by way of policies, to perform actions ( aka. to invoke capabilities ).
Policies
Policies define any combination of requirements that must be met in order to grant the permission to perform the action / invoke the capability. Here is a list of requirement types I have encountered and I think will cover almost any type of scenario you will face:
- Authentication Status
- Identity Type
- Resource Ownership / Association
- Permission Assignment
- Demographics
- Associated Products
- Regulations
As an application architect, or lead engineer, a key role is to identify the authorization policy requirements of functional capabilities. Listen for requirement matching patterns such as
PERSONA should not be able to PERFORM ACTION unless REQUIREMENT MET
Business Logic in Authorization
If you have studied Domain Driven Design (DDD) patterns, you may soon be asking yourself while reading through this post, “Are you sure this is not domain logic?” . The answer is a resounding YES, authorization logic is an aspect of domain logic.
So it should be an imperative that the authorization policies, requirements, and validation of requirements be implemented centrally within the domain layer.
Note that I mentioned authorization logic is an aspect of domain logic. If you have ever done aspect oriented programming (AOP), then you know the punch line here. AOP aims to separate the different aspects of a functional capability into dedicated parts . Common aspects include input validation, caching, transaction management, domain service or entity logic, and of course authorization logic.
Requirements
Authentication Status Requirement
The simplest authorization requirement is perhaps to grant permission based on the authentication status of the user. Some examples include:
- Authenticated User
- Anonymous User
- Step-Up Authenticated User
- Surprised?, this requirement would force a step-up authentication for critical actions.
Identity Type Membership Requirement
After authentication status, this is next in the evolution of authorization requirements. This is a check against high level segregation of user types; such as :
- Member
- Partner
- Support Agent
Resource Ownership / Association Requirement
Some policies require ownership to a resource in order to perform specific capabilities associated with it.
- Some Examples
- Only the individual can add authorized users to an account
- Only the individual can change their password
- Only the individual can view their medical records
Some other policies may require some ownership or delegated association to the resource
- Some Examples
- A contact must be associated with an organization in order to invite another contact to join the organization
Permission Assignment Requirement
Requires that a user has been assigned a permission by someone, or something, else with the proper authority to do so.
While this is by far, the most well-known type of policy requirement, it may seem pretty straightforward until you try to implement it yourself. So let me help you and your team out.
Assignments can be generally assigned and can also be assigned at the resource level through resource specific access control lists (ACL). Assignments can be explicit to an individual user or through grouping constructs. Lastly, there are good naming conventions for permissions and then there are bad ones.
I have broken this section up accordingly to those considerations.
General Permission Assignments
This is a very common, straightforward type of assignment; Where the assigned users can perform the operation without specific resource contexts, in other words, for any resource.
- Example of Permissions
- Can Enroll Users
- Can View Users
- Can Deactivate Users
Resource Access Control List (ACL) Assignments
Often times we run into situations, where we want even finer grain access to the specific resource(s). Access control lists ( ACLs ) are the set of permissions assigned specific to users for a specific resource.
- Examples of ACL Permissions
- Can View Meetings of Specific Calendar
- Can Schedule Meetings of Specific Calendar
- Can Cancel Meetings of specific Calendar
Be mindful of the maintenance required for end-users and the confusion this can bring. It may be more maintainable to assign ACLs by a higher level grouping construct resource.
- Examples of ACL Permissions by Group Construct Resources
- Can View Meetings of Operations’ Calendars
- Can Upgrade Memberships of customer in Sales Region A
- Can Complete Work Items under Company Project A
Assignments by Grouping Constructs
Solutions that allow for assigning permissions almost always has some form of grouping constructs to assign to. Although, role-based access control (RBAC) is the most common grouping construct for assigning permissions, this is not a limitation.
Role-Based Access Control (RBAC)
- Allows for defining roles, some example patterns
- Intended Permission Based ( Reader, Writer, Admin)
- Organization Based ( Service Rep, Sr. Service Rep, Supervisor, Manager )
- Allows for adding members into those roles
- Often integrated with an organization’s Identity Provider where roles can be centrally managed
- Finally, allows for assigning permissions based on those roles
Other Grouping Constructs
While RBAC grouping constructs are the most prevalent, it is important to recognize it is not the only grouping construct. Grouping constructs are simply a means of allowing users to assign permissions to some form of associated, or filtered, list of users.
For example, any of the other permission requirements outlined in this post could also be some form of a grouping construct. The big difference, is to define those potential requirements as a grouping construct and allowing for a run-time (re-)configuration of permissions based on those groups instead.
Naming Conventions
CRUD based permission assignments (bad)
vs.
Capability based permission assignments (good)
Two most difficult things to solve in engineering
- Naming Things
- Cache Invalidation
- Off By One Errors
While we may not solve cache invalidation and off by one errors here, I do want to provide guidance on permission naming conventions.
When it comes to defining permission that can be assigned, there are good ways, and then there are bad ways.
- CRUD based permission style ( bad )
- Can Create, Read, Update, and Delete Users
- Capability based permission style ( good )
- Can Enroll, View Public Profile of, Suspend, and Deactivate Users
When put side-by-side like that, it should be pretty obvious as to why CRUD based permissions are simply atrocious. The context of the user’s intent is lost; Consequently, a lot is left up to the interpretation of the person assigning permissions.
I find the existence of CRUD based permission models to be a strong indicator of either a) poor domain understanding by the application architect (or lead engineer), or b) an engineered generalization without sufficient extensibility.
Aiming for Capability-Based permission styles will always lead to a stronger understanding of the domain. Similarly true when aiming for capability based API endpoints.
Regulation Requirements
One of the more complicated types of policy requirements to implement in authorization logic is when there are regulations that need to be applied to protect access to functional capabilities
- Some Examples
- User must have be an adult or have parental consent to register into a tournament
- Evidence user is 18, or older, or
- Evidence user has parental consent
- User must have agreed to T&C agreement to view account details online
- Evidence of T&C signature
- User must have be an adult or have parental consent to register into a tournament
Code Impressions 