You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Alessio Soldano <as...@redhat.com> on 2014/07/23 11:44:09 UTC
On BouncyCastle installed as a global security provider
Hi,
I've been asked whether it's possible to avoid having BC installed as a
global security provider when using Apache CXF. I'm of course aware that
WSS4J installs it on behalf of CXF for supporting e.g. GCM algorithms,
which is not an option. However the question is still reasonable;
assuming the CXF stack is not the only framework running in the JVM,
other frameworks are going to be affected by that. They might or might
not want BC installed (for instance, just an example, because of [1]).
They might prefer different providers for a given set of algorithm
requirements. Ultimately, it should be up to the user to decide which
providers are set as global security provider, application should either
rely on the installed global providers without touching them, or
explicitly use what they want.
So I'm wondering if there's a way we could modify CXF/WSS4J/Santuario
for using BC (or whatever we want to use ;-) ) e.g. when needing GCM
without installing it as a global provider. Something around e.g.
getting ciphers through the javax.crypto.Cipher#getInstance(String
transformation, Provider provider) method instead of the
javax.crypto.Cipher#getInstance(String transformation) after having
loaded the provider without installing it globally, etc.
Any thought / idea?
Thanks
Alessio
[1] http://bouncycastle.org/jira/browse/BJA-19 /
https://issues.apache.org/jira/browse/HARMONY-3789, BouncyCastle DH
KeyPairGenerator algorithm can hang / eat lots of CPU
--
Alessio Soldano
Web Service Lead, JBoss
Re: On BouncyCastle installed as a global security provider
Posted by Alessio Soldano <as...@redhat.com>.
Cool, thanks for the feedback.
I can deal with CXF-5905, but need you to deal with WSS-507, as I don't
have commit rights on WSS4J ;-)
Thanks
Alessio
On 25/07/14 14:33, Colm O hEigeartaigh wrote:
>
> It looks fine to me.
>
> Colm.
>
>
> On Fri, Jul 25, 2014 at 11:48 AM, Alessio Soldano <asoldano@redhat.com
> <ma...@redhat.com>> wrote:
>
> Hi Colm,
> I've came up with a proposal, please see
> https://issues.apache.org/jira/browse/WSS-507 and
> https://issues.apache.org/jira/browse/CXF-5905 .
> The CXF side of the proposal patch is still to be finished, but it
> should give an idea of the approach.
> Please let me know what you think.
> Thanks
> Alessio
>
> On 23/07/14 12:49, Colm O hEigeartaigh wrote:
>
> Hi Alessio,
>
> I'm open to the idea of passing the BouncyCastle Provider
> Object to the
> various classes in WSS4J etc rather than installing it as a global
> provider, IF it can be done without large code changes.
> Ultimately, CXF
> does not ship with BouncyCastle installed by default, and you
> can use GCM
> algorithms by upgrading to Java 8 as Sergey said, and so most
> users will
> not have to install/use BouncyCastle.
>
> Colm.
>
>
> On Wed, Jul 23, 2014 at 10:44 AM, Alessio Soldano
> <asoldano@redhat.com <ma...@redhat.com>>
> wrote:
>
> Hi,
> I've been asked whether it's possible to avoid having BC
> installed as a
> global security provider when using Apache CXF. I'm of
> course aware that
> WSS4J installs it on behalf of CXF for supporting e.g. GCM
> algorithms,
> which is not an option. However the question is still
> reasonable; assuming
> the CXF stack is not the only framework running in the
> JVM, other
> frameworks are going to be affected by that. They might or
> might not want
> BC installed (for instance, just an example, because of
> [1]). They might
> prefer different providers for a given set of algorithm
> requirements.
> Ultimately, it should be up to the user to decide which
> providers are set
> as global security provider, application should either
> rely on the
> installed global providers without touching them, or
> explicitly use what
> they want.
> So I'm wondering if there's a way we could modify
> CXF/WSS4J/Santuario for
> using BC (or whatever we want to use ;-) ) e.g. when
> needing GCM without
> installing it as a global provider. Something around e.g.
> getting ciphers
> through the javax.crypto.Cipher#getInstance(String
> transformation,
> Provider provider) method instead of the
> javax.crypto.Cipher#getInstance(String
> transformation) after having loaded the provider without
> installing it
> globally, etc.
> Any thought / idea?
> Thanks
> Alessio
>
> [1] http://bouncycastle.org/jira/browse/BJA-19 /
> https://issues.apache.org/jira/browse/HARMONY-3789,
> BouncyCastle DH
> KeyPairGenerator algorithm can hang / eat lots of CPU
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
>
>
>
>
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
--
Alessio Soldano
Web Service Lead, JBoss
Re: On BouncyCastle installed as a global security provider
Posted by Colm O hEigeartaigh <co...@apache.org>.
It looks fine to me.
Colm.
On Fri, Jul 25, 2014 at 11:48 AM, Alessio Soldano <as...@redhat.com>
wrote:
> Hi Colm,
> I've came up with a proposal, please see https://issues.apache.org/
> jira/browse/WSS-507 and https://issues.apache.org/jira/browse/CXF-5905 .
> The CXF side of the proposal patch is still to be finished, but it should
> give an idea of the approach.
> Please let me know what you think.
> Thanks
> Alessio
>
> On 23/07/14 12:49, Colm O hEigeartaigh wrote:
>
>> Hi Alessio,
>>
>> I'm open to the idea of passing the BouncyCastle Provider Object to the
>> various classes in WSS4J etc rather than installing it as a global
>> provider, IF it can be done without large code changes. Ultimately, CXF
>> does not ship with BouncyCastle installed by default, and you can use GCM
>> algorithms by upgrading to Java 8 as Sergey said, and so most users will
>> not have to install/use BouncyCastle.
>>
>> Colm.
>>
>>
>> On Wed, Jul 23, 2014 at 10:44 AM, Alessio Soldano <as...@redhat.com>
>> wrote:
>>
>> Hi,
>>> I've been asked whether it's possible to avoid having BC installed as a
>>> global security provider when using Apache CXF. I'm of course aware that
>>> WSS4J installs it on behalf of CXF for supporting e.g. GCM algorithms,
>>> which is not an option. However the question is still reasonable;
>>> assuming
>>> the CXF stack is not the only framework running in the JVM, other
>>> frameworks are going to be affected by that. They might or might not want
>>> BC installed (for instance, just an example, because of [1]). They might
>>> prefer different providers for a given set of algorithm requirements.
>>> Ultimately, it should be up to the user to decide which providers are set
>>> as global security provider, application should either rely on the
>>> installed global providers without touching them, or explicitly use what
>>> they want.
>>> So I'm wondering if there's a way we could modify CXF/WSS4J/Santuario for
>>> using BC (or whatever we want to use ;-) ) e.g. when needing GCM without
>>> installing it as a global provider. Something around e.g. getting ciphers
>>> through the javax.crypto.Cipher#getInstance(String transformation,
>>> Provider provider) method instead of the javax.crypto.Cipher#
>>> getInstance(String
>>> transformation) after having loaded the provider without installing it
>>> globally, etc.
>>> Any thought / idea?
>>> Thanks
>>> Alessio
>>>
>>> [1] http://bouncycastle.org/jira/browse/BJA-19 /
>>> https://issues.apache.org/jira/browse/HARMONY-3789, BouncyCastle DH
>>> KeyPairGenerator algorithm can hang / eat lots of CPU
>>>
>>> --
>>> Alessio Soldano
>>> Web Service Lead, JBoss
>>>
>>>
>>>
>>
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: On BouncyCastle installed as a global security provider
Posted by Alessio Soldano <as...@redhat.com>.
Hi Colm,
I've came up with a proposal, please see
https://issues.apache.org/jira/browse/WSS-507 and
https://issues.apache.org/jira/browse/CXF-5905 .
The CXF side of the proposal patch is still to be finished, but it
should give an idea of the approach.
Please let me know what you think.
Thanks
Alessio
On 23/07/14 12:49, Colm O hEigeartaigh wrote:
> Hi Alessio,
>
> I'm open to the idea of passing the BouncyCastle Provider Object to the
> various classes in WSS4J etc rather than installing it as a global
> provider, IF it can be done without large code changes. Ultimately, CXF
> does not ship with BouncyCastle installed by default, and you can use GCM
> algorithms by upgrading to Java 8 as Sergey said, and so most users will
> not have to install/use BouncyCastle.
>
> Colm.
>
>
> On Wed, Jul 23, 2014 at 10:44 AM, Alessio Soldano <as...@redhat.com>
> wrote:
>
>> Hi,
>> I've been asked whether it's possible to avoid having BC installed as a
>> global security provider when using Apache CXF. I'm of course aware that
>> WSS4J installs it on behalf of CXF for supporting e.g. GCM algorithms,
>> which is not an option. However the question is still reasonable; assuming
>> the CXF stack is not the only framework running in the JVM, other
>> frameworks are going to be affected by that. They might or might not want
>> BC installed (for instance, just an example, because of [1]). They might
>> prefer different providers for a given set of algorithm requirements.
>> Ultimately, it should be up to the user to decide which providers are set
>> as global security provider, application should either rely on the
>> installed global providers without touching them, or explicitly use what
>> they want.
>> So I'm wondering if there's a way we could modify CXF/WSS4J/Santuario for
>> using BC (or whatever we want to use ;-) ) e.g. when needing GCM without
>> installing it as a global provider. Something around e.g. getting ciphers
>> through the javax.crypto.Cipher#getInstance(String transformation,
>> Provider provider) method instead of the javax.crypto.Cipher#getInstance(String
>> transformation) after having loaded the provider without installing it
>> globally, etc.
>> Any thought / idea?
>> Thanks
>> Alessio
>>
>> [1] http://bouncycastle.org/jira/browse/BJA-19 /
>> https://issues.apache.org/jira/browse/HARMONY-3789, BouncyCastle DH
>> KeyPairGenerator algorithm can hang / eat lots of CPU
>>
>> --
>> Alessio Soldano
>> Web Service Lead, JBoss
>>
>>
>
--
Alessio Soldano
Web Service Lead, JBoss
Re: On BouncyCastle installed as a global security provider
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Alessio,
I'm open to the idea of passing the BouncyCastle Provider Object to the
various classes in WSS4J etc rather than installing it as a global
provider, IF it can be done without large code changes. Ultimately, CXF
does not ship with BouncyCastle installed by default, and you can use GCM
algorithms by upgrading to Java 8 as Sergey said, and so most users will
not have to install/use BouncyCastle.
Colm.
On Wed, Jul 23, 2014 at 10:44 AM, Alessio Soldano <as...@redhat.com>
wrote:
> Hi,
> I've been asked whether it's possible to avoid having BC installed as a
> global security provider when using Apache CXF. I'm of course aware that
> WSS4J installs it on behalf of CXF for supporting e.g. GCM algorithms,
> which is not an option. However the question is still reasonable; assuming
> the CXF stack is not the only framework running in the JVM, other
> frameworks are going to be affected by that. They might or might not want
> BC installed (for instance, just an example, because of [1]). They might
> prefer different providers for a given set of algorithm requirements.
> Ultimately, it should be up to the user to decide which providers are set
> as global security provider, application should either rely on the
> installed global providers without touching them, or explicitly use what
> they want.
> So I'm wondering if there's a way we could modify CXF/WSS4J/Santuario for
> using BC (or whatever we want to use ;-) ) e.g. when needing GCM without
> installing it as a global provider. Something around e.g. getting ciphers
> through the javax.crypto.Cipher#getInstance(String transformation,
> Provider provider) method instead of the javax.crypto.Cipher#getInstance(String
> transformation) after having loaded the provider without installing it
> globally, etc.
> Any thought / idea?
> Thanks
> Alessio
>
> [1] http://bouncycastle.org/jira/browse/BJA-19 /
> https://issues.apache.org/jira/browse/HARMONY-3789, BouncyCastle DH
> KeyPairGenerator algorithm can hang / eat lots of CPU
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: On BouncyCastle installed as a global security provider
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Alessio
In my new tests around JSON security I'm doing exactly what you propose,
checking if BC is needed, apparently not with Java 8 only as far as GCM
is concerned.
it may be more sensitive in case of WSS4J...
Cheers, Sergey
On 23/07/14 12:44, Alessio Soldano wrote:
> Hi,
> I've been asked whether it's possible to avoid having BC installed as a
> global security provider when using Apache CXF. I'm of course aware that
> WSS4J installs it on behalf of CXF for supporting e.g. GCM algorithms,
> which is not an option. However the question is still reasonable;
> assuming the CXF stack is not the only framework running in the JVM,
> other frameworks are going to be affected by that. They might or might
> not want BC installed (for instance, just an example, because of [1]).
> They might prefer different providers for a given set of algorithm
> requirements. Ultimately, it should be up to the user to decide which
> providers are set as global security provider, application should either
> rely on the installed global providers without touching them, or
> explicitly use what they want.
> So I'm wondering if there's a way we could modify CXF/WSS4J/Santuario
> for using BC (or whatever we want to use ;-) ) e.g. when needing GCM
> without installing it as a global provider. Something around e.g.
> getting ciphers through the javax.crypto.Cipher#getInstance(String
> transformation, Provider provider) method instead of the
> javax.crypto.Cipher#getInstance(String transformation) after having
> loaded the provider without installing it globally, etc.
> Any thought / idea?
> Thanks
> Alessio
>
> [1] http://bouncycastle.org/jira/browse/BJA-19 /
> https://issues.apache.org/jira/browse/HARMONY-3789, BouncyCastle DH
> KeyPairGenerator algorithm can hang / eat lots of CPU
>