[
https://issues.apache.org/jira/browse/CXF-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808787#comment-17808787
]
Freeman Yue Fang edited comment on CXF-8971 at 1/19/24 7:53 PM:
----------------------------------------------------------------
Hi [~ppalaga],
We probably can introduce AlgorithmSuiteDefinition element as you suggested, I
just checked the ws-securitypolicy xsd schema, so AlgorithmSuite definition
there is very flexible, so technically we pretty much can add any thing under
AlgorithmSuite.
{code}
<xs:element name="AlgorithmSuite" type="tns:NestedPolicyType" >
<xs:annotation>
<xs:documentation xml:lang="en">
7.1 AlgorithmSuite Assertion
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name="NestedPolicyType">
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other"
processContents="lax"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax" />
</xs:complexType>
{code}
However, properties way are more align with current CXF implementation, please
take a look at CXF ws-securitypolicy document here
https://cxf.apache.org/docs/ws-securitypolicy.html
A lot of info is not defined in policy xml fragment but derived from properties
during runtime, we need to create Map<String, Object> as security context(used
by underlying WSS4J) for both client and server accordingly anyway when using
ws-security|ws-securitypolicy.
Currently, for all fields of AlgorithmSuite$AlgorithmSuiteType class
{code}
private String name;
private String digest;
private String encryption;
private String symmetricKeyWrap;
private String asymmetricKeyWrap;
private String encryptionKeyDerivation;
private String signatureKeyDerivation;
private int encryptionDerivedKeyLength;
private int signatureDerivedKeyLength;
private int minimumSymmetricKeyLength;
private int maximumSymmetricKeyLength;
private int minimumAsymmetricKeyLength;
private int maximumAsymmetricKeyLength;
private String mgfAlgo;
private String ns;
private String encryptionDigest;
private String symmetricSignature = SPConstants.HMAC_SHA1;
private String asymmetricSignature = SPConstants.RSA_SHA1;
{code}
Per CXF ws-securitypolicy doc
[here|https://cxf.apache.org/docs/ws-securitypolicy.html]
asymmetricSignature is configurable by property
ws-security.asymmetric.signature.algorithm
symmetricSignature is configurable by property
ws-security.symmetric.signature.algorithm. We better follow the similar way
here if we want other fields configurable as well in
AlgorithmSuite$AlgorithmSuiteType class
Freeman
was (Author: ffang):
Hi [~ppalaga],
We probably can introduce AlgorithmSuiteDefinition element as you suggested, I
just checked the ws-securitypolicy xsd schema, so AlgorithmSuite definition
there is very flexible, so technically we pretty much can add any thing under
AlgorithmSuite.
{code}
<xs:element name="AlgorithmSuite" type="tns:NestedPolicyType" >
<xs:annotation>
<xs:documentation xml:lang="en">
7.1 AlgorithmSuite Assertion
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name="NestedPolicyType">
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other"
processContents="lax"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax" />
</xs:complexType>
{code}
However, properties way are more align with current CXF implementation, please
take a look at CXF ws-securitypolicy document here
https://cxf.apache.org/docs/ws-securitypolicy.html
A lot of info is not defined in policy xml fragment but derived from properties
during runtime, we need to create Map<String, Object> as security context(used
by underlying WSS4J) for both client and server accordingly anyway when using
ws-security|ws-securitypolicy.
Freeman
> Introduce a customerizedAlgorithmSuite and make all parameters of it
> configurable
> ---------------------------------------------------------------------------------
>
> Key: CXF-8971
> URL: https://issues.apache.org/jira/browse/CXF-8971
> Project: CXF
> Issue Type: Improvement
> Reporter: Freeman Yue Fang
> Priority: Major
>
> In ws-securitypolicy, currently we have a list of AlgorithmSuite by name,
> some are defined in ws-securitypolicy, they are
> {code}
> Basic256
> Basic192
> Basic128
> TripleDes
> Basic256Rsa15
> Basic192Rsa15
> Basic128Rsa15
> TripleDesRsa15
> Basic256Sha256
> Basic192Sha256
> Basic128Sha256
> TripleDesSha256
> Basic256Sha256Rsa15
> Basic192Sha256Rsa15
> Basic128Sha256Rsa15
> TripleDesSha256Rsa15
> {code}
> And some are from CXF itself to address CVEs, they are
> {code}
> Basic128GCM
> Basic192GCM
> Basic256GCM
> {code}
> so if users specify a AlgorithmSuite name like
> {code}
> <sp:AlgorithmSuite>
> <wsp:Policy>
> <sp:Basic256Sha256Rsa15 />
> </wsp:Policy>
> </sp:AlgorithmSuite>
> {code}
> they will get a AlgorithmSuiteType instance of all parameters hardcoded with
> this AlgorithmSuite name.
> {code}
> new AlgorithmSuiteType(
> "Basic256Sha256Rsa15",
> SPConstants.SHA256,
> SPConstants.AES256,
> SPConstants.KW_AES256,
> SPConstants.KW_RSA15,
> SPConstants.P_SHA1_L256,
> SPConstants.P_SHA1_L192,
> 256, 192, 256,
> MAX_SKL, MIN_AKL, MAX_AKL)
> {code}
> However, security algorithms are evolving and some old-time algos may get
> cracked, or sometimes only some limited modern/strong security algorithms can
> be used in some scenarios, so current available AlgorithmSuiteType from both
> ws-securitypolicy or CXF may not meet the specific requirements.
> It would be great that we can introduce a fully configurable
> AlgorithmSuiteType which could be named as ,say, customerizedAlgorithmSuite
> which could have default values, but the parameters of AlgorithmSuiteType can
> be configured via endpoint(client or server) properties. This flexibility can
> offer us more convenience.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
