SAML et SSL, le désamour ?

Dans cet article je disais tout le bien que je pensais du SAML comme protocole utilisé pour un dialogue sécurisé entre un Service Provider et un Identity Service Provider lors de l’authentification des utilisateurs dans le monde du cloud. Le SAML est en particulier mis en avant dans les services de proxy web dans le cloud (Zscaler, Cisco, Websense ou BlueCoat pour n’en citer que quelques-uns) qui rencontrent un large succès depuis quelques années.

Cependant je n’avais pas relevé un écueil de taille dans mon précédent article : celui du délicat mariage entre SAML et SSL dans le cas d’un Proxy Web dans le cloud.

Comme je l’indiquais alors, lorsqu’un service web (Service Provider) demande une authentification pour un utilisateur, il forge une requête SAML qui est adressée et traitée par un Identity Service Provider. Cette requête est transmise durant la session du navigateur et est chiffrée en HTTPS durant toute la session.

payload : ça se complique...

Là où cela se complique c’est que ces informations d’authentification sont ajoutées au Payload et non au Header de la requête à destination du proxy. Le Payload comprend donc tout à la fois les données de la requête utilisateur envoyée au site web mais aussi les données d’authentification.

Problème : quand le site internet est en HTTPS c’est tout le Payload qui est chiffré y compris les informations d’authentification ce qui embarrasse fortement le proxy web pour savoir quelle politique appliquer à l’utilisateur ! En effet si le proxy ne peut pas récupérer les informations concernant l’utilisateur, principalement son nom et le ou les groupes auxquels il appartient impossible d’appliquer une politique de sécurité granulaire. Impossible par exemple de savoir si on doit bloquer ou pas Dropbox pour la personne qui demande un accès, idem pour Gmail et la plupart des sites web 2.0.

Conclusion : si le proxy ne déchiffre pas le flux SSL le proxy sera aveugle et sourd !

Exemple de requête Post avec Payload (après le ?)

Donc pour bien faire un proxy utilisant une authentification basée sur le SAML doit s’accompagner d’un déchiffrement des flux SSL pour être en mesure d’appliquer un filtrage granulaire !

La partie technique n’est pas la plus complexe à régler. Encore faut-il s’assurer que déchiffrer ces flux n’entrainera pas de messages d’erreur pour l’utilisateur ! La question la plus épineuse est : comment faire comprendre à l’utilisateur que la relation de confiance liée au SSL est aisément « cassée » par le premier proxy venu. De plus, en France, il est nécessaire d’informer les salariés que les flux SSL seront inspectés par le proxy même si certaines catégories comme les sites bancaires ou administratifs seront de fait exclus des inspections.

le SAML condamné ?

Alors le SAML est-il condamné ? Non sans doute pas mais il faut l’utiliser à bon escient. Si vous utilisez de nombreux services dans le cloud et un proxy lui même dans le cloud il va falloir sérieusement se pencher sur la problématique de l’inspection SSL! Si vous voulez appliquer une politique extrèmement granulaire bien sur! Avec comme corollaire, en France, les aspects légaux liés à une telle inspection. Le SAML reste donc intéressant à condition d'en comprendre les avantages et inconvénients. La quasi obligation de déchiffrer le SSL pour assurer la granularité de l'authentification est pour moi le principal écueil.

Comme en France et en Europe le déchiffrement SSL n’entre que tout doucement dans les mœurs je ne serais donc pas surpris de voir le SAML progressivement remplacé par d’autres solutions, Kerberos par exemple, permettant de s’affranchir cet inconvénient.

Philippe

Crdéit photo : © mvancaspel - Fotolia.com