Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-02-26 Thread via GitHub


ffang merged PR #1660:
URL: https://github.com/apache/cxf/pull/1660


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-02-13 Thread via GitHub


JiriOndrusek commented on code in PR #1660:
URL: https://github.com/apache/cxf/pull/1660#discussion_r1488072808


##
rt/ws/security/src/main/java/org/apache/cxf/ws/security/policy/custom/DefaultAlgorithmSuiteLoader.java:
##
@@ -140,9 +164,116 @@ protected void parseCustomAssertion(Assertion assertion) {
 } else if ("Basic256GCM".equals(assertionName)) {
 
setAlgorithmSuiteType(ALGORITHM_SUITE_TYPES.get("Basic256GCM"));
 getAlgorithmSuiteType().setNamespace(assertionNamespace);
+} else if ("CustomizedAlgorithmSuite".equals(assertionName)) {
+
setAlgorithmSuiteType(ALGORITHM_SUITE_TYPES.get("CustomizedAlgorithmSuite"));
+getAlgorithmSuiteType().setNamespace(assertionNamespace);
 }
 }
 }
 
 
+public static AlgorithmSuite.AlgorithmSuiteType 
customize(AlgorithmSuite.AlgorithmSuiteType suiteType,
+  Message message) 
{
+
+Map values = message.getContextualPropertyKeys()
+.stream()
+.filter(k -> 
k.startsWith(SecurityConstants.CUSTOM_ALG_SUITE_PREFIX))
+.collect(Collectors.toMap(Function.identity(), k -> 
message.getContextualProperty(k)));
+
+return customize(suiteType, values);
+
+}
+
+public static AlgorithmSuite.AlgorithmSuiteType 
customize(AlgorithmSuite.AlgorithmSuiteType suiteType,
+  Map values) {
+
+//customization happens only for CustomizedAlgorithmSuite
+if (suiteType != null && 
!"CustomizedAlgorithmSuite".equals(suiteType.getName())) {
+return suiteType;
+}
+
+
+AlgorithmSuite.AlgorithmSuiteType retVal = suiteType != null ? 
suiteType
+: new AlgorithmSuite.AlgorithmSuiteType(null, null, null, null,
+null, null, null,

Review Comment:
   fixed



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-02-13 Thread via GitHub


ffang commented on PR #1660:
URL: https://github.com/apache/cxf/pull/1660#issuecomment-1941778643

   > @ffang I removed the null AlgorithmSuiteType from the suite loader.
   
   Thanks @JiriOndrusek !


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-02-13 Thread via GitHub


ffang commented on code in PR #1660:
URL: https://github.com/apache/cxf/pull/1660#discussion_r1480553067


##
rt/ws/security/src/main/java/org/apache/cxf/ws/security/policy/custom/DefaultAlgorithmSuiteLoader.java:
##
@@ -140,9 +164,116 @@ protected void parseCustomAssertion(Assertion assertion) {
 } else if ("Basic256GCM".equals(assertionName)) {
 
setAlgorithmSuiteType(ALGORITHM_SUITE_TYPES.get("Basic256GCM"));
 getAlgorithmSuiteType().setNamespace(assertionNamespace);
+} else if ("CustomizedAlgorithmSuite".equals(assertionName)) {
+
setAlgorithmSuiteType(ALGORITHM_SUITE_TYPES.get("CustomizedAlgorithmSuite"));
+getAlgorithmSuiteType().setNamespace(assertionNamespace);
 }
 }
 }
 
 
+public static AlgorithmSuite.AlgorithmSuiteType 
customize(AlgorithmSuite.AlgorithmSuiteType suiteType,
+  Message message) 
{
+
+Map values = message.getContextualPropertyKeys()
+.stream()
+.filter(k -> 
k.startsWith(SecurityConstants.CUSTOM_ALG_SUITE_PREFIX))
+.collect(Collectors.toMap(Function.identity(), k -> 
message.getContextualProperty(k)));
+
+return customize(suiteType, values);
+
+}
+
+public static AlgorithmSuite.AlgorithmSuiteType 
customize(AlgorithmSuite.AlgorithmSuiteType suiteType,
+  Map values) {
+
+//customization happens only for CustomizedAlgorithmSuite
+if (suiteType != null && 
!"CustomizedAlgorithmSuite".equals(suiteType.getName())) {
+return suiteType;
+}
+
+
+AlgorithmSuite.AlgorithmSuiteType retVal = suiteType != null ? 
suiteType
+: new AlgorithmSuite.AlgorithmSuiteType(null, null, null, null,
+null, null, null,

Review Comment:
   Hi @JiriOndrusek ,
   
   I believe here the AlgorithmSuiteType name shouldn't be null anyway.
   Actually I think if the original suiteType is null, we shouldn't create a 
new one and customize it, we should just skip the customization.
   
   Freeman
   



##
systests/ws-security/src/test/resources/wsdl_systest_wssec/wssec10/WsSecurity10_policy_customizedAlgorithmSuite.wsdl:
##
@@ -0,0 +1,178 @@
+
+
+http://schemas.xmlsoap.org/wsdl/; 
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/; 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;
 xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/; 
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata; 
xmlns:tns="http://apache.cxf.org/; 
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing; 
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy; 
xmlns:wssec10test="http://WSSec/wssec10; 
xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema; 
xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl; 
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/; 
xmlns:wsa10="http://www.w3.org/2005/08/addressing; 
xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex; 
targetNamespace="http://apache.cxf.org/;>
+
+
+
+http://schemas.xmlsoap.org/ws/2005/07/securitypolicy;>
+
+
+
+http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient;>
+
+
+
+
+
+
+
+
+http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never;>
+
+
+
+
+
+
+
+
+

Review Comment:
   Hi @JiriOndrusek ,
   
   Though I believe technically it's doable,  like in the 
org.apache.cxf.ws.security.policy.custom.AlgorithmSuiteBuilder constructor you 
can get nestedPolicyElement which is a DOM element
   ```
   final Element nestedPolicyElement = 
SPUtils.getFirstPolicyChildElement(element);
   ```
   So you can get all child element from this point actually.
   
   However, I'm hesitant to do it because this behaviour isn't aligned with 
current properties implementations used in WSS4J and CXF. You can find more 
discussion in 
   https://issues.apache.org/jira/browse/CXF-8971
   
   Best Regards
   Freeman



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on 

Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-02-13 Thread via GitHub


JiriOndrusek commented on PR #1660:
URL: https://github.com/apache/cxf/pull/1660#issuecomment-1941774951

   @ffang I removed the null AlgorithmSuiteType from the suite loader.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-02-13 Thread via GitHub


JiriOndrusek commented on code in PR #1660:
URL: https://github.com/apache/cxf/pull/1660#discussion_r1488064493


##
rt/ws/security/src/main/java/org/apache/cxf/ws/security/policy/custom/DefaultAlgorithmSuiteLoader.java:
##
@@ -53,6 +59,8 @@ public AlgorithmSuite getAlgorithmSuite(Bus bus, 
SPConstants.SPVersion version,
 assertions.put(qName, new PrimitiveAssertion(qName));
 qName = new QName(ns, "Basic256GCM");
 assertions.put(qName, new PrimitiveAssertion(qName));
+qName = new QName(ns, "CustomizedAlgorithmSuite");

Review Comment:
   renamed



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-02-13 Thread via GitHub


JiriOndrusek commented on PR #1660:
URL: https://github.com/apache/cxf/pull/1660#issuecomment-1941354036

   PR requires update of **wss4j** to **3.0.3** before merging


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-02-07 Thread via GitHub


JiriOndrusek commented on code in PR #1660:
URL: https://github.com/apache/cxf/pull/1660#discussion_r1481431210


##
systests/ws-security/src/test/resources/wsdl_systest_wssec/wssec10/WsSecurity10_policy_customizedAlgorithmSuite.wsdl:
##
@@ -0,0 +1,178 @@
+
+
+http://schemas.xmlsoap.org/wsdl/; 
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/; 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;
 xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/; 
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata; 
xmlns:tns="http://apache.cxf.org/; 
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing; 
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy; 
xmlns:wssec10test="http://WSSec/wssec10; 
xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema; 
xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl; 
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/; 
xmlns:wsa10="http://www.w3.org/2005/08/addressing; 
xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex; 
targetNamespace="http://apache.cxf.org/;>
+
+
+
+http://schemas.xmlsoap.org/ws/2005/07/securitypolicy;>
+
+
+
+http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient;>
+
+
+
+
+
+
+
+
+http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never;>
+
+
+
+
+
+
+
+
+

Review Comment:
   WDYT @ffang ^^ (I thing that the information would benefit to all. On the 
other hand similar features in cxf are not exposing the details either),  
   



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-02-07 Thread via GitHub


JiriOndrusek commented on code in PR #1660:
URL: https://github.com/apache/cxf/pull/1660#discussion_r1481427972


##
rt/ws/security/src/main/java/org/apache/cxf/ws/security/policy/custom/DefaultAlgorithmSuiteLoader.java:
##
@@ -53,6 +59,8 @@ public AlgorithmSuite getAlgorithmSuite(Bus bus, 
SPConstants.SPVersion version,
 assertions.put(qName, new PrimitiveAssertion(qName));
 qName = new QName(ns, "Basic256GCM");
 assertions.put(qName, new PrimitiveAssertion(qName));
+qName = new QName(ns, "CustomizedAlgorithmSuite");

Review Comment:
   I agree



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-02-07 Thread via GitHub


ppalaga commented on code in PR #1660:
URL: https://github.com/apache/cxf/pull/1660#discussion_r1481121130


##
rt/ws/security/src/main/java/org/apache/cxf/ws/security/policy/custom/DefaultAlgorithmSuiteLoader.java:
##
@@ -53,6 +59,8 @@ public AlgorithmSuite getAlgorithmSuite(Bus bus, 
SPConstants.SPVersion version,
 assertions.put(qName, new PrimitiveAssertion(qName));
 qName = new QName(ns, "Basic256GCM");
 assertions.put(qName, new PrimitiveAssertion(qName));
+qName = new QName(ns, "CustomizedAlgorithmSuite");

Review Comment:
   Could we perhaps change the name (here and elsewhere) to 
`CustomAlgorithmSuite`? It is shorter and has the same meaning. 



##
systests/ws-security/src/test/resources/wsdl_systest_wssec/wssec10/WsSecurity10_policy_customizedAlgorithmSuite.wsdl:
##
@@ -0,0 +1,178 @@
+
+
+http://schemas.xmlsoap.org/wsdl/; 
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/; 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;
 xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/; 
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata; 
xmlns:tns="http://apache.cxf.org/; 
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing; 
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy; 
xmlns:wssec10test="http://WSSec/wssec10; 
xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema; 
xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl; 
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/; 
xmlns:wsa10="http://www.w3.org/2005/08/addressing; 
xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex; 
targetNamespace="http://apache.cxf.org/;>
+
+
+
+http://schemas.xmlsoap.org/ws/2005/07/securitypolicy;>
+
+
+
+http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient;>
+
+
+
+
+
+
+
+
+http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never;>
+
+
+
+
+
+
+
+
+

Review Comment:
   So this PR does not implement exposing the details of the 
CustomAlgorithmSuite in the policy, right? Would it be doable?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-02-02 Thread via GitHub


ffang commented on PR #1660:
URL: https://github.com/apache/cxf/pull/1660#issuecomment-1923890930

   > @ffang is current failure related to the PR? I don't see any failed test. 
I'd say that some threads are hanging during the tests. Yesterday CI execution 
showed 1 failure because of NPE, which is fixed in the current PR.
   
   Hi @JiriOndrusek ,
   
   No, I don't think they are related.
   
   Freeman


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-02-02 Thread via GitHub


JiriOndrusek commented on PR #1660:
URL: https://github.com/apache/cxf/pull/1660#issuecomment-1923750354

   @ffang is current failure related to the PR? I don't see any failed test. 
I'd say that some threads are hanging during the tests. Yesterday CI execution 
showed 1 failure because of NPE, which is fixed in the current PR.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-02-01 Thread via GitHub


JiriOndrusek commented on PR #1660:
URL: https://github.com/apache/cxf/pull/1660#issuecomment-1921487670

   I just verified FIPS compliance by running test 
`WSSecurity10CustomizedAlgorithmSuiteTest` (by execution of  `mvn clean test -f 
systests/ws-security -Dtest=WSSecurity10CustomizedAlgorithmSuiteTest 
-Dorg.apache.xml.security.securerandom.algorithm=PKCS11`)
   
   Scenarion 03 and 04 failed with `no such algorithm`  (as expected), because 
those 2 tests customizes algSuite of the server to be the same as Basic256 - 
which does not work on FIPS
   
   Scenario 01 succeeds - default `CustomizedAlgorithmSuite` works on FIPS.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-02-01 Thread via GitHub


JiriOndrusek commented on PR #1660:
URL: https://github.com/apache/cxf/pull/1660#issuecomment-1921459299

   I harcoded the version of  to 3.0.3-SNAPSHOT to 
get https://issues.apache.org/jira/browse/WSS-709
   
   PR requires update of wss4f to 3.0.3 before merging


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-02-01 Thread via GitHub


JiriOndrusek commented on PR #1660:
URL: https://github.com/apache/cxf/pull/1660#issuecomment-1921423123

   @ffang Thanks for the help. The PR is currently prepared to be merged.
   
   Here is a small summary:
   
   - New algSuite `CustomizedAlgorithmSuite` is registered in 
`DefaultAlgorithmSuiteLoader` with default values allowed in FIPS environment
   - It is possible to change values of this suite by configuring properties 
starting with `ws-security.custom.alg.suite.`
   - Test `WSSecurity10CustomerizedAlgorithmSuiteTest` is verifying scenarios 
where the customization parameters are used correnctly and incorrectly (for 
both stax and non-stax server)
   - Test `CustomizedAlgorithmLoaderTest` is covering the basic customization 
method, which changes the values based on security properties. Test covers 
corner cases and validates, that all parameters are used.
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-01-31 Thread via GitHub


ffang commented on PR #1660:
URL: https://github.com/apache/cxf/pull/1660#issuecomment-1919507106

   > Hi @ffang ,
   > 
   > I continued with the work on this feature. Work is almost done, I'm stuck 
on a following problem:
   > 
   > When I try to customize the alg. suite for he stax server, wss4j is 
validating the runtime usage of algorithms with assertions. Runtime is using 
customized values, assertion contains the default values. Solution is simple, 
the assertion has to be customized as well. (I did the same for the non-stax 
case) Unfortunately I can not find a correct way of changing such parameter.
   > 
   > If you look into this line -
   > 
   > 
https://github.com/apache/cxf/blob/1bf24e1193c0decffcc3b34328b1c41a035201fe/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/PolicyBasedWSS4JStaxInInterceptor.java#L436
   > 
   > You can see `operationPolicies`, this variable is containing the assertion 
values and it seems, that it is the unserialized policy.xml. If I can access 
the AlgorithSuiteType, I can customize it by one line.
   > 
   > Do you have an idea, how to access this reference?
   > 
   > I'm adding a screenshot of the first policyComponent from my test 
`WSSecurity10CustomizedAlgorithmSuiteTest` 
![image](https://private-user-images.githubusercontent.com/26897889/301185722-35bcf95a-46f0-4be7-9ef6-b55a29295947.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MDY3MTAxMzYsIm5iZiI6MTcwNjcwOTgzNiwicGF0aCI6Ii8yNjg5Nzg4OS8zMDExODU3MjItMzViY2Y5NWEtNDZmMC00YmU3LTllZjYtYjU1YTI5Mjk1OTQ3LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDAxMzElMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwMTMxVDE0MDM1NlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWQxYzM4OTQwZTgwZmJiZDI1MjgxN2Y1ZjMxYzExMWI5Nzc0MmQ2YjkzYmRhYzkwNDIzNTg5NmNiYmVlMmRhMTImWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.WKkMVGIJdndrTuN5si2sHKFq8hTuENHe-CQk-W1Lojk)
   
   Hi @JiriOndrusek ,
   
   Please see my comment here
   
https://github.com/apache/cxf/commit/83720f669acc3c0b6d59d781531fb025ce1c554a#r138127443
   This can fix the broken test.
   
   Also I have other comments in the PR.
   
   Thanks!
   Freeman


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-01-31 Thread via GitHub


JiriOndrusek commented on PR #1660:
URL: https://github.com/apache/cxf/pull/1660#issuecomment-1919158378

   Hi @ffang ,
   
   I continued with the work on this feature.  Work is almost done, I'm stuck 
on a following problem:
   
   When I try to customize the alg. suite for he stax server, wss4j is 
validating the runtime usage of algorithms with assertions. Runtime is using 
customized values, assertion contains the default values.
   Solution is simple, the assertion has to be customized as well. (I did the 
same for the non-stax case)
   Unfortunately I can not find a correct way of changing such parameter. 
   
   If you look into this line - 
https://github.com/apache/cxf/blob/1bf24e1193c0decffcc3b34328b1c41a035201fe/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/PolicyBasedWSS4JStaxInInterceptor.java#L436
   You can see `operationPolicies`, this variable is containing the assertion 
values and it seems, that it is the unserialized policy.xml. If I can access 
the AlgorithSuiteType, I can customize it by one line.
   
   Do you have an idea, how to access this reference?
   
   I'm adding a screenshot of the first policyComponent from my test 
`WSSecurity10CustomizedAlgorithmSuiteTest`
   
![image](https://github.com/apache/cxf/assets/26897889/35bcf95a-46f0-4be7-9ef6-b55a29295947)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-01-25 Thread via GitHub


ffang commented on PR #1660:
URL: https://github.com/apache/cxf/pull/1660#issuecomment-1911011441

   Thanks for the PR @JiriOndrusek !
   
   FYI, just created
   https://issues.apache.org/jira/browse/WSS-709
   to add more setters for AlgorithmSuite$AlgorithmSuiteType so that the 
customizedPolicy tag is configurable


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-01-24 Thread via GitHub


JiriOndrusek commented on PR #1660:
URL: https://github.com/apache/cxf/pull/1660#issuecomment-1908114962

   @ffang FYI ^


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-01-24 Thread via GitHub


JiriOndrusek opened a new pull request, #1660:
URL: https://github.com/apache/cxf/pull/1660

   This draft introduces CustomerizedAlgorithmSuite according to 
https://issues.apache.org/jira/browse/CXF-8971
   
   Several pieces of code might need claricfication/discussion.
   
   **commit 1**
   
   Commit 1 works on its own (could be merged separately - it is finished).
   
   - New default algorithm suite (name `CustomerizedAlgorithmSuite`) is 
registered in `DefaultAlgorithmSuiteLoader`. Default values of this suites are 
compliant with the FIPS.
   - New test `WSSecurity10CustomerizedAlgorithmSuiteTest` (based on 
`WSSecurity10Test`) is introduced. This test can be successfully run on the 
machine with FIPS. (Parameter 
`-Dorg.apache.xml.security.securerandom.algorithm=PKCS1` is required in such 
case)
   - New certificates are required to fulfill FIPS. I added a script 
`generate-certs.sh', which could be used for its generation.
   
   **commit 2**
   
   - Security properties for customization of the alg suite are created (prefix 
`ws-security.custom.alg.suite .`)
   - Those properties are used in `AlgorithmSuiteTranslater` and  
`PolicyBasedWSS4JOutInterceptor` to modify customize alg. suite.
   
   ### Problems
   
   1. It is not  possible to set properties via setters into algSuiteType (see 
missing setters in 
https://github.com/apache/ws-wss4j/blob/wss4j-3.0.1/policy/src/main/java/org/apache/wss4j/policy/model/AlgorithmSuite.java#L434-L440)
 and commit 
(https://github.com/apache/ws-wss4j/commit/2a5dff9ebb0b7b809cc3d4c75139b9b7e20604ce).
 Which means, that the customization on e.g. `PolicyBasedWSS4JOutInterceptor` 
can not change much. We would need to add setters to make customization work 
(as is prepared in this PR)
   
   ### Questions and suggestions (about commit 2)
   
   1.  Would it make sense to merge commit 1 on its own?  (From my POV it makes 
sense, because it would make configuration in FIPS possible)
   2. There are 2 security parameters already present 
(`ws-security.symmetric.signature.algorithm` and 
`ws-security.asymmetric.signature.algorithm`). My understanding is, that their 
functionality is almost the same as is defined for customized alg. suite. 
Therefore it would make sense, to skip 
`ws-security.custom.alg.suite.asymmetric.key.encryption.algorithm` and 
`ws-security.custom.alg.suite.symmetric.key.encryption.algorithm`
   3. I think that it is not needed to call `CustomerizedAlgorithmSuite` in 
that way. I would like to call the suite something like 
`FipsBasic256Sha256gcmRsa15` or perhaps `FipsBasic256` - this name would show 
the intent, that the default values are FIPS compliant **AND** the 
customization mechanism would be used every-time (not just for 
customerizedAlgorithmSuite) -> which means that user could not "customize" but 
rather "set" algorithm via properties, if not specified, the alg. suite defined 
in the policy would be used as now. (which is the behavior of 
`ws-security.symmetric.signature.algorithm` and 
`ws-security.asymmetric.signature.algorithm` currently)
   
   
   
   ### TODO
   
   1. After answering the questions, the customization should be probably added 
into `PolicyBasedWSS4JStaxInInterceptor`, `StaxAsymmetricBindingHandler`, 
`StaxSymmetricBindingHandler` and `StaxTransportBindingHandler` as well.
   2. Ideally add a test covering the customized alg suite.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: Introduction

2017-11-16 Thread Andriy Redko
Hi Andrei,

Welcome! Thanks a lot for joining, your contributions 
are very valueable and much appreciated! 

Best Regards,
   Andriy Redko 

AI> Hi,
AI> As requested by Sergey Beryozkin, I'm sending this email to introduce
AI> myself :-)

AI> I'm a Java developer (though in the last year I've been derailed to ext.js
AI> and Python), from Romania, and CXF user and fan.

AI> I also like to keep an eye on the development progress on some of the
AI> frameworks I use (like CXF, Spring or Hibernate), as I find it valuable to
AI> see if there are any bugs that could affect me and also to see how various
AI> features are implemented by people smarter than me :-)
AI> That implies looking at GIT changes and I like to comment if happen to
AI> notice something weird, which triggered the attention of Sergey.

AI> Unfortunately, I rarely have the time to contribute more to the frameworks
AI> I use, in the form of code changes.

AI> Regards,
AI> Andrei



Re: Introduction

2017-11-16 Thread Sergey Beryozkin

Hi Andrei

Thank you for the introduction and welcome :-)

Please keep your review comments coming, very much appreciated

Cheers, Sergey
On 16/11/17 11:17, Andrei Ivanov wrote:

Hi,
As requested by Sergey Beryozkin, I'm sending this email to introduce
myself :-)

I'm a Java developer (though in the last year I've been derailed to ext.js
and Python), from Romania, and CXF user and fan.

I also like to keep an eye on the development progress on some of the
frameworks I use (like CXF, Spring or Hibernate), as I find it valuable to
see if there are any bugs that could affect me and also to see how various
features are implemented by people smarter than me :-)
That implies looking at GIT changes and I like to comment if happen to
notice something weird, which triggered the attention of Sergey.

Unfortunately, I rarely have the time to contribute more to the frameworks
I use, in the form of code changes.

Regards,
Andrei



Introduction

2017-11-16 Thread Andrei Ivanov
Hi,
As requested by Sergey Beryozkin, I'm sending this email to introduce
myself :-)

I'm a Java developer (though in the last year I've been derailed to ext.js
and Python), from Romania, and CXF user and fan.

I also like to keep an eye on the development progress on some of the
frameworks I use (like CXF, Spring or Hibernate), as I find it valuable to
see if there are any bugs that could affect me and also to see how various
features are implemented by people smarter than me :-)
That implies looking at GIT changes and I like to comment if happen to
notice something weird, which triggered the attention of Sergey.

Unfortunately, I rarely have the time to contribute more to the frameworks
I use, in the form of code changes.

Regards,
Andrei


Re: Introduction

2016-08-17 Thread Sergey Beryozkin

On 17/08/16 17:32, Andy McCright wrote:

Sure, please do. FYI, in CXF 3.1.7 we have JAX-RS

MessageBodyReader/Writer cache supported something that Neal Hu and myself
worked upon. MediaType cache has also been implemented earlier (with thanks
to Alessio).

Interesting - that is where we have found the most success as well.  In
3.0.3 and 3.0.9, we found a lot of time was spent determining the
appropriate MBR/MBW for a given request/response.  I'll take a look at
those changes to see if they could be ported back to the the 3.0.X stream.

Rookie question, but what is the major difference between the 3.0.X stream
and 3.1.X stream?  Does 3.1.X require Java 8 (or higher)?

3.0.x supports Java 6+, 3.1.x - Java 7+, master (3.2.0-SNAPSHOT) - Java 8+

Cheers, Sergey



Thanks,
Andy

On Wed, Aug 17, 2016 at 10:48 AM, Sergey Beryozkin 
wrote:


Hi Andy

Welcome, thanks for the introductions, some comments below
On 17/08/16 15:56, Andy McCright wrote:


Hi All,

I wanted to introduce myself.  My name is Andy McCright and I'll be taking
over Iris Deng's role as IBM's advocate for CXF and JAX-RS.



Please pass our thanks to Iris, who is still a CXF committer :-)

I'm planning

to join the JSR 370 expert group as well.

Will be good, the group does need new people joining, we already have

Alessio Soldano representing our friends from RedHat (RestEasy) there
joining recently too.

My background has been mainly in WebSphere development.  I've worked on few

different areas including the kernel/bootstrap/OSGi implementation, the
classloading mechanism, trace and logging, the EJB container, etc.  I've
taken over the JAX-RS role due to some recent reorganizations.

So far, my only involvement with CXF has been internal to IBM.  We've been
tweaking a few things in our WebSphere Liberty implementation.  Our main
concern lately has been in the area of performance.  We've seen about a
20%
degradation of performance when taking a very simple JAX-RS 1.1-compliant
app (running with the Apache Wink implementation) and running it on CXF
3.0.3 - using Liberty's jaxrs-2.0 feature.  I know this is not an
"apples-to-apples" comparison, and I suspect that much of the difference
is
time spent on function specific to JAX-RS 2.0.  That said, we have also
seen another ~10% drop in performance from 3.0.3 to 3.0.9.

I am hoping to contribute some performance fixes to the community in the
near future.  I am still pretty new to this code base, so I'll be asking
for some help with code reviews and suggestions, etc.

Sure, please do. FYI, in CXF 3.1.7 we have JAX-RS

MessageBodyReader/Writer cache supported something that Neal Hu and myself
worked upon. MediaType cache has also been implemented earlier (with thanks
to Alessio).
I believe one of your colleagues opened an issue earlier related to a CXF
Bus synchronization issue and said they'd evaluate a fix.


Looking forward to working with you,




Looking forward to working with you too

Sergey



Andy









--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/


Re: Introduction

2016-08-17 Thread Andy McCright
> Sure, please do. FYI, in CXF 3.1.7 we have JAX-RS
MessageBodyReader/Writer cache supported something that Neal Hu and myself
worked upon. MediaType cache has also been implemented earlier (with thanks
to Alessio).

Interesting - that is where we have found the most success as well.  In
3.0.3 and 3.0.9, we found a lot of time was spent determining the
appropriate MBR/MBW for a given request/response.  I'll take a look at
those changes to see if they could be ported back to the the 3.0.X stream.

Rookie question, but what is the major difference between the 3.0.X stream
and 3.1.X stream?  Does 3.1.X require Java 8 (or higher)?

Thanks,
Andy

On Wed, Aug 17, 2016 at 10:48 AM, Sergey Beryozkin 
wrote:

> Hi Andy
>
> Welcome, thanks for the introductions, some comments below
> On 17/08/16 15:56, Andy McCright wrote:
>
>> Hi All,
>>
>> I wanted to introduce myself.  My name is Andy McCright and I'll be taking
>> over Iris Deng's role as IBM's advocate for CXF and JAX-RS.
>>
>
> Please pass our thanks to Iris, who is still a CXF committer :-)
>
> I'm planning
>> to join the JSR 370 expert group as well.
>>
>> Will be good, the group does need new people joining, we already have
> Alessio Soldano representing our friends from RedHat (RestEasy) there
> joining recently too.
>
> My background has been mainly in WebSphere development.  I've worked on few
>> different areas including the kernel/bootstrap/OSGi implementation, the
>> classloading mechanism, trace and logging, the EJB container, etc.  I've
>> taken over the JAX-RS role due to some recent reorganizations.
>>
>> So far, my only involvement with CXF has been internal to IBM.  We've been
>> tweaking a few things in our WebSphere Liberty implementation.  Our main
>> concern lately has been in the area of performance.  We've seen about a
>> 20%
>> degradation of performance when taking a very simple JAX-RS 1.1-compliant
>> app (running with the Apache Wink implementation) and running it on CXF
>> 3.0.3 - using Liberty's jaxrs-2.0 feature.  I know this is not an
>> "apples-to-apples" comparison, and I suspect that much of the difference
>> is
>> time spent on function specific to JAX-RS 2.0.  That said, we have also
>> seen another ~10% drop in performance from 3.0.3 to 3.0.9.
>>
>> I am hoping to contribute some performance fixes to the community in the
>> near future.  I am still pretty new to this code base, so I'll be asking
>> for some help with code reviews and suggestions, etc.
>>
>> Sure, please do. FYI, in CXF 3.1.7 we have JAX-RS
> MessageBodyReader/Writer cache supported something that Neal Hu and myself
> worked upon. MediaType cache has also been implemented earlier (with thanks
> to Alessio).
> I believe one of your colleagues opened an issue earlier related to a CXF
> Bus synchronization issue and said they'd evaluate a fix.
>
>
> Looking forward to working with you,
>>
>
> Looking forward to working with you too
>
> Sergey
>
>
>> Andy
>>
>>
>


Re: Introduction

2016-08-17 Thread Sergey Beryozkin

Hi Andy

Welcome, thanks for the introductions, some comments below
On 17/08/16 15:56, Andy McCright wrote:

Hi All,

I wanted to introduce myself.  My name is Andy McCright and I'll be taking
over Iris Deng's role as IBM's advocate for CXF and JAX-RS.


Please pass our thanks to Iris, who is still a CXF committer :-)


I'm planning
to join the JSR 370 expert group as well.

Will be good, the group does need new people joining, we already have 
Alessio Soldano representing our friends from RedHat (RestEasy) there 
joining recently too.



My background has been mainly in WebSphere development.  I've worked on few
different areas including the kernel/bootstrap/OSGi implementation, the
classloading mechanism, trace and logging, the EJB container, etc.  I've
taken over the JAX-RS role due to some recent reorganizations.

So far, my only involvement with CXF has been internal to IBM.  We've been
tweaking a few things in our WebSphere Liberty implementation.  Our main
concern lately has been in the area of performance.  We've seen about a 20%
degradation of performance when taking a very simple JAX-RS 1.1-compliant
app (running with the Apache Wink implementation) and running it on CXF
3.0.3 - using Liberty's jaxrs-2.0 feature.  I know this is not an
"apples-to-apples" comparison, and I suspect that much of the difference is
time spent on function specific to JAX-RS 2.0.  That said, we have also
seen another ~10% drop in performance from 3.0.3 to 3.0.9.

I am hoping to contribute some performance fixes to the community in the
near future.  I am still pretty new to this code base, so I'll be asking
for some help with code reviews and suggestions, etc.

Sure, please do. FYI, in CXF 3.1.7 we have JAX-RS 
MessageBodyReader/Writer cache supported something that Neal Hu and 
myself worked upon. MediaType cache has also been implemented earlier 
(with thanks to Alessio).
I believe one of your colleagues opened an issue earlier related to a 
CXF Bus synchronization issue and said they'd evaluate a fix.




Looking forward to working with you,


Looking forward to working with you too

Sergey



Andy





Introduction

2016-08-17 Thread Andy McCright
Hi All,

I wanted to introduce myself.  My name is Andy McCright and I'll be taking
over Iris Deng's role as IBM's advocate for CXF and JAX-RS.  I'm planning
to join the JSR 370 expert group as well.

My background has been mainly in WebSphere development.  I've worked on few
different areas including the kernel/bootstrap/OSGi implementation, the
classloading mechanism, trace and logging, the EJB container, etc.  I've
taken over the JAX-RS role due to some recent reorganizations.

So far, my only involvement with CXF has been internal to IBM.  We've been
tweaking a few things in our WebSphere Liberty implementation.  Our main
concern lately has been in the area of performance.  We've seen about a 20%
degradation of performance when taking a very simple JAX-RS 1.1-compliant
app (running with the Apache Wink implementation) and running it on CXF
3.0.3 - using Liberty's jaxrs-2.0 feature.  I know this is not an
"apples-to-apples" comparison, and I suspect that much of the difference is
time spent on function specific to JAX-RS 2.0.  That said, we have also
seen another ~10% drop in performance from 3.0.3 to 3.0.9.

I am hoping to contribute some performance fixes to the community in the
near future.  I am still pretty new to this code base, so I'll be asking
for some help with code reviews and suggestions, etc.

Looking forward to working with you,

Andy