You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by "George Stanchev (JIRA)" <ji...@apache.org> on 2007/07/18 23:29:04 UTC
[jira] Created: (WSS-82) Add the ability to use a custom-loaded JCE
provider instance instead of using the system-provided one
Add the ability to use a custom-loaded JCE provider instance instead of using the system-provided one
-----------------------------------------------------------------------------------------------------
Key: WSS-82
URL: https://issues.apache.org/jira/browse/WSS-82
Project: WSS4J
Issue Type: Bug
Reporter: George Stanchev
Assignee: Davanum Srinivas
Currently WSS4J loads the BouncyCastle JCE (see WSSConfig.java). However, it uses the JCE Security class to then register the JCE in the java.security.Security registry. The problem is, that it uses the context classloader which might or might not be available for other parties. The JCE providers loaded via java.security.Secruity must be installed in the system classloader since it loads the JCE.
JCE 1.4 and onwards provides a way to use an instance of a JCE provider supplied by the caller instead of the classes requesting one from the Security registry.
For example to get a cypher, one can write
Class clazz = myClassloader.loadClass("my.custom.JCEProvider");
java.security.Provider myprov = (java.security.Provider) clazz.getInstance();
javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation, myprov);
instead of
javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation);
or
javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation, "myprov");
This way WSS4J will stay trully independent of any system-provider JCE providers.
Same needs to be done for XML-Security library
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-82) Add the ability to use a custom-loaded
JCE provider instance instead of using the system-provided one
Posted by "George Stanchev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12588935#action_12588935 ]
George Stanchev commented on WSS-82:
------------------------------------
Hi Fred,
I think this will suffice in near term. Addressing this in a more generic way in 2.0 would be nice. BTW, thanks for all the recent work on wss4j.
George
> Add the ability to use a custom-loaded JCE provider instance instead of using the system-provided one
> -----------------------------------------------------------------------------------------------------
>
> Key: WSS-82
> URL: https://issues.apache.org/jira/browse/WSS-82
> Project: WSS4J
> Issue Type: Bug
> Reporter: George Stanchev
>
> Currently WSS4J loads the BouncyCastle JCE (see WSSConfig.java). However, it uses the JCE Security class to then register the JCE in the java.security.Security registry. The problem is, that it uses the context classloader which might or might not be available for other parties. The JCE providers loaded via java.security.Secruity must be installed in the system classloader since it loads the JCE.
> JCE 1.4 and onwards provides a way to use an instance of a JCE provider supplied by the caller instead of the classes requesting one from the Security registry.
> For example to get a cypher, one can write
> Class clazz = myClassloader.loadClass("my.custom.JCEProvider");
> java.security.Provider myprov = (java.security.Provider) clazz.getInstance();
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation, myprov);
> instead of
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation);
> or
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation, "myprov");
> This way WSS4J will stay trully independent of any system-provider JCE providers.
> Same needs to be done for XML-Security library
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Updated: (WSS-82) Add the ability to use a custom-loaded JCE
provider instance instead of using the system-provided one
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Davanum Srinivas updated WSS-82:
--------------------------------
Assignee: (was: Davanum Srinivas)
> Add the ability to use a custom-loaded JCE provider instance instead of using the system-provided one
> -----------------------------------------------------------------------------------------------------
>
> Key: WSS-82
> URL: https://issues.apache.org/jira/browse/WSS-82
> Project: WSS4J
> Issue Type: Bug
> Reporter: George Stanchev
>
> Currently WSS4J loads the BouncyCastle JCE (see WSSConfig.java). However, it uses the JCE Security class to then register the JCE in the java.security.Security registry. The problem is, that it uses the context classloader which might or might not be available for other parties. The JCE providers loaded via java.security.Secruity must be installed in the system classloader since it loads the JCE.
> JCE 1.4 and onwards provides a way to use an instance of a JCE provider supplied by the caller instead of the classes requesting one from the Security registry.
> For example to get a cypher, one can write
> Class clazz = myClassloader.loadClass("my.custom.JCEProvider");
> java.security.Provider myprov = (java.security.Provider) clazz.getInstance();
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation, myprov);
> instead of
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation);
> or
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation, "myprov");
> This way WSS4J will stay trully independent of any system-provider JCE providers.
> Same needs to be done for XML-Security library
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-82) Add the ability to use a custom-loaded
JCE provider instance instead of using the system-provided one
Posted by "Fred Dushin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12589065#action_12589065 ]
Fred Dushin commented on WSS-82:
--------------------------------
Good points, Werner.
I believe the changes I made are 100% backwards compatible. Specifically, the out-of-the-box behavior is exactly the same as it was before, but you can modify the WSConfig object to disable registration of JCE provider. As mentioned, this introduces a potential race condition, which I can live with for now, but which we can address in the future with perhaps modified initialization semantics. But as you rightly point out, we'll be constrained by the Apache XMLSec initialization, as well.
> Add the ability to use a custom-loaded JCE provider instance instead of using the system-provided one
> -----------------------------------------------------------------------------------------------------
>
> Key: WSS-82
> URL: https://issues.apache.org/jira/browse/WSS-82
> Project: WSS4J
> Issue Type: Bug
> Reporter: George Stanchev
>
> Currently WSS4J loads the BouncyCastle JCE (see WSSConfig.java). However, it uses the JCE Security class to then register the JCE in the java.security.Security registry. The problem is, that it uses the context classloader which might or might not be available for other parties. The JCE providers loaded via java.security.Secruity must be installed in the system classloader since it loads the JCE.
> JCE 1.4 and onwards provides a way to use an instance of a JCE provider supplied by the caller instead of the classes requesting one from the Security registry.
> For example to get a cypher, one can write
> Class clazz = myClassloader.loadClass("my.custom.JCEProvider");
> java.security.Provider myprov = (java.security.Provider) clazz.getInstance();
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation, myprov);
> instead of
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation);
> or
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation, "myprov");
> This way WSS4J will stay trully independent of any system-provider JCE providers.
> Same needs to be done for XML-Security library
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-82) Add the ability to use a custom-loaded
JCE provider instance instead of using the system-provided one
Posted by "Dittmann, Werner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12588983#action_12588983 ]
Dittmann, Werner commented on WSS-82:
-------------------------------------
The current handling of JCE in WSS4J was driven by some
requirements and/or contraints given by xmlsec. IMHO when
changing this handling we have to be careful with respect
to these contraints. Also at that point in time we need to
support Java 1.3 that had constraints in JCE provider handling
I can remember discussions that lead to this specific handling
of JCE providers. We had problems when using specific algorithms
and key length, for example RSA-1024.
During the first time we simply added BC without giving a position.
Now, if WSS4J required an algorithm _and_ a specific key length
(RSA-1024 instead of RSA-512) this caused problems: AFAIK you may
perform a lookup for a specific algorithm, but not for a specific
key length for this algo.
If some JCE provider that was in front of BC in the list of JCE
providers and this provider implements RSA then you get this provider.
If this JCE provider only supports key lengths up to 512 and not
1024 then you are in trouble :-) .
Adapating the handling of JCE providers need to be tested carefully,
taking backward compatibility into consideration (still supporting
Java 1.3? Just lately I've seen a mail regarding Java 1.3 support
on the list).
Werner
> Add the ability to use a custom-loaded JCE provider instance instead of using the system-provided one
> -----------------------------------------------------------------------------------------------------
>
> Key: WSS-82
> URL: https://issues.apache.org/jira/browse/WSS-82
> Project: WSS4J
> Issue Type: Bug
> Reporter: George Stanchev
>
> Currently WSS4J loads the BouncyCastle JCE (see WSSConfig.java). However, it uses the JCE Security class to then register the JCE in the java.security.Security registry. The problem is, that it uses the context classloader which might or might not be available for other parties. The JCE providers loaded via java.security.Secruity must be installed in the system classloader since it loads the JCE.
> JCE 1.4 and onwards provides a way to use an instance of a JCE provider supplied by the caller instead of the classes requesting one from the Security registry.
> For example to get a cypher, one can write
> Class clazz = myClassloader.loadClass("my.custom.JCEProvider");
> java.security.Provider myprov = (java.security.Provider) clazz.getInstance();
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation, myprov);
> instead of
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation);
> or
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation, "myprov");
> This way WSS4J will stay trully independent of any system-provider JCE providers.
> Same needs to be done for XML-Security library
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Resolved: (WSS-82) Add the ability to use a custom-loaded
JCE provider instance instead of using the system-provided one
Posted by "Fred Dushin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fred Dushin resolved WSS-82.
----------------------------
Resolution: Fixed
The current approach is acceptable, but we need to flag this issue for a more comprehensive solution in 2.0
> Add the ability to use a custom-loaded JCE provider instance instead of using the system-provided one
> -----------------------------------------------------------------------------------------------------
>
> Key: WSS-82
> URL: https://issues.apache.org/jira/browse/WSS-82
> Project: WSS4J
> Issue Type: Bug
> Reporter: George Stanchev
> Assignee: Fred Dushin
>
> Currently WSS4J loads the BouncyCastle JCE (see WSSConfig.java). However, it uses the JCE Security class to then register the JCE in the java.security.Security registry. The problem is, that it uses the context classloader which might or might not be available for other parties. The JCE providers loaded via java.security.Secruity must be installed in the system classloader since it loads the JCE.
> JCE 1.4 and onwards provides a way to use an instance of a JCE provider supplied by the caller instead of the classes requesting one from the Security registry.
> For example to get a cypher, one can write
> Class clazz = myClassloader.loadClass("my.custom.JCEProvider");
> java.security.Provider myprov = (java.security.Provider) clazz.getInstance();
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation, myprov);
> instead of
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation);
> or
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation, "myprov");
> This way WSS4J will stay trully independent of any system-provider JCE providers.
> Same needs to be done for XML-Security library
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Assigned: (WSS-82) Add the ability to use a custom-loaded
JCE provider instance instead of using the system-provided one
Posted by "Fred Dushin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fred Dushin reassigned WSS-82:
------------------------------
Assignee: Fred Dushin
> Add the ability to use a custom-loaded JCE provider instance instead of using the system-provided one
> -----------------------------------------------------------------------------------------------------
>
> Key: WSS-82
> URL: https://issues.apache.org/jira/browse/WSS-82
> Project: WSS4J
> Issue Type: Bug
> Reporter: George Stanchev
> Assignee: Fred Dushin
>
> Currently WSS4J loads the BouncyCastle JCE (see WSSConfig.java). However, it uses the JCE Security class to then register the JCE in the java.security.Security registry. The problem is, that it uses the context classloader which might or might not be available for other parties. The JCE providers loaded via java.security.Secruity must be installed in the system classloader since it loads the JCE.
> JCE 1.4 and onwards provides a way to use an instance of a JCE provider supplied by the caller instead of the classes requesting one from the Security registry.
> For example to get a cypher, one can write
> Class clazz = myClassloader.loadClass("my.custom.JCEProvider");
> java.security.Provider myprov = (java.security.Provider) clazz.getInstance();
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation, myprov);
> instead of
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation);
> or
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation, "myprov");
> This way WSS4J will stay trully independent of any system-provider JCE providers.
> Same needs to be done for XML-Security library
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-82) Add the ability to use a custom-loaded
JCE provider instance instead of using the system-provided one
Posted by "Fred Dushin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12588766#action_12588766 ]
Fred Dushin commented on WSS-82:
--------------------------------
Hi George,
In r644869, we added the ability to disable BouncyCastle and Juice registration with the JCE, though this currently requires a call to a static operation, introducing the standard problems you're likely to encounter with multi-threaded apps.
Would this suffice, in the near term, for this bug? I'd like to be able to handle the issue in the future, perhaps with a well-defined initialization semantics, but I think that may need to wait for 2.0.
Thanks!
> Add the ability to use a custom-loaded JCE provider instance instead of using the system-provided one
> -----------------------------------------------------------------------------------------------------
>
> Key: WSS-82
> URL: https://issues.apache.org/jira/browse/WSS-82
> Project: WSS4J
> Issue Type: Bug
> Reporter: George Stanchev
>
> Currently WSS4J loads the BouncyCastle JCE (see WSSConfig.java). However, it uses the JCE Security class to then register the JCE in the java.security.Security registry. The problem is, that it uses the context classloader which might or might not be available for other parties. The JCE providers loaded via java.security.Secruity must be installed in the system classloader since it loads the JCE.
> JCE 1.4 and onwards provides a way to use an instance of a JCE provider supplied by the caller instead of the classes requesting one from the Security registry.
> For example to get a cypher, one can write
> Class clazz = myClassloader.loadClass("my.custom.JCEProvider");
> java.security.Provider myprov = (java.security.Provider) clazz.getInstance();
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation, myprov);
> instead of
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation);
> or
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation, "myprov");
> This way WSS4J will stay trully independent of any system-provider JCE providers.
> Same needs to be done for XML-Security library
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org