You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Andrei Shakirin (Created) (JIRA)" <ji...@apache.org> on 2012/01/20 11:45:40 UTC
[jira] [Created] (CXF-4049) Check external CryptoProvider from
message context properties in Wss4jInInterceptor
Check external CryptoProvider from message context properties in Wss4jInInterceptor
-----------------------------------------------------------------------------------
Key: CXF-4049
URL: https://issues.apache.org/jira/browse/CXF-4049
Project: CXF
Issue Type: Improvement
Components: Core
Affects Versions: 2.5.1
Environment: Windows
Reporter: Andrei Shakirin
Attachments: WSS4JInInterceptor.patch
Hi,
Just a small improvements in Wss4jInInterceptor.
Normally CryptoProvider doesn't instantiated directly via CryptoFactory, but firstly tried to obtained from message context properties (SecurityConstants.ENCRYPT_CRYPTO, SecurityConstants.SIGNATURE_CRYPTO). And only if the properties are not set, CryptoProvider is instantiated via CryptoFactory. This gives the possibility to replace Merlin CryptoProvider to custom one (probably non keystore based).
AbstractBindingBuilder, XmlSignHandler, SAMLUtils are working in this way.
Unfortunatelly it is not the case for Wss4jInInterceptor. It doesn't initializes crypto provider in RequestData and crypto provider is always created via CryptoFactory. It makes impossible to use custom implementation of CryptoProvider in incoming chain.
Patch is attached.
Regards,
Andrei.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4049) Check external CryptoProvider from
message context properties in Wss4jInInterceptor
Posted by "Colm O hEigeartaigh (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13220830#comment-13220830 ]
Colm O hEigeartaigh commented on CXF-4049:
------------------------------------------
Hi Andrei,
The problem with the patch you submitted, is that it would override the work done in CXF-4034. With the current code I checked in, it only gets called for the non-policy case.
Colm.
> Check external CryptoProvider from message context properties in Wss4jInInterceptor
> -----------------------------------------------------------------------------------
>
> Key: CXF-4049
> URL: https://issues.apache.org/jira/browse/CXF-4049
> Project: CXF
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.5.1
> Environment: Windows
> Reporter: Andrei Shakirin
> Assignee: Colm O hEigeartaigh
> Fix For: 2.4.7, 2.5.3
>
> Attachments: WSS4JInInterceptor.patch, WSS4JInInterceptor.patch
>
>
> Hi,
> Just a small improvements in Wss4jInInterceptor.
> Normally CryptoProvider doesn't instantiated directly via CryptoFactory, but firstly tried to obtained from message context properties (SecurityConstants.ENCRYPT_CRYPTO, SecurityConstants.SIGNATURE_CRYPTO). And only if the properties are not set, CryptoProvider is instantiated via CryptoFactory. This gives the possibility to replace Merlin CryptoProvider to custom one (probably non keystore based).
> AbstractBindingBuilder, XmlSignHandler, SAMLUtils are working in this way.
> Unfortunatelly it is not the case for Wss4jInInterceptor. It doesn't initializes crypto provider in RequestData and crypto provider is always created via CryptoFactory. It makes impossible to use custom implementation of CryptoProvider in incoming chain.
> Patch is attached.
> Regards,
> Andrei.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4049) Check external CryptoProvider from
message context properties in Wss4jInInterceptor
Posted by "Colm O hEigeartaigh (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217152#comment-13217152 ]
Colm O hEigeartaigh commented on CXF-4049:
------------------------------------------
Resending...please see the previous comment.
Colm.
> Check external CryptoProvider from message context properties in Wss4jInInterceptor
> -----------------------------------------------------------------------------------
>
> Key: CXF-4049
> URL: https://issues.apache.org/jira/browse/CXF-4049
> Project: CXF
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.5.1
> Environment: Windows
> Reporter: Andrei Shakirin
> Assignee: Colm O hEigeartaigh
> Fix For: 2.4.7, 2.5.3
>
> Attachments: WSS4JInInterceptor.patch
>
>
> Hi,
> Just a small improvements in Wss4jInInterceptor.
> Normally CryptoProvider doesn't instantiated directly via CryptoFactory, but firstly tried to obtained from message context properties (SecurityConstants.ENCRYPT_CRYPTO, SecurityConstants.SIGNATURE_CRYPTO). And only if the properties are not set, CryptoProvider is instantiated via CryptoFactory. This gives the possibility to replace Merlin CryptoProvider to custom one (probably non keystore based).
> AbstractBindingBuilder, XmlSignHandler, SAMLUtils are working in this way.
> Unfortunatelly it is not the case for Wss4jInInterceptor. It doesn't initializes crypto provider in RequestData and crypto provider is always created via CryptoFactory. It makes impossible to use custom implementation of CryptoProvider in incoming chain.
> Patch is attached.
> Regards,
> Andrei.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4049) Check external CryptoProvider from
message context properties in Wss4jInInterceptor
Posted by "Colm O hEigeartaigh (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh updated CXF-4049:
-------------------------------------
CXF Fields: Blocked on External
> Check external CryptoProvider from message context properties in Wss4jInInterceptor
> -----------------------------------------------------------------------------------
>
> Key: CXF-4049
> URL: https://issues.apache.org/jira/browse/CXF-4049
> Project: CXF
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.5.1
> Environment: Windows
> Reporter: Andrei Shakirin
> Assignee: Colm O hEigeartaigh
> Fix For: 2.4.7, 2.5.3
>
> Attachments: WSS4JInInterceptor.patch
>
>
> Hi,
> Just a small improvements in Wss4jInInterceptor.
> Normally CryptoProvider doesn't instantiated directly via CryptoFactory, but firstly tried to obtained from message context properties (SecurityConstants.ENCRYPT_CRYPTO, SecurityConstants.SIGNATURE_CRYPTO). And only if the properties are not set, CryptoProvider is instantiated via CryptoFactory. This gives the possibility to replace Merlin CryptoProvider to custom one (probably non keystore based).
> AbstractBindingBuilder, XmlSignHandler, SAMLUtils are working in this way.
> Unfortunatelly it is not the case for Wss4jInInterceptor. It doesn't initializes crypto provider in RequestData and crypto provider is always created via CryptoFactory. It makes impossible to use custom implementation of CryptoProvider in incoming chain.
> Patch is attached.
> Regards,
> Andrei.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4049) Check external CryptoProvider from
message context properties in Wss4jInInterceptor
Posted by "Andrei Shakirin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13220824#comment-13220824 ]
Andrei Shakirin commented on CXF-4049:
--------------------------------------
Hi Colm,
Probably not completely got your comment from 20/Jan/12.
If I move this functionality to "Wss4jInInterceptor.computeAction()", PolicyBasedWss4JInInterceptor will override with method and custom crypto provider will not be activated. Or did you mean "PolicyBasedWss4JInInterceptor.computeAction()"? Also not sure that computeAction() is the right place for checking custom crypto provider.
But as far as you already fixed this problem by [CXF-4034|https://issues.apache.org/jira/browse/CXF-4034] in "PolicyBasedWss4JInInterceptor.checkAsymmetricBinding()", it doesn't matter.
> Check external CryptoProvider from message context properties in Wss4jInInterceptor
> -----------------------------------------------------------------------------------
>
> Key: CXF-4049
> URL: https://issues.apache.org/jira/browse/CXF-4049
> Project: CXF
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.5.1
> Environment: Windows
> Reporter: Andrei Shakirin
> Assignee: Colm O hEigeartaigh
> Fix For: 2.4.7, 2.5.3
>
> Attachments: WSS4JInInterceptor.patch, WSS4JInInterceptor.patch
>
>
> Hi,
> Just a small improvements in Wss4jInInterceptor.
> Normally CryptoProvider doesn't instantiated directly via CryptoFactory, but firstly tried to obtained from message context properties (SecurityConstants.ENCRYPT_CRYPTO, SecurityConstants.SIGNATURE_CRYPTO). And only if the properties are not set, CryptoProvider is instantiated via CryptoFactory. This gives the possibility to replace Merlin CryptoProvider to custom one (probably non keystore based).
> AbstractBindingBuilder, XmlSignHandler, SAMLUtils are working in this way.
> Unfortunatelly it is not the case for Wss4jInInterceptor. It doesn't initializes crypto provider in RequestData and crypto provider is always created via CryptoFactory. It makes impossible to use custom implementation of CryptoProvider in incoming chain.
> Patch is attached.
> Regards,
> Andrei.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4049) Check external CryptoProvider from
message context properties in Wss4jInInterceptor
Posted by "Colm O hEigeartaigh (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13210352#comment-13210352 ]
Colm O hEigeartaigh commented on CXF-4049:
------------------------------------------
Hi Andrei,
Can you resubmit this patch giving a license to Apache?
Colm.
> Check external CryptoProvider from message context properties in Wss4jInInterceptor
> -----------------------------------------------------------------------------------
>
> Key: CXF-4049
> URL: https://issues.apache.org/jira/browse/CXF-4049
> Project: CXF
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.5.1
> Environment: Windows
> Reporter: Andrei Shakirin
> Assignee: Colm O hEigeartaigh
> Fix For: 2.4.7, 2.5.3
>
> Attachments: WSS4JInInterceptor.patch
>
>
> Hi,
> Just a small improvements in Wss4jInInterceptor.
> Normally CryptoProvider doesn't instantiated directly via CryptoFactory, but firstly tried to obtained from message context properties (SecurityConstants.ENCRYPT_CRYPTO, SecurityConstants.SIGNATURE_CRYPTO). And only if the properties are not set, CryptoProvider is instantiated via CryptoFactory. This gives the possibility to replace Merlin CryptoProvider to custom one (probably non keystore based).
> AbstractBindingBuilder, XmlSignHandler, SAMLUtils are working in this way.
> Unfortunatelly it is not the case for Wss4jInInterceptor. It doesn't initializes crypto provider in RequestData and crypto provider is always created via CryptoFactory. It makes impossible to use custom implementation of CryptoProvider in incoming chain.
> Patch is attached.
> Regards,
> Andrei.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4049) Check external CryptoProvider from
message context properties in Wss4jInInterceptor
Posted by "Colm O hEigeartaigh (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh updated CXF-4049:
-------------------------------------
Fix Version/s: 2.5.3
2.4.7
> Check external CryptoProvider from message context properties in Wss4jInInterceptor
> -----------------------------------------------------------------------------------
>
> Key: CXF-4049
> URL: https://issues.apache.org/jira/browse/CXF-4049
> Project: CXF
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.5.1
> Environment: Windows
> Reporter: Andrei Shakirin
> Assignee: Colm O hEigeartaigh
> Fix For: 2.4.7, 2.5.3
>
> Attachments: WSS4JInInterceptor.patch
>
>
> Hi,
> Just a small improvements in Wss4jInInterceptor.
> Normally CryptoProvider doesn't instantiated directly via CryptoFactory, but firstly tried to obtained from message context properties (SecurityConstants.ENCRYPT_CRYPTO, SecurityConstants.SIGNATURE_CRYPTO). And only if the properties are not set, CryptoProvider is instantiated via CryptoFactory. This gives the possibility to replace Merlin CryptoProvider to custom one (probably non keystore based).
> AbstractBindingBuilder, XmlSignHandler, SAMLUtils are working in this way.
> Unfortunatelly it is not the case for Wss4jInInterceptor. It doesn't initializes crypto provider in RequestData and crypto provider is always created via CryptoFactory. It makes impossible to use custom implementation of CryptoProvider in incoming chain.
> Patch is attached.
> Regards,
> Andrei.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4049) Check external CryptoProvider from
message context properties in Wss4jInInterceptor
Posted by "Andrei Shakirin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13220904#comment-13220904 ]
Andrei Shakirin commented on CXF-4049:
--------------------------------------
Aah, got it.
Andrei.
> Check external CryptoProvider from message context properties in Wss4jInInterceptor
> -----------------------------------------------------------------------------------
>
> Key: CXF-4049
> URL: https://issues.apache.org/jira/browse/CXF-4049
> Project: CXF
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.5.1
> Environment: Windows
> Reporter: Andrei Shakirin
> Assignee: Colm O hEigeartaigh
> Fix For: 2.4.7, 2.5.3
>
> Attachments: WSS4JInInterceptor.patch, WSS4JInInterceptor.patch
>
>
> Hi,
> Just a small improvements in Wss4jInInterceptor.
> Normally CryptoProvider doesn't instantiated directly via CryptoFactory, but firstly tried to obtained from message context properties (SecurityConstants.ENCRYPT_CRYPTO, SecurityConstants.SIGNATURE_CRYPTO). And only if the properties are not set, CryptoProvider is instantiated via CryptoFactory. This gives the possibility to replace Merlin CryptoProvider to custom one (probably non keystore based).
> AbstractBindingBuilder, XmlSignHandler, SAMLUtils are working in this way.
> Unfortunatelly it is not the case for Wss4jInInterceptor. It doesn't initializes crypto provider in RequestData and crypto provider is always created via CryptoFactory. It makes impossible to use custom implementation of CryptoProvider in incoming chain.
> Patch is attached.
> Regards,
> Andrei.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4049) Check external CryptoProvider from
message context properties in Wss4jInInterceptor
Posted by "Andrei Shakirin (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrei Shakirin updated CXF-4049:
---------------------------------
Attachment: WSS4JInInterceptor.patch
Patch
> Check external CryptoProvider from message context properties in Wss4jInInterceptor
> -----------------------------------------------------------------------------------
>
> Key: CXF-4049
> URL: https://issues.apache.org/jira/browse/CXF-4049
> Project: CXF
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.5.1
> Environment: Windows
> Reporter: Andrei Shakirin
> Attachments: WSS4JInInterceptor.patch
>
>
> Hi,
> Just a small improvements in Wss4jInInterceptor.
> Normally CryptoProvider doesn't instantiated directly via CryptoFactory, but firstly tried to obtained from message context properties (SecurityConstants.ENCRYPT_CRYPTO, SecurityConstants.SIGNATURE_CRYPTO). And only if the properties are not set, CryptoProvider is instantiated via CryptoFactory. This gives the possibility to replace Merlin CryptoProvider to custom one (probably non keystore based).
> AbstractBindingBuilder, XmlSignHandler, SAMLUtils are working in this way.
> Unfortunatelly it is not the case for Wss4jInInterceptor. It doesn't initializes crypto provider in RequestData and crypto provider is always created via CryptoFactory. It makes impossible to use custom implementation of CryptoProvider in incoming chain.
> Patch is attached.
> Regards,
> Andrei.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4049) Check external CryptoProvider from
message context properties in Wss4jInInterceptor
Posted by "Andrei Shakirin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13192100#comment-13192100 ]
Andrei Shakirin commented on CXF-4049:
--------------------------------------
Hi Colm,
yep, I am agree with your patch.
Andrei.
> Check external CryptoProvider from message context properties in Wss4jInInterceptor
> -----------------------------------------------------------------------------------
>
> Key: CXF-4049
> URL: https://issues.apache.org/jira/browse/CXF-4049
> Project: CXF
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.5.1
> Environment: Windows
> Reporter: Andrei Shakirin
> Attachments: WSS4JInInterceptor.patch
>
>
> Hi,
> Just a small improvements in Wss4jInInterceptor.
> Normally CryptoProvider doesn't instantiated directly via CryptoFactory, but firstly tried to obtained from message context properties (SecurityConstants.ENCRYPT_CRYPTO, SecurityConstants.SIGNATURE_CRYPTO). And only if the properties are not set, CryptoProvider is instantiated via CryptoFactory. This gives the possibility to replace Merlin CryptoProvider to custom one (probably non keystore based).
> AbstractBindingBuilder, XmlSignHandler, SAMLUtils are working in this way.
> Unfortunatelly it is not the case for Wss4jInInterceptor. It doesn't initializes crypto provider in RequestData and crypto provider is always created via CryptoFactory. It makes impossible to use custom implementation of CryptoProvider in incoming chain.
> Patch is attached.
> Regards,
> Andrei.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4049) Check external CryptoProvider from
message context properties in Wss4jInInterceptor
Posted by "Andrei Shakirin (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrei Shakirin updated CXF-4049:
---------------------------------
Attachment: WSS4JInInterceptor.patch
Resubmitted with ASF
> Check external CryptoProvider from message context properties in Wss4jInInterceptor
> -----------------------------------------------------------------------------------
>
> Key: CXF-4049
> URL: https://issues.apache.org/jira/browse/CXF-4049
> Project: CXF
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.5.1
> Environment: Windows
> Reporter: Andrei Shakirin
> Assignee: Colm O hEigeartaigh
> Fix For: 2.4.7, 2.5.3
>
> Attachments: WSS4JInInterceptor.patch, WSS4JInInterceptor.patch
>
>
> Hi,
> Just a small improvements in Wss4jInInterceptor.
> Normally CryptoProvider doesn't instantiated directly via CryptoFactory, but firstly tried to obtained from message context properties (SecurityConstants.ENCRYPT_CRYPTO, SecurityConstants.SIGNATURE_CRYPTO). And only if the properties are not set, CryptoProvider is instantiated via CryptoFactory. This gives the possibility to replace Merlin CryptoProvider to custom one (probably non keystore based).
> AbstractBindingBuilder, XmlSignHandler, SAMLUtils are working in this way.
> Unfortunatelly it is not the case for Wss4jInInterceptor. It doesn't initializes crypto provider in RequestData and crypto provider is always created via CryptoFactory. It makes impossible to use custom implementation of CryptoProvider in incoming chain.
> Patch is attached.
> Regards,
> Andrei.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CXF-4049) Check external CryptoProvider from
message context properties in Wss4jInInterceptor
Posted by "Colm O hEigeartaigh (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh reassigned CXF-4049:
----------------------------------------
Assignee: Colm O hEigeartaigh
> Check external CryptoProvider from message context properties in Wss4jInInterceptor
> -----------------------------------------------------------------------------------
>
> Key: CXF-4049
> URL: https://issues.apache.org/jira/browse/CXF-4049
> Project: CXF
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.5.1
> Environment: Windows
> Reporter: Andrei Shakirin
> Assignee: Colm O hEigeartaigh
> Attachments: WSS4JInInterceptor.patch
>
>
> Hi,
> Just a small improvements in Wss4jInInterceptor.
> Normally CryptoProvider doesn't instantiated directly via CryptoFactory, but firstly tried to obtained from message context properties (SecurityConstants.ENCRYPT_CRYPTO, SecurityConstants.SIGNATURE_CRYPTO). And only if the properties are not set, CryptoProvider is instantiated via CryptoFactory. This gives the possibility to replace Merlin CryptoProvider to custom one (probably non keystore based).
> AbstractBindingBuilder, XmlSignHandler, SAMLUtils are working in this way.
> Unfortunatelly it is not the case for Wss4jInInterceptor. It doesn't initializes crypto provider in RequestData and crypto provider is always created via CryptoFactory. It makes impossible to use custom implementation of CryptoProvider in incoming chain.
> Patch is attached.
> Regards,
> Andrei.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CXF-4049) Check external
CryptoProvider from message context properties in Wss4jInInterceptor
Posted by "Andrei Shakirin (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13220824#comment-13220824 ]
Andrei Shakirin edited comment on CXF-4049 at 3/2/12 10:36 AM:
---------------------------------------------------------------
Hi Colm,
Probably not completely got your comment from 20/Jan/12.
If I move this functionality to "Wss4jInInterceptor.computeAction()", PolicyBasedWss4JInInterceptor will override with method and custom crypto provider will not be activated. Or did you mean "PolicyBasedWss4JInInterceptor.computeAction()"? Also not sure that computeAction() is the right place for checking custom crypto provider.
But as far as you already fixed this problem by [CXF-4034|https://issues.apache.org/jira/browse/CXF-4034] in "PolicyBasedWss4JInInterceptor.checkAsymmetricBinding()", it doesn't matter.
Andrei.
was (Author: ashakirin):
Hi Colm,
Probably not completely got your comment from 20/Jan/12.
If I move this functionality to "Wss4jInInterceptor.computeAction()", PolicyBasedWss4JInInterceptor will override with method and custom crypto provider will not be activated. Or did you mean "PolicyBasedWss4JInInterceptor.computeAction()"? Also not sure that computeAction() is the right place for checking custom crypto provider.
But as far as you already fixed this problem by [CXF-4034|https://issues.apache.org/jira/browse/CXF-4034] in "PolicyBasedWss4JInInterceptor.checkAsymmetricBinding()", it doesn't matter.
> Check external CryptoProvider from message context properties in Wss4jInInterceptor
> -----------------------------------------------------------------------------------
>
> Key: CXF-4049
> URL: https://issues.apache.org/jira/browse/CXF-4049
> Project: CXF
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.5.1
> Environment: Windows
> Reporter: Andrei Shakirin
> Assignee: Colm O hEigeartaigh
> Fix For: 2.4.7, 2.5.3
>
> Attachments: WSS4JInInterceptor.patch, WSS4JInInterceptor.patch
>
>
> Hi,
> Just a small improvements in Wss4jInInterceptor.
> Normally CryptoProvider doesn't instantiated directly via CryptoFactory, but firstly tried to obtained from message context properties (SecurityConstants.ENCRYPT_CRYPTO, SecurityConstants.SIGNATURE_CRYPTO). And only if the properties are not set, CryptoProvider is instantiated via CryptoFactory. This gives the possibility to replace Merlin CryptoProvider to custom one (probably non keystore based).
> AbstractBindingBuilder, XmlSignHandler, SAMLUtils are working in this way.
> Unfortunatelly it is not the case for Wss4jInInterceptor. It doesn't initializes crypto provider in RequestData and crypto provider is always created via CryptoFactory. It makes impossible to use custom implementation of CryptoProvider in incoming chain.
> Patch is attached.
> Regards,
> Andrei.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4049) Check external CryptoProvider from
message context properties in Wss4jInInterceptor
Posted by "Colm O hEigeartaigh (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh resolved CXF-4049.
--------------------------------------
Resolution: Fixed
> Check external CryptoProvider from message context properties in Wss4jInInterceptor
> -----------------------------------------------------------------------------------
>
> Key: CXF-4049
> URL: https://issues.apache.org/jira/browse/CXF-4049
> Project: CXF
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.5.1
> Environment: Windows
> Reporter: Andrei Shakirin
> Assignee: Colm O hEigeartaigh
> Fix For: 2.4.7, 2.5.3
>
> Attachments: WSS4JInInterceptor.patch, WSS4JInInterceptor.patch
>
>
> Hi,
> Just a small improvements in Wss4jInInterceptor.
> Normally CryptoProvider doesn't instantiated directly via CryptoFactory, but firstly tried to obtained from message context properties (SecurityConstants.ENCRYPT_CRYPTO, SecurityConstants.SIGNATURE_CRYPTO). And only if the properties are not set, CryptoProvider is instantiated via CryptoFactory. This gives the possibility to replace Merlin CryptoProvider to custom one (probably non keystore based).
> AbstractBindingBuilder, XmlSignHandler, SAMLUtils are working in this way.
> Unfortunatelly it is not the case for Wss4jInInterceptor. It doesn't initializes crypto provider in RequestData and crypto provider is always created via CryptoFactory. It makes impossible to use custom implementation of CryptoProvider in incoming chain.
> Patch is attached.
> Regards,
> Andrei.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4049) Check external CryptoProvider from
message context properties in Wss4jInInterceptor
Posted by "Colm O hEigeartaigh (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189835#comment-13189835 ]
Colm O hEigeartaigh commented on CXF-4049:
------------------------------------------
Hi Andrei,
I would be ok with this patch if you moved the functionality into the protected "computeAction" method instead. That way it doesn't override the PolicyBasedWSS4JInInterceptor. A patch for the latter is available on CXF-4034 for this issue.
Colm.
> Check external CryptoProvider from message context properties in Wss4jInInterceptor
> -----------------------------------------------------------------------------------
>
> Key: CXF-4049
> URL: https://issues.apache.org/jira/browse/CXF-4049
> Project: CXF
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.5.1
> Environment: Windows
> Reporter: Andrei Shakirin
> Attachments: WSS4JInInterceptor.patch
>
>
> Hi,
> Just a small improvements in Wss4jInInterceptor.
> Normally CryptoProvider doesn't instantiated directly via CryptoFactory, but firstly tried to obtained from message context properties (SecurityConstants.ENCRYPT_CRYPTO, SecurityConstants.SIGNATURE_CRYPTO). And only if the properties are not set, CryptoProvider is instantiated via CryptoFactory. This gives the possibility to replace Merlin CryptoProvider to custom one (probably non keystore based).
> AbstractBindingBuilder, XmlSignHandler, SAMLUtils are working in this way.
> Unfortunatelly it is not the case for Wss4jInInterceptor. It doesn't initializes crypto provider in RequestData and crypto provider is always created via CryptoFactory. It makes impossible to use custom implementation of CryptoProvider in incoming chain.
> Patch is attached.
> Regards,
> Andrei.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira