Come abilitare l'autenticazione Kerberos per la chiamata EJB remota su WebSphere?

Question

La mia applicazione è un client Swing autonomo che richiama i bean di sessione stateless EJB grazie alla classica ricerca JNDI e alle chiamate al metodo RMI-IIOP. Viene avviato come applicazione Java WebStart. Il mio obiettivo è recuperare l'identità dell'utente del client da EJBContext con il metodo getCallerPrincipal grazie a Kerberos SSO tra la workstation Windows, ActiveDirectory e il server WebSphere in esecuzione su Linux.

Ho già configurato correttamente la mia cella WebSphere in modalità di implementazione della rete per supportare l'autenticazione Kerberos thanks to the infocenter documentation.

Entrambi i file krb5.conf e krb5.keytab sono OK e testato sia con Linux kinit, klist e wsadmin, $AdminTask validateKrbConfig risponde true.

Il client setup si riferisce solo a un file JAAS login.config per consentire con la proprietà del sistema di comando. La mia intuizione mi dice che probabilmente non è abbastanza.

Ma ora, non trovo ulteriori informazioni per finalizzare il test case:

• come l'ambiente JNDI contesto iniziale deve essere impostato per innescare Kerberos trattativa?
• se ci sono altri requisiti sul lato server come proteggere il mio EJB con un ruolo (JBoss non lo richiede ad esempio)?

Aggiornamento

Poiché non è in esecuzione contenitore client JavaEE con ./launchClient, ho impostato nel mio JNLP le proprietà richieste per leggere sas.client.props e JAAS configurazione login:

<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"/> 

mio wsjaas_client.config è per Oracle Java quindi contiene:

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

mio 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 

Al momento, nessuna autenticazione Kerberos viene attivato: non c'è TGS per l'SPN WAS/myserver.mydomain.com nella mia cache di Kerberos (sia da stazioni di lavoro Windows o Linux) e connessione JNDI è ancora stabilito in forma anonima .

Nessun messaggio di errore, nessun avviso e infine nessun principale. Come faccio a diagnosticare cosa c'è che non va?

Aggiornamento 2012/06/20

Ecco alcuni passi in avanti.Nel mio JNLP applicazione in esecuzione con Oracle Java, ho impostare le seguenti proprietà per utilizzare IBM ORB e permettere la piena traccia ed eseguire il debug informazioni:

<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"/> 

Il file TraceSettings.properties contiene

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

Anche dopo aver letto gran parte di WebSphere 7 Security IBM RedBook Non riesco ancora a ottenere l'autenticazione Kerberos con trigger CSIv2 dal lato client.

Answer 1

Per riassumere il contesto: la nostra implementazione è in produzione da anni con IBM WebSphere in esecuzione su Linux e applicazione distribuita grazie a Java WebStart in esecuzione su Sun JavaSE 6 con IBM ORB incluso e configurato per connettersi senza alcuna autenticazione. Ora vogliamo abilitare l'autenticazione Kerberos e il single-sign-on su RMI-IIOP, supportato da WebSphere 6 (credo).

Qui ci sono ora pezzi di risposta.

Dopo WebSphere 7, è stato introdotto un nuovo concetto per configurare gli aspetti di sicurezza per server: dominio di sicurezza. Teoricamente qualsiasi opzione che non è stata modificata in un dominio di sicurezza eredita dalla sezione sicurezza globale.

Durante il test dell'impostazione Kerberos, abbiamo creato un dominio di sicurezza dedicato per il nostro server di test, per evitare problemi con altri server in esecuzione nella cella.

MA anche se Kerberos è attivato in sicurezza globale, non è ereditata/abilitata per un server configurato con un proprio dominio di sicurezza .

Non appena si corre il nostro server di prova con la sicurezza globale predefinito dove le opzioni Kerberos sono visibili e abilitati, quindi l'autenticazione Kerberos ha iniziato a lavorare con IBM JavaSE 6 eseguito da uno script cmd pipistrello con ClassPath usuale e tutte le proprietà dichiarate nella documentazione.

Nota: l'opzione JNDI Context.SECURITY_AUTHENTICATION non è mai impostata. Dopo la decompilazione, gli unici valori disponibili per IBM ORB sono none, simple e strong ma strong non ha ancora implementato.

Un altro punto: in base al log generato, IBM ORB non è in grado di lavorare con file:/C:/temp/sas.client.config come valore per com.ibm.CORBA.ConfigURL. È DEVE essere un URI e non un percorso di file. Abbiamo anche avuto errore di ricerca DNS per risolvere il nome host C! ARFF. Tutti gli esempi di documentazione sono basati su Unix con file:/path/to/sas.client.config quindi abbiamo fatto molte prove prima di consegnare quel file da un server HTTP.

Ora la parte Java Web Start della distribuzione:

• stesso JNLP originale senza alcuna nessuna impostazione Kerberos sicurezza e funziona perfettamente sia con Oracle JavaSE 6 e IBM Java 6

• con Sicurezza WebSphere abilitata e Kerberos in JNLP (e solo quel set di modifiche), IBM ORB in esecuzione su IBM Java 6 si lamenta con NoClassDefFoundError sull'implementazione del gestore log ffdc disponibile (sempre/sempre) disponibile in ClassPath. Sembra davvero un'incompatibilità di codice con la gerarchia ClassLoader protetta da Java WebStart.

• con Kerberos JNLP, IBM ORB in esecuzione su Oracle JavaSE 6 sembra semplicemente ignorare le impostazioni di sicurezza e si collega in modo anonimo come al solito.

Quindi, un primo passo è ora al lavoro: IBM Java 6 ha iniziato da riga di comando, ma le indagini non sono più per raggiungere il nostro obiettivo: Kerberos con Oracle JavaSE 6 nel contesto Java Web Start.

Answer 2

Dato che non hai menzionato in modo specifico nei passaggi che hai seguito, hai configurato il tuo sas.client.props come nel link di configurazione del client che hai fornito?

È possibile controllare RedBook Implementing Kerberos in a WebSphere Application Server Environment per esempi su come effettuare questa configurazione, oltre alla configurazione rimanente per Client di applicazione.

La sezione 13.5 (13.5 Configurazione del client dell'applicazione Java EE) fornisce esempi per l'impostazione del runtime del client thick, incluso il file sas.client.props.

Answer 3

In base alla guida GSS-API/Kerberos v5 Authentication è necessario autenticarsi su Kerberos prima di effettuare la chiamata al contesto JNDI. Dopo aver eseguito la configurazione Kerberos si configura il contesto intial come segue:

• Quando si crea il contesto iniziale, impostare il Context.SECURITY_AUTHENTICATION (nella documentazione di riferimento API) in ambiente alla stringa "GSSAPI".

Mi sono occupato di ottenere un client Java per utilizzare Kerberos in passato (anche se non con JNDI). Qui è il mio approccio per eliminare la necessità per le opzioni JVM ei file di configurazione locali sul lato client (richiamare questo codice prima che il client tenta di autenticare):

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; 
} 

Si avrà probabilmente bisogno di modificare questo per il vostro contesto (java.security.krb5.kdc e java.security.krb5.realm non sarà corretto) - ma spero che aiuti. Girare sun.security.krb5.debugtrue per quantità voluminose di registrazione.