2009-05-09 23 views
6

A través de la adquisición tenemos una serie de productos que requieren autenticación y autorización. Los productos incluyen sitios web y aplicaciones del lado del cliente, las aplicaciones del lado del cliente usan algunos servicios web. Somos una tienda .Net y los servidores ejecutarán Server 2008, ¿los clientes ejecutarán XP SP? y después.¿Es una buena idea usar Kerberos para autenticarse en sitios web y servicios web?

Los usuarios de los productos que no son parte de nuestra organización y van desde usuarios individuales con un PC independiente a los usuarios de organizaciones que ejecuta Active Directory, etc.

Actualmente no hay autenticación o identidad común tienda y estamos buscando a remediar eso. Nuestros objetivos son:

  • Un único nombre de usuario y contraseña (o certificado) en todos los productos.
  • Lo ideal sería un inicio de sesión único (fácil si estamos lanzando un sitio web desde una aplicación cliente, presumiblemente menos si un usuario inicia sesión en un sitio web primero y luego inicia la aplicación del lado del cliente).
  • Además de lo habitual; robusto, escalable ...

Al igual que la mayoría de las empresas, tenemos recursos limitados y un calendario apretado.

Una ruta sugerida para la autenticación es Kerberos, que es probablemente la ruta ideal para que una aplicación cliente se autentique en un servicio web, pero me complace utilizarlo en un sitio web donde el usuario envíe un nombre de usuario y contraseña y el Servidor web sería responsable de la emisión de boletos (luego, almacenar el ticket en una cookie?). Siento que podemos estar mejor con una única tienda de identidades y nuestro propio servicio de autenticación que toma un nombre de usuario y una contraseña, se compara con un hash ordenado y luego emite un token de seguridad personalizado basado en el tiempo. Tal vez usar SqlMembershipProvider?

Gracias a todos los que han leído hasta aquí. ¿Es Kerberos la mejor opción para este escenario o debería buscar en otro lado? Si no es una buena opción, ¿por qué no?

También estamos buscando a AD LDS para la autorización, pero creo que este post es el tiempo suficiente ya ...

Respuesta

3

¿Ha considerado OpenID?

+0

Si quiere ir al extremo, puede implementar SSL bidireccional y emitir certs privados a todos sus usuarios. Podría eliminar la necesidad de que los usuarios tengan la autenticación de nombre/pwd (su navegador simplemente entregaría sus credenciales al servidor) y este es el método más seguro posible. – Cuga

+0

Me gustan tanto OpenID como certs, pero supongo que si fuéramos OpenID, querríamos tener nuestro propio servidor OpenID y no creo que tengamos el recurso/tiempo/presupuesto para hacerlo. Lo mismo se aplica a la emisión de nuestros propios certs. Hay un proveedor de certificados en nuestra industria que emite certificados sin costo para el usuario y conlleva responsabilidad por la autenticación inicial, etc. pero, cuando miramos por última vez, el costo de autenticar los certificados de los usuarios con ellos sopló el caso comercial para usar ellos. –

+1

De cualquier forma, el problema que tengo en este momento es que la primera opción parece ser Kerberos, con lo que no me siento cómodo en un sitio web. Sin embargo, no puedo reunir ningún argumento en contra de usarlo de otra manera que no obtendremos todos los beneficios de Kerberos y no "huele" bien para la autenticación del sitio web. Ninguno de los cuales parece buenos argumentos. Es posible que Kerberos sea la solución correcta y me siento incómodo debido a mi falta de conocimiento. –

1

OpenID para sus cuentas de usuario único, y OAuth para autorizar a las aplicaciones a acceder a los datos en otro sitio web, hacer una buena solución distribuida. Sí, Active Directory u otra solución pura de inicio de sesión único funciona muy bien en un entorno homogéneo, pero suena bastante divergente en su organización.

La configuración de un proveedor de OpenID seguro es en realidad una gran responsabilidad y no debería ser algo que simplemente se acelera abofeteando una biblioteca junto con un servidor web. Puede permitir que sus usuarios usen sus propios OpenID y luego tener una base de datos donde sus usuarios registren sus OpenID para que sean reconocidos como empleados/miembros en todo el sistema. Varias partes del sistema pueden verificar un OpenID para la membresía directamente en la base de datos, o puede usar OAuth para ayudar a verificar la membresía también.

Posibilidades muy interesantes de combinar estas dos tecnologías.

+1

Gracias por las publicaciones hasta ahora, algunas buenas ideas, pero aún necesito saber, si Kerberos no es la solución correcta, ¿por qué no? –

+1

Si funciona para su situación, entonces Kerberos probablemente sea la mejor opción. –

4

No tiene nada de intrínsecamente incorrecto, excepto que Kerberos no está diseñado para este tipo de casos de uso, y generalmente no funciona bien con los cortafuegos. Por ejemplo, probablemente no desee abrir el acceso externo al mismo Kerberos KDC que usa internamente.

Más si te refieres a MS Kerberos, y aparentemente lo haces, abrir Kerberos viene con un nido de protocolos MS que tienes que abrir más tarde o más tarde, porque el nivel superior está enredado con AD etc. junto con Kerberos.

que decía:

Siento que podemos estar mejor con un [...] nuestro propio servicio de autenticación

no

Casi con toda seguridad. Por lo general, no desea reinventar la rueda, y si no debe entonces esa rueda. Los protocolos de autenticación son generalmente difíciles de hacer e incluso más difíciles de acceder a la web. Limítese a algo que ya existe: autenticación básica + SSL o certificados de cliente y SSL, más seguimiento de sesión (otra vez a través de SSL si esto realmente importa), o un servicio LDAP que es distinto de su DA. Esos enfoques tienen todos sus propios problemas, pero no tantos como los que tendrá con rodar algo propio.

1

Para sitios web, puede usar SPNego/GSS-API/Kerberos. Todos los principales navegadores y servidores web son compatibles con SP Nego. Con LDAP, NFS y HAdoop todos compatibles con Kerberos, debe ver esta solución. Mira el comando Curl con la opción negociar.

Cuestiones relacionadas