Como yo lo entiendo,

  • SPN es una autentica herramienta para los servicios de windows.
  • Kerberos es un
    usuario del servicio de autenticación de
  • SPNEGO-GSSAPI es la tercera parte de la API
    ser capaz de utilizar esos servicios.
  • SSPI : es el Neutro de la capa de enviar
    solicitud de SPNEGO a SPN servicio.

Estoy completamente perdido?

Tratando de averiguar cómo funciona, pero la información es muy precisa o no lo suficiente.

Gracias

InformationsquelleAutor Jonathan L | 2013-12-05

3 Comentarios

  1. 12

    Aceptar más detallado respuesta:-

    1. SPN – Nombre Principal de Servicio. Es un identificador asociado a cada cuenta en un KDC aplicación(EA, OpenLDAP, etc). Básicamente, si su cuenta actúa como un servicio para que el cliente se autentica, el cliente tiene que especificar «que» se quiere transmitir. Este «quién» identificador es el SPN. Esta es la definición estricta. Muchas personas llaman a menudo el nombre del cliente (UPN – Nombre Principal de Usuario) de un servicio de SPN. Esto sucede cuando el servicio en sí, puede actuar como un cliente( google el escenario de delegación ). Esto no es estrictamente correcto, pero ampliamente asumido cierto.

    2. Kerberos es un protocolo de autenticación. Es un nombre para un marco. Implica servidor de un tercero(llamado KDC o Clave de Centro de Distribución) y consiste en una serie de pasos de la adquisición de los boletos(tokens de autenticación). Es realmente complicado, por lo que http://en.wikipedia.org/wiki/Kerberos_(protocolo)

    3. Hasta cierto punto tienes este derecho. GSSAPI es una API, pero SPNEGO no lo es. GSSAPI es técnicamente válidos para el mecanismo de autenticación que utilice, pero la mayoría de la gente utiliza para la autenticación kerberos. SPNEGO es un pseudo mecanismo, en el sentido se declara un RFC para la autenticación de comunicación basado en HTTP dominio. Estrictamente hablando SPNEGO es una especificación, pero la mayoría de la gente también lo consideran como una aplicación. Por ejemplo, Sun e IBM JDK proporciona un mecanismo de «proveedores» para SPNEGO generación token pero GSSAPI se utiliza para llamar a ella. Esto se hace en muchos proyectos(Tomcat como Servidor y el ejemplo que llegan a la parte superior de mi cabeza y una de las personas que respondieron a esta pregunta desarrollado).

    4. IPS es un análogo de GSSAPI en windows. Sus diferentes API que termina haciendo algo muy similar a GSSAPI.

    • Así que si tengo que pedir a mi proveedor para registrar su solicitud para ser integrada de Windows. Necesito a él para crear una capa de conexión para el SPN uso de SPNEGO? En la actualidad se utiliza sólo SASL para la autenticación Kerberos SPN que no está bien con ÉL.
    • Ok, así que por lo que entiendo de tu proveedor debe ser authenicated en contra de usted(me refiero a que su código es el servidor). SPNEGO apoyará Kerberos o NTLM y registrar su SPN en un KDC aplicación(suponiendo que su Kerberos autenticación basada). No sé cómo Spn se han registrado si el uso de la autenticación de NTLM. SASL es un contenedor a través de GSSAPI y no tiene nada que ver con SPNEGO. Yo preferiría si la publicación de su código.
    • Ah, y también depende de lo que su proveedor de diseño de las aplicaciones. Si tus proveedores app utiliza HTTP basado en la comunicación, entonces, sí, se deberá comunicar a usted a través de SPNEGO. Un ejemplo clásico es el navegador de auth. Los navegadores tienen un duro formato de SPN que se conectan a HTTP/canonicaldnsnameofserver.reino.com. Este no puede ser cambiado y servidores para apoyar esta definiendo sus SPN como la de arriba. Sin embargo esto no es correcto siempre. Por ejemplo, yo había modificado el rizo proyecto de ley de un cliente en el que objetivo de Spn son arbitrarias. github.com/Khalian/CURL
    • Tampoco GSS-API tiene una noción de keytabs. Este es el único de Kerberos característica.
    • Sí, tienes razón, me fijo que parte del comentario. Gracias. Yo generalmente uso GSSAPI con Kerberos del MIT en tándem y todavía tienen que encontrar un puente API entre SSPI y Kerberos del MIT. Así que se mezclaron. Mis disculpas
  2. 2

    No del todo.

    SPN significa simplemente ‘Nombre de Servidor Principal» y es que el ANUNCIO o Kerberos argot para el servicio intenta autenticar contra.

    Kerberos es un usuario del servicio de autenticación, más o menos sí. También proporciona seguridad para la red de mensajes y llamadas entre los servicios.

    SPNEGO-GSSAPI* es una especie de extraña bestia. GSSAPI (Genérico Servicio de Seguridad de la Interfaz de Programa de Aplicación) es una API (en principio) de autenticación diferentes servicios, ofrece la negociación de los mecanismos utilizados. A menudo el único mecanismo disponible será de Kerberos, aunque. Es la costumbre de la API para conectar la 3ª parte de los programas de Kerberos cuando usted está en Unix (definido en varios RFCs, por ejemplo RFC 2743 )

    En la plataforma windows SSPI es la capa genérica, por lo que se compara con GSSAPI.

    SPNEGO es una especie de híbrido extraño. Se trata de un mecanismo a ser utilizado en SSPI, HTTP Auth o GSSAPI que negocia otro protocolo de autenticación (por ejemplo Kerberos o NTLM si estás en Windows), por lo que básicamente hace lo mismo GSSAPI hace de nuevo de una manera diferente.

    Usos típicos de SPNEGO son la autenticación de HTTP a un dominio de windows, por ejemplo IIS utiliza si utiliza ‘la autenticación Integrada de windows’. También se usa cuando se selecciona ‘Negociar’ opciones para SSPI. Véase, por ejemplo, RFC 4559

  3. 1

    Casi la totalidad de sus entendimientos están equivocados.

    Aquí va:

    1. SPN: UN servicio específico de clase está enlazado a una cuenta específica, por ejemplo, de HTTP http://www.stackoverflow.com => HTTP/[email protected]

    2. 3./4. GSS-API (Unix)/SSPI (Windows): Mecanismo neutral de la API para interactuar con. E. g, Kerberos 5, NTLM, SPNEGO, etc.
    3. SPNEGO: es uno de los muchos mechnisms apoyado por GSS-API/SSPI. En realidad, es una pseudo-mech.

Dejar respuesta

Please enter your comment!
Please enter your name here