[MLB-Auth]Epic: MLBlocks Authentication

[cstefanache]

Objective: Implement user authentication, authorization, and token management system that allows users to log in with their username and password, receive authentication tokens, and allow administrative users to create and manage user accounts and API keys. To allow the authentication mechanism described in the previous specifications to be optional for the MLBlocks, so that users can activate it when needed, without adding overhead to those who don’t require this feature.

Consider introducing another external database for the user management component. Currently we can use Redis (I am fine to work with it if you consider that is appropriate - otherwise consider switching to another SQL solution [Postgres maybe])

Implementation Strategy:

1. Middleware-based Approach: Lazy Loading Middleware: Design the middleware to be lazy-loaded, i.e., it should only be instantiated and put into action when the authentication system is turned on. This ensures that without activation, the middleware won't add any processing overhead.

Conditional Middleware Activation: If the authentication is enabled, the middleware checks for the token in the request header for all MLBlocks API calls. If the token is missing or invalid, the request is denied.

2. Dynamic Dependency Injection: Authentication Module: Package the authentication functionality as a separate module. This module will have all the necessary tools, models, and functions related to user management and token handling.

On-demand Inclusion: When the server starts or when MLBlocks is instantiated, check a configuration setting (e.g., a flag like AUTH_ENABLED). If true, import and initialize the authentication module; if false, bypass it entirely.

3. Configuration-based Approach: Configuration Setting: Introduce a configuration setting (like AUTH_ENABLED) that determines whether authentication is active. This could be a simple configuration file, environment variable, or a parameter during initialization.

Decorators: Utilize Python decorators on the MLBlocks API methods. When AUTH_ENABLED is true, the decorator checks the token's validity before allowing the actual method to execute.

Instructions for Activation: Enable Authentication: Set the AUTH_ENABLED flag/configuration to true either through environment variables, a configuration file, or during initialization.

Interact with MLBlocks: Once activated, any interaction with MLBlocks APIs will require a valid token. The /login endpoint can be used to obtain this token using the correct username and password.

Embedding: Separate Package: If MLBlocks supports plugins or modular architecture, consider packaging the authentication module separately. Users who want the authentication feature can then install it separately.

Lean Core: Ensure that the core MLBlocks codebase remains lean. Only when the authentication feature is activated, the additional components are loaded into memory.

Additional Considerations: Documentation [Laura]: Clearly document the process of activating the authentication system and how to interact with the MLBlocks APIs once it's active - https://docs.google.com/document/d/1KBQeJ-mjGyET4olDl0nH7cADADt0Z-ywqKZsOFaMWuk/edit#bookmark=id.kl2jhsajrmh0

Fallback: Implement a clear mechanism to deactivate the authentication in case of misconfiguration or issues, allowing users to revert to an open system if needed.

Performance Impact: Regularly test and measure the performance of MLBlocks with and without the authentication system active to ensure there's no significant overhead.

API Endpoints:

Endpoint: /login Method: POST Input: username, password Output: Success: token, expiration_date, user_details Error: error_message Description: Validates the username and password, and if successful, returns a token and its expiration date.

Endpoint: /admin/users Method: POST Input: username, password, role Output: Success: user_id, creation_date, role Error: error_message Description: Allows admin to create a user with a specific role. Role could be user or admin.

Endpoint: /admin/apikeys Method: POST Input: user_id, expiration_date Output: Success: api_key, user_id, expiration_date Error: error_message Description: Allows admin to generate and assign an API key to a user with a specific expiration date.

Specifications:

User Model: user_id: Unique identifier for the user. username: User's unique username. hashed_password: Hashed version of the user's password. role: Role assigned to the user (e.g., "admin", "user").

Token Model: token: Unique identifier that represents a user session. user_id: Identifier linking to the associated user. expiration_date: Date and time when the token expires.

API Key Model: api_key: Unique string allowing access without traditional login. user_id: Identifier linking to the associated user. expiration_date: Date and time when the API key expires.

Authentication & Authorization:

• Passwords should be stored securely using hashing.
• Tokens and API keys should be generated using secure random methods.
• Tokens and API keys should be verified on every request.
• Administrative API endpoints (/admin/*) should be accessible only by users with the admin role.

Additional Considerations:

• Implement rate limiting to prevent abuse.
• Use HTTPS for all API endpoints to ensure data security.
• Implement logging mechanisms to track successful and unsuccessful authentication attempts.
• Consider adding mechanisms like multi-factor authentication for added security.

[cstefanache]

You can explore the following use case to test the implementation:

Use: https://huggingface.co/facebook/bart-large-mnli and expose the model to predict that will take the following payload:

{
  "text": "string-like text",
  "classes": ["urgent", "not urgent", "phone", "tablet", "computer"],
  "multipleTrue": true
}

and return the value of each class

The use case should be implemented in the playground repository

[llaura-mb]

Will there be multiple types of users? Will the user have different rights on block level - for example will there be users that will have access only to certain blocks, to certain data, etc?

There will be multiple types of users with different access to the blocks; Once activated, any interaction with MLBlocks APIs will require a valid token. The /login endpoint can be used to obtain this token using the correct username and password.

Activation of user management will take place in configs;