Wolf is a versatile Role-Based Access Control (RBAC) authority system, suitable for all HTTP applications, offering unified authorization and access control functionalities.
It addresses the common issue within companies where various backend services and their corresponding management interfaces have disparate account systems and authority modules. This redundancy leads to resource wastage and management disarray, particularly when different teams develop these systems. Wolf enables a consolidated account and authorization management across diverse platforms and systems without necessitating any modifications to existing systems.
- Language Independent: Compatible with any HTTP-enabled application, including static web pages, JSP, PHP, ASP, Python, Node.js, and other web systems.
- Low Coupling & Non-intrusive: Facilitates the integration of new applications without requiring modifications, managing resource permissions at a proxy layer.
- Integrated Management Console (
console
module): Manages applications, users, roles, permissions, and resources. - OAuth 2.0 Support: Enables login with Wolf account for seamless application integration.
- Dual Authentication Modes: Supports password and LDAP authentication.
- Comprehensive Application Support: Accommodates Restful interfaces and purely HTML applications rendered on the backend.
- Access Logging: Facilitates auditing and troubleshooting through detailed access logs.
- Extensive Testing: Code coverage exceeding 90%.
- Database Compatibility: Works with PostgreSQL and MySQL.
- APISIX Gateway Support: Integrates with Apache APISIX: Wolf-RBAC
- The system encompasses three primary modules:
Wolf-Server
: Implements service and backend functionalities.Wolf-Console
: Frontend code for management.Wolf-Agent
: Access Check proxy for RBAC.
- Entity Objects in the System:
- Applications: Supports multiple applications with distinct permissions, roles, and resources, and enables visualization of RBAC object relationship charts.
- Users: A unified user base across the entire system. User-specific authorizations include:
- Administrator Permissions: Administrators can log into the Console for backend management and oversee applications.
- Application List: Users can be associated with a variety of applications. For administrators, this means management capabilities; for non-administrators, this implies login and usage rights.
- Roles: Users can be assigned multiple roles, accumulating a comprehensive set of permissions from each role.
- Permissions: Direct permission assignments are possible, deviating from typical RBAC models to enhance flexibility.
- Roles: Encompasses a collection of permissions, structuring user access and capabilities.
- Permission Categories: Organizes permissions into manageable groups, typically aligned with major functional modules for easier navigation and assignment.
- Permission: Establishes a one-to-many relationship with resources, allowing singular or shared permissions across multiple resources.
- Resources: Primarily associated with HTTP requests, characterized by a unique combination of match type, name, and action. Key attributes include:
- Match Type: Defines how URLs are matched, including exact, suffix, and prefix matching methods.
- Name: The specific HTTP URL, with conventions based on the match type.
- Action: The HTTP method applicable, with ALL encompassing all methods.
- Permission: Refers to the permissions required to access a resource. The system has two built-in permissions: Allow All means all users can access, Deny All means no user can access.
- Audit Log: A comprehensive record of all system interactions, including user details, access metrics, and resource matches, supporting robust auditing and issue tracing.
- The resource matching method accommodates various priorities, governed by the following set of rules:
- Match Type Priority: The order of priority for match types is as follows:
- Equals Match: This type holds the highest priority.
- Suffix Match: Ranked next in priority, focusing on URL suffixes.
- Prefix Match: The lowest in priority, emphasizing URL prefixes.
- Action (Representing HTTP Method):
- The term 'Action' corresponds to the HTTP Method used.
- ALL: This method is given the lowest priority among the HTTP methods.
- Specific Methods (e.g., GET, POST, PUT): These methods share an equal level of priority, each ranking higher than the 'ALL' method.
- Name (Indicating HTTP URL):
- 'Name' refers to the HTTP URL.
- The priority is based on URL length; a longer URL signifies a higher priority.
- Match Type Priority: The order of priority for match types is as follows:
Note: The URL references herein are confined to the path component of the standard URL structure, excluding domain, port, and parameter details
- Server: Utilizes NodeJS, KOA, Sequelize, JWT
- Console: Employs VueJS, Element, Babel, NodeJS
- Agent: Powered by OpenResty(ngx_lua)
- Database: Supports PostgreSQL.
- Cache: Incorporates Redis.
![]() |
---|
Application List |
![]() |
---|
Application, User, Role, Permission Relations |
![]() |
---|
User Management |
![]() |
---|
Role Management |
![]() |
---|
Details of the Role's Permissions/Permissions Grouping Display |
![]() |
---|
Permission Management |
![]() |
---|
Audit Log |
![]() |
---|
Client Login |
![]() |
---|
Main Page (Note: Added information bar at top.) |
![]() |
---|
No Permission Page |