Re: catalogLocation in JAXB/JSON Provider and @SchemaValidation

[Vjacheslav V. Borisov]

2016-03-23 18:26 GMT+04:00 Sergey Beryozkin :

>
> I'm not sure what happens when you use @SchemaValidation and no schema
> holder. Can you please put a breakpoint in AbstractJaxbProvider.init() and
> see how SchemaValidation is processed. I can imagine that a schema will be
> loaded 4 times in this case - twice for default providers and twice for the
> same providers loaded from Spring
>
Yes, it is. And third time I am geting exception due to unconfigured
catalog. Now I am understand.


>
> but also, as I mentioned it is really better to use a schema holder in
> this case - only user registered providers will be set-up with a shared
> schema reference.
>

I agree, I removed annotaion @SchemaValidation and configured SchemaHandler
in spring

Re: Encrypting timestamp or other security headers using WS-SecurityPolicy

[Giriraj Bhojak]

Thank you Colm, that policy did help out.

Thanks,
Giriraj
On Mar 23, 2016 1:57 PM, "Colm O hEigeartaigh"  wrote:

> See here:
>
>
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=systests/ws-security/src/test/resources/org/apache/cxf/systest/ws/x509/DoubleItX509.wsdl;h=dcf01b23c124795a04be170f5d8079102a516b35;hb=HEAD
>
> On Wed, Mar 23, 2016 at 5:50 PM, Giriraj Bhojak 
> wrote:
>
>> Thank you Colm.
>> Would you have a policy example of using EncryptedElements instead of
>> using  EncryptedParts?
>> I tried few combinations, but they didn't work out.
>>
>> Thanks,
>> Giriraj
>> On Mar 23, 2016 12:58 PM, "Colm O hEigeartaigh" 
>> wrote:
>>
>>> Answers inline.
>>>
>>> On Wed, Mar 23, 2016 at 4:49 PM, Giriraj Bhojak 
>>> wrote:
>>>
 Do you mean to say the timestamp is not just signed but encrypted as
 well if it is part of the AsymmetricBinding?

>>> No, just signed.
>>>
 In my policy I have also added username token as a supporting token,
 outside of AsymmetricBinding. Would this token be signed and encrypted too?

>>>
>>> No. However it would be if you specified a
>>> "SignedEncryptedSupportingToken" policy instead of "SupportingToken".
>>>
>>> Colm.
>>>
>>>
 I have written a Java client that is able to successfully send and
 receive a response using the policy. I have a requirement to test the
 endpoint using SoapUI tool as well and that's where I am facing issues
 since I couldn't just import the policy SoapUI.

 Thanks,
 Giriraj
 On Mar 23, 2016 7:04 AM, "Colm O hEigeartaigh" 
 wrote:

> If you are using the  SymmetricBinding or AsymmetricBinding policies,
> the
> Timestamp is automatically signed if the "IncludeTimestamp" policy is
> in
> the Binding policy.
>
> The "sp:Header" policy in SignedParts/EncryptedParts is designed to be
> used
> for SOAP headers, not for internal headers in the security header
> (such as
> Timestamp). Instead, use an "EncryptedElements" policy, with an XPath
> expression pointing to the Timestamp.
>
> Colm.
>
> On Tue, Mar 22, 2016 at 3:17 AM, Giriraj Bhojak 
> wrote:
>
> > Hello,
> >
> >
> > I need to sign and encrypt the timestamp WS-Security header.
> >
> > My policy file has following assertions:
> >
> >
> >
> > 
> >
> >
> >
> >http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> > " />
> >
> > 
> >
> > 
> >
> >
> >
> >http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> > " />
> >
> > 
> >
> >  Above namespace belongs to wsu element.
> >
> > I can still see following entry in the wsse:Security element:
> >
> >
> >
> >  > wsu:Id="TS-A91AE37C42BC91148914586148175181">
> >
> >
> >  2016-03-22T02:46:57.516Z
> >
> >
> >  2016-03-22T02:51:57.516Z
> >
> > 
> >
> >
> >
> > If I try to add the namespace of wsse into the signed and encrypted
> parts
> > above in order to encrypt and sign entire header as follows:
> >
> > 
> >
> >
> >
> >http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> > " />
> >
> > 
> >
> > 
> >
> >
> >
> >http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> > " />
> >
> > 
> >
> >
> >
> > Then on the CXF server I get:
> >
> > org.apache.cxf.interceptor.Fault- Exception Message: Found element {
> > http://www.w3.org/2001/04/xmlenc#}EncryptionMethod but could not
> find
> > matching RPC/Literal part
> >
> > I am using CXF v2.7.11.
> >
> > Am I doing something wrong?
> >
> > Thanks,
> > Giriraj
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>

>>>
>>>
>>> --
>>> Colm O hEigeartaigh
>>>
>>> Talend Community Coder
>>> http://coders.talend.com
>>>
>>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>

Re: CXF JAXRS Client : HttpAsyncClient and KeepAlive

[chandra shekhar]

Thanks Sergey for prompt response.

I am testing with
https://github.com/apache/cxf/blob/master/rt/transports/http-hc/src/test/java/org/apache/cxf/transport/http/asyncclient/AsyncHTTPConduitTest.java.

I set following in already existing start method.
#alreadythere in testcase
Bus b = createStaticBus();
 b.setProperty(AsyncHTTPConduit.USE_ASYNC,
AsyncHTTPConduitFactory.UseAsyncPolicy.ALWAYS);
# I included following.
 b.setProperty(AsyncHTTPConduitFactory.CONNECTION_TTL, "5"); 


I am testing with both testCall and testCallAsync method. For both I am not
able to find any change.

Or I believe my understanding is not correct.

Please suggest.

Regards,
Chandra Shekhar



--
View this message in context: 
http://cxf.547215.n5.nabble.com/CXF-JAXRS-Client-HttpAsyncClient-and-KeepAlive-tp5747402p5767193.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Encrypting timestamp or other security headers using WS-SecurityPolicy

[Colm O hEigeartaigh]

See here:

https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=systests/ws-security/src/test/resources/org/apache/cxf/systest/ws/x509/DoubleItX509.wsdl;h=dcf01b23c124795a04be170f5d8079102a516b35;hb=HEAD

On Wed, Mar 23, 2016 at 5:50 PM, Giriraj Bhojak  wrote:

> Thank you Colm.
> Would you have a policy example of using EncryptedElements instead of
> using  EncryptedParts?
> I tried few combinations, but they didn't work out.
>
> Thanks,
> Giriraj
> On Mar 23, 2016 12:58 PM, "Colm O hEigeartaigh" 
> wrote:
>
>> Answers inline.
>>
>> On Wed, Mar 23, 2016 at 4:49 PM, Giriraj Bhojak 
>> wrote:
>>
>>> Do you mean to say the timestamp is not just signed but encrypted as
>>> well if it is part of the AsymmetricBinding?
>>>
>> No, just signed.
>>
>>> In my policy I have also added username token as a supporting token,
>>> outside of AsymmetricBinding. Would this token be signed and encrypted too?
>>>
>>
>> No. However it would be if you specified a
>> "SignedEncryptedSupportingToken" policy instead of "SupportingToken".
>>
>> Colm.
>>
>>
>>> I have written a Java client that is able to successfully send and
>>> receive a response using the policy. I have a requirement to test the
>>> endpoint using SoapUI tool as well and that's where I am facing issues
>>> since I couldn't just import the policy SoapUI.
>>>
>>> Thanks,
>>> Giriraj
>>> On Mar 23, 2016 7:04 AM, "Colm O hEigeartaigh" 
>>> wrote:
>>>
 If you are using the  SymmetricBinding or AsymmetricBinding policies,
 the
 Timestamp is automatically signed if the "IncludeTimestamp" policy is in
 the Binding policy.

 The "sp:Header" policy in SignedParts/EncryptedParts is designed to be
 used
 for SOAP headers, not for internal headers in the security header (such
 as
 Timestamp). Instead, use an "EncryptedElements" policy, with an XPath
 expression pointing to the Timestamp.

 Colm.

 On Tue, Mar 22, 2016 at 3:17 AM, Giriraj Bhojak 
 wrote:

 > Hello,
 >
 >
 > I need to sign and encrypt the timestamp WS-Security header.
 >
 > My policy file has following assertions:
 >
 >
 >
 > 
 >
 >
 >
 >http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
 > " />
 >
 > 
 >
 > 
 >
 >
 >
 >http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
 > " />
 >
 > 
 >
 >  Above namespace belongs to wsu element.
 >
 > I can still see following entry in the wsse:Security element:
 >
 >
 >
 > >>> > wsu:Id="TS-A91AE37C42BC91148914586148175181">
 >
 >
 >  2016-03-22T02:46:57.516Z
 >
 >
 >  2016-03-22T02:51:57.516Z
 >
 > 
 >
 >
 >
 > If I try to add the namespace of wsse into the signed and encrypted
 parts
 > above in order to encrypt and sign entire header as follows:
 >
 > 
 >
 >
 >
 >http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
 > " />
 >
 > 
 >
 > 
 >
 >
 >
 >http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
 > " />
 >
 > 
 >
 >
 >
 > Then on the CXF server I get:
 >
 > org.apache.cxf.interceptor.Fault- Exception Message: Found element {
 > http://www.w3.org/2001/04/xmlenc#}EncryptionMethod but could not find
 > matching RPC/Literal part
 >
 > I am using CXF v2.7.11.
 >
 > Am I doing something wrong?
 >
 > Thanks,
 > Giriraj
 >



 --
 Colm O hEigeartaigh

 Talend Community Coder
 http://coders.talend.com

>>>
>>
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Encrypting timestamp or other security headers using WS-SecurityPolicy

[Giriraj Bhojak]

Thank you Colm.
Would you have a policy example of using EncryptedElements instead of
using  EncryptedParts?
I tried few combinations, but they didn't work out.

Thanks,
Giriraj
On Mar 23, 2016 12:58 PM, "Colm O hEigeartaigh"  wrote:

> Answers inline.
>
> On Wed, Mar 23, 2016 at 4:49 PM, Giriraj Bhojak 
> wrote:
>
>> Do you mean to say the timestamp is not just signed but encrypted as well
>> if it is part of the AsymmetricBinding?
>>
> No, just signed.
>
>> In my policy I have also added username token as a supporting token,
>> outside of AsymmetricBinding. Would this token be signed and encrypted too?
>>
>
> No. However it would be if you specified a
> "SignedEncryptedSupportingToken" policy instead of "SupportingToken".
>
> Colm.
>
>
>> I have written a Java client that is able to successfully send and
>> receive a response using the policy. I have a requirement to test the
>> endpoint using SoapUI tool as well and that's where I am facing issues
>> since I couldn't just import the policy SoapUI.
>>
>> Thanks,
>> Giriraj
>> On Mar 23, 2016 7:04 AM, "Colm O hEigeartaigh" 
>> wrote:
>>
>>> If you are using the  SymmetricBinding or AsymmetricBinding policies, the
>>> Timestamp is automatically signed if the "IncludeTimestamp" policy is in
>>> the Binding policy.
>>>
>>> The "sp:Header" policy in SignedParts/EncryptedParts is designed to be
>>> used
>>> for SOAP headers, not for internal headers in the security header (such
>>> as
>>> Timestamp). Instead, use an "EncryptedElements" policy, with an XPath
>>> expression pointing to the Timestamp.
>>>
>>> Colm.
>>>
>>> On Tue, Mar 22, 2016 at 3:17 AM, Giriraj Bhojak 
>>> wrote:
>>>
>>> > Hello,
>>> >
>>> >
>>> > I need to sign and encrypt the timestamp WS-Security header.
>>> >
>>> > My policy file has following assertions:
>>> >
>>> >
>>> >
>>> > 
>>> >
>>> >
>>> >
>>> >http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>> > " />
>>> >
>>> > 
>>> >
>>> > 
>>> >
>>> >
>>> >
>>> >http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>> > " />
>>> >
>>> > 
>>> >
>>> >  Above namespace belongs to wsu element.
>>> >
>>> > I can still see following entry in the wsse:Security element:
>>> >
>>> >
>>> >
>>> > >> > wsu:Id="TS-A91AE37C42BC91148914586148175181">
>>> >
>>> >
>>> >  2016-03-22T02:46:57.516Z
>>> >
>>> >
>>> >  2016-03-22T02:51:57.516Z
>>> >
>>> > 
>>> >
>>> >
>>> >
>>> > If I try to add the namespace of wsse into the signed and encrypted
>>> parts
>>> > above in order to encrypt and sign entire header as follows:
>>> >
>>> > 
>>> >
>>> >
>>> >
>>> >http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>> > " />
>>> >
>>> > 
>>> >
>>> > 
>>> >
>>> >
>>> >
>>> >http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>> > " />
>>> >
>>> > 
>>> >
>>> >
>>> >
>>> > Then on the CXF server I get:
>>> >
>>> > org.apache.cxf.interceptor.Fault- Exception Message: Found element {
>>> > http://www.w3.org/2001/04/xmlenc#}EncryptionMethod but could not find
>>> > matching RPC/Literal part
>>> >
>>> > I am using CXF v2.7.11.
>>> >
>>> > Am I doing something wrong?
>>> >
>>> > Thanks,
>>> > Giriraj
>>> >
>>>
>>>
>>>
>>> --
>>> Colm O hEigeartaigh
>>>
>>> Talend Community Coder
>>> http://coders.talend.com
>>>
>>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>

Re: Encrypting timestamp or other security headers using WS-SecurityPolicy

[Colm O hEigeartaigh]

Answers inline.

On Wed, Mar 23, 2016 at 4:49 PM, Giriraj Bhojak  wrote:

> Do you mean to say the timestamp is not just signed but encrypted as well
> if it is part of the AsymmetricBinding?
>
No, just signed.

> In my policy I have also added username token as a supporting token,
> outside of AsymmetricBinding. Would this token be signed and encrypted too?
>

No. However it would be if you specified a "SignedEncryptedSupportingToken"
policy instead of "SupportingToken".

Colm.


> I have written a Java client that is able to successfully send and receive
> a response using the policy. I have a requirement to test the endpoint
> using SoapUI tool as well and that's where I am facing issues since I
> couldn't just import the policy SoapUI.
>
> Thanks,
> Giriraj
> On Mar 23, 2016 7:04 AM, "Colm O hEigeartaigh" 
> wrote:
>
>> If you are using the  SymmetricBinding or AsymmetricBinding policies, the
>> Timestamp is automatically signed if the "IncludeTimestamp" policy is in
>> the Binding policy.
>>
>> The "sp:Header" policy in SignedParts/EncryptedParts is designed to be
>> used
>> for SOAP headers, not for internal headers in the security header (such as
>> Timestamp). Instead, use an "EncryptedElements" policy, with an XPath
>> expression pointing to the Timestamp.
>>
>> Colm.
>>
>> On Tue, Mar 22, 2016 at 3:17 AM, Giriraj Bhojak 
>> wrote:
>>
>> > Hello,
>> >
>> >
>> > I need to sign and encrypt the timestamp WS-Security header.
>> >
>> > My policy file has following assertions:
>> >
>> >
>> >
>> > 
>> >
>> >
>> >
>> >http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>> > " />
>> >
>> > 
>> >
>> > 
>> >
>> >
>> >
>> >http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>> > " />
>> >
>> > 
>> >
>> >  Above namespace belongs to wsu element.
>> >
>> > I can still see following entry in the wsse:Security element:
>> >
>> >
>> >
>> > > > wsu:Id="TS-A91AE37C42BC91148914586148175181">
>> >
>> >
>> >  2016-03-22T02:46:57.516Z
>> >
>> >
>> >  2016-03-22T02:51:57.516Z
>> >
>> > 
>> >
>> >
>> >
>> > If I try to add the namespace of wsse into the signed and encrypted
>> parts
>> > above in order to encrypt and sign entire header as follows:
>> >
>> > 
>> >
>> >
>> >
>> >http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> > " />
>> >
>> > 
>> >
>> > 
>> >
>> >
>> >
>> >http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> > " />
>> >
>> > 
>> >
>> >
>> >
>> > Then on the CXF server I get:
>> >
>> > org.apache.cxf.interceptor.Fault- Exception Message: Found element {
>> > http://www.w3.org/2001/04/xmlenc#}EncryptionMethod but could not find
>> > matching RPC/Literal part
>> >
>> > I am using CXF v2.7.11.
>> >
>> > Am I doing something wrong?
>> >
>> > Thanks,
>> > Giriraj
>> >
>>
>>
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: oauth2 server side cxf configuration

[Sergey Beryozkin]

Can you clarify please what you'd like to do, as far as enabling OAuth2 is
concerned ?

Cheers, Sergey



--
View this message in context: 
http://cxf.547215.n5.nabble.com/oauth2-server-side-cxf-configuration-tp5767107p5767152.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: CXF JAXRS Client : HttpAsyncClient and KeepAlive

[Sergey Beryozkin]

Well, I suppose you set as per the documentation.
I'm not sure why it has no effect with HttpAsyncClient, I'll experiment a
bit later

Sergey



--
View this message in context: 
http://cxf.547215.n5.nabble.com/CXF-JAXRS-Client-HttpAsyncClient-and-KeepAlive-tp5747402p5767151.html
Sent from the cxf-user mailing list archive at Nabble.com.

RE: STSClient.validateSecurityToken expects RequestSecurityTokenResponseCollection?

[Stephen.CTR.Chappell]

Oh, well that explains it then. Thanx!

Stephen W. Chappell

From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Wednesday, March 23, 2016 8:45 AM
To: Chappell, Stephen CTR (FAA)
Cc: users@cxf.apache.org
Subject: Re: STSClient.validateSecurityToken expects 
RequestSecurityTokenResponseCollection?

That's because there are no security policies that support RSA-SHA256 as the 
specs are quite old now, so CXF gives you the option of overriding the 
signature algorithm via a configuration parameter.
Colm.

On Wed, Mar 23, 2016 at 12:38 PM, 
> wrote:
Solved. Sucking in the WSDL and using the WS-SecurityPolicy did the trick, once 
I set up the ws-security.signature.* properties in the property map. One weird 
thing though is that I had to explicitly set the signature algorithm ...


  
...
http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
  


It was no problem to do that, but it seems weird since everything else got 
configured from the policy.

Thanx,

Stephen W. Chappell

-Original Message-
From: Chappell, Stephen CTR (FAA)
Sent: Wednesday, March 23, 2016 7:47 AM
To: cohei...@apache.org
Cc: users@cxf.apache.org
Subject: RE: STSClient.validateSecurityToken expects 
RequestSecurityTokenResponseCollection?

I was used to using the interceptors from other projects, so I didn’t really 
give it any thought; but it does make more sense to use the policy approach. 
Now if I can just get the property map configured right …

Stephen W. Chappell

From: Colm O hEigeartaigh 
[mailto:cohei...@apache.org]
Sent: Wednesday, March 23, 2016 7:40 AM
To: Chappell, Stephen CTR (FAA)
Cc: users@cxf.apache.org
Subject: Re: STSClient.validateSecurityToken expects 
RequestSecurityTokenResponseCollection?

I guess so. It's unusual to use the WSS4J interceptors when invoking on the 
STS, all of the testing is done with WS-SecurityPolicy.
Colm.

On Wed, Mar 23, 2016 at 11:37 AM, 
>>
 wrote:
Yeah, that is exactly what my wsdl looks like. I think the problem is that I 
didn't specify a wsdlLocation in my client bean, only a location. That worked 
fine for the issue operation, but not at all for validate. So I tried 
configuring that and ran into some new problems, which I think is because the 
WSDL specifies security policy and the client uses WSS4JOutInterceptors to 
configure the outbound security. This is my client bean configuration:

  



http://localhost:9080/FAA-IAM-STS/STS-BST?wsdl"/>
http://docs.oasis-open.org/ws-sx/ws-trust/200512/}BSTSecurityTokenService"/>
http://docs.oasis-open.org/ws-sx/ws-trust/200512/}STS_Port"/>


  

  


  

  


  
 

  


  


  



  

So I'm working on configuring the right properties in the property map to make 
it all work. Am I on the right track with that?

Thanx,

Stephen W. Chappell



-Original Message-
From: Colm O hEigeartaigh 
[mailto:cohei...@apache.org>]
Sent: Wednesday, March 23, 2016 7:27 AM
To: 
users@cxf.apache.org>
Subject: Re: STSClient.validateSecurityToken expects 
RequestSecurityTokenResponseCollection?

What does your WSDL look like? At a guess it is expecting the Collection to be 
returned as opposed to the single element. The portType should look something 
like:


http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Validate;
message="tns:RequestSecurityTokenMsg"/>
http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/ValidateFinal;
message="tns:RequestSecurityTokenResponseMsg"/>


Colm.

On Tue, Mar 22, 2016 at 5:44 PM, 
>>
 wrote:

> Hi -
>
> I'm using the CXF 3.1.4 STSClient to write a simple test client for my
> CXF-based STS. Requesting tokens has worked as expected, but
> requesting validation of a token is having a problem. It would appear
> that STSClient creates a proper RST, and gets a proper RSTR from the
> STS. But something deep inside the stack is expecting a
> RequestSecurityTokenResponseCollection
> instead of a RequestSecurityTokenResponse, 

Re: STSClient.validateSecurityToken expects RequestSecurityTokenResponseCollection?

[Colm O hEigeartaigh]

That's because there are no security policies that support RSA-SHA256 as
the specs are quite old now, so CXF gives you the option of overriding the
signature algorithm via a configuration parameter.

Colm.

On Wed, Mar 23, 2016 at 12:38 PM,  wrote:

> Solved. Sucking in the WSDL and using the WS-SecurityPolicy did the trick,
> once I set up the ws-security.signature.* properties in the property map.
> One weird thing though is that I had to explicitly set the signature
> algorithm ...
>
> 
>   
> ...
> http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
>   
> 
>
> It was no problem to do that, but it seems weird since everything else got
> configured from the policy.
>
> Thanx,
>
> Stephen W. Chappell
>
> -Original Message-
> From: Chappell, Stephen CTR (FAA)
> Sent: Wednesday, March 23, 2016 7:47 AM
> To: cohei...@apache.org
> Cc: users@cxf.apache.org
> Subject: RE: STSClient.validateSecurityToken expects
> RequestSecurityTokenResponseCollection?
>
> I was used to using the interceptors from other projects, so I didn’t
> really give it any thought; but it does make more sense to use the policy
> approach. Now if I can just get the property map configured right …
>
> Stephen W. Chappell
>
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Wednesday, March 23, 2016 7:40 AM
> To: Chappell, Stephen CTR (FAA)
> Cc: users@cxf.apache.org
> Subject: Re: STSClient.validateSecurityToken expects
> RequestSecurityTokenResponseCollection?
>
> I guess so. It's unusual to use the WSS4J interceptors when invoking on
> the STS, all of the testing is done with WS-SecurityPolicy.
> Colm.
>
> On Wed, Mar 23, 2016 at 11:37 AM, > wrote:
> Yeah, that is exactly what my wsdl looks like. I think the problem is that
> I didn't specify a wsdlLocation in my client bean, only a location. That
> worked fine for the issue operation, but not at all for validate. So I
> tried configuring that and ran into some new problems, which I think is
> because the WSDL specifies security policy and the client uses
> WSS4JOutInterceptors to configure the outbound security. This is my client
> bean configuration:
>
>   
> 
>
> 
> http://localhost:9080/FAA-IAM-STS/STS-BST?wsdl"/>
> http://docs.oasis-open.org/ws-sx/ws-trust/200512/}BSTSecurityTokenService<
> http://docs.oasis-open.org/ws-sx/ws-trust/200512/%7dBSTSecurityTokenService
> >"/>
> http://docs.oasis-open.org/ws-sx/ws-trust/200512/}STS_Port<
> http://docs.oasis-open.org/ws-sx/ws-trust/200512/%7dSTS_Port>"/>
> 
> 
>   
> 
>   
> 
> 
>   
> 
>   
> 
> 
>   
>  
> 
>   
> 
> 
>   
> 
>  value-ref="cryptoProperties"/>
>   
> 
> 
> 
>   
>
> So I'm working on configuring the right properties in the property map to
> make it all work. Am I on the right track with that?
>
> Thanx,
>
> Stephen W. Chappell
>
>
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org cohei...@apache.org>]
> Sent: Wednesday, March 23, 2016 7:27 AM
> To: users@cxf.apache.org
> Subject: Re: STSClient.validateSecurityToken expects
> RequestSecurityTokenResponseCollection?
>
> What does your WSDL look like? At a guess it is expecting the Collection
> to be returned as opposed to the single element. The portType should look
> something like:
>
> 
> http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Validate;
> message="tns:RequestSecurityTokenMsg"/>
> http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/ValidateFinal;
> message="tns:RequestSecurityTokenResponseMsg"/>
> 
>
> Colm.
>
> On Tue, Mar 22, 2016 at 5:44 PM, > wrote:
>
> > Hi -
> >
> > I'm using the CXF 3.1.4 STSClient to write a simple test client for my
> > CXF-based STS. Requesting tokens has worked as expected, but
> > requesting validation of a token is having a problem. It would appear
> > that STSClient creates a proper RST, and gets a proper RSTR from the
> > STS. But something deep inside the stack is expecting a
> > RequestSecurityTokenResponseCollection
> > instead of a RequestSecurityTokenResponse, which is causing this
> exception:
> >
> > org.apache.cxf.interceptor.Fault: Unexpected element {
> >
> http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityTokenResponse
> <
> http://docs.oasis-open.org/ws-sx/ws-trust/200512%7dRequestSecurityTokenResponse
> >
> > found.   Expected {
> > http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityTokenR
> >  > enR>
> > esponseCollection
> > .
> > at
> >
> org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.validatePart(DocLiteralInInterceptor.java:280)
> > at

RE: STSClient.validateSecurityToken expects RequestSecurityTokenResponseCollection?

[Stephen.CTR.Chappell]

Solved. Sucking in the WSDL and using the WS-SecurityPolicy did the trick, once 
I set up the ws-security.signature.* properties in the property map. One weird 
thing though is that I had to explicitly set the signature algorithm ...


  
...
http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
  


It was no problem to do that, but it seems weird since everything else got 
configured from the policy.

Thanx,

Stephen W. Chappell

-Original Message-
From: Chappell, Stephen CTR (FAA) 
Sent: Wednesday, March 23, 2016 7:47 AM
To: cohei...@apache.org
Cc: users@cxf.apache.org
Subject: RE: STSClient.validateSecurityToken expects 
RequestSecurityTokenResponseCollection?

I was used to using the interceptors from other projects, so I didn’t really 
give it any thought; but it does make more sense to use the policy approach. 
Now if I can just get the property map configured right …

Stephen W. Chappell

From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Wednesday, March 23, 2016 7:40 AM
To: Chappell, Stephen CTR (FAA)
Cc: users@cxf.apache.org
Subject: Re: STSClient.validateSecurityToken expects 
RequestSecurityTokenResponseCollection?

I guess so. It's unusual to use the WSS4J interceptors when invoking on the 
STS, all of the testing is done with WS-SecurityPolicy.
Colm.

On Wed, Mar 23, 2016 at 11:37 AM, 
> wrote:
Yeah, that is exactly what my wsdl looks like. I think the problem is that I 
didn't specify a wsdlLocation in my client bean, only a location. That worked 
fine for the issue operation, but not at all for validate. So I tried 
configuring that and ran into some new problems, which I think is because the 
WSDL specifies security policy and the client uses WSS4JOutInterceptors to 
configure the outbound security. This is my client bean configuration:

  



http://localhost:9080/FAA-IAM-STS/STS-BST?wsdl"/>
http://docs.oasis-open.org/ws-sx/ws-trust/200512/}BSTSecurityTokenService"/>
http://docs.oasis-open.org/ws-sx/ws-trust/200512/}STS_Port"/>


  

  


  

  


  
 

  


  


  



  

So I'm working on configuring the right properties in the property map to make 
it all work. Am I on the right track with that?

Thanx,

Stephen W. Chappell



-Original Message-
From: Colm O hEigeartaigh 
[mailto:cohei...@apache.org]
Sent: Wednesday, March 23, 2016 7:27 AM
To: users@cxf.apache.org
Subject: Re: STSClient.validateSecurityToken expects 
RequestSecurityTokenResponseCollection?

What does your WSDL look like? At a guess it is expecting the Collection to be 
returned as opposed to the single element. The portType should look something 
like:


http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Validate;
message="tns:RequestSecurityTokenMsg"/>
http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/ValidateFinal;
message="tns:RequestSecurityTokenResponseMsg"/>


Colm.

On Tue, Mar 22, 2016 at 5:44 PM, 
> wrote:

> Hi -
>
> I'm using the CXF 3.1.4 STSClient to write a simple test client for my 
> CXF-based STS. Requesting tokens has worked as expected, but 
> requesting validation of a token is having a problem. It would appear 
> that STSClient creates a proper RST, and gets a proper RSTR from the 
> STS. But something deep inside the stack is expecting a 
> RequestSecurityTokenResponseCollection
> instead of a RequestSecurityTokenResponse, which is causing this exception:
>
> org.apache.cxf.interceptor.Fault: Unexpected element { 
> http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityTokenResponse
> found.   Expected {
> http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityTokenR
>  enR>
> esponseCollection
> .
> at
> org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.validatePart(DocLiteralInInterceptor.java:280)
> at
> org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:191)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:798)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1669)
> at
> 

Re: catalogLocation in JAXB/JSON Provider and @SchemaValidation

[Vjacheslav V. Borisov]

2016-03-23 15:48 GMT+04:00 Sergey Beryozkin :

> Thanks for the analysis and the patch, I'm traveling so will look into it
> in detail next week (though might apply the patch earlier), does your patch
> addresses all of your concerns you raised in this thread ?
>
>
Yes, counting that for first I found suitable workaround.

Re: CXF JAXRS Client : HttpAsyncClient and KeepAlive

[Sergey Beryozkin]

Hi

How do you set it ?

Cheers, Sergey
On 23/03/16 08:51, chandra shekhar wrote:

Hi Sergey, I set CONNECTION_TTL but I do not see any affect. I see that
connection always close in a minute which I see is receiveTimeout default
value.

Any suggestions here.



--
View this message in context: 
http://cxf.547215.n5.nabble.com/CXF-JAXRS-Client-HttpAsyncClient-and-KeepAlive-tp5747402p5767130.html
Sent from the cxf-user mailing list archive at Nabble.com.




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Re: catalogLocation in JAXB/JSON Provider and @SchemaValidation

[Sergey Beryozkin]

Thanks for the analysis and the patch, I'm traveling so will look into 
it in detail next week (though might apply the patch earlier), does your 
patch addresses all of your concerns you raised in this thread ?


Cheers, Sergey

On 23/03/16 08:21, Vjacheslav V. Borisov wrote:

Don't know, how should this fixed (or should not)
E.g. , code like this could fix that, but seems ugly:
resolvedLocation =
catalogResolver.resolvePublic(publicId!=null?publicId:namespaceURI,
systemId);



Found where it takes place in case of cxf-wadl2java-plugin,
please see SchemaCompilerImpl.bind(), it passes namespaceURI as publicId
parameter, while SchemaHandler passes publicId as publicId, which is null,
and resolve does not takes place.
http://grepcode.com/file/repo1.maven.org/maven2/com.sun.xml.bind/jaxb-xjc/2.2.11/com/sun/tools/xjc/api/impl/s2j/SchemaCompilerImpl.java

I submitted my patch  https://issues.apache.org/jira/browse/CXF-6840




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

RE: STSClient.validateSecurityToken expects RequestSecurityTokenResponseCollection?

[Stephen.CTR.Chappell]

I was used to using the interceptors from other projects, so I didn’t really 
give it any thought; but it does make more sense to use the policy approach. 
Now if I can just get the property map configured right …

Stephen W. Chappell

From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Wednesday, March 23, 2016 7:40 AM
To: Chappell, Stephen CTR (FAA)
Cc: users@cxf.apache.org
Subject: Re: STSClient.validateSecurityToken expects 
RequestSecurityTokenResponseCollection?

I guess so. It's unusual to use the WSS4J interceptors when invoking on the 
STS, all of the testing is done with WS-SecurityPolicy.
Colm.

On Wed, Mar 23, 2016 at 11:37 AM, 
> wrote:
Yeah, that is exactly what my wsdl looks like. I think the problem is that I 
didn't specify a wsdlLocation in my client bean, only a location. That worked 
fine for the issue operation, but not at all for validate. So I tried 
configuring that and ran into some new problems, which I think is because the 
WSDL specifies security policy and the client uses WSS4JOutInterceptors to 
configure the outbound security. This is my client bean configuration:

  



http://localhost:9080/FAA-IAM-STS/STS-BST?wsdl"/>
http://docs.oasis-open.org/ws-sx/ws-trust/200512/}BSTSecurityTokenService"/>
http://docs.oasis-open.org/ws-sx/ws-trust/200512/}STS_Port"/>


  

  


  

  


  
 

  


  


  



  

So I'm working on configuring the right properties in the property map to make 
it all work. Am I on the right track with that?

Thanx,

Stephen W. Chappell



-Original Message-
From: Colm O hEigeartaigh 
[mailto:cohei...@apache.org]
Sent: Wednesday, March 23, 2016 7:27 AM
To: users@cxf.apache.org
Subject: Re: STSClient.validateSecurityToken expects 
RequestSecurityTokenResponseCollection?

What does your WSDL look like? At a guess it is expecting the Collection to be 
returned as opposed to the single element. The portType should look something 
like:


http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Validate;
message="tns:RequestSecurityTokenMsg"/>
http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/ValidateFinal;
message="tns:RequestSecurityTokenResponseMsg"/>


Colm.

On Tue, Mar 22, 2016 at 5:44 PM, 
> wrote:

> Hi -
>
> I'm using the CXF 3.1.4 STSClient to write a simple test client for my
> CXF-based STS. Requesting tokens has worked as expected, but
> requesting validation of a token is having a problem. It would appear
> that STSClient creates a proper RST, and gets a proper RSTR from the
> STS. But something deep inside the stack is expecting a
> RequestSecurityTokenResponseCollection
> instead of a RequestSecurityTokenResponse, which is causing this exception:
>
> org.apache.cxf.interceptor.Fault: Unexpected element {
> http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityTokenResponse
> found.   Expected {
> http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityTokenR
> esponseCollection
> .
> at
> org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.validatePart(DocLiteralInInterceptor.java:280)
> at
> org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:191)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:798)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1669)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1550)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1347)
> at
> org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56)
> at
> org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215)
> at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at
> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:651)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at
> 

Re: STSClient.validateSecurityToken expects RequestSecurityTokenResponseCollection?

[Colm O hEigeartaigh]

I guess so. It's unusual to use the WSS4J interceptors when invoking on the
STS, all of the testing is done with WS-SecurityPolicy.

Colm.

On Wed, Mar 23, 2016 at 11:37 AM,  wrote:

> Yeah, that is exactly what my wsdl looks like. I think the problem is that
> I didn't specify a wsdlLocation in my client bean, only a location. That
> worked fine for the issue operation, but not at all for validate. So I
> tried configuring that and ran into some new problems, which I think is
> because the WSDL specifies security policy and the client uses
> WSS4JOutInterceptors to configure the outbound security. This is my client
> bean configuration:
>
>   
> 
>
> 
> http://localhost:9080/FAA-IAM-STS/STS-BST?wsdl"/>
> http://docs.oasis-open.org/ws-sx/ws-trust/200512/}BSTSecurityTokenService
> "/>
> http://docs.oasis-open.org/ws-sx/ws-trust/200512/}STS_Port"/>
> 
> 
>   
> 
>   
> 
> 
>   
> 
>   
> 
> 
>   
>  
> 
>   
> 
> 
>   
> 
>  value-ref="cryptoProperties"/>
>   
> 
> 
> 
>   
>
> So I'm working on configuring the right properties in the property map to
> make it all work. Am I on the right track with that?
>
> Thanx,
>
> Stephen W. Chappell
>
>
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Wednesday, March 23, 2016 7:27 AM
> To: users@cxf.apache.org
> Subject: Re: STSClient.validateSecurityToken expects
> RequestSecurityTokenResponseCollection?
>
> What does your WSDL look like? At a guess it is expecting the Collection
> to be returned as opposed to the single element. The portType should look
> something like:
>
> 
> http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Validate;
> message="tns:RequestSecurityTokenMsg"/>
> http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/ValidateFinal;
> message="tns:RequestSecurityTokenResponseMsg"/>
> 
>
> Colm.
>
> On Tue, Mar 22, 2016 at 5:44 PM,  wrote:
>
> > Hi -
> >
> > I'm using the CXF 3.1.4 STSClient to write a simple test client for my
> > CXF-based STS. Requesting tokens has worked as expected, but
> > requesting validation of a token is having a problem. It would appear
> > that STSClient creates a proper RST, and gets a proper RSTR from the
> > STS. But something deep inside the stack is expecting a
> > RequestSecurityTokenResponseCollection
> > instead of a RequestSecurityTokenResponse, which is causing this
> exception:
> >
> > org.apache.cxf.interceptor.Fault: Unexpected element {
> >
> http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityTokenResponse
> > found.   Expected {
> > http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityTokenR
> > esponseCollection
> > .
> > at
> >
> org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.validatePart(DocLiteralInInterceptor.java:280)
> > at
> >
> org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:191)
> > at
> >
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> > at
> > org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:798)
> > at
> >
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1669)
> > at
> >
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1550)
> > at
> >
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1347)
> > at
> >
> org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56)
> > at
> > org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215)
> > at
> > org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> > at
> > org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:651)
> > at
> >
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> > at
> >
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> > at
> > org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
> > at
> > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
> > at
> > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:324)
> > at
> > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:277)
> > at
> >
> org.apache.cxf.ws.security.trust.AbstractSTSClient.validate(AbstractSTSClient.java:1124)
> > at
> >
> 

RE: STSClient.validateSecurityToken expects RequestSecurityTokenResponseCollection?

[Stephen.CTR.Chappell]

Yeah, that is exactly what my wsdl looks like. I think the problem is that I 
didn't specify a wsdlLocation in my client bean, only a location. That worked 
fine for the issue operation, but not at all for validate. So I tried 
configuring that and ran into some new problems, which I think is because the 
WSDL specifies security policy and the client uses WSS4JOutInterceptors to 
configure the outbound security. This is my client bean configuration:

  



http://localhost:9080/FAA-IAM-STS/STS-BST?wsdl"/>
http://docs.oasis-open.org/ws-sx/ws-trust/200512/}BSTSecurityTokenService"/>
http://docs.oasis-open.org/ws-sx/ws-trust/200512/}STS_Port"/>


  

  


  

  


  
 

  


  


  



  
  
So I'm working on configuring the right properties in the property map to make 
it all work. Am I on the right track with that?

Thanx,

Stephen W. Chappell



-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Wednesday, March 23, 2016 7:27 AM
To: users@cxf.apache.org
Subject: Re: STSClient.validateSecurityToken expects 
RequestSecurityTokenResponseCollection?

What does your WSDL look like? At a guess it is expecting the Collection to be 
returned as opposed to the single element. The portType should look something 
like:


http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Validate;
message="tns:RequestSecurityTokenMsg"/>
http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/ValidateFinal;
message="tns:RequestSecurityTokenResponseMsg"/>


Colm.

On Tue, Mar 22, 2016 at 5:44 PM,  wrote:

> Hi -
>
> I'm using the CXF 3.1.4 STSClient to write a simple test client for my 
> CXF-based STS. Requesting tokens has worked as expected, but 
> requesting validation of a token is having a problem. It would appear 
> that STSClient creates a proper RST, and gets a proper RSTR from the 
> STS. But something deep inside the stack is expecting a 
> RequestSecurityTokenResponseCollection
> instead of a RequestSecurityTokenResponse, which is causing this exception:
>
> org.apache.cxf.interceptor.Fault: Unexpected element { 
> http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityTokenResponse
> found.   Expected {
> http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityTokenR
> esponseCollection
> .
> at
> org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.validatePart(DocLiteralInInterceptor.java:280)
> at
> org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:191)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:798)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1669)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1550)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1347)
> at
> org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56)
> at
> org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215)
> at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at
> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:651)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
> at
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
> at
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:324)
> at
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:277)
> at
> org.apache.cxf.ws.security.trust.AbstractSTSClient.validate(AbstractSTSClient.java:1124)
> at
> org.apache.cxf.ws.security.trust.STSClient.validateSecurityToken(STSClient.java:105)
> at
> org.apache.cxf.ws.security.trust.STSClient.validateSecurityToken(STSClient.java:100)
> at
> gov.faa.iam.sts.IAMSTSTestClient.sendValidateRequest(IAMSTSTestClient.java:242)
> at
> gov.faa.iam.sts.IAMSTSTestClient.run(IAMSTSTestClient.java:264)
> at
> gov.faa.iam.sts.IAMSTSTestClient.main(IAMSTSTestClient.java:326)
>
> I really don't want to change the STS at this point to return a RSTRC 
> for validations. 

Re: STSClient.validateSecurityToken expects RequestSecurityTokenResponseCollection?

[Colm O hEigeartaigh]

What does your WSDL look like? At a guess it is expecting the Collection to
be returned as opposed to the single element. The portType should look
something like:


http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Validate;
message="tns:RequestSecurityTokenMsg"/>
http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/ValidateFinal;
message="tns:RequestSecurityTokenResponseMsg"/>


Colm.

On Tue, Mar 22, 2016 at 5:44 PM,  wrote:

> Hi -
>
> I'm using the CXF 3.1.4 STSClient to write a simple test client for my
> CXF-based STS. Requesting tokens has worked as expected, but requesting
> validation of a token is having a problem. It would appear that STSClient
> creates a proper RST, and gets a proper RSTR from the STS. But something
> deep inside the stack is expecting a RequestSecurityTokenResponseCollection
> instead of a RequestSecurityTokenResponse, which is causing this exception:
>
> org.apache.cxf.interceptor.Fault: Unexpected element {
> http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityTokenResponse
> found.   Expected {
> http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityTokenResponseCollection
> .
> at
> org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.validatePart(DocLiteralInInterceptor.java:280)
> at
> org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:191)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:798)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1669)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1550)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1347)
> at
> org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56)
> at
> org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215)
> at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at
> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:651)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
> at
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
> at
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:324)
> at
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:277)
> at
> org.apache.cxf.ws.security.trust.AbstractSTSClient.validate(AbstractSTSClient.java:1124)
> at
> org.apache.cxf.ws.security.trust.STSClient.validateSecurityToken(STSClient.java:105)
> at
> org.apache.cxf.ws.security.trust.STSClient.validateSecurityToken(STSClient.java:100)
> at
> gov.faa.iam.sts.IAMSTSTestClient.sendValidateRequest(IAMSTSTestClient.java:242)
> at
> gov.faa.iam.sts.IAMSTSTestClient.run(IAMSTSTestClient.java:264)
> at
> gov.faa.iam.sts.IAMSTSTestClient.main(IAMSTSTestClient.java:326)
>
> I really don't want to change the STS at this point to return a RSTRC for
> validations. But it's not clear what to change in the STSClient to deal
> with the RSTR - there's already code there for handling it, but the
> execution doesn't look like it's getting that far. I'm not even sure why it
> says it's expecting an RSTRC. Does anyone have any ideas on what might be
> happening here?
>
> Thanx,
>
>
> Stephen W. Chappell
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Encrypting timestamp or other security headers using WS-SecurityPolicy

[Colm O hEigeartaigh]

If you are using the  SymmetricBinding or AsymmetricBinding policies, the
Timestamp is automatically signed if the "IncludeTimestamp" policy is in
the Binding policy.

The "sp:Header" policy in SignedParts/EncryptedParts is designed to be used
for SOAP headers, not for internal headers in the security header (such as
Timestamp). Instead, use an "EncryptedElements" policy, with an XPath
expression pointing to the Timestamp.

Colm.

On Tue, Mar 22, 2016 at 3:17 AM, Giriraj Bhojak  wrote:

> Hello,
>
>
> I need to sign and encrypt the timestamp WS-Security header.
>
> My policy file has following assertions:
>
>
>
> 
>
>
>
>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> " />
>
> 
>
> 
>
>
>
>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> " />
>
> 
>
>  Above namespace belongs to wsu element.
>
> I can still see following entry in the wsse:Security element:
>
>
>
>  wsu:Id="TS-A91AE37C42BC91148914586148175181">
>
>
>  2016-03-22T02:46:57.516Z
>
>
>  2016-03-22T02:51:57.516Z
>
> 
>
>
>
> If I try to add the namespace of wsse into the signed and encrypted parts
> above in order to encrypt and sign entire header as follows:
>
> 
>
>
>
>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> " />
>
> 
>
> 
>
>
>
>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> " />
>
> 
>
>
>
> Then on the CXF server I get:
>
> org.apache.cxf.interceptor.Fault- Exception Message: Found element {
> http://www.w3.org/2001/04/xmlenc#}EncryptionMethod but could not find
> matching RPC/Literal part
>
> I am using CXF v2.7.11.
>
> Am I doing something wrong?
>
> Thanks,
> Giriraj
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: trying to unsubscribe

[Colm O hEigeartaigh]

See here: http://cxf.apache.org/mailing-lists.html

Colm.

On Tue, Mar 22, 2016 at 7:43 PM, Tim Clotworthy <
tclotwor...@bluestonelogic.com> wrote:

> Hello,
>
> I am trying to unsubscribe to :
>
> users@cxf.apache.org
> any help is greatly appreciated. Thank you
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com