Externalizing Access Control

Scattered and Hard-to-Maintain Authorizations

Authorization Spaghetti Code

In a traditional approach, authorization rules are scattered throughout the application code:

// Typical example of "hardcoded" authorization logic
public Patient getPatient(Long id, User user) {
    Patient patient = patientRepository.findById(id);

    if (user.hasRole("ADMIN")) {
        return patient;
    }

    if (user.getDepartment().equals(patient.getDepartment())) {
        if (user.hasRole("PHYSICIAN") || user.hasRole("NURSE")) {
            return patient;
        }
    }

    if (patient.getCareTeam().contains(user.getId())) {
        return patient;
    }

    throw new AccessDeniedException("Access denied");
}

This code presents several issues:

• Tight coupling: business logic and access rules are mixed together
• Duplication: these checks are repeated throughout the application
• Rigidity: any modification requires redeployment
• Opacity: impossible to answer “who can access what?”

Healthcare Industry Challenges

In the hospital domain, requirements are particularly stringent:

• Regulatory compliance (GDPR, HIPAA, HITECH)
• Audit trail for sensitive data access
• Fine-grained permissions based on roles and context
• Emergency procedures (“break-glass”)

The Solution: Externalization with Big ACL

Externalized Architecture

Access control externalization relies on the PDP/PEP pattern (Policy Decision Point / Policy Enforcement Point):

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│   Application   │────▶│   PEP (SDK)     │────▶│   PDP (OPA)     │
│   Hospital      │     │   Big ACL       │     │   Policies      │
└─────────────────┘     └─────────────────┘     └─────────────────┘
                                                        │
                                                        ▼
                                               ┌─────────────────┐
                                               │   PAP (Console) │
                                               │   Big ACL       │
                                               └─────────────────┘

• PEP (Policy Enforcement Point): intercepts requests and enforces decisions
• PDP (Policy Decision Point): evaluates rules and makes decisions
• PAP (Policy Administration Point): policy management interface

Demonstration: The Hospital Demo Application

Our demo application simulates a hospital patient portal with sophisticated access rules: department-based access, role-based permissions, care team membership, and emergency “break-glass” procedures.

Access Control in Action

Depending on the user’s profile, permissions vary automatically. An ER physician only sees patients from their department, while a department head has broader access.

[Screenshot: Access comparison between a physician and a nurse on the same patient record - showing available/unavailable actions based on profile]

Policies in Rego

A Declarative and Expressive Language

Authorization rules are defined in Rego, Open Policy Agent’s policy language:

package hospital.authz

# Main authorization rule
allow {
    input.action == "view"
    is_care_team_member
}

allow {
    input.action == "view"
    same_department
    is_clinical_staff
}

# A care team member can always access
is_care_team_member {
    input.subject.id == input.resource.careTeamUserIds[_]
}

# Department check
same_department {
    input.subject.department == input.resource.department
}

# Clinical staff
is_clinical_staff {
    input.subject.roles[_] == "ROLE_PHYSICIAN"
}

is_clinical_staff {
    input.subject.roles[_] == "ROLE_NURSE"
}

Benefits of Declarative Policies

1. Readability: rules are understandable by non-developers
2. Testability: policies can be unit tested
3. Auditability: complete history of changes
4. Reusability: same policies for multiple applications

Administration with Big ACL PAP

Centralized Management Console

The Big ACL PAP offers an intuitive interface for managing policies: real-time editing, simulation before deployment, and complete decision traceability.

[Screenshot: Big ACL PAP Console showing the policy editor and audit logs]

Concrete Benefits

1. Separation of Concerns

Application code focuses on business logic:

// Before: mixed authorization logic
public Patient getPatient(Long id, User user) {
    // 50 lines of checks...
}

// After: delegation to PDP
@PreAuthorize("@pdp.check('view', #id)")
public Patient getPatient(Long id) {
    return patientRepository.findById(id);
}

2. Modification Without Redeployment

Rules can be updated in real-time via the PAP, without touching code or redeploying the application.

3. Simplified Compliance

• Audit: “Show me all access rules for sensitive data”
• Documentation: policies serve as living documentation
• Certification: tangible evidence for auditors

4. Risk Reduction

• Automated policy testing
• Separate code review for security
• Instant rollback if issues arise

5. Scalability

The same policies can be shared across:

• Web and mobile applications
• APIs and microservices
• Batch and asynchronous processing

Conclusion

Externalizing access control with Big ACL transforms authorization management:

Aspect	Before	After
Rule location	Scattered in code	Centralized in PAP
Modification	Redeployment required	Real-time
Audit	Manual and incomplete	Automatic and comprehensive
Testing	Complex	Unit-based and automated
Understanding	Reserved for developers	Accessible to business users

For applications handling sensitive data like medical records, this approach is no longer a luxury but a necessity to ensure security, compliance, and agility.

---

Additional Resources:

• Big ACL Documentation
• Open Policy Agent
• Demo Source Code

This article was written by the Big ACL team. For any questions, contact us at contact@big-acl.com