Discussion :

[JWillow]

J'ai quand même l'impression que beaucoup oubli que Google fournit un infrastructure de cloud pas un simple serveur où on peut faire ce que l'on veut.
Pourquoi les restrictions de Google ? Simplement pour permettre la scalabilité de l'ensemble des applications qu'ils hébergent pas pour nous embêter.
Ok je suis dépendant de leur infrastructure mais c'est un peu ce que chercher parce que cela me permet de répondre à des milliers de requêtes (et de me prémunir des pics d'affluence qui peuvent submergé mes serveurs) sans avoir investi des milliers d'euros en serveur et sans avoir à les administrer (pas d'administration serveur, pas d'administration de BdD et en plus j'ai pas forcément à ma disposition ces compétences).

[nicorama]

Parfaitement d'accord. Je préfère être dépendant des compétences et de la solidité (toute relative) économique de Google que de mes qualités dans ce domaines .

[*alexandre*]

petite question à benwit

concernant ton billet sur l'authentification à google app engine, le principe du cloud c'est quand même au travers d'une application de se connecté à plusieurs services tout en réutilisant le même login

comment navigues tu aux travers des applications SANS UN COMPTE GOOGLE ? et ainsi réutiliser ton compte loggé au travers de l'application initial

l'App Engine ne se base sur aucune API connu et commune à l'ensemble des providers de services c'est donc impossible ... (sans une passerelle commune impossible d'échanger des données encryptées ou non -exemple un user token-)

[benwit]

le principe du cloud c'est quand même au travers d'une application de se connecté à plusieurs services tout en réutilisant le même login

ça, c'est plutôt le principe du SSO (cloud ou non).

Comme tu dis, il n'y a pas de mystère, pour naviguer d'un service applicatif à un autre, il faut bien que les fournisseurs de services mettent en œuvre un système d'authentification commun.

Les universités utilisent par exemple un serveur CAS pour leur SSO afin de pouvoir passer d'un service à l'autre avec une identification unique.

Certaines entreprises utilisent également un SSO pour leur différents services.

C'est plus facile à mettre en œuvre dans une même organisation mais l'authentification unique aurait encore plus d'intérêt entre différentes entreprises.

A mon avis, si on veut que ça fonctionne, il faut une solution ouverte.
Il y a eu plusieurs tentatives mais certaines n'ont jamais prises. La tentative d'Open Id se développe lentement mais prendra t'elle ???

Ce que je trouve bien dans l'authentification app engine, c'est qu'on peut développer une application qui utilise les comptes google.

Ce que je trouve critiquable :

• Si les comptes google sont un vrai SSO entre les différents services de google (passage de l'un à l'autre sans ressaisir son mdp), ils n'en sont pas un entre les services google et les applications app-engine (puisqu'il faut dans tous les cas saisir son mdp) et je doute (je n'ai pas essayé) que ce soit un SSO entre diverses applications GAE.
• Google supporte Open Id avec ses comptes Google. J'avais l'impression que ce n'était pas mis en œuvre dans l'authentification de GAE mais je n'en suis plus aussi sûr ... (Alors que la majorité d'entre vous qui ont essayé mon application de demo de login se sont connectés avec leur compte gmail, je ne m'explique pas que l'un d'entre vous a laissé son email orange.fr dans mes traces de console )

[*alexandre*]

Je t'embête un peu avec ce problème car c'est un problème récurant dans le cadre de nos développements

Que penses-tu d'une solution comme http://www.zurich.ibm.com/news/08/ztic.html ? couplé avec un ldap et un service d'authentification qui valide une key unique selon le provider de solution et de services

c'est un mélange d'authentification centralisé (ztic) et une solution de de clef validé de type carte à matrice validé par un provider

tu ne valides qu'après une première authentification qu'une clef dynamique qui sera par la suite validé avec ton username et échanger d'après le service que tu veux consulter donc tu ne communiques que ton username et la clef qui est définit par service et dont sa validité n'a qu'un temps limitée et est gérée par le dit service (cela ressemble à CAS mais deviendrait valide sur un ensemble de service ...)

[nicorama]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
HTTP 1.1
GET http://server.externe.com/whatYouWant
Auhtorization : GiveMeTheWayGiveItToMeNow

REST, guyz. REST !

[*alexandre*]

Une *petite* publication dans le domaine du management de l'identité

http://www.aspeninstitute.org/sites/..._Computing.pdf

C'est pas technique mais peut permettre d'ouvrir un débat sur la notion d'identité