[JuiCE] Some information about latest state

[Dittmann, Werner]

During the last days JuiCE did another step forward.

Thanks to Berin the native part of JuiCE can be built
with VC++ for Windows and is available as DLL. Berin
works on some topics to make it installable.

Using a 64-bit Java 5 (JDK 1.5.0_6) and a 64-bit SuSE
Linux system I was able to create and test a real 64-bit
version of JuiCE.

We need some support to have real multi-threading tests
of the JuiCE implementation to see if the JuiCE OpenSSL
thread locking works on real multi-processor systems
(together with the Java part). Does anybody have such a
system "at hand" to setup a real thread test?


Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

[Scott Cantor]

> We need some support to have real multi-threading tests
> of the JuiCE implementation to see if the JuiCE OpenSSL
> thread locking works on real multi-processor systems
> (together with the Java part). Does anybody have such a
> system "at hand" to setup a real thread test?

It would be relatively easy to set up a load test against a Shibboleth IdP
that was using Juice for signing. However, I'd need some quick guidance or a
pointer to such explaining how to drop this into an xmlsec application.

To be honest, I've lost track of all the permutations of config.xml in
xmlsec and how to turn on alternate providers.

-- Scott


---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

[Dittmann, Werner]

 

> -----Ursprüngliche Nachricht-----
> Von: Scott Cantor [mailto:cantor.2@...]
> Gesendet: Montag, 20. Februar 2006 15:25
> An: juice-dev@...
> Betreff: RE: [JuiCE] Some information about latest state
>
> > We need some support to have real multi-threading tests
> > of the JuiCE implementation to see if the JuiCE OpenSSL
> > thread locking works on real multi-processor systems
> > (together with the Java part). Does anybody have such a
> > system "at hand" to setup a real thread test?
>
> It would be relatively easy to set up a load test against a
> Shibboleth IdP
> that was using Juice for signing. However, I'd need some
> quick guidance or a
> pointer to such explaining how to drop this into an xmlsec
> application.
>
> To be honest, I've lost track of all the permutations of config.xml in
> xmlsec and how to turn on alternate providers.

In WSS4J I use the following way to set the provider for the Signature
and Hash implementations:

...
import org.apache.xml.security.algorithms.JCEMapper;
...
JCEMapper.setProviderId("JuiCE");

This call intializes a static variable in JCEMapper that the algorithm
implementations use later on. IMHO there is no way to specify the
provider via config.xml.

If your tests use XMLCipher be aware that XMLCipher does _not_ use
this way but you have to define the provider id using specific
"getProviderInstance()" calls - long live common programming patterns :-).

When you install JuiCE pls have a look into the README.txt, gives some
ideas how to do it. If you running on a *nix based system make sure
the native shared lib is contained in you library path, e.g. LD_LIBRARY_PATH

Pls e-mail if you have any questions.

Regards,
Werner


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

[Scott Cantor]

> In WSS4J I use the following way to set the provider for the Signature
> and Hash implementations:
>
> ...
> import org.apache.xml.security.algorithms.JCEMapper;
> ...
> JCEMapper.setProviderId("JuiCE");
>
> This call intializes a static variable in JCEMapper that the algorithm
> implementations use later on. IMHO there is no way to specify the
> provider via config.xml.

So this is something the code should call during initialization of the
servlets, then? And that should route requests for supported algorithms to
JuiCE?

> If your tests use XMLCipher be aware that XMLCipher does _not_ use
> this way but you have to define the provider id using specific
> "getProviderInstance()" calls - long live common programming
> patterns :-).

No encryption in this code yet.

> When you install JuiCE pls have a look into the README.txt, gives some
> ideas how to do it.

Thx.

-- Scott


---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

[Dittmann, Werner]

 

> -----Ursprüngliche Nachricht-----
> Von: Scott Cantor [mailto:cantor.2@...]
> Gesendet: Montag, 20. Februar 2006 16:13
> An: juice-dev@...
> Betreff: RE: [JuiCE] Some information about latest state
>
> > In WSS4J I use the following way to set the provider for
> the Signature
> > and Hash implementations:
> >
> > ...
> > import org.apache.xml.security.algorithms.JCEMapper;
> > ...
> > JCEMapper.setProviderId("JuiCE");
> >
> > This call intializes a static variable in JCEMapper that
> the algorithm
> > implementations use later on. IMHO there is no way to specify the
> > provider via config.xml.
>
> So this is something the code should call during initialization of the
> servlets, then? And that should route requests for supported
> algorithms to
> JuiCE?
>

Yes, in WSS4J we do this very early during intialization. At least the
RSA algorithm implementation of xml-sec use the provider info of
JCEMapper. I've looked into DSA algo implementation but this does _not_
use it - another incompatibility inside xml-sec (I've tested it with
RSA only :-(  ).

I'll dive into the stuff and try to fix it and propose a patch.

So, if you test it then only the RSA based signatures will work
with JuiCE.

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

[Raul Benito-2]

On 2/20/06, Dittmann, Werner <werner.dittmann@...> wrote:

>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Scott Cantor [mailto:cantor.2@...]
> > Gesendet: Montag, 20. Februar 2006 16:13
> > An: juice-dev@...
> > Betreff: RE: [JuiCE] Some information about latest state
> >
> > > In WSS4J I use the following way to set the provider for
> > the Signature
> > > and Hash implementations:
> > >
> > > ...
> > > import org.apache.xml.security.algorithms.JCEMapper;
> > > ...
> > > JCEMapper.setProviderId("JuiCE");
> > >
> > > This call intializes a static variable in JCEMapper that
> > the algorithm
> > > implementations use later on. IMHO there is no way to specify the
> > > provider via config.xml.
> >
> > So this is something the code should call during initialization of the
> > servlets, then? And that should route requests for supported
> > algorithms to
> > JuiCE?
> >
> Yes, in WSS4J we do this very early during intialization. At least the
> RSA algorithm implementation of xml-sec use the provider info of
> JCEMapper. I've looked into DSA algo implementation but this does _not_
> use it - another incompatibility inside xml-sec (I've tested it with
> RSA only :-(  ).
>

I'm one the one to blame for all this things with JCEMapper, sorry...
I think that the best way is to store register the Juice provider as
the default provider using
java.security.Security.insertProviderAt( new .... ,0)
I think we shall depcretaed JCEMapper

Regards,

Raul

> I'll dive into the stuff and try to fix it and propose a patch.
>
> So, if you test it then only the RSA based signatures will work
> with JuiCE.
>
> Regards,
> Werner
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>

--
http://r-bg.com

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

[Dittmann, Werner]

Raul,

inserting a provider at poisition zero is not a good idea. I've
tried that with BouncyCastle and that failed. This is due that
the Sun (maybe also IBM) loader that checks the JCE jar signatures
has some "hardwired" dependency on the JCE provider that is on
position zero. Putting on position one may help. On the other
hand we shall IMHO provide some way to explicitly specify a
provider.

I haven't tested if putting e.g. JuiCE at position one always
uses JuiCE for the standard algos like RSA, DSA, AES etc or if
in that case to provider at position zero is selected.

I'll give it a try during the next days.

Regards,
Werner

> -----Ursprüngliche Nachricht-----
> Von: raul.benito.garcia@...
> [mailto:raul.benito.garcia@...] Im Auftrag von Raul Benito
> Gesendet: Montag, 20. Februar 2006 17:26
> An: juice-dev@...
> Betreff: Re: [JuiCE] Some information about latest state
>
> On 2/20/06, Dittmann, Werner <werner.dittmann@...> wrote:
> >
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Scott Cantor [mailto:cantor.2@...]
> > > Gesendet: Montag, 20. Februar 2006 16:13
> > > An: juice-dev@...
> > > Betreff: RE: [JuiCE] Some information about latest state
> > >
> > > > In WSS4J I use the following way to set the provider for
> > > the Signature
> > > > and Hash implementations:
> > > >
> > > > ...
> > > > import org.apache.xml.security.algorithms.JCEMapper;
> > > > ...
> > > > JCEMapper.setProviderId("JuiCE");
> > > >
> > > > This call intializes a static variable in JCEMapper that
> > > the algorithm
> > > > implementations use later on. IMHO there is no way to
> specify the
> > > > provider via config.xml.
> > >
> > > So this is something the code should call during
> initialization of the
> > > servlets, then? And that should route requests for supported
> > > algorithms to
> > > JuiCE?
> > >
> > Yes, in WSS4J we do this very early during intialization.
> At least the
> > RSA algorithm implementation of xml-sec use the provider info of
> > JCEMapper. I've looked into DSA algo implementation but
> this does _not_
> > use it - another incompatibility inside xml-sec (I've tested it with
> > RSA only :-(  ).
> >
> I'm one the one to blame for all this things with JCEMapper, sorry...
> I think that the best way is to store register the Juice provider as
> the default provider using
> java.security.Security.insertProviderAt( new .... ,0)
> I think we shall depcretaed JCEMapper
>
> Regards,
>
> Raul
> > I'll dive into the stuff and try to fix it and propose a patch.
> >
> > So, if you test it then only the RSA based signatures will work
> > with JuiCE.
> >
> > Regards,
> > Werner
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: juice-dev-unsubscribe@...
> > For additional commands, e-mail: juice-dev-help@...
> >
> >
>
>
> --
> http://r-bg.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...