[GitHub] [inlong] woofyzhao opened a new pull request, #5173: [INLONG-5167][Manager][Agent][Dataproxy][SDK] Support manager open API authentication

Thu, 21 Jul 2022 09:20:05 -0700 


woofyzhao opened a new pull request, #5173:
URL: https://github.com/apache/inlong/pull/5173

   - Fixes #5167
   
   ### Motivation
   
   The manager's open APIs are free to call from anywhere anonymously, which is 
not secure.
   Fix: Add some sort of authentication support to very the identity of the 
clients (i.e. authorized agent/dataproxy/sdk etc)
   
   ### Alternative Mechanisms
   There are several ways to provide web api authentication, with the typical 
two described below:
   
   **1. Basic Access Authentication**
   https://en.wikipedia.org/wiki/Basic_access_authentication
   
   <img width="770" alt="image" 
src="https://user-images.githubusercontent.com/941634/180249246-4c94ae2e-c21f-493c-8497-757e2be3f200.png";>
   
   
   The auth process is simple:
   A) The api server side generates a secretID  & secretKey pair for each 
client who wants access.
   B) The client encode the id & key pair (base64) in the http header.
   C) The server's interceptor / filter retrieves the secretID and compares the 
secretKey param with the true secretKey stored at some database (usually 
encrypted)
   
   **Pros:**  
     - Light and easy to understand
     - little extra work to use
   
   **Cons:**  
     - Since base64 is used, it is not secure in non-encrypted channel. 
     - So it **must be used along with HTTPS.**
   
   **2. API Secure Signature**
   This is commonly used in public cloud apis, like the one described in this 
[Tencent cloud approach](https://cloud.tencent.com/document/product/213/30654).
   
   <img width="884" alt="image" 
src="https://user-images.githubusercontent.com/941634/180251731-8889df8c-fc58-4063-8908-ecdb1a1f8604.png";>
   
   
   The auth process is roughly like this:
   A) The api server side generates a secretID  & secretKey pair for each 
client who want access.
   B) The client organize some of the request context info (URI、domain、sorted 
params、body data etc) into a basic string. 
   C) Then client use RSA or hashing to encrypt this string to a signature with 
the secretKey
   D) The client request the API with the signature and secretID
   E) The server retrieves the secretID, find its corresponding secretKey, and 
uses the same encoding process as B) and C) to calculate the signature.
   F) The server compares its calculated signature and the one from the request 
to determine the final authenticating result.
   
   **Pros:**
     - More secure, since the secretKey is not transported across the network 
but merely as part of the signature.  Thus can also be used in unencrypted 
channels like HTTP. 
   
   **Cons:**
     - The process is more sophisticated and thus error prone.  Steps like B) 
has no standards to follow. Often need more debugging time for the user.
   
   ### Design
   **This PR choosing the basic auth approach** for the following reasons:
   1) We should always use HTTPs as a modern web application. Thus we enforce 
it and basic auth is easy and sufficiently secure.
   2) The open APIs exposed by manager are quite limited and are usually read 
only (Most important of which includes configuration query for agency and 
dataproxy
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to