Comparaison de SAML 2.0 et de WS-Federation

Des chevauchements existent entre la spécification WS-Federation et le standard SAML 2.0. En effet, dans la famille de spécifications WS-*, SAML est uniquement un type de jeton de sécurité facilitant l’authentification tandis que la fonctionnalité de fédération est offerte par WS-Federation. Or, SAML est capable de supporter le principe de fédération d’où ce chevauchement.

Afin de vérifier l’adaptabilité d’une solution de fédération d’identité aux exemples d’Organisations Virtuelles listés dans le chapitre 1 et de définir les moyens de son déploiement dans ces différents contextes, nous avons étudié le standard SAML 2.0 et la spécification WS-Federation. Dans un premier temps, nous avons établi un tableau comparatif des mécanismes offerts par l’un ou l’autre et ceci, en se basant sur des critères tels que :

1. Les types de jetons de sécurité supportés,

2. La dépendance de SAML2.0 et WS-Federation sur d’autres standards et spécifications, 3. leur support pour la fédération d’identité et SLO,

4. Les contextes d’authentification supportés, 5. Les mécanismes d’autorisation supportés.

Notre étude et nos analyses [Kamel et al. 2007a] nous ont amené à établir le tableau comparatif (Tableau II).

Tableau II. SAML2.0 vs. WS-Federation

SAML 2.0 WS-Federation

Les jetons de sécurité supportés

- Assertions SAML

- Tout type de jetons transportés dans une assertion SAML

Les jetons supportés par WS- Trust (assertions SAML,

certificats X509, Kerberos, etc.)

Dépendances Aucune WS-Trust, WS-Policy,

WS- SecurityPolicy, WS- Eventing, WS-Transfer, WS- ResourceTransfer

Fédération d’identité - L’association des identités entre sites fait partie de l’IdP - L’association est créée par l’IdP mais peut être modifiée par l’IdP ou le SP.

- L’association des identités est fournie par le service de

pseudonymes

- L’association est créée par le sujet ou le SP

Single Logout (SLO) SLO initié par le SP SLO peut être initié par le SP ou le STS primaire

Service d’autorisation

Le contexte d’autorisation est une partie complémentaire du profil XACML pour SAML

Un STS spécialisé

Niveau

d’authentification

SAML 2.0 offre un ensemble de contextes d’authentification (basé sur les assertions SAML) beaucoup plus large que celui de WS-Federation.

WS-Trust définit le paramètre « AuthenticationType ». WS- Federation spécifie des valeurs prédéfinies (e.g. SSL, carte à puce, mot de passe, etc.) Respect de la vie

privée

- SAML offre une gamme d’options pour limiter l’utilisation et le domaine d’application d’une assertion - Ces contraintes proviennent du SP ou de l’IdP

- Le sujet peut exprimer les exigences de sécurité demandées pour les jetons de sécurité qu’il requiert

- Les déclarations de confidentialité peuvent être extraites par WS-Transfer

Et pour affiner nos recherches et nos analyses, dans un deuxième temps, nous avons comparé SAML 2.0 et WS-Federation par rapport à des critères liés à la fédération d’identité au sein d’un environnement collaboratif. L’implémentation d’une solution de fédération d’identité entre organisations a les exigences suivantes :

1. Un besoin d’une authentification fédérée entre organisations,

2. L’établissement d’une structure pour supporter une gestion d’identité et d’accès fédérée,

3. Le support de l’interaction entre systèmes d’authentification hétérogènes et,

4. La solution doit être facile et rapide à intégrer dans le Système d’Information des différentes organisations.

Ces différentes exigences nous ont amené à identifier les critères qui semblaient être pertinents pour comparer SAML 2.0 et WS-Federation, deux langages conçus pour l’échange de l’information de sécurité entre des domaines hétérogènes. Les critères retenus sont:

1. Le langage doit répondre aux exigences d’une solution de fédération

SAML 2.0 et WS-Federation supportent la fédération d’identité pour les navigateurs Web, les applications Web et les Services Web. Ils fournissent des solutions pour différents cas de figures mais en adoptant différentes approches. Ainsi, en adoptant l’un ou l’autre ça ne change rien en termes de fonctionnalités offertes ni en termes de cas d’utilisation supportés et, en conséquent, ça n’a aucune influence sur le fonctionnement du système distribué. De ce point de vue, SAML 2.0 et WS-Federation sont à égalité.

2. Le langage doit être supporté dans des produits commerciaux

Etant donné que la quasi-totalité des spécifications de fédération (à l’exception de WS- Federation) ont convergé en SAML 2.0, tous les fournisseurs de systèmes de gestion d’identité supportent SAML 2.0 dans leurs produits. Récemment, ces fournisseurs commencent à offrir de nouvelles versions de leurs produits qui supportent WS-Federation en plus de SAML 2.0. En fait, ces produits supportent le « passive requestor profile » de WS- Federation (ce qui revient à supporter la fonctionnalité Web SSO qui est déjà supportée par SAML 2.0).

3. Le langage doit être standardisé pour l’utiliser à large échelle

SAML 2.0 ayant été élaboré dans le cadre d'un processus de normalisation de l'OASIS a été soumis à un processus d'audience publique. Cette standardisation permet d’assurer l’interopérabilité d’un côté, et d’incrémenter le niveau de compétence et d’innovation d’un autre côté.

D’un autre côté, bien que la spécification WS-Federation ait été publiée en 2003, cette dernière n’a pas encore été standardisée par un organisme de standardisation. En effet, en mai 2007, OASIS a annoncé que ses membres ont formé un nouveau comité pour étudier la standardisation de WS-Federation.

4. Le langage doit interagir avec des standards pour l’approvisionnement et la gestion de rôles des utilisateurs

SAML 2.0, offrant une solution au transfert des identités entre sites distants, doit être complémenté par une solution pour le transfert de l’information de droits d’accès des utilisateurs. Le standard eXtensible Access Control Markup Language 2.0 (voir chapitre 3, section 3.5.3), défini par l’OASIS, permet de transférer les politiques de contrôle d’accès et les demandes d’accès à des ressources distribuées et de ce fait, il complémente SAML 2.0. D’un autre côté, WS-Federation n’interagit pas avec le standard XACML 2.0 et de ce fait, SAML 2.0 est préféré à WS-Federation.

5. Des tests d’interopérabilité doivent être réalisés par des parties tierces pour vérifier l’interopérabilité des produits supportant l’un ou l’autre des langages.

En effet, la Liberty Alliance a lancé un programme pour vérifier l’interopérabilité des produits de fédération d’identité supportant le standard SAML 2.0 (parmi autres). Ce programme, nommé « Liberty Alliance’s Liberty Interoperable », permet d’évaluer la conformité des produits avec les spécifications de SAML 2.0. Par contre et pour l’instant, il n’existe pas des tests d’interopérabilité des produits supportant WS-Federation.

Après étude de ces produits, nous considérons que SAML 2.0 et WS-Federation sont adaptés à un contexte d’Organisation Virtuelle. Les différences essentielles portent sur des éléments tels que la disponibilité des produits qui les supportent ou bien leur interaction avec d’autres standards traitant la gestion des accès. Le Tableau III récapitule ce qui a été annoncé et présente une comparaison entre SAML 2.0 et WS-Federation basée sur les critères retenus. Dans le Tableau III, le caractère ‘+’ signifie que le langage est meilleur que l’autre.

Tableau III. Adaptabilité de SAML 2.0 et WS-Federation aux contextes d’OV

SAML 2.0 WS-Federation

Répondre aux exigences

d’une fédération d’identité + +

Disponibilité de produits commerciaux supportant les

spécifications

+ Seulement pour le « passive

requestor profile »

Basé sur des standards + -

Interaction avec d’autres

standards (ex : XACML) + -

Disponibilité de tests

d’interopérabilité + -