The Haystack Authentication Protocol defines a way for a Haystack client and server to negotiate the authentication mechanism for a user trying to login. Currently, we define a single auth scheme: SCRAM authentication.
There are use cases where the remote Haystack server is authenticating users against a 3rd party user management system (e.g. LDAP); essentially the Haystack server is acting as an authentication proxy for the client. In this case, it is necessary to send the username and password to the Haystack server, so that the server can authenticate on behalf of the client.
The following proposal defines how we can add support for a plaintext auth scheme to the haystack authentication protocol. It should be noted at the outset, that this scheme only makes sense to use when the connection to the Haystack server is over TLS.
The following spec is for review and comments:
PLAINTEXT
The PLAINTEXT auth scheme SHALL be used to authenticate the client using a base64url encoded username and password. Use of the PLAINTEXT scheme MUST only be allowed over a secure TLS connection.
Hello
Note: Header lines have been split to ease readability. All base64url encodings are without padding. In the following example, a user named user with password password authenticates with the server.
The client sends a hello message identifying the user as user.
C: GET /haystack/about HTTP/1.1
HOST: server.example.com
Authorization: HELLO username=dXNlcg
The server responds to the client indicating the user should authenticate using PLAINTEXT.
The client continues the authentication exchange. The following attributes are included:
username: the base64url-encoded username
password: the base64url-encoded password
C: GET /haystack/about HTTP/1.1
Host: server.example.com
Authorization: PLAINTEXT username=dXNlcg, password=cGFzc3dvcmQ
The final server message indicates the user is authenticated.
S: HTTP/1.1 200 Ok
Authentication-Info: authToken=AuthTokenXXYYZZ
Chris BreederveldThu 3 Jun 2021
Hi Matthew,
Sounds easy enough to implement and may be useful.
However, if I may play devil's advocate here, why not just support Basic authentication? It is less efficient perhaps, but already a commonly used feature in the HTTP protocol.
Brian FrankThu 3 Jun 2021
However, if I may play devil's advocate here, why not just support Basic authentication? It is less efficient perhaps, but already a commonly used feature in the HTTP protocol.
I think its worth debating. However I have two main issues with standard Basic authentication:
The client sends the username and passwords in plaintext before the server gets a chance to decide the best authentication strategy for the user account
It by-passes the standard plug-in design we already have
In the current design there is one well known flow - the client sends a hello message with the username, then the server decides which authentication scheme to use for the given user.
Chris BreederveldThu 3 Jun 2021
I agree that this setup is more elegant and probably easier to implement server-side. Just making sure this was at least considered ;-)
Matthew Giannini Wed 2 Jun 2021
Background
The Haystack Authentication Protocol defines a way for a Haystack client and server to negotiate the authentication mechanism for a user trying to login. Currently, we define a single auth scheme:
SCRAM
authentication.There are use cases where the remote Haystack server is authenticating users against a 3rd party user management system (e.g. LDAP); essentially the Haystack server is acting as an authentication proxy for the client. In this case, it is necessary to send the username and password to the Haystack server, so that the server can authenticate on behalf of the client.
The following proposal defines how we can add support for a
plaintext
auth scheme to the haystack authentication protocol. It should be noted at the outset, that this scheme only makes sense to use when the connection to the Haystack server is over TLS.The following spec is for review and comments:
PLAINTEXT
The
PLAINTEXT
auth scheme SHALL be used to authenticate the client using a base64url encoded username and password. Use of thePLAINTEXT
scheme MUST only be allowed over a secure TLS connection.Hello
Note: Header lines have been split to ease readability. All base64url encodings are without padding. In the following example, a user named
user
with passwordpassword
authenticates with the server.The client sends a hello message identifying the user as
user
.The server responds to the client indicating the user should authenticate using
PLAINTEXT
.The client continues the authentication exchange. The following attributes are included:
username
: the base64url-encoded usernamepassword
: the base64url-encoded passwordThe final server message indicates the user is authenticated.
Chris Breederveld Thu 3 Jun 2021
Hi Matthew,
Sounds easy enough to implement and may be useful.
However, if I may play devil's advocate here, why not just support Basic authentication? It is less efficient perhaps, but already a commonly used feature in the HTTP protocol.
Brian Frank Thu 3 Jun 2021
I think its worth debating. However I have two main issues with standard Basic authentication:
In the current design there is one well known flow - the client sends a hello message with the username, then the server decides which authentication scheme to use for the given user.
Chris Breederveld Thu 3 Jun 2021
I agree that this setup is more elegant and probably easier to implement server-side. Just making sure this was at least considered ;-)