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
