The user role system in Maltiverse is designed to provide clear and manageable access control based on a user’s role within their team. Each user belongs to a team and is assigned a specific role. The role determines their permissions within the team context.
Roles and Permissions #
The available roles within a team are as follows:
Role | Description | Permissions |
🚀Leader | The team manager responsible for user management and overseeing the team’s activities. | – Manage team members – Full read/write access |
🔎Researcher | A contributor with full permissions to interact with the team’s resources and perform tasks. | – Full read/write access |
👤Consumer | An integration-oriented user with limited access for data consumption purposes only. | – Read-only access |
Role Descriptions:
● 🚀Leader: This role is designed for managing the team and its members. Leaders have full permissions, including creating, editing, and deleting team indicators, as well as managing users in the team.
● 🔎Researcher: Researchers have unrestricted access to the team’s resources, allowing them to fully engage in tasks like data analysis, uploading and deleting indicators, setting up scoring rules and configuring integrations within the team.
● 👤Consumer: Consumers have limited access and can only view indicators. This role is ideal for scenarios like API integrations where write access is unnecessary or undesirable.
Role Management #
The interface allows user roles to be managed directly within the team management section:
The team management interface provides an intuitive way to edit user roles within a team. Only users with the Leader role have the ability to configure and modify user roles.
1. Role Assignment and Editing:
Leaders can edit the roles of team members by using the Edit button next to each user’s profile in the team members section.
○ Clicking the edit button opens a menu where the role (Leader, Researcher, or Consumer) can be updated.
○ Once updated, permissions for the user are immediately enforced based on their new role.
2. Permissions Enforcement:
○ Only Leaders have access to the Edit Team option to modify user roles.
○ Other roles (Researcher and Consumer) do not see role management options, ensuring security and controlled access.
3. Leave Team Option:
Users can leave the team through the Leave Team button. Note that Leaders cannot leave a team unless another user is promoted to the Leader role to maintain team management capabilities.
Default User Role #
Researcher is the default role assigned to new users within a team. This design simplifies onboarding by granting new users full read/write permissions to interact with the team’s resources. However, administrators (Leaders) have the ability to modify a user’s role based on specific requirements. This role is ideal for most team members who are actively contributing to a project or collaborating on research tasks.
Assigning the Consumer Role #
For users or systems that only need limited access (read-only), their role must be manually set to Consumer. The Consumer role is specifically designed for integrations that consume data (e.g., fetching indicators, querying resources). This role is particularly useful for external systems or automated scripts where write access is unnecessary or a potential security risk.
The Leader must explicitly change a user’s role to Consumer via the Team Management Interface.
Why Consumer Role is Important #
Security: Limits permissions to prevent accidental or unauthorized modifications to team resources.
Integrations: Designed for external systems or users that only need to consume indicators or data from the API.
Audit and Accountability: Ensures that users or systems with read-only access cannot make any changes, which is crucial for maintaining data integrity.
Leader Responsibilities #
Leaders should regularly review team roles to ensure users have the appropriate permissions for their tasks. If a user or system only needs to fetch data, their role should be updated to Consumer as a best practice.
API Response Structure #
Maltiverse API ensures consistent and meaningful responses for various authentication and authorization scenarios.
1. Successful Request
When a request is successfully authenticated and the user’s role matches the allowed roles for the endpoint.
2. Missing or Invalid Authentication Token
If the request lacks a valid authentication token:
- The system responds with a 401 Unauthorized status.
- Example Response:
{
"status": "fail",
"error": "Authentication Error",
"message": "Invalid or missing authentication token."
}
3. Unauthorized Role
If the user is authenticated but their role does not match the required roles:
- The system responds with a 403 Forbidden status.
- Example Response:
{
"status": "fail",
"error": "Unauthorized",
"message": "User 'username' with role 'current_role' is unauthorized. Any of these roles is required: [required_roles]"
}