Posts Tagged 'SAML'

SSO et contrôle d’accès

Le SSO doit-il faire du contrôle d’accès ?

Introduction

Sur un projet de gestion d’identité, lors de la configuration de la solution SSO, j’ai été confronté au besoin fonctionnel de refuser l’accès aux applications, par le serveur de sécurité, des utilisateurs qui ne remplissent pas certains critères techniques, bien qu’authentifiés.

Mon, client considère, contrairement à moi, que ces critères techniques qui correspondent fonctionnellement à une habilitation doivent être pris en compte dans le processus d’accès aux applications, au même titre que l’authentification. Lire la suite ‘SSO et contrôle d’accès’

Shibboleth – un SSO ++

Nous avons évoqué, lors de précédents billets, le fonctionnement de Shibboleth basé sur la norme SAML 2.0.

La norme décrit les échanges entre le Service Provider (SP), qui protège les services, le Discovery Service (DS) qui permet à l’utilisateur d’indiquer son fournisseur d’identités et l’Identity Provider (IdP), qui assure l’authentification des utilisateurs.

Au sein d’une même entreprise, le déploiement d’une telle solution est comparable aux solutions de SSO standard, avec toutefois des avantages non négligeables.

Lire la suite ‘Shibboleth – un SSO ++’

Shibboleth – présentation

Logo Shibboleth

À l’origine, le mot hébreu Shibboleth permettait à un peuple de distinguer ses ennemis, incapables de le prononcer correctement. Grâce à ce mot, une confiance pouvait être établie au sein d’une population bien définie.

Aujourd’hui, Shibboleth désigne un logiciel open source, du consortium Internet 2, qui établit de la même manière une relation de confiance entre entités bien définies et identifiées. Il assure un accès filtré et sécurisé, aux ressources de ces entités, limité uniquement aux membres de ces mêmes entités.

Shibboleth, dans sa version 2, se place ainsi comme le logiciel open source de référence de fédération d’identité qui supporte la norme SAML 2.0. Lire la suite ‘Shibboleth – présentation’

La fédération d’identité

Ce billet a pour vocation de présenter la fédération d’identité en s’appuyant sur le protocole SAML 2.0. Un futur billet présentera le logiciel Shibboleth, implémentation open source de référence de cette norme.

SAML 2.0

Normalisé, dans sa version 2.0, en mai 2005 par l’OASIS, SAML permet l’échange sécurisé d’informations d’identités (authentification et autorisation). SAML définit le format du message XML, appelé assertion, ainsi qu’un ensemble de profils. Ces profils sont des cas d’utilisation détaillés qui présentent la cinématique d’échange des messages, les paramètres attendus et renvoyés.

Fonctionnement

SAML définit deux briques essentielles pour sécuriser les échanges :

  • Le SP (Service Provider), fournisseur de service, protège l’accès aux applications. Il refuse tout accès sans authentification préalable et redirige l’utilisateur non authentifié vers son fournisseur d’identité
  • L’IdP (Identity Provider), fournisseur d’identité, s’occupe d’authentifier l’utilisateur ainsi que de récupérer des informations additionnelles associées à son identité

Ce mode de fonctionnement est suffisant pour une utilisation cantonnée à l’entreprise avec un annuaire des identités centralisé.
Dans le cadre d’une fédération entre plusieurs domaine d’identification, SAML défini une troisième brique appelée le DS (Discovery Service) qui permet à l’utilisateur de sélectionner manuellement son domaine parmi une liste. Avec un peu de configuration, il est possible de supprimer cet élément, un peu bloquant pour les utilisateurs.

Profils

Le profil le plus courant, appelé « Web Browser SSO », décrit, entre autres, les étapes d’authentification d’un utilisateur et les allers-retours entre le SP et l’IdP. L’utilisateur tente d’accéder à sa ressource protégée par le SP. Le SP vérifie que l’utilisateur est authentifié et s’il ne l’est pas, le redirige vers son IdP. L’IdP demande à l’utilisateur de s’authentifier (identifiant puis mot de passe par exemple) puis renvoie une assertion SAML au SP contenant l’identité de l’utilisateur et la garantie qu’il est authentifié. Le SP autorise alors l’utilisateur à accéder à la ressource initialement demandée.

Ce mécanisme d’authentification repose sur les redirections du navigateur Internet. Ce profil permet aussi de récupérer un ensemble d’attributs supplémentaires liés à l’identité de l’utilisateur et demandés par la ressource.

Un second profil basé sur des artéfacts, permet de décorréler l’authentification de la récupération des informations d’identité de l’utilisateur. Le SP reçoit de l’IdP, par le navigateur Internet de l’utilisateur, une assertion SAML contentant un artefact. Le SP doit alors interroger directement l’IdP pour obtenir les informations liées à l’identité de l’utilisateur.

D’autres profils décrivent comment mettre en œuvre le DS, les notions de logout et la possibilité de se passer du navigateur de l’utilisateur pour transmettre les assertions SAML entre services.

Sécurité

Les assertions SAML sont basées sur les couches SOAP, XML Encryption et XML Signature.

  • SOAP est le protocole d’encapsulation standard des messages XML, utilisé principalement par les Web services.
  • XML Encryption est le protocole standard de chiffrement des messages XML. Il a la particularité de pouvoir chiffrer la globalité du message ou simplement un sous-ensemble précis. Cela permet d’avoir par exemple un document XML en clair avec des valeurs d’attributs chiffrées.
  • XML Signature est le protocole standard de signature des messages XML. Tout comme XML Encryption il permet de cibler l’élément à signer. Cela permet à plusieurs intervenants de signer chacun une partie différente du document XML.

Le SP et L’IdP sont deux entités qui ont connaissance chacun l’une de l’autre en terme d’identifiant et de certificat. Les messages XML qui transitent sur le réseau sont donc chiffrés par la clé publique du destinataire, seul capable de déchiffrer le message avec sa clé privée. L’émetteur signe ses assertions avec sa clé privée permettant au destinataire de vérifier sa provenance.

Conclusion

Ce protocole est donc très sécurisé et remplit parfaitement les fonctions de SSO au sein d’une entreprise et entre différents domaines d’identification. Il devrait, à mon sens, remplacer les logiciels propriétaires de Web SSO, beaucoup moins sécurisés.

Thierry ALBAIN


Mises à jour Twitter

Erreur : Twitter ne répond pas. Veuillez patienter quelques minutes avant d'actualiser cette page.

Entrer votre adresse e-mail pour vous inscrire a ce blog et recevoir les notifications des nouveaux articles par e-mail.

Rejoignez 29 autres abonnés

Catégories

Statistiques

  • 64,079 hits