In the current state, the flight sql do handshake method uses a hardcoded username and password for authorization. One of the essential features for production readiness is to improve the security posture by having configurable authorization. The goal of this PR is to add a simple abstraction (the "Authorizer" trait) that allows for implementations of a variety of commonly used authorization schemes (basic auth, jwt, ldap, etc.). I only implemented basic auth for now in a backwards-compatible way so I can get feedback on the approach.
What changes are included in this PR?
This PR adds a new trait "Authorizer" that has a simple validate method that is passed the value of the authorization metadata the client sends with the request. Implementations can be created for basic authentication, jwt, ldap, etc. I've made the validate function async so if implementations require http requests over the network, this is supported.
Are there any user-facing changes?
The PR is meant to be backwards compatible, defaulting to basic auth with same username/password.
Which issue does this PR close?
Closes #835
Rationale for this change
In the current state, the flight sql do handshake method uses a hardcoded username and password for authorization. One of the essential features for production readiness is to improve the security posture by having configurable authorization. The goal of this PR is to add a simple abstraction (the "Authorizer" trait) that allows for implementations of a variety of commonly used authorization schemes (basic auth, jwt, ldap, etc.). I only implemented basic auth for now in a backwards-compatible way so I can get feedback on the approach.
What changes are included in this PR?
This PR adds a new trait "Authorizer" that has a simple validate method that is passed the value of the authorization metadata the client sends with the request. Implementations can be created for basic authentication, jwt, ldap, etc. I've made the validate function async so if implementations require http requests over the network, this is supported.
Are there any user-facing changes?
The PR is meant to be backwards compatible, defaulting to basic auth with same username/password.