I'm very happy that there is some discussion about this, and
also very happy to see the Jira issue opened.
I would like to emphasize one point: I did try putting the
bc jar in /jre/lib/ext and configuring java.security, and
that caused WebSphere to not be able to start. This is
exactly the #2 problem you list below.
When I deploy my app, I have to send an ear file to a
different government department, and they deploy it on their
servers. They're very tight about security and
configuration, and I'm sure they wouldn't want to mess
around with the security settings. They host several
applications on each server. So that just reinforces the
notion that we need to implement a solution that doesn't
require configuration at the system level.
In the mean time, I'm writing my own class loader that I'll
package in the xml-security jar, that extracts the Cipher
and provider classes directly from jars in a directory (i.e.
the app context + WEB-INF/lib). I consider it a temporary
hack until the fix appears in xml-security or wss4j.
Are there any ClassLoader experts in the group? I've hit a
snag...
cheers,
md
> -----Original Message-----
> From: George Stanchev [mailto:Gstanchev serena.com]
> Sent: Wednesday, July 18, 2007 6:26 PM
> To: Fred Dushin
> Cc: wss4j-devws.apache.org
> Subject: RE: [dev-crypto] Bug in Cipher class?
>
>
> Hi Fred,
>
> I agree its hard to manage since all instantiations
need to go
> through the custom provider and I agree most calls are
in
> XML-Security.
>
> However it's a serious problem, and may be others can
chime
> in on whats
> the best way to solve it.
>
> May be we can write a java.security.Security wrapper
that instead of
> hitting the global JCE registry, hits our own registry.
That
> wouldn't be
> too hard to implement. Then we load that implementation
along with the
> BC provider and the classes within our context use us
instead of the
> global Security object. If a transforamtion can be
satisfied by the BC
> JCE provider
> then we pass along an implementation from it, otherwise
we
> can delegate
> to the system registry and try to find a transformation
there.
>
> Of course adding the BC to the /jre/lib/ext and
properly
> registering it
> there would solve the problem but that really creates a
> strain on users.
>
> But you see the problem - if the thread context loader
of WSS4J is
> different than
> the application loader (say a derivative) then there is
a real chance
> of screwing up (especially since WSS4J tries to put the
BC at slot 2!)
> by:
> 1. screwed up as Michael was when the javax.crypto.*
classes try to
> instantiate
> a provider from a classloader they are not permitted
(lower
> then them in
> the hierarchy) to see
> 2. Screw up other applications that try to do JCE
> transformationss that
> happen
> to stumble upon our provider.
>
> The real solutions are 2 - either we run BC JCE
alongside the
> other JCE
> providers
> or run in isolation.
>
> Best Regards,
> George
>
> -----Original Message-----
> From: Fred Dushin [mailto:freddushin.net]
> Sent: Wednesday, July 18, 2007 3:34 PM
> To: George Stanchev
> Cc: wss4j-devws.apache.org
> Subject: Re: [dev-crypto] Bug in Cipher class?
>
> Hi George,
>
> Wouldn't this require that every call to
XXX.getInstance(...) in WSS4J
> be modified to specify a provider?
>
> In general, I actually think that's a good idea (though
probably very
> complex to manage!).
>
> But more to the point, I think many of these calls will
not
> be found in
> WSS4J, but instead in Apache XML-Sec.
>
> Or am I missing something here?
>
> Thanks!
> Fred
>
>
> On Jul 18, 2007, at 12:39 PM, George Stanchev wrote:
>
> > An alternative solution would be to not go via the
> > java.security.Security JCE registry and use the
JCE
> provider directly
> > via XXX.getInstance(String transformation,
Provider prov)
> calls. But
> > for some reason (and here the WSS4J developers can
chime
> > in)
> > WSS4J relies on
> > the Java 1.3 JCE interfaces which lack those
methods and need to go
> > via the security registry.
>
>
>
************************************************************
**********
> This email and any files transmitted with it are
confidential and
> intended solely for the use of the individual or entity
to whom they
> are addressed. Any unauthorized review, use, disclosure
or
> distribution is prohibited. If you are not the intended
> recipient, please contact the sender by reply e-mail
and
> destroy all copies of the original message.
>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: wss4j-dev-unsubscribews.apache.org
> For additional commands, e-mail: wss4j-dev-helpws.apache.org
>
>
|