risingwavelabs / risingwave

Best-in-class stream processing, analytics, and management. Perform continuous analytics, or build event-driven applications, real-time ETL pipelines, and feature stores in minutes. Unified streaming and batch. PostgreSQL compatible.
https://go.risingwave.com/slack
Apache License 2.0
7.09k stars 585 forks source link

discussion: enable OAuth2 authentication for risingwave #11440

Open yezizp2012 opened 1 year ago

yezizp2012 commented 1 year ago

Is your feature request related to a problem? Please describe.

Feature required from cloud.

  1. SASL: https://www.postgresql.org/docs/devel/sasl-authentication.html. Its authentication method is as follows:

    To begin with, the SCRAM client is in possession of a username and  
    password (*) (or a ClientKey/ServerKey, or SaltedPassword).  It sends  
    the username to the server, which retrieves the corresponding  
    authentication information, i.e., a salt, StoredKey, ServerKey, and  
    the iteration count i.  (Note that a server implementation may choose  
    to use the same iteration count for all accounts.)  The server sends  
    the salt and the iteration count to the client, which then computes  
    the following values and sends a ClientProof to the server:  
    
     SaltedPassword  := Hi(Normalize(password), salt, i)  
     ClientKey       := HMAC(SaltedPassword, "Client Key")  
     StoredKey       := H(ClientKey)  
     AuthMessage     := client-first-message-bare + "," +  
                        server-first-message + "," +  
                        client-final-message-without-proof  
     ClientSignature := HMAC(StoredKey, AuthMessage)  
     ClientProof     := ClientKey XOR ClientSignature  
     ServerKey       := HMAC(SaltedPassword, "Server Key")  
     ServerSignature := HMAC(ServerKey, AuthMessage)  
    
    The server authenticates the client by computing the ClientSignature,  
    exclusive-ORing that with the ClientProof to recover the ClientKey  
    and verifying the correctness of the ClientKey by applying the hash  
    function and comparing the result to the StoredKey.  If the ClientKey  
    is correct, this proves that the client has access to the user's  
    password.  
    
    Similarly, the client authenticates the server by computing the  
    ServerSignature and comparing it to the value sent by the server.  If  
    the two are equal, it proves that the server had access to the user's  
    ServerKey.  
    
    The AuthMessage is computed by concatenating messages from the  
    authentication exchange.  The format of these messages is defined in  
    Section 7. 
  2. PAM:https://www.postgresql.org/docs/current/auth-pam.html An workaround way to enable OAuth2 in postgreSQL, we may refer: https://www.janua.fr/postgres-oauth2-authentication/

  3. Native support for OAuth and service interaction that issues authentication tokens. Implement a token verification logic by oneself, when the user's password is managed through tokens, interact and verify with the token issuing center. Specific details to be discussed.

Links that might help: Authentication methods in PostgreSQL Configuring OAUTHBEARER in kafka

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Additional context

No response

yezizp2012 commented 1 year ago

Cc @xuhui-lu .

github-actions[bot] commented 5 months ago

This issue has been open for 60 days with no activity. Could you please update the status? Feel free to continue discussion or close as not planned.