> If I define AlgorithmSuite to Basic256 in WSP, what "encryptionAlgorithm" and "keyWrapAlgorithm" should I use?
encryptionAlgorithm: "http://www.w3.org/2001/04/xmlenc#aes256-cbc"; keyWrapAlgorithm: "http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"; > If .NET need different "encryptionAlgorithm" and "keyWrapAlgorithm", how do I configure another set of "encryptionAlgorithm" and > "keyWrapAlgorithm" in cxf-encrypted-ut.xml? You can set an EncryptionProperties bean per-service via the "encryptionProperties" property of the StaticService bean. Colm. On Mon, Jul 23, 2012 at 3:38 PM, Gina Choi <[email protected]> wrote: > Hi Clom, > > I switched AlgorithmSuite to Basic256Rsa15 and it worked. Thank you. > Following is content of my cxf-encrypted-ut.xml. If I define AlgorithmSuite > to Basic256 in WSP, what "encryptionAlgorithm" and "keyWrapAlgorithm" > should I use? Second, as you can see I have two endpoints configured for > cxf-encrypted-ut.xml. 'doubleit' is for java WSP and 'Agency' is .NET WSP. > If .NET need different "encryptionAlgorithm" and "keyWrapAlgorithm", how do > I configure another set of "encryptionAlgorithm" and "keyWrapAlgorithm" in > cxf-encrypted-ut.xml? > > > > <util:list id="encryptedUtEndpoints"> > <value> > https://wkengchoi.global.sdl.corp:8443/doubleit/services/doubleit</value> > <value>https://medevasarafia01.global.sdl.corp/Agency/</value> > </util:list> > <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> > > On Mon, Jul 23, 2012 at 9:39 AM, Colm O hEigeartaigh > <[email protected]>wrote: > >> This is not a bug. Your WSP is rejecting the client request as it uses >> encryption algorithms that are not defined in the relevant security >> policy. >> To support the RSA 1.5 key transport algorithm, your WSP should be using >> the following AlgorithmSuite instead: >> >> Basic256Rsa15 >> >> Colm. >> >> On Sat, Jul 21, 2012 at 2:41 AM, Gina Choi <[email protected]> wrote: >> >> > 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. >> > >> >> > > >> > > >> > >> >> >> >> -- >> Colm O hEigeartaigh >> >> Talend Community Coder >> http://coders.talend.com >> > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
