SASL como todo concepto abstracto no es simple de explicar. En principio es un mecanismo a través del cual los protocolos orientados a conexiones (LDAP, SMTP, IMAP) se desligan del manejo de la autenticación, la cual pasa a ser una serie de bits cuyo contenido no tiene importancia para el protocolo. El objetivo es mantener todos los mecanismos de autenticación en un lugar común a todos los protocolos, con la ventaja de eliminar redundancia de código y con la posibilidad de que se soporten nuevos mecanismos de autenticación sin tocar una linea de codigo en las implementaciones de los servicios.
Expliquemos mejor como funciona con un ejemplo concreto. Supongamos que tenemos un SMTP (Postfix) que soporta SASL a través de la librería Cyrus-SASL. A su vez esta libreria tiene los plugins para soportar los mecanismos de autenticación PLAIN y DIGEST-MD5. Veamos el comienzo de la comunicación SMTP:
S: 220 mail.ejemplo.com.ar ESMTP Postfix
C: ehlo woitasen.com.ar
S: 250-mail.ejemplo.com.ar
S: 250-PIPELINING
S: 250-SIZE 10240000
S: 250-VRFY
S: 250-ETRN
S: 250-STARTTLS
S: 250-AUTH PLAIN DIGEST-MD5
S: 250-ENHANCEDSTATUSCODES
S: 250-8BITMIME
S: 250 DSN
La C indica los mensajes enviados por el cliente y la S los enviados por el servidor.
Este es el clásico comando HELO del protocolo SMTP. Se usa para que el cliente se anuncie al servidor, el cual contesta con una serie de parámetros informativos. El mas importante ahora es el “250-AUTH”, el cual indica que el servidor soporta autenticación a través de los mecanismos PLAIN y DIGEST-MD5. En realidad, el servidor soporta SASL y es esta quien soporta esos mecanismos de autenticación.
Ahora bien, para que todo funcione el cliente tambien debe soportar SASL. Supongamos que el cliente usa Cyrus-SASL. Si la libreria tiene solo el plugin para autenticar con DIGEST-MD5, entonces se produce la siguiente secuencia de mensajes:
C: AUTH DIGEST-MD5
S: 334
PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
S: 235 Authentication successful.
El cliente le esta indicando al servidor que quiere autenticar con DIGEST-MD5, el servidor le contesta 334 enviando un “challenge” al cual el cliente responde. El intercambio finaliza con la confirmación de que la autenticación finalizo correctamente.
Ahora veamos como encaja SASL. EL challenge, es esa secuencia de caracteres enviados por el servidor luego del 334. Esta secuencia es generada por la librería SASL. Al servidor SMTP no le importa el contenido de este mensaje. El cliente recibe el challenge y lo procesa con su librería SASL, la cual devuelve otra secuencia de caracteres que el cliente envía al servidor. La función de SASL es generar estos mensajes y de avisarle al servidor si la autenticación finalizo correctamente o no.
Entonces, para ir cerrando, SASL se encarga del manejo de los mensajes de autenticación, siendo algo abstracto para los protocolos orientados a servicios. Si aparece un nuevo mecanismo de autenticación y la librería de SASL lo soporta, automaticamente el servicio también tendrá soporte sin tocar una linea código.
