Return-Path: X-Original-To: apmail-axis-java-user-archive@www.apache.org Delivered-To: apmail-axis-java-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 514459BC1 for ; Wed, 25 Apr 2012 14:17:47 +0000 (UTC) Received: (qmail 33632 invoked by uid 500); 25 Apr 2012 14:17:46 -0000 Delivered-To: apmail-axis-java-user-archive@axis.apache.org Received: (qmail 33339 invoked by uid 500); 25 Apr 2012 14:17:45 -0000 Mailing-List: contact java-user-help@axis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-user@axis.apache.org Delivered-To: mailing list java-user@axis.apache.org Received: (qmail 33326 invoked by uid 99); 25 Apr 2012 14:17:45 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Apr 2012 14:17:45 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of futhark77@gmail.com designates 209.85.213.45 as permitted sender) Received: from [209.85.213.45] (HELO mail-yw0-f45.google.com) (209.85.213.45) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Apr 2012 14:17:38 +0000 Received: by yhoo21 with SMTP id o21so155911yho.32 for ; Wed, 25 Apr 2012 07:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=p2hfs3fsiyhjywqvYD3HTvMdmtTBwkXLLjVlJKM2xKs=; b=hmcHpCZb0WZUzOqFJMzNpnHJEuc8SwuLbXOZuS7N09ywIRgK5qK81Jhh69sv36/OQj 51ihFoq302rb9RZbyQwp8B4TRY/0QH6fQOxMADzfYiaKBHl4zel7F1bwM+YEj2yp1Q7i QCE11nuPhzbWCEnb9Qmg9LDdfPEIiJKE8noSmFDvMinGnZ6nLyaPDIYwTIasJE9BCO0I BjtiRix+X2EhJfi0PmL5ic1NUNsOiRrmg2Jszy9K2CfAYJS7gayI4hHLz6oiBaUNcjn0 QnEXS2ne1VdIE1x3z4IakV8UlXmJX8+mVHFRxZqLoxBzZxT9HBOkJ/+LYpjtjOE5fnVj 5p/Q== MIME-Version: 1.0 Received: by 10.236.181.70 with SMTP id k46mr2722767yhm.21.1335363437333; Wed, 25 Apr 2012 07:17:17 -0700 (PDT) Received: by 10.236.180.132 with HTTP; Wed, 25 Apr 2012 07:17:17 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Apr 2012 10:17:17 -0400 Message-ID: Subject: Re: [rampart 1.5.2] SignedEncryptedSupportingTokens -> Unexpected signature From: "Philippe A." To: java-user@axis.apache.org Content-Type: multipart/alternative; boundary=20cf305b1264540c6b04be81872d --20cf305b1264540c6b04be81872d Content-Type: text/plain; charset=ISO-8859-1 I have been able to put sp:UsernameToken inside sp:SignedEncryptedSupportingTokens. I do not know what I did wrong initially. Here's what I have now. This is with Axis 1.5.6 + Rampart 1.5.2. 2012/4/18 Philippe A. > > > 2012/4/17 Philippe A. > > Hello, >> >> I am writing a web service and a corresponding client. If I put my >> username token inside a SignedEncryptedSupportingTokens assertion, the >> server will systematically produce an exception upon receiving requests.: >> >> org.apache.axis2.AxisFault: Unexpected signature >> at >> org.apache.rampart.handler.RampartReceiver.setFaultCodeAndThrowAxisFault(RampartReceiver.java:180) >> at >> org.apache.rampart.handler.RampartReceiver.invoke(RampartReceiver.java:99) >> at org.apache.axis2.engine.Phase.invoke(Phase.java:318) >> at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:254) >> at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:160) >> at >> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:173) >> at >> org.apache.axis2.transport.http.HTTPWorker.service(HTTPWorker.java:266) >> at >> org.apache.axis2.transport.http.server.AxisHttpService.doService(AxisHttpService.java:281) >> at >> org.apache.axis2.transport.http.server.AxisHttpService.handleRequest(AxisHttpService.java:187) >> at >> org.apache.axis2.transport.http.server.HttpServiceProcessor.run(HttpServiceProcessor.java:82) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) >> at java.lang.Thread.run(Thread.java:662) >> Caused by: org.apache.rampart.RampartException: Unexpected signature >> at >> org.apache.rampart.PolicyBasedResultsValidator.validateEncrSig(PolicyBasedResultsValidator.java:226) >> at >> org.apache.rampart.PolicyBasedResultsValidator.validate(PolicyBasedResultsValidator.java:132) >> at >> org.apache.rampart.RampartEngine.process(RampartEngine.java:308) >> at >> org.apache.rampart.handler.RampartReceiver.invoke(RampartReceiver.java:92) >> ... 11 more >> >> Since Rampart seems to be always encrypting the username token, I decided >> to use SignedSupportingTokens for now. But I don't really like doing that >> as I feel my policy risks not producing the desired result if I change >> client technology. >> >> This is with rampart 1.5.2 + axis 1.5.6. >> > > The ws-securitypolicy 1.2 standard seem to allow the username token to be > encrypted even if it is listed as a sp:SupportingToken. > > 760 When the UsernameToken is to be encrypted it SHOULD be listed as a > 761 SignedEncryptedSupportingToken (Section 8.5), > EndorsingEncryptedSupportingToken (Section 8.6) or > 762 SignedEndorsingEncryptedSupportingToken (Section 8.7). > > 3807 3. A wsse:UsernameToken may be encrypted when a transport binding is > not being used > 3808 (Section 5.3.1). > > However, I strongly believe that listing the username token under > sp:SignedEncryptedSupportingToken should not fault. > > -- > Philippe > > -- Philippe --20cf305b1264540c6b04be81872d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have been able to put sp:UsernameToken inside = sp:SignedEncryptedSupportingTokens. I do not know what I did wrong initiall= y.

Here's what I have now.

=A0=A0=A0=A0=A0=A0=A0=A0=A0 &l= t;sp:SignedEncryptedSupportingTokens>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <wsp:Policy>
=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 <sp:UsernameToken sp:IncludeToken=3D"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/20070= 2/IncludeToken/AlwaysToRecipient"/>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 </wsp:Policy>
=A0=A0=A0=A0=A0=A0= =A0=A0=A0 </sp:SignedEncryptedSupportingTokens>

This is with A= xis 1.5.6 + Rampart 1.5.2.

2012/4/18 Phil= ippe A. <futhark77@gmail.com>


2012/4/17= Philippe A. <futhark77@gmail.com>

Hello,

I am writing a web service and a corresponding client. If I p= ut my username token inside a SignedEncryptedSupportingTokens assertion, th= e server will systematically produce an exception upon receiving requests.:=

org.apache.axis2.AxisFault: Unexpected signature
=A0=A0=A0=A0=A0=A0= =A0 at org.apache.rampart.handler.RampartReceiver.setFaultCodeAndThrowAxisF= ault(RampartReceiver.java:180)
=A0=A0=A0=A0=A0=A0=A0 at org.apache.rampa= rt.handler.RampartReceiver.invoke(RampartReceiver.java:99)
=A0=A0=A0=A0=A0=A0=A0 at org.apache.axis2.engine.Phase.invoke(Phase.java:31= 8)
=A0=A0=A0=A0=A0=A0=A0 at org.apache.axis2.engine.AxisEngine.invoke(Ax= isEngine.java:254)
=A0=A0=A0=A0=A0=A0=A0 at org.apache.axis2.engine.Axis= Engine.receive(AxisEngine.java:160)
=A0=A0=A0=A0=A0=A0=A0 at org.apache.axis2.transport.http.HTTPTransportUtils= .processHTTPPostRequest(HTTPTransportUtils.java:173)
=A0=A0=A0=A0=A0=A0= =A0 at org.apache.axis2.transport.http.HTTPWorker.service(HTTPWorker.java:2= 66)
=A0=A0=A0=A0=A0=A0=A0 at org.apache.axis2.transport.http.server.Axis= HttpService.doService(AxisHttpService.java:281)
=A0=A0=A0=A0=A0=A0=A0 at org.apache.axis2.transport.http.server.AxisHttpSer= vice.handleRequest(AxisHttpService.java:187)
=A0=A0=A0=A0=A0=A0=A0 at or= g.apache.axis2.transport.http.server.HttpServiceProcessor.run(HttpServicePr= ocessor.java:82)
=A0=A0=A0=A0=A0=A0=A0 at java.util.concurrent.ThreadPoo= lExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
=A0=A0=A0=A0=A0=A0=A0 at java.util.concurrent.ThreadPoolExecutor$Worker.run= (ThreadPoolExecutor.java:908)
=A0=A0=A0=A0=A0=A0=A0 at java.lang.Thread.= run(Thread.java:662)
Caused by: org.apache.rampart.RampartException: Une= xpected signature
=A0=A0=A0=A0=A0=A0=A0 at org.apache.rampart.PolicyBase= dResultsValidator.validateEncrSig(PolicyBasedResultsValidator.java:226)
=A0=A0=A0=A0=A0=A0=A0 at org.apache.rampart.PolicyBasedResultsValidator.val= idate(PolicyBasedResultsValidator.java:132)
=A0=A0=A0=A0=A0=A0=A0 at org= .apache.rampart.RampartEngine.process(RampartEngine.java:308)
=A0=A0=A0= =A0=A0=A0=A0 at org.apache.rampart.handler.RampartReceiver.invoke(RampartRe= ceiver.java:92)
=A0=A0=A0=A0=A0=A0=A0 ... 11 more

Since Rampart seems to be always e= ncrypting the username token, I decided to use SignedSupportingTokens for n= ow. But I don't really like doing that as I feel my policy risks not pr= oducing the desired result if I change client technology.

This is with rampart 1.5.2 + axis 1.5.6.
<= /div>

The ws-securitypolicy 1.2 standard seem to allow the u= sername token to be encrypted even if it is listed as a sp:SupportingToken.=

760 When the UsernameToken is to be encrypted it SHOULD be listed as a =
761 SignedEncryptedSupportingToken (Section 8.5), EndorsingEncryptedSup= portingToken (Section 8.6) or
762 SignedEndorsingEncryptedSupportingTok= en (Section 8.7).

3807 3. A wsse:UsernameToken may be encrypted when a transport binding = is not being used
3808 (Section 5.3.1).

However, I strongly beli= eve that listing the username token under sp:SignedEncryptedSupportingToken= should not fault.

--
Philippe




--
Philippe<= br>
--20cf305b1264540c6b04be81872d--