vendredi 2 juillet 2010

Sophiaconf 2010 - Gestion de l'identité et sécurisation des services webs

C'est en ce moment même qu'à lieu la sophiaconf2010. Tout d'abord, qu'est ce la sophiaconf ?
C'est un ensemble de 20 conférences organisée en partenariat entre plusieurs acteurs de Sophia Antipolis comme la commission open source de Telecom Valley ou le Riviera JUG. Point intéressant, ces conférences sont gratuites ou presque. Pour plus d'informationshttp://sophiaconf2010.fr/

1ère partie

La conférence commence avec Hubert Le Van Gong, architecte spécialisé dans la gestion d'identité et sécurité. Il est aussi community leader pour open sso, développeur OAuth et a déployé openid au sein de Sun.

PROBLÉMATIQUE

  • fracture paysage et identité de l'entreprise
  • Explosion de la complexité
  • Rationalisationdes couts
  • Limitation des risques


Il y a 20-30 ans, sur le web, la notion d'identité n'existait pas. Avec l'explosion du web, les services se sont multipliés; et pour chaque services, une identité différente. Depuis 10 ans, le partage de l'identité fait son chemin.

L'objectif des protocoles de gestion d'identité est de limiter la complexité.
Il existe néamoins des risques sur la vie privée et sur l'exposition des entreprises.

L'actualité nous le montre :

  • Facebook et ses contreverses sur la vie privée. Le bouton "aime" entre autre qui expose publiquement
  • Google avec Street View et sa tentation de garder des infos dont il n'a pas besoin


OBJECTIFS

  • Limiter les risques
  • Sécuriser les services web et les échanges
  • Limiter le vol d'identite pour le consommateur
  • Limiter l expo légale d'une entreprise


Autres avantages

  • Meilleure interopérabilité
  • Architecture plus simple, plus efficace
  • Satisfaction de l'usager
  • Rationaliser les couts
  • Réduction moyens informatique
  • Eviter les duplications d'informations


Exemple d'un achat sur internet :

Je commande, je paie par carte bancaire et me fait livrer sur mon lieu de travail.
Le site à t il besoin de savoir ou j'habite ? Pas forcément.
La banque a t elle besoin de savoir ce que j'ai commandé ? Non.
Le livreur a t-il besoin des mes coordonnées bancaire et ce que j'ai commandé ? Non

DÉLÉGATION AUTHENTIFICATION

Idp : identity provider, c'est lui qui gère l'identification.
Sp : Service provider en gère plus l'identité. Fait partie d'un cercle de confiance avec l'idp. Il partage des attributs avec l'idp. Il en fait usage mais ne les stocke pas.

Les principaux protocoles sont :

  • SAML
  • Shibboleth
  • Openid
  • Ws-federation


L'adoption se fait à la fois dans le secteur privé (banques, telecom, ...) que dans le service public de plusieurs pays (France, Nouvelle Zélande, ...). En France par exemple, monservicepublic utilise open sso.

SAML

  • La référence
  • Sinle sign on (SSO)
  • Single log out
  • Fédération identité
  • Echange attribut


SAML fonctionne par jetons d'assertions (auth, autorisation, attributs)
protocoles : requetes/réponse pour obtenir les assertions et gestion identité
binding : mapper les protocole saml sur les autres (soap, http redirect, ...)

http://saml.xml.org

DÉLÉGATION D'AUTORISATION

  • id-wsf 2.0
  • OAuth (le pendant openid de la délégation d'autorisation)
  • ws-*

Adoption au sein de réseaux sociaux comme twitter mais le plus gros reste à venir.

OAuth

  • Orienté web 2.0
  • Se charge aussi de la délégation authentification


Mode de fonctionnement : autorise un service web a échanger avec un autre services web de la part d'un utilisateur authentifié.
Il existe des bibliothèques dans la plupart des langages.

http://www.oauth.net


Ws-*

Ses spécifications ne sont pas forcement basé sur identité. C'est aussi une assez grosse grappe : beaucoup de dépendances entre les différente spécifications. Néamoins certaines se détachent : ws-adressing, security, trust (confiance), policy (modélisation des contrainte usage).

CONCLUSION

2 grands domaines :

  • délégation authentification
  • délégation autorisation


Les 2 principales spécifications sont SAML et OAuth.

http://blog.levangong.com


2 ème partie : les retours d'expérience.

C'est Pascal Agosti qui commence cette partie. Il n'est pas du tout dans la technique puisqu'il est avocat au barreau de Nice chez Caprioli Associé. Il est cependant spécialiste du droit dans le monde informatique, même s'il avoue ne pas toujours comprendre ce que nous (les gens de la technique) racontons.
Il commence par nous raconter une petite histoire datant de quelques années : un couple avait constaté que peu à peu des transfert avait été fait à leur insu et représentaient une somme de 26500€. Selon la banque, ces transferts avaient été effectué depuis leur compte en ligne et ne voulait pas rembourser, c'est le client qui est responsable si son mot de passe est découvert en étant trop simple par exemple et de sa non divulgation. Cette affaire a finit devant les tribunaux. Quelle a été le verdict du juge ? L'authentification par login et mot de passe est insuffisante... Cela marqua en première dans ce domaine.
L'authentification, c'est la vérification d'une identité.
Il est donc important de ne pas confondre les notions d'identification et d'authentification. Le problème est que les lois parlent d'identification et non pas d'authentification.
Un seul facteur pour authentifier n'est pas suffisant.

Techniques authentifications :

  • Quelque chose que l'on connait (mot de passe, ...)
  • Quelque chose que l'on possede (carte à puce, ...)
  • Quelque chose qui nous est personnel (biometrie, ....)


C'est ensuite au tour Frédéric Aime, CTO de Janua, qui nous livre un retour d'expérience de Openid

cas 1 : utilisation de la couche Openid pour logiciel de sécurisation "end point' entrée de gamme.

cas 2 : utilisation de Openid dans un logiciel de widget de bureaux pour se rapprocher de sso.

Son avis est Openid est intéressant pour mais ne doit pas concerner des taches risquées où on attend un niveau de sécurité important.
Il existe plusieurs implémentations : java, php et .net
java : openid 4 java

Avantages/inconvéniants

  • Intégration facile
  • Multi-langages
  • Limité à de l'authentification pure :loggé ou non, il ne gère pas de droits.
  • Identité est maintenue par le client et n'est donc pas garantie
  • Pas de gestions de droit
  • 100 % web based (pas de client lourds)


Tant que l'on pas la Nasa ni une banque, il convient pour une authentification basique.



Et pour finir, Florent Peyraud, cofondateur de Tryphon SARL, vient nous parler de CACert,autorité de certification communautaire qui fournit gratuitement des certificats électronique.

Un certificat électronique doit être :

  • cryptage asymétrique
  • certifié


Autorité de certification

  • Commerciaux : Thawte, verisign, gandi
  • Gratuit : CACert, Gandi (1 an), Verisign (60 jours)


En tant que système communautaire, un certificat CACert est validé par les membres. Avec le temps, et vos validations de membres, vous gagnez des points et votre certificat obtient plus de crédibilité.
Cette initiative est basée en Australie. Le contrat de certification étant rédigé en langue anglaise et mentionnant l'adresse australienne de la communauté, il semblerait que ce soit le droit australien qui s'applique.

http://www.caassert.org

Aucun commentaire:

Enregistrer un commentaire