Pour une révision du protocole SAML

Le protocole SAML V2 est standardisé depuis 2005. Cet héritier de la grande vague d'interopérabilité des années 2000 est-il encore adapté à nos besoins ?

En tant que standard il est important qu'il soit stable, c'est en effet un gage d'adoption. Basé sur des socles solides comme XML et le chiffrement asymétrique (XML Dsig et XML Enc), SAML V2 possède des qualités de robustesse, voire de rusticité. Cependant une évolution me semble nécessaire.

Examinons en premier ce que propose OpenID Connect principal concurrent du SAML, nous verrons ensuite des pistes d’évolution du SAML.

OpenId Connect le concurrent du SAML

Quelles sont les différences entre SAML et OpenId qui expliquent le succès de ce dernier ?

SAML repose sur le principe d'un cercle de confiance. C'est un cas d'usage très particulier qui nécessite l'établissement d'une relation entre deux partenaires, chacun jouant un rôle symétrique pour l'autre:

• Je fais confiance à tes utilisateurs
• Je fais confiance à tes services
• J'autorise mes utilisateurs à consommer tes services
• J'autorise l'accès de mes services à tes utilisateurs

Comparons le cas d'usage de OAuth v2 ou OpenId Connect :

• Toi utilisateur, tu veux utiliser mon application
• Moi développeur, je veux (j’ai besoin de ?) tes données personnelles
• Pour cela, je m'inscris chez ton fournisseur de données
• Tu m'autorises l'accès à tes données, je t'ouvre mon application

On voit bien que nous ne sommes plus dans une relation totalement symétrique, car l’utilisateur doit céder une partie de ses informations, détenues par un tiers, contre l'usage d'un service d'un autre fournisseur.

Le succès d'OpenId Connect tient donc dans cette relation ternaire (Identité - Ressources - Application) qui donne une vraie place au développeur et qui permet à l'utilisateur de consentir à un accès à ses données indépendamment d'une décision de son fournisseur d'identité (avec SAML toutes les identités d'un IdP "consentent" à l'usage d'un SP). De même qu'un utilisateur consent, il peut rompre unilatéralement sa relation avec l'application.

Les évolutions possibles du SAML

Examinons maintenant quelques-uns des points qui pourraient permettre l’évolution du SAML et une plus grande adoption par les développeurs.

XML vs JSON

SAML repose entièrement sur XML, qui pour beaucoup de développeur est d'une lourdeur rédhibitoire. JSON, qui est finalement une version allégée du langage balisé, offre le gros avantage d'être plus rapidement un objet consommable en JavaScript. Tout objet XML est transposable en JSON, y compris la signature (JSON Web Signature). Le passage de XML à JSON serait une possibilité d'adaptation. SAML pourrait être exposé comme un service REST et retourner des objets JSON. Et pourquoi pas une implémentation JavaScript d'un Service Provider SAML !

SAML OAuth v2 profile

OAuth a déjà fait un travail d'ouverture vers SAML en acceptant les assertions XML comme preuve d'authentification (RFC 7522). Serait-il possible d'envisager qu'un service ou plutôt qu'une ressource SAML accepte des jetons d'identité JWT. Par exemple je dispose d’une preuve d’identité obtenue auprès de mon compte Google sous la forme d’un jeton signé au format JWT. J’accède à un service qui est dans une fédération d’identité SAML comme les universités par exemple et je suis autorisé en accès. Ce serait une manière d'assurer une interopérabilité entre les deux protocoles.

Proposer un schéma d'identité

Avec OpenId Connect, OAuth a récupéré un schéma d'identité, ne serait-il pas possible dans SAML de définir plus précisément ce qu'est une identité. En cela le règlement eIDAS est d'une grande aide, car il donne déjà à SAML cette dimension pour le territoire européen.

SAML pour IoT

C'est particulièrement dans les cas d'usage que SAML doit être audacieux. Si le terrain semble occupé par OpenId Connect sur le monde des applications grand public, il reste de la place autour des objets connectés. Le concept de pseudonymat est particulièrement adapté à cet usage et SAML propose depuis longtemps ce type de présentation d'identité (transient pseudonym). Le principe est que je suis authentifié sur la base de mon identité numérique, mais je n’expose qu’une partie de mes attributs ce qui me garantit un certain anonymat. Un autre avantage de SAML, pour ce cas d’usage, est qu'il a été pensé pour des clients lourds et pas seulement des navigateurs.

Voici par exemple un cas d'usage pour SAML IoT que l’on peut imaginer:

• J’inscris un objet (IoT) dans mon cercle de confiance
• Je lui délègue une partie de mon identité et de mes actions
• Pour chaque usage / contexte l'objet prend un pseudonyme auprès d'un tiers de confiance
• Ce pseudonyme est transmis dans le réseau des objets avec une valeur de confiance

Un service peut faire confiance à l'objet sans que celui trahisse mon identité

Conclusion

De nombreux éditeurs de solutions d’accès comme PingIdentity par exemple assument déjà l’interopérabilité entre SAML et OpenId Connect. Ce n’est donc pas sur cet axe qu’il faut chercher un motif de révision pour le SAML. Par contre le modèle basé sur deux rôles seulement (Service Provider et Identity Provider) est une sévère limitation qu’il faudrait dépasser.

Stéphane

Pour aller plus loin

Pour tout savoir sur les tendances 2016 de la cyberdéfense en 120 secondes
Orange Cyberdefense protège vos essentiels
Cloud Access Security Brokers (CASB) : le nouvel eldorado de la sécurité ?