cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: Difference between CXF Fediz UT_Port and UTEncrypted_Port
Date Mon, 23 Jul 2012 13:39:59 GMT
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 <ginachoi88@gmail.com> 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 <ginachoi88@gmail.com> 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 <
> coheigea@apache.org
> > > 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message