spring-security - taglibs - taglib spring

Kerberos roto después de la actualización de Java6 a Java7

Question

Tengo una aplicación que funciona usando la extensión Kerberos de seguridad de primavera, ejecutándose en jboss, ejecutando java 6.

Estoy en el proceso de actualizar mi jvm de java 6 a java 7. Cuando hago eso, usando la misma base de código y la misma tabla de claves que funcionó en java 6, ahora recibo un error cuando uso java 7.

Recibo constantemente: java.security.PrivilegedActionException: GSSException: error no especificado en el nivel GSS-API (nivel de mecanismo: argumento no válido (400) - No se puede encontrar la clave del tipo apropiado para descifrar AP REP - RC4 con HMAC)

He intentado regenerar la tabla de claves con las diferentes / opciones de criptografía que se han descrito en otros foros sin resultado.

He depurado el código java 7 y, de hecho, las clases que se ocupan de la lectura de la tabla clave al inicio cambiaron de 6 a 7. ¿Podría ser que mi keytab ya no se esté leyendo correctamente en la aplicación? Algunos de los mensajes de depuración que veo al iniciar usando Java6 ya no aparecen en 7, pero no puedo decir si eso es por diseño o si eso indica que algo más está en juego. ¿Alguien más tuvo problemas para actualizar de 6 a 7 y tuvo su integración con Kerberos en ellos? ¿Algún consejo?

Con el inicio de sesión de depuración de spnego y kerberos para iniciar, mi registro muestra:

2012-12-10 10:29:30,886  Debug is  true storeKey true useTicketCache false useKeyTab true doNotPrompt true ticketCache is null isInitiator false KeyTab is jndi:/localhost/docfinity/WEB-INF/classes/config/common/security/http-docfinity.keytab refreshKrb5Config is false principal is HTTP/[email protected] tryFirstPass is false useFirstPass is false storePass is false clearPass is false
2012-12-10 10:30:26,322  principal is HTTP/[email protected]
2012-12-10 10:30:29,794  Will use keytab
2012-12-10 10:30:29,807  Ordering keys wrt default_tkt_enctypes list
2012-12-10 10:30:29,821  Config name: C:/Windows/krb5.ini
2012-12-10 10:30:29,827  Using builtin default etypes for default_tkt_enctypes
2012-12-10 10:30:29,832  default etypes for default_tkt_enctypes:
2012-12-10 10:30:29,837   17    aes128-cts-hmac-sha1-96
2012-12-10 10:30:29,839   16    des3-cbc-sha1-kd
2012-12-10 10:30:29,842   23    rc4-hmac
2012-12-10 10:30:29,846   1     des-cbc-crc
2012-12-10 10:30:29,849   3     des-cbc-md5
2012-12-10 10:30:29,851  .
2012-12-10 10:30:29,855  Commit Succeeded 

Otra pregunta: verá que está intentando leer C: / Windows / krb5.ini. No tengo ese archivo en mi servidor. ¿Necesito uno? Yo tampoco tenía uno con java 6 y eso funcionó.

aaron

Answer 1

Cambie el objeto keyTabLocation por una cadena.

So private String keyTabLocaiton.

      @Override
        public void afterPropertiesSet() throws Exception {
            Assert.notNull(this.servicePrincipal, "servicePrincipal must be specified");
            Assert.notNull(this.keyTabLocation, "keyTab must be specified");
            // if (keyTabLocation instanceof ClassPathResource) {
            // LOG.warn("Your keytab is in the classpath. This file needs special protection and shouldn''t be in the classpath. JAAS may also not be able to load this file from classpath.");
            // }
            LoginConfig loginConfig = new LoginConfig(this.keyTabLocation, this.servicePrincipal,
                    this.debug);
            Set<Principal> princ = new HashSet<Principal>(1);
            princ.add(new KerberosPrincipal(this.servicePrincipal));
            Subject sub = new Subject(false, princ, new HashSet<Object>(), new HashSet<Object>());
            LoginContext lc = new LoginContext("", sub, null, loginConfig);
            lc.login();
            this.serviceSubject = lc.getSubject();
        }

También donde el tipo LoginConfig, establece el indicador isInitiator en verdadero.

 public AppConfigurationEntry[] getAppConfigurationEntry(String name) {
            HashMap<String, String> options = new HashMap<String, String>();
            options.put("useKeyTab", "true");
            options.put("keyTab", this.keyTabLocation);
            options.put("principal", this.servicePrincipalName);
            options.put("storeKey", "true");
            options.put("doNotPrompt", "true");
            if (this.debug) {
                options.put("debug", "true");
            }
            options.put("isInitiator", "true");
            //options.put("isInitiator", "false");

            return new AppConfigurationEntry[] { new AppConfigurationEntry("com.sun.security.auth.module.Krb5LoginModule",
                    AppConfigurationEntry.LoginModuleControlFlag.REQUIRED, options), };
        }

Espero que esto te ayude a solucionar tu problema.

Answer 2

¡Sí! Reparamos SunJaasKerberosTicketValidator para que se vea así y funcionó:

String keyTabPath = this.keyTabLocation.getURL().toExternalForm();
String runtimeVersion = System.getProperty("java.version");
if (runtimeVersion.startsWith("1.7")) 
{
      LOG.info("Detected jdk 7. Modifying keytabpath");
      if (keyTabPath != null)
      {
        if (keyTabPath.startsWith("file:")) 
        {
            keyTabPath = keyTabPath.substring(5);
        }
      }
}
LOG.info("KeyTabPath: " + keyTabPath);
LoginConfig loginConfig = new LoginConfig(keyTabPath, this.servicePrincipal,
                this.debug);

Answer 3

Aquí hay dos posibles problemas que pueden estarlo:

1. Java 7 parece cambiar el orden de tipo de cifrado predeterminado. Detalles:

   • Problema Kerberos de Java 7: suma de comprobación corrupta AES128
     
     

2. No dijiste qué versión específica de JDK 7 estás usando, pero había un error en las versiones anteriores de JDK 7 que impedía cargar archivos keytab a través de URLs "file:":

   • http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2221392

Otro usuario de SO trabajó alrededor del último problema modificando Spring source:

• BadCredentialsException: la validación de Kerberos no fue exitosa