# 001 - IBP Authorizer

Gil Ferreira

Alexander Zabielski

Last Modified: June 30th, 2025

Status: Implemented

# Context

The legacy IBP Authorizer was a critical bottleneck in our API infrastructure. It suffered from significant architectural limitations:

It handled token-based and request-based authentication in separate modules, introducing misalignment in auth flow.
Security enforcement was flawed, with permissive logic and inadequate RBAC implementation.
The codebase lacked modularity, making maintenance and enhancements difficult.
Performance issues were prevalent, with average latency of 4 seconds due to inefficient policy evaluation and lack of caching optimization.

These challenges created systemic risk for the platform, especially as demands for consistent, secure, and performant API access control increased across our products.

# Decision

We replaced the legacy IBP Authorizer with a re-engineered Lambda-based authorizer using Python 3.12. This new implementation features unified support for both token-based and request-based authentication, YAML-based RBAC policies, enhanced logging, and robust access control mechanisms.

# Rationale

The decision was based on several critical factors:

Security:
- The previous authorizer allowed overly permissive access due to token decoding without sufficient role validation.
- The new authorizer uses strict role-based enforcement and eliminates insecure caching patterns.
Performance:
- The new Lambda authorizer achieved a 90% reduction in latency, from 4 seconds to 400ms.
- Improvements stem from architectural redesign, code optimizations, memory allocation tuning, and provisioned concurrency.
Maintainability and Simplicity:
- Removed Redis from the critical path, simplifying the stack.
- YAML-based RBAC and method ARN targeting allow easier updates and faster evaluation.
Developer Experience:
- Clear separation of concerns in the codebase (auth, RBAC, app logic).
- CI/CD pipelines with code quality checks improve long-term maintainability.
Flexibility and Immediate Policy Effectiveness:
- Removed policy caching, enabling dynamic policy updates without redeployment or invalidation delays.
- Policy on each request versus a blank allow policy

# Implications

People/Training:

Team training was minimal due to use of familiar tools (Python, AWS Lambda).
Some education around new RBAC structure and YAML configuration was required.

Process Adjustments:

CI/CD pipelines updated to accommodate the new deployment model via Terraform.
API Gateway configurations adjusted to utilize the new Lambda authorizer.

Tooling:

Ubuntu workspaces with proper tooling installed.
Consolidated infrastructure-as-code via Terraform.

Risks:

Initial learning curve for new YAML-based RBAC policy format.
Risk of unifying all APIs to one authorizer requires proper gatekeeping to ensure that no issues flow their way to production.

# Trade-Offs

Benefits:

Unified authentication logic for all API requests.
Stronger, granular access control with default-deny security posture.
Easier debugging and operational visibility.
Dramatically faster invocation time.

Drawbacks:

Policy changes now rely on RBAC file updates; requires discipline in config management.

# Key Evaluation Metrics

Latency: Average invocation time reduced to ~400ms.
Security: Role-based enforcement active for all endpoints; isPublic tagging introduced.
Reliability: Dynamic, cache-less policy evaluation reduces update lag.
Developer Productivity: Reduced time to onboard new APIs to authorization model.

# Conclusion

We recommend adopting the re-engineered IBP Authorizer due to its substantial improvements in performance, security, and maintainability. While there are small trade-offs such as managing RBAC configuration, the overall benefits provide a significantly more secure, responsive, and scalable API authorization solution.