Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]
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]
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]
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]
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 messag
Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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
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
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
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
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
> 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
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
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