Deseo implementar Single Sign On con Kerberos en Java y he logrado crear un ticket para el Servicio utilizando el ticket del 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 desactivo. 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.¿Existe alguna forma en Java o en una línea de comandos para obtener un vale Kerberos para un servicio que utiliza la API SSPI nativa?
Lamentablemente no tengo acceso al registro en las computadoras donde se utilizará mi aplicación, entonces estoy buscando una manera de hacerlo sin tener que modificarlo. Cuando realizo el inicio de sesión único en SPNEGO en Internet Explorer o Mozilla Firefox, crean un ticket de servicio en mi caché de tickets, por lo que definitivamente tiene que haber una forma de hacerlo sin configurar la clave de registro. ¿Alguien tiene una idea de cómo hacer esto en Java?
Gracias por su ayuda, Memminger
Actualización: Me estoy dando seguimiento a este tema. La clave de registro de Windows impide el acceso al ticket (más exactamente: el asunto) dentro de la memoria caché del ticket. Java en Windows usa su propia implementación de GSSAPI, y supongo que necesita acceso al ticket para crear un ticket de servicio. Sin embargo, la API SSPI de Windows tiene acceso completo a la memoria caché de Ticket y, por lo tanto, puede crear tickets de Servicio. Esta API es utilizada por los navegadores web, pero Java no la usa (de acuerdo con http://java.sun.com/developer/technicalArticles/J2SE/security/#3). Cuando desactivo SSPI en Firefox después de haber accedido a una página web (para que se haya creado un ticket de servicio), aún puedo acceder a la página, así que tal vez bastaría con una línea de comando que cree un ticket de servicio utilizando la API de SPPI.
Para nosotros, esto significa que ahora podemos abandonar el inicio de sesión único (que no es aceptable para nosotros) o que realizamos la autenticación en el lado del cliente de nuestra aplicación (porque solo podemos leer el nombre de usuario pero no verificar el boleto en el servidor), que es un riesgo de seguridad importante. Otro ejemplo de cómo las restricciones de seguridad más fuertes llevan a agujeros de seguridad más grandes porque se vuelven demasiado complicados de usar.
¿Ha mirado OpenID como una alternativa a Kerberos? –
Conozco OpenID y lo estoy usando para varios servicios web. Pero en este caso hay una infraestructura existente que utiliza Kerberos y, por cierto, quiero implementar SSO para una aplicación que no es web, por lo que no creo que OpenID brinde ningún beneficio a los usuarios. – user269667