Building Secure Software: The Hidden Complexity of Authorization

Authorization?is a vital part of any software system. Once a user is authenticated, the next step is determining what that user is allowed to do. This process, known as authorization, ensures that users can only access the data, functionalities and outputs that their roles or permissions allow. While authorization is essential, it’s often highly complex. Each system tends to reinvent the wheel instead of leveraging reusable checklists and frameworks.

Authorization isn’t solely about internal business requirements. External factors — such as?legal obligations or licensing constraints?— add layers of complexity to the process. For instance, software licenses might limit the number of users, API calls, or functions that can be accessed.

Authorization spans also several levels, such as?data segregation, functional segregation, and output segregation. Each of these levels contributes to the overarching complexity of building a secure system:

Data Segregation: This ensures that users can access only the data relevant to their role. However, what appears straightforward can quickly become intricate. For example:

• Users may have different permissions for reading, writing, or deleting data. Users might be able to update or delete certain records but can only view others.
• A multinational bank may need to segregate data by country, allowing users to access data from specific countries. Exceptions might exist, such as cross-border teams needing access to multiple countries, or users serving VIP customers who require special permissions.
• Additionally, sensitive data, like credit card numbers, may need to be hidden or anonymized to comply with regulations like PCI-DSS or GDPR. Even if users have access to a record, certain data attributes could remain restricted.

Functional Segregation: This controls which functions users can access within the software. It’s not just about high-level access to entire modules; users may have different access levels to specific features within those modules. For instance, a user might be able to search records but not create them, or only perform certain actions based on a record’s status. This granular control is crucial, particularly in compliance-heavy environments.

Output Segregation: This dictates what outputs, such as reports, screens, or data exports, users can view. Limiting outputs based on user permissions not only protects sensitive information but also streamlines the user experience, making the software easier to navigate without compromising security.

Multi-tenancy: In SaaS (Software as a Service) models, a single software instance often serves multiple tenants, such as different companies or user groups. Each tenant has its own security administrators, licenses and configurations. A robust authorization model must ensure that tenants are isolated from each other, both in terms of data and performance (e.g. preventing one tenant’s heavy processing from affecting others).

The Four-Eyes (N-Eyes) Principle: In financial services, the four-eyes principle (or six-eyes or eight-eyes) is common, requiring an update to be validated by another user before it takes effect. This adds an additional layer of authorization complexity, as different users with approval roles must be properly configured and updates need to be temporarily stored until validated.

Two widely?adopted models?help manage these complex authorization needs:

• Role-Based Access Control (RBAC): RBAC is a traditional approach where users are assigned roles corresponding to specific permissions. For example, a "manager" role may have access to more functions and data than a "customer service representative" role. While RBAC works well in many scenarios, it can become cumbersome when fine-grained access is needed, as roles can multiply rapidly.
• Attribute-Based Access Control (ABAC): ABAC offers a more flexible solution by determining access based on user attributes, resource characteristics, or environmental conditions. For example, access to a customer record might depend not only on the user’s role but also on attributes like location, time of day, or record status. ABAC provides more dynamic control, but its complexity makes policy management challenging.

Despite the availability of RBAC, ABAC, and reusable checklists, many organizations still create custom authorization mechanisms, often underestimating the complexity involved. Common challenges include:

• Performance: Data segregation often requires query-level filtering, adding extra conditions (e.g. WHERE clauses). This can be efficient if authorization rules are simple, but complex rules may require post-query authorization, slowing down the application.
• Flexibility vs. Maintainability: Balancing flexibility with maintainability is a major challenge. A rigid system may be difficult to scale, while an overly flexible system can become hard to manage, especially with strict security and compliance requirements.
• Centralized Authorization Tools: In heavily regulated industries like finance, authorization is often managed through tools like Active Directory. When users log in (often via SSO), roles are returned by this central tool, and the application must adjust permissions accordingly. While these tools simplify some aspects of authorization, they also impose constraints that can hinder custom implementations.

The above shows that authorization is both a technical and business challenge, requiring careful planning and execution. While frameworks like RBAC and ABAC can simplify the process, building a secure, flexible, and maintainable system without sacrificing performance or compliance remains a complex task. Leveraging established frameworks and checklists can help avoid unnecessary reinvention, but there’s no one-size-fits-all solution—especially in multi-tenant and high-security environments.

For more insights, visit my blog at?https://bankloch.blogspot.com