¿Cómo habilitar la autenticación Kerberos para llamadas EJB remotas en WebSphere?

Question

Mi aplicación es un cliente Swing independiente que invoca los beans EJB de sesión sin estado gracias a la búsqueda clásica JNDI y las llamadas al método RMI-IIOP. Se inicia como una aplicación Java WebStart. Mi objetivo es recuperar la identidad del usuario del cliente de EJBContext con el método getCallerPrincipal gracias al SSO de Kerberos entre la estación de trabajo de Windows, ActiveDirectory y el servidor de WebSphere que se ejecuta en Linux.

Ya he configurado correctamente mi celda de WebSphere en modo de implementación de red para admitir la autenticación Kerberos thanks to the infocenter documentation.

Ambos krb5.conf y krb5.keytab archivos están bien y probado tanto con Linux kinit, klist y wsadmin, $AdminTask validateKrbConfig responde true.

El client setup solo hace referencia a un archivo JAAS login.config para habilitarlo con la propiedad del sistema de comando. Mi intuición me dice que probablemente no sea suficiente.

Pero ahora, no se me hace más información para finalizar el caso de prueba:

• cómo el entorno contexto inicial JNDI debe ser configurado para activar la negociación de Kerberos?
• si hay otros requisitos en el lado del servidor como proteger mi EJB con un rol (JBoss no lo requiere, por ejemplo)?

actualización

Como no se está ejecutando contenedor de cliente JavaEE con ./launchClient, yo he puesto en mi JNLP las propiedades requeridas para leer sas.client.props y JAAS configuración de entrada:

<property name="java.security.auth.login.config" value="C:\temp\wsjaas_client.config"/> 
<property name="com.ibm.CORBA.ConfigURL" value="C:\temp\sas.client.props"/> 

Mi wsjaas_client.config es para Oracle Java por lo que contiene:

WSKRB5Login{ 
    com.sun.security.auth.module.Krb5LoginModule required 
     debug=true useTicketCache=true doNotPrompt=true; 
}; 

Mi sas.client.props contiene:

com.ibm.CORBA.securityEnabled=true 
com.ibm.CORBA.authenticationTarget=KRB5 
com.ibm.CORBA.loginSource=krb5Ccache 
com.ibm.CORBA.loginUserid= 
com.ibm.CORBA.loginPassword= 
com.ibm.CORBA.krb5CcacheFile= 
com.ibm.CORBA.krb5ConfigFile=C:\\temp\\krb5.conf 

Por el momento, ninguna autenticación Kerberos se dispara: no hay TGS para el SPN WAS/myserver.mydomain.com en mi caché Kerberos (ya sea desde estaciones de trabajo Windows o Linux) y la conexión JNDI todavía se establece de forma anónima .

No hay mensaje de error, ninguna advertencia y, finalmente, no hay nada principal. ¿Cómo puedo diagnosticar lo que está mal o lo que falta?

Actualización 2012/06/20

Éstos son algunos pasos hacia adelante.En mi JNLP aplicación que se ejecuta con Oracle Java, he establezca las siguientes propiedades para utilizar IBM ORB y permitir la plena traza y depurar información:

<property name="org.omg.CORBA.ORBSingletonClass" value="com.ibm.rmi.corba.ORBSingleton"/> 
<property name="org.omg.CORBA.ORBClass" value="com.ibm.CORBA.iiop.ORB"/> 
<property name="traceSettingsFile" value="C:\temp\TraceSettings.properties"/> 

El archivo TraceSettings.properties contiene

traceFileName=c:\\temp\\traces.log 
ORBRas=all=enabled 
SASRas=all=enabled 
com.ibm.*=all=enabled 

Incluso después de leer piezas grandes de WebSphere 7 Security IBM RedBook Todavía no consigo que CSIv2 active la autenticación Kerberos desde el lado del cliente.

Answer 1

Para resumir el contexto: nuestra implementación está en producción desde hace años con IBM WebSphere ejecutándose en Linux y la aplicación implementada gracias a Java WebStart ejecutándose en Sun JavaSE 6 con IBM ORB incluido y configurado para conectarse sin ninguna autenticación. Ahora queremos habilitar la autenticación Kerberos y el inicio de sesión único en RMI-IIOP, compatible desde WebSphere 6 (creo).

Aquí están las piezas de respuesta.

Desde WebSphere 7, se ha introducido un nuevo concepto para configurar aspectos de seguridad por servidor: dominio de seguridad. En teoría, cualquier opción que no se haya modificado en un dominio de seguridad hereda de la sección de seguridad global.

Al probar la configuración de Kerberos, hemos creado un dominio de seguridad dedicado para nuestro servidor de prueba, para evitar problemas con otros servidores que se ejecutan en la célula.

PERO incluso si Kerberos está habilitado en la seguridad global , no se hereda/habilitado para un servidor configurado con su propio dominio de seguridad .

Tan pronto como nos dirigimos nuestro servidor de prueba con la seguridad global predeterminada donde las opciones de Kerberos son visibles y habilitado, entonces la autenticación Kerberos ha comenzado a trabajar con IBM JavaSE 6 ejecutado desde un script bat cmd con ClassPath habitual y todas las propiedades declaradas en la documentación.

A tener en cuenta: la opción JNDI Context.SECURITY_AUTHENTICATION nunca se establece. Después de la descompilación, los únicos valores disponibles para IBM ORB son none, simple y strong, pero strong aún no tiene implementación.

Otro punto: según el registro generado, IBM ORB no puede trabajar con file:/C:/temp/sas.client.config como valor para com.ibm.CORBA.ConfigURL. Es DEBE ser un URI y no una ruta de archivo. Incluso obtuvimos un error de búsqueda de DNS para resolver C nombre de host! Arff. Todos los ejemplos de documentación están basados ​​en Unix con file:/path/to/sas.client.config, por lo que hicimos muchas pruebas antes de entregar ese archivo desde un servidor HTTP.

Ahora la parte Java WebStart del despliegue:

• la misma JNLP original sin ningún tipo de seguridad y no hay configuración de Kerberos funciona perfectamente tanto con Oracle JavaSE 6 y Java de IBM 6

• con La seguridad de WebSphere habilitada y Kerberos en JNLP (y solo ese conjunto de cambios), IBM ORB ejecutándose en IBM Java 6 se queja con NoClassDefFoundError sobre la implementación del administrador de registro ffdc que está (todavía/siempre) disponible en ClassPath. Realmente suena como una incompatibilidad de código con la jerarquía de ClassLoader segura de Java WebStart.

• con Kerberos JNLP, IBM ORB ejecutándose en Oracle JavaSE 6 parece simplemente ignorar la configuración de seguridad y se conecta de forma anónima como de costumbre.

lo tanto, un primer paso está trabajando ahora: IBM Java 6 comenzó a partir de la línea de comandos, pero las investigaciones no han terminado para alcanzar nuestro objetivo: Kerberos con Oracle JavaSE 6 en el contexto de Java Web Start.

Answer 2

Como no mencionaste específicamente en los pasos que seguiste, ¿has configurado tus sas.client.props como en el enlace de configuración del cliente que has proporcionado?

Puede consultar RedBook Implementing Kerberos in a WebSphere Application Server Environment para ver ejemplos de cómo realizar esta configuración, así como la configuración restante para Application Client.

La Sección 13.5 (13.5 Configuración del cliente de la aplicación Java EE) proporciona ejemplos para configurar el tiempo de ejecución de cliente grueso, incluido el archivo sas.client.props.

Answer 3

De acuerdo con la guía GSS-API/Kerberos v5 Authentication, debe autenticarse en Kerberos antes de realizar su llamada al contexto JNDI. Una vez que haya realizado la configuración de Kerberos se configura el contexto intial de la siguiente manera:

• Al crear el contexto inicial, establecer el Context.SECURITY_AUTHENTICATION (en la documentación de referencia de la API) propiedad de entorno a la cadena "GSSAPI".

He tratado de obtener un cliente Java para usar Kerberos en el pasado (aunque no con JNDI). Aquí está mi enfoque para eliminar la necesidad de opciones de JVM y archivos de configuración local en el lado del cliente (invocar este código antes de que el cliente intenta autenticar):

public static void initKerberosConfig() 
{     
     System.setProperty("javax.security.auth.useSubjectCredsOnly", "false"); 
     System.setProperty("java.security.krb5.kdc", "host.name:88"); 
     System.setProperty("java.security.krb5.realm", "REALM"); 
     System.setProperty("sun.security.krb5.debug", "false");         
     Configuration progConfig = getProgramaticLoginConfig(); 
     Configuration.setConfiguration(progConfig); 
} 

private static Configuration getProgramaticLoginConfig() 
{ 
     HashMap<String, String> options = new HashMap<String, String>(); 
     options.put("useTicketCache", "true"); 
     options.put("doNotPrompt", "true");             
     AppConfigurationEntry krb5LoginModule = new AppConfigurationEntry("com.sun.security.auth.module.Krb5LoginModule", LoginModuleControlFlag.REQUIRED, options); 
     final AppConfigurationEntry[] aces = new AppConfigurationEntry[]{krb5LoginModule}; 
     Configuration progConfig = new Configuration() 
     { 
       @Override 
       public AppConfigurationEntry[] getAppConfigurationEntry(String arg0) 
       {         
         return aces; 
       } 

     }; 
     return progConfig; 
} 

Es probable que tenga que modificar esto para su contexto (java.security.krb5.kdc y java.security.krb5.realm no será correcto) - pero espero que ayude. Gire sun.security.krb5.debugtrue para cantidades voluminosas de registro.