2009-11-23 4 views
5

J'ajoute la connexion OpenID à une petite application web en utilisant Spring Security 2.0.5. Je veux être en mesure d'identifier les utilisateurs dans mon application en fonction de l'identifiant OpenID avec lequel ils se sont connectés. Cela fonctionne très bien lorsque vous utilisez Verisign en tant que fournisseur; chaque identificateur est un URI spécifique à l'utilisateur comme http://jbloggs.pip.verisignlabs.com/, qui est facilement recherché dans ma base de données utilisateur pour trouver "Joe Bloggs".Pourquoi mon application OpenID reçoit-elle différents Google OpenID de différentes machines client pour le même utilisateur?

Toutefois, lorsqu'un utilisateur saisit l'identifiant Google OpenID standard (www.google.com/accounts/o8/id), l'identifiant envoyé par Google après une authentification réussie (quelque chose comme https://www.google.com/accounts/o8/id?id=AItOawnKrvwaGk9YU0q9STQGj9G7XIRlNmsjuiI) varie d'une machine à l'autre pour la même utilisateur. Cela rend impossible (ou du moins pas pratique) d'identifier cet utilisateur en recherchant son identifiant dans ma base de données utilisateur.

Comment puis-je faire en sorte que Google envoie toujours le même identifiant pour le même utilisateur Google? FWIW, l'application s'exécute dans JBoss 3.2.7 avec Tomcat 5.0.28 intégré.

+1

OpenID est nul, acceptez-vous? – jayarjo

+0

Non, j'aime la commodité de l'identité fédérée. Qui veut se souvenir de 50 noms d'utilisateur et mots de passe? Ou pire, confier le même nom d'utilisateur et mot de passe à 50 sites Web, qui ne sont pas tous fiables? –

+0

Je ne dis pas que cette idée est nulle. En fait c'est pas. C'est bien. Même avec tous les problèmes potentiels. Je pense que la mise en œuvre est lâche et défectueuse et diffère d'un fournisseur à l'autre, comme s'il n'y avait aucune norme définie. – jayarjo

Répondre

10

Google utilise une fonctionnalité d'OpenID appelée identité dirigée, ce qui signifie que Google crée un nouvel identifiant unique et non corrigible pour chaque RP (site Web acceptant OpenID) dans lequel l'utilisateur se connecte. Ce n'est pas une option - c'est la seule façon dont Google fonctionne. La clé par laquelle Google discerne entre les RP est le paramètre openid.realm, aussi longtemps que cela est le même, vous obtiendrez les mêmes identifiants pour vos utilisateurs. Mais si vous changez de domaine, toutes les identités de vos utilisateurs seront perdues, car Google enverra un nouveau site d'identifiants à vos utilisateurs existants.

Que pouvez-vous faire à ce sujet? Deux options:

  1. maintenir constante openid.realm de sorte que les identifiants ne changent pas
  2. utilisation AX « require » l'adresse e-mail des utilisateurs lorsque le fournisseur est Google, et vous pouvez faire corrélation entre les identifiants Google basé sur l'adresse email. (difficile cependant: beaucoup de ramifications de sécurité lors de la jonglerie entre les identifiants d'openid et d'email).
+2

Point # 1 résolu pour moi. Lorsque j'ai testé mon application à partir du serveur, j'ai utilisé l'URL http: // localhost/myapp, mais à partir d'une deuxième machine, j'ai utilisé http: // nom_serveur/mon application. Ce que je n'avais pas réalisé, c'est que Google verrait cela comme deux domaines différents et donc retournerait des identités différentes pour le même utilisateur de Google. Quand j'ai changé mon application pour utiliser SSL, j'ai dû utiliser "server_name" dans l'URL même du serveur lui-même à cause du certificat SSL, et quand il a commencé à fonctionner, j'ai supposé à tort que c'était grâce à SSL. même nom d'hôte des deux machines. Merci de votre aide! –

+1

Maintenant, n'est-ce pas un gâchis? Fondamentalement, il faut manipuler chaque fournisseur openid comme s'il n'y avait pas de normes ou de règles d'implémentation du tout. – jayarjo