SASL est un cadre pour l'authentification dans des protocoles orientés connexions. Actuellement, PostgreSQL implémente trois mécanismes d'authentification SASL, SCRAM-SHA-256, SCRAM-SHA-256-PLUS et OAUTHBEARER. D'autres pourraient être ajoutés dans le futur. Les étapes ci-dessous illustrent comment l'authentification SASL est réalisé en général, alors que la sous-section suivante donne plus de détails sur particular mechanisms.
Flot de message d'authentification SASL
Pour commencer un échange d'authentification SASL, le serveur envoie un message AuthenticationSASL. Il inclut une liste des mécanismes d'authentification SASL que le serveur peut accepter, dans l'ordre de préférence du serveur.
Le client sélectionne un des mécanismes supportés dans la liste, et envoie
un message SASLInitialResponse au serveur. Le message inclut le nom du
mécanisme sélectionné, et un optionnel Initial Client
Response, si le mécanisme sélectionné utilise cela.
Un ou plusieurs messages server-challenge et
client-response suivront. Chaque message
server-challenge est envoyé dans un message
AuthenticationSASLContinue, suivi par une réponse d'un client dans un
message SASLResponse. Les particularités des messages sont spécifiques au
mécanisme.
Enfin, quand l'échange d'authentification est terminé avec succès, le serveur envoie un message AuthenticationSASLFinal optionnel, suivi immédiatement par un message AuthenticationOk. Le message AuthenticationSASLFinal contient des données supplémentaires du serveur au client, dont le contenu est spécifique au mécanisme d'authentification sélectionné. Si le mécanisme d'authentification n'utilise pas les données supplémentaires envoyées en fin, le message AuthenticationSASLFinal n'est pas envoyé.
En cas d'erreur, le serveur peut annuler l'authentification à tout moment, et envoie un message ErrorMessage.
SCRAM-SHA-256, and its variant with channel
binding SCRAM-SHA-256-PLUS, are password-based
authentication mechanisms. Ils sont décrits en détails dans
RFC 7677 et RFC 5802.
Quand SCRAM-SHA-256 est utilisé dans PostgreSQL, le serveur ignorera le nom
d'utilisateur que le client envoie dans
client-first-message. Le nom d'utilisateur qui
était déjà envoyé dans le message de démarrage est utilisé à la place.
PostgreSQL accepte plusieurs encodages de
caractères, alors que SCRAM impose l'utilisation d'UTF-8 pour le nom
d'utilisateur, donc il pourrait être impossible de représenter le nom
d'utilisateur PostgreSQL en UTF-8.
La spécification SCRAM impose que le mot de passe soit aussi en UTF-8, et soit traité avec l'algorithme SASLprep. Néanmoins, PostgreSQL ne requiert pas l'utilisation d'UTF-8 pour le mot de passE. Quand le mot de passe d'un utilisateur est configuré, il est traité avec SASLprep comme s'il était en UTF-8, quelque soit l'encodage réel. Néanmoins, s'il ne s'agit pas d'une séquence légale d'octets UTF-8 ou s'il contient des séquences d'octets UTF-8 qui sont interdites par l'algorithme SASLprep, le mot de passe brut sera utilisé sans le traitement de SASLprep, au lieu de renvoyer une erreur. Ceci permet au mot de passe d'être normalisé quand il est en UTF-8, en autorisant toujours l'utilisation d'un mot de passe non UTF-8, sans nécessiter que le système connaisse l'encodage du mot de passe.
La liaison de canal (Channel binding) est accepté par
PostgreSQL si ce dernier a été compilé avec le support de SSL. Le nom du
mécanisme SASL pour SCRAM avec liaison de canal est
SCRAM-SHA-256-PLUS. Le type de liaison utilisé par
PostgreSQL est tls-server-end-point.
Dans SCRAM sans liaison de canal, le serveur choisit un nombre aléatoire qui est transmis au client pour être mélangé avec le mot de passe fourni par l'utilisateur dans le hachage transmis du mot de passe. Bien que ceci empêche le hachage du mot de passe d'être retransmis avec succès dans une session ultérieure, cela n'empêche pas un faux serveur entre le serveur réel et le client de passer la valeur aléatoire du serveur et de s'authentifier avec succès.
SCRAM avec liaison de canal empêche ce type d'attaques man-in-the-middle en mélangeant la signature du certificat du serveur dans le hachage transmis du mot de passe. Bien qu'un faux serveur peut retransmettre le certificat du vrai serveur, il n'a pas accès à la clé privée correspondant à ce certificat et ne peut donc pas prouver qu'il en est le propriétaire, imposant de ce fait un échec de la connexion SSL.
Exemple
Le serveur envoie un message AuthenticationSASL. Il inclut une liste des
mécanismes d'authentification SASL que le serveur peut accepter. Ce sera
SCRAM-SHA-256-PLUS et SCRAM-SHA-256
si le serveur dispose du support de SSL. Dans le cas contraire, ce sera
uniquement le dernier.
Le client répond en envoyant un message SASLInitialResponse, qui indique
le mécanisme choisi, SCRAM-SHA-256 ou
SCRAM-SHA-256-PLUS. (Un client est libre de choisir un
mécanisme mais pour une sécurité plus forte, il devra choisir la variante
à liaison de canal s'il le gère.) Dans le champ Initial Client
response, le message contient le message SCRAM
client-first-message. Le message
client-first-message contient aussi le type de
liaison de canal choisi par le client.
Le serveur envoie un message AuthenticationSASLContinue, avec un message
SCRAM server-first-message comme contenu.
Le client envoie un message SASLResponse, avec le message SCRAM
client-final-message comme contenu.
Le serveur envoie un message AuthenticationSASLFinal, avec le message
SCRAM server-final-message, suivi immédiatement
par un message AuthenticationOk.
OAUTHBEARER is a token-based mechanism for federated
authentication. It is described in detail in
RFC 7628.
A typical exchange differs depending on whether or not the client already has a bearer token cached for the current user. If it does not, the exchange will take place over two connections: the first "discovery" connection to obtain OAuth metadata from the server, and the second connection to send the token after the client has obtained it. (libpq does not currently implement a caching method as part of its builtin flow, so it uses the two-connection exchange.)
This mechanism is client-initiated, like SCRAM. The client initial response
consists of the standard "GS2" header used by SCRAM, followed by a list of
key=value pairs. The only key currently supported by
the server is auth, which contains the bearer token.
OAUTHBEARER additionally specifies three optional
components of the client initial response (the authzid of
the GS2 header, and the host and
port keys) which are currently ignored by the
server.
OAUTHBEARER does not support channel binding, and there
is no "OAUTHBEARER-PLUS" mechanism. This mechanism does not make use of
server data during a successful authentication, so the
AuthenticationSASLFinal message is not used in the exchange.
Example
During the first exchange, the server sends an AuthenticationSASL message
with the OAUTHBEARER mechanism advertised.
The client responds by sending a SASLInitialResponse message which
indicates the OAUTHBEARER mechanism. Assuming the
client does not already have a valid bearer token for the current user,
the auth field is empty, indicating a discovery
connection.
Server sends an AuthenticationSASLContinue message containing an error
status alongside a well-known URI and scopes that the
client should use to conduct an OAuth flow.
Client sends a SASLResponse message containing the empty set (a single
0x01 byte) to finish its half of the discovery
exchange.
Server sends an ErrorMessage to fail the first exchange.
At this point, the client conducts one of many possible OAuth flows to
obtain a bearer token, using any metadata that it has been configured with
in addition to that provided by the server. (This description is left
deliberately vague; OAUTHBEARER does not specify or
mandate any particular method for obtaining a token.)
Once it has a token, the client reconnects to the server for the final exchange:
The server once again sends an AuthenticationSASL message with the
OAUTHBEARER mechanism advertised.
The client responds by sending a SASLInitialResponse message, but this
time the auth field in the message contains the
bearer token that was obtained during the client flow.
The server validates the token according to the instructions of the token provider. If the client is authorized to connect, it sends an AuthenticationOk message to end the SASL exchange.
