Tag Archives: Java

Integrating SafeNet Luna PCI 3000 with WSS4J

Because of the need to integrate Luna PCI HSM Cryptographic accelerator card with WS-Security for WS-Signature operations for improving speed I had to customize a couple of things in the configuration of WSS4J, I will take Axis2 Configuration as example but it applies to CXF too as it uses WSS4J for WS-Security operations.

First of all Luna JSP (Java Service Provider) should be installed, with Luna JCE and JCA correctly installed in the JRE and java.security file with the apaaaaapropiate Luna providers in this position:


security.provider.1=sun.security.provider.Sun
security.provider.2=com.chrysalisits.crypto.LunaJCAProvider
security.provider.3=com.chrysalisits.cryptox.LunaJCEProvider
security.provider.4=sun.security.rsa.SunRsaSign
security.provider.5=com.sun.net.ssl.internal.ssl.Provider
...

 

As I’m using a policy based WS-Security configuration. I had to modify policy as follows:


...
</sp:SignedParts>
<ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy">
<ramp:user>SDE Server</ramp:user>
<ramp:passwordCallbackClass>com.kprtech.service.ws.security.ServerCallback</ramp:passwordCallbackClass>

<ramp:signatureCrypto>
<ramp:crypto provider="example.MyMerlin">
<ramp:property name="org.apache.ws.security.crypto.merlin.keystore.type">Luna</ramp:property>
<ramp:property name="org.apache.ws.security.crypto.merlin.file"></ramp:property>
<ramp:property name="org.apache.ws.security.crypto.merlin.keystore.password"></ramp:property>
</ramp:crypto>
</ramp:signatureCrypto>



</ramp:RampartConfig>

...


Where ramp:user is the alias in the HSM for the signing certificate and example.MyMerlin is as follows:

package example;

import com.chrysalisits.crypto.LunaPrivateKeyRsa;
import com.chrysalisits.crypto.LunaSession;
import com.chrysalisits.crypto.LunaTokenObject;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.ws.security.components.crypto.CredentialException;
import org.apache.ws.security.components.crypto.Merlin;

import java.io.IOException;
import java.security.PrivateKey;
import java.util.Properties;

/**
* Creado por: jaime
* 13/02/12
*/
public class MyMerlin extends Merlin {

/**
* THE HANDLE!
*/
public static final int PRIVATE_KEY_HANDLE = 71;

public MyMerlin(Properties properties, ClassLoader loader) throws CredentialException, IOException {
super(properties, loader);
}

public MyMerlin(Properties properties) throws CredentialException, IOException {
super(properties);
}

private static Log log = LogFactory.getLog(MyMerlin.class);

@Override
public PrivateKey getPrivateKey(String alias, String password) throws Exception {
return new LunaPrivateKeyRsa(new LunaTokenObject(PRIVATE_KEY_HANDLE, LunaSession.GetNewInstance()));
}

}</pre>
&nbsp;
<pre>

Where the constant PRIVATE_KEY_HANDLE should be set the value of the handle id of the private key used for signing. ramp:user set in the first configuration won’t be enough as the Luna JCA Keystore implementation maps only to the certificate and not the private key. This is not a really clean solution but to the time it works.

You can always get the handle id using Luna software:


cmu list 

You will need too to place calls to:


 HSM_Manager.HSM_Login();

and


 HSM_Manager.HSM_Login();

in the correct places in your app so your application becomes logged to the HSM.

Any question I’ll be glad to help you as this problem took me more than a week to get resolved.

One point worths to note is that the improvement in speed wasn’t as good as I expected, I suppose that because of the work done by Axis2/Rampart to create Ws-Security XML is more than the work needed to create the actual signature

Probando la interfaz o la implementación

Hoy mientras escribía unas pruebas unitarias para los métodos de una interfaz me preguntaba que es lo que se debe probar, la realización de una interfaz o una implementación de esa interfaz.

Esto es:

Prueba de la realización de una interfaz:


public class Data {
}

public interface DataProvider {

/**
* @param encodedData
* @return
* @should extract data in a platform specific way
*/
Data extractData(String encodedData);

}

 


public class DataProviderTest {
/**
* @verifies extract data in a platform specific way
* @see DataProvider#extractData(String)
*/
@org.junit.Test
public void extractData_shouldExtractDataInAPlatformSpecificWay() throws Exception {
//TODO auto-generated
Assert.fail("Not yet implemented");
}
}

Prueba de la implementación


public interface DataProvider {

/**
* @param encodedData
* @return
* @should extract data in a platform specific way
*/
Data extractData(String encodedData);

}

 


public class DataProvideImpl1 implements DataProvider {

/**
* @param encodedData
* @return
* @should extract data in a platform specific way
*/
@Override
public Data extractData(String encodedData) {
return null;

}

/**
* @should do something impl specific
*/
void implementationSpeficMethod() {

}
}

 


public class DataProvideImpl1Test {

/**
* @verifies extract data in a platform specific way
* @see DataProvideImpl1#extractData(String)
*/
@org.junit.Test
public void extractData_shouldExtractDataInAPlatformSpecificWay() throws Exception {
//TODO auto-generated
Assert.fail("Not yet implemented");
}
/**
* @verifies do something impl specific
* @see DataProvideImpl1#implementationSpeficMethod()
*/
@org.junit.Test
public void implementationSpeficMethod_shouldDoSomethingImplSpecific() throws Exception {
//TODO auto-generated
Assert.fail("Not yet implemented");
}

}

Y pues dado que la aplicación debería girar en torno a los servicios (métodos) provistos por las interfaces, y como recomienda la metodología TDD al sugerir que debemos programar concentrados en el cumplimiento de las interfaces (realizaciones) , pues parece bastante claro que nuestro principal y derepente único interés debería ser hacer que se cumpla el contrato de cada uno de los métodos de las interfaces,por lo cual es exactamente eso lo que deberían probar nuestros método y no tendrían por qué hacer algo como (ahora mismo no se me ocurre una excepción a esta regla):

</pre>
/**
* @verifies do something impl specific
* @see DataProvideImpl1#implementationSpeficMethod()
*/
@org.junit.Test
public void implementationSpeficMethod_shouldDoSomethingImplSpecific() throws Exception {
//TODO auto-generated
Assert.fail("Not yet implemented");
}
<pre>

Pero si es así surge un problema, qué sucede cuando tenemos más de una implementación, de qué manera nombramos a la clase de pruebas, está claro que no podría ser InterfazBajoPruebaTest, debido a que hay más de una implementación y el código en la clase InterfazBajoPruebaTest solo debería probar código para una implementación.


public interface DataProvider {

/**
* @param encodedData
* @return
* @should extract data in a platform specific way
*/
Data extractData(String encodedData);

}

public class DataProvideImpl1 implements DataProvider {

/**
* @param encodedData
* @return
* @should extract data in a platform specific way
*/
@Override
public Data extractData(String encodedData) {
return null;

}

/**
* @should do something impl specific
*/
void implementationSpeficMethod() {

}
}

public class DataProviderImpl2 implements DataProvider{

/**
* @param encodedData
* @return
* @should extract data in a platform specific way
*/
@Override
public Data extractData(String encodedData) {
return null;
}
}

public class DataProviderTest {
/**
* @verifies extract data in a platform specific way
* @see DataProvider#extractData(String)
*/
@org.junit.Test
public void extractData_shouldExtractDataInAPlatformSpecificWay() throws Exception {
//TODO auto-generated
Assert.fail("Not yet implemented");
}
}

Por lo tanto sugiero como solución a este problema. Utilizar el nombre de las implementaciones para las clases de prueba pero solo los métodos de la interfaz implementada para la creación de los métodos de pruebas, esto es, no se deberían probar los métodos que no sean parte del contrato establecido por la interfaz.

public interface DataProvider {

/**
* @param encodedData
* @return
* @should extract data in a platform specific way
*/
Data extractData(String encodedData);

}

public class DataProvideImpl1 implements DataProvider {

/**
* @param encodedData
* @return
* @should extract data in a platform specific way
*/
@Override
public Data extractData(String encodedData) {
return null;

}

/**
* do something impl specific (not tested)
*/
void implementationSpeficMethod() {

}
}

public class DataProvideImpl1Test {

/**
* @verifies extract data in a platform specific way
* @see DataProvideImpl1#extractData(String)
*/
@org.junit.Test
public void extractData_shouldExtractDataInAPlatformSpecificWay() throws Exception {
//TODO auto-generated
Assert.fail("Not yet implemented");
}

}

public class DataProviderImpl2 implements DataProvider{

/**
* @param encodedData
* @return
* @should extract data in a platform specific way
*/
@Override
public Data extractData(String encodedData) {
return null;
}
}
public class DataProviderImpl2Test {
/**
* @verifies extract data in a platform specific way
* @see DataProviderImpl2#extractData(String)
*/
@org.junit.Test
public void extractData_shouldExtractDataInAPlatformSpecificWay() throws Exception {
//TODO auto-generated
Assert.fail("Not yet implemented");
}
}

Aprendizaje automático con weka

Weka es un programa que permite analizar datos y junto a algoritmos de inteligencia artificial puede clasificarlos entre muchas otras cosas.

http://www.cs.waikato.ac.nz/ml/weka/

Éste esta orientado hacia la minería de datos y aprendizaje automático, para ello cuenta con algoritmos de árboles de decisión que permiten clasificar datos y predecir el comportamiento (de manera estadística).

Una página en la que se puede encontrar un tutorial maravilloso para iniciarse es  ésta:

http://users.dsic.upv.es/~cferri/weka/

El tutorial al que se hace mención se encuentra precisamente aquí:

http://users.dsic.upv.es/~cferri/weka/CursDoctorat-weka.pdf

Además se necesitará descargar los datasets de la misma página para hacer uso de ellos a lo largo del tutorial.

Otro recurso interesante para conseguir una idea general sobre weka es el siguiente:

http://metaemotion.com/diego.garcia.morate/