2010-08-24 17 views
5

proveedor de OpenID Cada proveedor tiene una URL (por ejemplo Google: https://www.google.com/accounts/o8/id)DotNetOpenAuth: ¿Cómo implementar un simple proveedor OpenId?

Usando OpenIdRelyingParty.CreateRequest he conseguido con éxito para redirigir al usuario a proveedores de Google Url y recibir la devolución de llamada del proveedor. Todo funcionó bien

Ahora estoy tratando de implementar mi propio proveedor de OpenId (quiero actuar como Google en mi ejemplo). DotNetOpenAuth tiene una demostración de proveedor llamada OpenIdProviderWebForms. Durante las últimas 4 o 5 horas he intentado conectarme con la misma demostración que logré conectar en Google. Primero: no tengo claro a qué URL debo llamar. Probé todas las URL (server.aspx, provider.ashx ...) y todas activan una excepción "No se encontró ningún punto final OpenID". Todas las configuraciones parecen estar bien.

¿Cómo implemento un simple proveedor OpenId? ¿A qué URL debo llamar en el OpenRelyingParty.CreateRequest?

Respuesta

16

En primer lugar vamos a establecer algunos términos:

El User-supplied identifier es la cadena que el usuario realmente en tipos (o se activa pulsando un botón predefinido en el RP) que desencadena el descubrimiento OpenID tenga lugar. No está normalizado y nunca debe usarse para representar al usuario en su base de datos porque no es seguro o único, pero es un punto de partida necesario. El descubrimiento en este identificador da un claimed identifier o un OP Identifier. Ejemplos: yahoo.com, myopenid.com, andrewarnott.myopenid.com

El Claimed Identifier es el identificador de OpenID que el usuario "controla" o usa como su identidad. Puede o puede no ser una URL (puede ser un XRI). Una afirmación positiva de un OP siempre será un identificador reclamado (incluso si el descubrimiento comenzó con un identificador OP). Ejemplos: https://andrewarnott.myopenid.com/

El OP Identifier, o "Identificador de proveedor de OpenID" es el OpenID Identifer que RPs pueden realizar el descubrimiento de comenzar un flujo identifier select donde el RP todavía no sabe cuál será reclamada Identificador del usuario. Ejemplos: https://me.yahoo.com/, http://www.myopenid.com/ y https://www.google.com/accounts/o8/id

El OP Endpoint es la URL real que el RP redirige al usuario con el fin de autenticar al usuario, y se usa para establecer asociaciones compartidas o llevar a cabo la verificación directa de una aserción que utiliza un OP privada asociación. Ejemplos: http://localhost/server.aspx, http://localhost/provider.ashx, https://www.google.com/accounts/o8/ud (nótese el ud terminando en lugar de id)

Así que con todo este contexto, el OpenIdRelyingParty.CreateRequest llamada debe recibir un identificador proporcionado por el usuario, que puede ser también un identificador reclamado o un identificador de OP. Debe no ser el punto final OP. Así, por ejemplo, que se puede desmayar en:

openIdRelyingParty.CreateRequest("http://localhost/sampleop/") 

o

openIdRelyingParty.CreateRequest("http://localhost/user.aspx?username=bob") 
+2

Andrew, muchas gracias por todas estas explicaciones +1. Realmente me ayudó a aclarar estos conceptos. Logré hacer que las 2 demos de DotNetOpenAuth se conectaran entre sí (OP y RP) pero no pude crear mi propio OP y conectarme a él.Siga recibiendo los "puntos finales no OpenId encontrados", lo que no es un error muy explicativo. Su proyecto (DotNetOpenAuth) parece ser impresionante, pero le falta documentación. De hecho, creo que Openid carece de documentación. No pude encontrar estos conceptos apuntados en otro lugar. Gracias de todos modos :) –

+0

@ André Pena, he intentado durante días hacer que mi OP funcione. pero es el mismo problema que estás teniendo. ¿Alguna vez has resuelto esto? –

2

Para los ejemplos DotNetOpenAuth MVC, la url abierta ID Identificador de usar es http://localhost:4864/User/Identity (donde OpenIdProviderMvc está configurado para ejecutarse en el puerto 4864 de localhost)

Cuestiones relacionadas