java windows active-directory single-sign-on kerberos

¿Hay alguna forma en Java o en una línea de comandos para obtener un ticket de Kerberos para un servicio utilizando la API SSPI nativa?



windows active-directory (3)

¿Ha intentado configurar sun.security.jgss.native en Java 6? ¿No sería SSPI la interfaz "nativa" para Windows?

Quiero implementar el inicio de sesión único con Kerberos en Java y he logrado crear un ticket para el servicio utilizando el ticket desde el inicio de sesión de Windows. Desafortunadamente, solo puedo crear ese ticket cuando la clave de registro "allowtgtsessionkey" está habilitada. Recibo una excepción con el mensaje "El identificador no coincide con el valor esperado (906)" tan pronto como lo inhabilito. La clave de registro está documentada en http://java.sun.com/j2se/1.5.0/docs/guide/security/jgss/tutorials/Troubleshooting.html y http://support.microsoft.com/kb/308339 .

Desafortunadamente, no tengo acceso al registro en las computadoras donde se usará mi aplicación, por lo que estoy buscando una forma de hacerlo sin tener que modificarla. Cuando hago el inicio de sesión único a través de SPNEGO en Internet Explorer o Mozilla Firefox, crean un ticket de servicio en mi caché de tickets, por lo que definitivamente debe haber una forma de hacerlo sin configurar la clave de registro. ¿Alguien tiene una idea de cómo hacer esto en Java?

Gracias por tu ayuda, memminger

Actualización: Estoy renunciando a este problema. La clave de registro de Windows impide el acceso al ticket (más exactamente: el sujeto) dentro de la caché del ticket. Java en Windows usa su propia implementación GSSAPI, y supongo que necesita acceso al Ticket para crear un Ticket de servicio. Sin embargo, la API de Windows de SSPI tiene acceso completo al caché de Ticket y, por lo tanto, puede crear tickets de servicio. Los navegadores web utilizan esta API, pero no la utiliza Java (de acuerdo con http://java.sun.com/developer/technicalArticles/J2SE/security/#3 ). Cuando deshabilito SSPI en Firefox después de haber accedido a una página web una vez (por lo que se creó un ticket de servicio), todavía puedo acceder a la página, por lo que tal vez una herramienta de línea de comandos sea suficiente para crear un ticket de servicio utilizando la API SPPI.

Para nosotros, esto significa que ahora podemos abandonar el inicio de sesión único (lo que es inaceptable para nosotros) o que hacemos la autenticación en el lado del cliente de nuestra aplicación (porque solo podemos leer el nombre de usuario pero no verificar el ticket en el servidor), que es un riesgo de seguridad importante. Otro ejemplo de cómo las restricciones de seguridad más fuertes conducen a agujeros de seguridad más grandes porque se vuelven demasiado complicados de usar.

Perdóname si te estoy entendiendo mal, pero ...

El punto de los sistemas de tipo SSO es que el cliente se autentica directamente en el servidor de autenticación (separado) y obtiene un ticket del mismo. Luego pasa el ticket al servidor o servidores de destino que desea usar, cada uno de los cuales verifica que el ticket sea válido con el servidor de autenticación. Si se valida el ticket, el servidor puede asumir que el cliente solo lo obtuvo presentando al servidor Kerberos (de confianza) con credenciales aceptables.

En ninguna parte del proceso, cualquier servidor debe autenticarse en nombre del cliente. En tal sistema, el único servidor que necesita conocer y validar las credenciales del cliente es el servidor de autenticación; ningún otro servidor debe tener acceso a esta información. De esta manera, el cliente puede autenticarse para muchos servidores con un solo intercambio de autenticación, y las credenciales no se ponen en riesgo al ser almacenadas o accesibles a múltiples servidores.

Parece que su implementación está funcionando como debería: la autenticación debe realizarse en el lado del cliente de la aplicación, y esto es correcto y no constituye un riesgo para la seguridad.