valkey-io
[NEW] Token-based authentication
The problem/use-case that the feature addresses
Currently, Valkey does not have a secure token based authentication process, which poses risks of unauthorized access and data breaches. Integrating token-based authentication as a module will enhance security by ensuring that only authenticated users can access the cache.
Description of the feature Module Development: A specialized module is developed to intercept incoming requests to the Valkey server. This module acts as a middleware, ensuring that every request is authenticated before being processed.
Token Validation: Upon intercepting a request, the module will communicate with an ADFS (Active Directory Federation Services) or a custom user information service to validate the token provided by the client. This validation process checks the authenticity and integrity of the token, ensuring that it is valid and has not been tampered with.
Role-Based Access Control: The module will also verify the roles associated with the token. Based on the roles and permissions, the request will be either allowed or denied, ensuring that only authorized users can access specific resources or perform certain actions.
Configuration-Based Integration: The module is designed to be loaded as part of the Valkey server configuration. This means that users can enable token-based authentication without needing to modify the Valkey source code. The solution is designed to be version-independent, allowing it to work seamlessly across different versions of Valkey.
Ease of Use: The module provides a straightforward way for Valkey service providers to implement token-based authentication by simply enabling the module in the server configuration. This reduces the need for extensive code changes or updates, streamlining the integration process.
Security Enhancement: By implementing this module, the Valkey server will benefit from enhanced security measures, protecting against unauthorized access and ensuring that only authenticated and authorized requests are processed.
Alternatives you've considered
Considered using traditional username/password authentication, but it lacks scalability and is less secure compared to token-based methods. Evaluated existing feature requests for similar authentication mechanisms, but they were closed due to compatibility issues with Valkey's architecture.
Additional information
My name is Mahendiran Sundararajan, working at JP Morgan Chase, reachable at [email protected]. Need to contribute my solution on token based authentication for Valkey initial version. The integration of token-based authentication directly into the Valkey source code represents a significant advancement in streamlining the authentication process. This contribution allows developers and service providers to utilize the Valkey source code as-is, eliminating the need for custom authentication solutions with each build. By embedding token-based authentication within the core functionality, Valkey ensures consistent and secure access control across all deployments, reducing development overhead and enhancing security without requiring extensive customization for every version or build.
@Mahendira I see a few problems that need to be solved for implementing a token based authentication system.
The first one that comes to mind is that the RESP protocol is not prepared to piggyback a token with a command, so how do you plan to get the token in every request?
Here is framework for secure and efficient token-based authentication, leveraging federated identity management and role-based access control. It ensures that only authenticated and authorized requests are processed by the Valkey server, enhancing security and operational integrity.-
-
Client Onboarding: The client is on boarded to a Federated Service, which provides a public key for the resource. This key is essential for secure token generation and validation.
-
Token Generation: Using the Federated Service's resource public key and client credentials, the client generates a token. This token encapsulates the client's identity and permissions. Request Authentication:
-
The client sends requests to the Valkey server, including the generated token as part of the AUTH command. This ensures that every request is accompanied by authentication credentials. Custom Module Configuration:
-
The Valkey server is equipped with a custom module designed to intercept all incoming requests. This module's primary function is to validate the token before processing any commands.
-
Token Validation Process:Upon receiving a request, the custom module calls an intermediate service to validate the token. This service can either be part of the Federated Service or operate locally, connecting to the Federated Service for token validation.
-
The intermediate service checks the token's validity and retrieves the roles associated with the user. Role-Based Command Execution:
Based on the roles retrieved, the Valkey server determines whether the command from the user is authorized to execute. This ensures that only users with appropriate permissions can perform specific actions.
Valkey should never support authentication and authorization of every single request that comes to the server via federated auth service. It's simply too expensive. A typical valkey command takes 1-5us, whereas symmetric cryptography will take 10s of us and asymmetric cryptography even longer.
I think doing authentication via a federated system per session seems reasonable though. Valkey LDAP (https://github.com/valkey-io/valkey-ldap) already basically supports this functionality. There are already module API hooks to build most of what you are proposing, so maybe the next step might be to build a module? If the feature is widely adopted, we can move the functionality into the core.
yes, the next step might be to build a module - doing authentication via a federated system per session. are there any timelines to be considered?
yes, the next step might be to build a module - doing authentication via a federated system per session. are there any timelines to be considered?
Not really.