Hi Colm,
<<<
The other hand, I set "http://www.w3.org/2001/04/xmlenc#aes256-cbc"; as
"encryptionAlgorithm" on STS side, but it turns to "keyWrapAlgorithm" on
WSP side.
>>>
Please ignore above. The "keyWrapAlgorithm" on WSP side is "
http://www.w3.org/2001/04/xmlenc#kw-aes256"; which is obviously different
than "http://www.w3.org/2001/04/xmlenc#aes256-cbc";.
On both WSP and STS wsdl file, AlgorithmSuite is defined as "Basic256" like
bellow.
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
That's why value of algorithmSuite varialbe is as follow on WSP side(I got
it from debugging). This is set by
org.apache.cxf.ws.security.policy.model.AlgorithmSuite.java class. As I
mentioned before, asymmetricKeyWrap and symmetricKeyWrap never can be same.
*algorithmSuite* org.apache.cxf.ws.security.policy.model.AlgorithmSuite
(id=81)
algoSuiteString "Basic256" (id=113)
asymmetricKeyWrap
"http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p";(id=114)
asymmetricSignature "http://www.w3.org/2000/09/xmldsig#rsa-sha1";
(id=115)
c14n "http://www.w3.org/2001/10/xml-exc-c14n#"; (id=116)
computedKey "http://schemas.xmlsoap.org/ws/2005/02/sc/dk/p_sha1";
(id=117)
constants org.apache.cxf.ws.security.policy.SP12Constants
(id=118)
digest "http://www.w3.org/2000/09/xmldsig#sha1"; (id=121)
encryption "http://www.w3.org/2001/04/xmlenc#aes256-cbc"; (id=122)
encryptionDerivedKeyLength 256
encryptionKeyDerivation "
http://schemas.xmlsoap.org/ws/2005/02/sc/dk/p_sha1"; (id=117)
ignorable false
isOptional false
maximumAsymmetricKeyLength 4096
maximumSymmetricKeyLength 256
minimumAsymmetricKeyLength 1024
minimumSymmetricKeyLength 256
normalized false
signatureDerivedKeyLength 192
signatureKeyDerivation "
http://schemas.xmlsoap.org/ws/2005/02/sc/dk/p_sha1"; (id=117)
soapNormalization null
strTransform null
symmetricKeyWrap "http://www.w3.org/2001/04/xmlenc#kw-aes256";(id=123)
symmetricSignature "http://www.w3.org/2000/09/xmldsig#hmac-sha1";
(id=124)
xPath null
On Fri, Jul 20, 2012 at 6:49 PM, Gina Choi <[email protected]> wrote:
> Hi Colm,
>
>
> <<<<
> The first is that the "cxf-ut-encrypted" STS configuration shipped with
> Fediz does not in fact encrypt the issued token due to a missing
> configuration line. I've merged a fix for this here:
>
> http://svn.apache.org/viewvc?view=revision&revision=1363393
> >>>
> I have applied your fix now setting for "encProperties" in
> cxf-encrypted-ut.xml is reflected.
>
>
> <<<
> Secondly, the Symmetric holder-of-key use-case, where the symmetric key is
> encrypted with the certificate of the service provider, does not use the
> EncryptionProperties.
>>
>> getKeyWrapAlgorithm as you might expect, but always
>> uses the default RSA 1.5 algorithm. I've fixed this as well:
>>
>> https://issues.apache.org/jira/browse/CXF-4436
>> http://svn.apache.org/viewvc?view=revision&revision=1363394
>
> >>>>
> I have applied your fix.
>
>
> <<<
> I can't reproduce the decryption error you're seeing though. Could you
> upgrade your JDK to the latest 1.6.x and apply the unlimited security
> policies, and try again using the latest CXF SNAPSHOT code?
> >>>
> I installed jdk1.6.0_33. jdk1.6.0_33 package comes with unlimited security
> policies(local_policy.jar and US_export_policy.jar), but they didn't work.
> I was keeping getting "Caused by: java.security.InvalidKeyException:
> Illegal key size or default parameters", so I downloaded from
> http://www.oracle.com/technetwork/java/javase/downloads/index.html (for
> Java 6) and overwrote existing one to over come exception.
>
> on idp-sts side, I set following content on cxf-encrypted-ut.xml.
>
>
> <bean id="encProperties"
> class="org.apache.cxf.sts.service.EncryptionProperties">
> <property name="encryptionAlgorithm" value="
> http://www.w3.org/2001/04/xmlenc#aes256-cbc"; />
> <property name="keyWrapAlgorithm" value="
> http://www.w3.org/2001/04/xmlenc#rsa-1_5"; />
> </bean>
>
> With that same content, I ran client on both jdk1.6.0_24 and jdk1.6.0_33
> environment, but failed on WSP side with same reason. I repeated test
> several time. I ran all(WSC, WSP, STS) build on jdk1.6.0_24 and tested it.
> I also ran build on jdk1.6.0_33 and tested as well. In both cases, it is
> failed in
> org.apache.cxf.ws.security.wss4j.policyvalidators.AlgorithmSuitePolicyValidator.java(cfx-rt-ws-security-2.6.2-SNAPSOT.jar)
> at line 151. Value of the transportMethod is "
> http://www.w3.org/2001/04/xmlenc#rsa-1_5"; and
> algorithmPolicy.getSymmetricKeyWrap() returns "
> http://www.w3.org/2001/04/xmlenc#kw-aes256"; while
> algorithmPolicy.getAsymmetricKeyWrap() returns "
> http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p";. Therefore, to not to
> fail in this if statement, 'algorithmPolicy' must return same values for
> both symmetricKeyWrap and asymmetricKeyWrap. When I looked at
> setAlgorithmSuite method in the
> org.apache.cxf.ws.security.policy.model.AlgorithmSuite.java,
> symmetricKeyWrap and asymmetricKeyWrap are set always differently. So, Line
> 151 if statement is unlikely satisfied. The other hand, I set "
> http://www.w3.org/2001/04/xmlenc#aes256-cbc"; as "encryptionAlgorithm" on
> STS side, but it turns to "keyWrapAlgorithm" on WSP side.
>
>
> private boolean checkEncryptionAlgorithms(
> WSSecurityEngineResult result,
> AlgorithmSuite algorithmPolicy,
> AssertionInfo ai
> ) {
> String transportMethod =
>
> (String)result.get(WSSecurityEngineResult.TAG_ENCRYPTED_KEY_TRANSPORT_METHOD);
> if (transportMethod != null //Line151
> &&
> !algorithmPolicy.getSymmetricKeyWrap().equals(transportMethod)
> &&
> !algorithmPolicy.getAsymmetricKeyWrap().equals(transportMethod)) {
> ai.setNotAsserted(
> "The Key transport method does not match the requirement"
> );
> return false;
>
> }
>
>
> On Thu, Jul 19, 2012 at 11:58 AM, Colm O hEigeartaigh <[email protected]
> > wrote:
>
>> I've found two issues after looking into this in more detail.
>>
>> The first is that the "cxf-ut-encrypted" STS configuration shipped with
>> Fediz does not in fact encrypt the issued token due to a missing
>> configuration line. I've merged a fix for this here:
>>
>> http://svn.apache.org/viewvc?view=revision&revision=1363393
>>
>> Secondly, the Symmetric holder-of-key use-case, where the symmetric key is
>> encrypted with the certificate of the service provider, does not use the
>> EncryptionProperties.getKeyWrapAlgorithm as you might expect, but always
>> uses the default RSA 1.5 algorithm. I've fixed this as well:
>>
>> https://issues.apache.org/jira/browse/CXF-4436
>> http://svn.apache.org/viewvc?view=revision&revision=1363394
>>
>> I can't reproduce the decryption error you're seeing though. Could you
>> upgrade your JDK to the latest 1.6.x and apply the unlimited security
>> policies, and try again using the latest CXF SNAPSHOT code?
>>
>> Colm.
>>
>
>
