RBAC middleware support

[goginenibhavani2000]

Description:

• Added a declarative RBAC middleware with JSON‑defined roles, flexible role extraction, pattern matching, and helper functions enables consistent, reusable, and easy‑to‑maintain authorization across routes.
• Addresses RBAC(Role-Based Access Control) Support #2000
• GoFr has no native RBAC, forcing manual, repetitive route‑level authorization that risks inconsistency and increases maintenance. Expected Benefits include centralized, configurable, and reusable access control that’s easier to maintain, more flexible, and improves security.

Breaking Changes (if applicable):

• None

Additional Information:

• No relevant dependencies effected or external libraries used.

Checklist:

• I have formatted my code using goimport and golangci-lint.
• All new code is covered by unit tests.
• This PR does not decrease the overall code coverage.
• I have reviewed the code comments and documentation for clarity.

[coolwednesday]

We would like to keep RBAC as a separate module. Hence add go.mod in it. So that it does not get added in the binary of the gofr framework.

[akshat-kumar-singhal]

We would like to keep RBAC as a separate module. Hence add go.mod in it. So that it does not get added in the binary of the gofr framework.

@coolwednesday What's the advantage of having RBAC in another module, unless we move the auth middlewares into a separate module as well?

[Umang01-hash]

@goginenibhavani2000 please go ahead and resolve the review comments given by the reviewer. While we decide whether to keep it inside or outside like a separate module i think we can focus on completing the implementation, testing, documentation etc. Please let us know if you know any more help.

[Umang01-hash]

We would like to keep RBAC as a separate module. Hence add go.mod in it. So that it does not get added in the binary of the gofr framework.

@coolwednesday What's the advantage of having RBAC in another module, unless we move the auth middlewares into a separate module as well?

@akshat-kumar-singhal We see RBAC as a layer beneath Auth—more specialized and not universally required. Auth is core to GoFr and widely used, which is why its middlewares are bundled. RBAC, on the other hand, is optional and domain-specific, so we’re keeping it modular to avoid unnecessary coupling and binary weight.

[akshat-kumar-singhal]

Won’t it be taken care of by the dead code elimination done during build? I agree that RBAC shouldn’t be a default, but an easy to include module/package. What we could consider is having the interface for RBAC within gofr and the external module implementing that interface.

…

On Wed, 20 Aug 2025 at 16:58, Umang Mundhra ***@***.***> wrote: *Umang01-hash* left a comment (gofr-dev/gofr#2144) <#2144 (comment)> We would like to keep RBAC as a separate module. Hence add go.mod in it. So that it does not get added in the binary of the gofr framework. @coolwednesday <https://github.com/coolwednesday> What's the advantage of having RBAC in another module, unless we move the auth middlewares into a separate module as well? @akshat-kumar-singhal <https://github.com/akshat-kumar-singhal> We see RBAC as a layer beneath Auth—more specialized and not universally required. Auth is core to GoFr and widely used, which is why its middlewares are bundled. RBAC, on the other hand, is optional and domain-specific, so we’re keeping it modular to avoid unnecessary coupling and binary weight. — Reply to this email directly, view it on GitHub <#2144 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APUGM5WLZAMQTTVY4YHXRRD3ORLXVAVCNFSM6AAAAACDUPRBZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMBVG44DMNJTHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Umang01-hash]

taken care of by the dead code elimination done during build? I agree that RBAC shouldn’t be a default, but an easy to include module/package. What we could consider is having the interface for RBAC

Yes that makes sense. WE can have the interface in GoFr and implementation outside.

[Umang01-hash]

@goginenibhavani2000 Are you still working on the issue. Please let us know in case you need any further help for the same.

[goginenibhavani2000]

@goginenibhavani2000 Are you still working on the issue. Please let us know in case you need any further help for the same.

Yes, i have completed the suggested changes except the change in having interface. Would like to confirm if the RBAC interface is like below

type RBAC interface {
RoleExtractor(r *http.Request, args ...any) (string, error)
IsPathAllowed(role string, path string) bool
}

[coolwednesday]

@goginenibhavani2000, So Sorry for the delay. I will be prioritising this issue review for the next week's release. Let me know if you are interested to tale this further if not, I myself will pick up this issue.

[goginenibhavani2000]

@coolwednesday I’d be happy to take this further and help with the changes. Let me know if there's anything specific you'd like me to focus on.

[Umang01-hash]

• In all the examples added, if the handlers are not using the ctx so we can keep the signature like :

func handlerName(_ *gofr.Context){}

• Files like adapter.go, jwt_extractor.go have very less coverage. Can we please try and improve it?

[aryanmehrotra]

code needs to be simplified, once the structural fixes are done code needs to be reviewed again.

[Copilot]

Pull request overview

This PR introduces a comprehensive RBAC (Role-Based Access Control) middleware system for GoFr, enabling declarative authorization through JSON/YAML configuration files. The implementation provides flexible role extraction via headers or JWT claims, pattern-based endpoint matching, role inheritance, and built-in observability through logging, metrics, and tracing.

Key Changes:

• Added RBACProvider interface in core GoFr package for extensible RBAC implementations
• Implemented complete RBAC package with configuration loading, middleware, and authorization logic
• Integrated observability features (logging, metrics, tracing) into the RBAC workflow
• Added comprehensive documentation and test coverage

Reviewed changes

Copilot reviewed 17 out of 18 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
pkg/gofr/rbac.go	Defines RBACProvider interface and EnableRBAC method for integrating RBAC into GoFr applications
pkg/gofr/rbac/provider.go	Implements RBAC provider with config loading from JSON/YAML and middleware application
pkg/gofr/rbac/config.go	Defines RBAC configuration structures (roles, permissions, endpoints) with validation and processing logic
pkg/gofr/rbac/middleware.go	Core authorization middleware implementing role extraction, endpoint matching, and permission checks
pkg/gofr/rbac/endpoint_matcher.go	Handles endpoint pattern matching (exact, wildcard, regex) and authorization decisions
pkg/gofr/rbac/logger.go	Defines logger interface for RBAC audit logging
pkg/gofr/rbac/metrics.go	Defines metrics interface for RBAC observability
pkg/gofr/rbac/*_test.go	Comprehensive test suite covering all RBAC functionality
pkg/gofr/rbac/go.mod	Module definition with Go 1.25 (invalid version - needs correction)
docs/advanced-guide/rbac/page.md	Complete documentation including quick start, configuration examples, and best practices
docs/navigation.js	Added RBAC documentation link to navigation
go.work	Added RBAC package to workspace

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The defer span.End() is called immediately after starting the span, but the span is never actually used after this point since the function returns the modified request. The span will end before the authorization logic completes. This defeats the purpose of tracing. Consider removing the defer and ending the span at the end of the middleware function in Middleware(), or restructure the tracing to properly span the entire authorization operation.