On Jul 18, 2007, at 6:26 PM, George Stanchev wrote:
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.
I guess all I was thinking was that we could have a map/registry of
algorithm ids -> providers, which can be configured in some manner
(programmatically, for most cases, I suppose). If there's an entry
in the map, then the algorithm lookup (getInstance) would be called
with that provider.
The rub is that we'd have to do this in XMLSec, as well. Not
impossible, but I'm not well versed in that code (yet).
I would like to remove the insertProvider calls in WSS4J, or at least
move it out of the library and into something like the Axis bits
(http://issues.apache.org/jira/browse/WSS-56).
I'm wondering, would all of these problems go away if applications
were forced to add providers, manually, as opposed to having WSS4J do
it for them? (Maybe in conjunction with supporting retrieval of
algorithms based on provider ids, and described above) I'm not quite
sure what the issue is with classloading, since that's loading the
provider; where the provider is loaded from shouldn't matter, right,
as long as the bloody thing is installed in the JCE, no?
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.
Yeah, it should always be an option, but it should not be the only
way to do it.
-Fred
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
