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
>
