IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

52.5. Authentification SASL

SASL est un framework pour l'authentification dans les protocoles orientées connexion. Actuellement, PostgreSQL™ implémente seulement le mécanisme d'authentification SASL, SCRAM-SHA-256, mais d'autres pourraient être ajoutées dans le futur. Les étapes suivantes illustrent comment l'authentification SASL est réalisée en général, alors que la sous-section suivant donne plus de détails sur SCRAM-SHA-256.

Procédure 52.1. Flux de message d'authentification SASL

  1. Pour commencer un échange d'authentification SASL, le serveur envoie un message AuthenticationSASL. Il inclut une liste de mécanismes d'authentification SASL que le serveur accepte, dans l'ordre de préférence du serveur.

  2. 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 message Initial Client Response optionnel, si le mécanisme sélection l'utilise.

  3. Un ou plusieurs messages question-serveur et réponse-client suivent. Chaque question du serveur est envoyée dans un message AuthenticationSASLContinue, suivie d'une réponse du client dans un message SASLResponse. Les particularités des messages sont spécifique au mécanisme.

  4. Enfin, quand l'échange d'authentification se termine avec succès, le serveur envoie un message AuthenticationSASLFinal, suivi immédiatement d'un message AuthenticationOk. Le message AuthenticationSASLFinal contient des données supplémentaires du serveur pour le client, dont le contenu est spécifique au mécanisme d'authentification sélectionné. Si le mécanisme d'authentification n'utilise pas de données supplémentaires en fin d'authentification, le message AuthenticationSASLFinal n'est pas envoyé.

En cas d'erreur, le serveur peut annuler l'authentification à tout moment, et peut envoyer un message ErrorMessage.

52.5.1. Authentification SCRAM-SHA-256

SCRAM-SHA-256 (appelé simplement SCRAM à partir de maintenant) est le seul mécanisme SASL implémenté actuellement. Il est décrit en détail dans les 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 le premier-message- client. Le nom d'utilisateur déjà envoyé dans le message de démarrage est utilisé à la place. PostgreSQL™ supporte plusieurs encodages de caractères alors que SCRAM requiert l'utilisation d'UTF-8 pour le nom de l'utilisateur. Pour éviter les confusions, le client doit utiliser pg_same_as_startup_message comme nom d'utilisateur pour le premier-message-client.

La spécification SCRAM requiert que le mot de passe soit aussi en UTF-8, et est traité avec l'algorithme SASLprep. Néanmoins, PostgreSQL™ ne requiert pas que UTF-8 soit utilisé pour le mot de passe. Lors de la configuration du mot de passe d'un utilisateur, ce mot de passe est traité avec SASLprep comme s'il était en UTF-8, quelque soit l'encodage réellement utilisé. Néanmoins, s'il ne s'agit pas d'une séquence UTF-8 légale d'octets ou s'il contient des séquences d'octets UTF-8 interdites par l'algorithme SASLprep, le mot de passe brut sera utilisé sans traitement par SASLprep, plutôt que de renvoyer une erreur. Ceci permet la normalisation du mot de passe quand ce dernier est en UTF-8 mais autorise aussi l'utilisation d'un mot de passe qui n'est pas en UTF-8 et ne nécessite pas que le système connaisse l'encodage utilisé par le mot de passe.

Le Channel binding n'est pas encore implémenté.

Procédure 52.2. Exemple

  1. Le serveur envoie un message AuthenticationSASL. Il inclut une liste de mécanismes d'authentification SASL que le serveur peut accepter.

  2. Le client répond en envoyant un message SASLInitialResponse indiquant le mécanisme choisi, SCRAM-SHA-256. Dans le champ de réponse Initial Client, le message contient le premier-message-client SCRAM.

  3. Le serveur envoie un message AuthenticationSASLContinue, avec un server-first message SCRAM comme contenu.

  4. Le client envoie un message SASLResponse, avec client-final-message SCRAM comme contenu.

  5. Le serveur envoie un message AuthenticationSASLFinal, avec server-final-message SCRAM, immédiatement suivi d'un message AuthenticationOk.