java.lang.IndexOutOfBoundsException at org.apache.cxf.message.MessageContentsList.get(MessageContentsList.java:80)
Hi,
I have a WebService Client wsdl that should allow me to PULL an XML file
with embedded PDF attachment from a WebService Server.
Below is the summary of the WSDL:
wsdl:types
xs:schema
attributeFormDefault=unqualified
elementFormDefault=qualified
targetNamespace=http://www.sterlingcommerce.com/mesa;
xmlns=http://www.sterlingcommerce.com/mesa;
xmlns:tns=http://www.sterlingcommerce.com/mesa;
xmlns:ref=http://ws-i.org/profiles/basic/1.1/xsd
xmlns:xs=http://www.w3.org/2001/XMLSchema;
xs:import
namespace=http://ws-i.org/profiles/basic/1.1/xsd;
schemaLocation=swaref.xsd/
xs:complexType
name=Binary
xs:simpleContent
xs:extension base=xs:base64Binary
xs:attribute name=href type=ref:swaRef/
/xs:extension
/xs:simpleContent
/xs:complexType
xs:element
name=attachment type=Binary/
/xs:schema
xs:schema
attributeFormDefault=unqualified
elementFormDefault=qualified
targetNamespace=http://address/jbms/msggate/reqresp/v1;
xmlns=http://customs.govt.nz/jbms/msggate/reqresp/v1;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
xs:element
name=RequestResponseResponse
...
/xs:element
xs:element
name=RequestResponse
...
/xs:element
/xs:schema
/wsdl:types
wsdl:message name=TSW_BP_REQUEST_RESPONSE
wsdl:part element=tns1:RequestResponse
name=parameters/
/wsdl:message
wsdl:message name=TSW_BP_REQUEST_RESPONSEOutput
xmlns:xs=http://www.w3.org/2001/XMLSchema;
wsdl:part
element=tns1:RequestResponseResponse name=parameters/
wsdl:part element=mesa_xsd:attachment
name=attachment/
/wsdl:message
wsdl:portType name=GISPortType
wsdl:operation
name=executeTSW_BP_REQUEST_RESPONSE
wsdl:input
message=mesa_xsd:TSW_BP_REQUEST_RESPONSE/
wsdl:output
message=mesa_xsd:TSW_BP_REQUEST_RESPONSEOutput/
/wsdl:operation
/wsdl:portType
wsdl:binding name=GISBinding type=mesa_xsd:GISPortType
soap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation
name=executeTSW_BP_REQUEST_RESPONSE
soap:operation
soapAction=sii:TSW_BP_REQUEST_RESPONSE style=document/
wsdl:input
wsp:PolicyReference URI=#X509V3SignOnly/
soap:body
use=literal/
/wsdl:input
wsdl:output
wsp:PolicyReference URI=#X509V3SignOnly/
mime:multipartRelated
mime:part
soap:body use=literal/
/mime:part
/mime:multipartRelated
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:service name=TSW_WS_REQUEST_LODGE_RESPONSE
wsdl:port binding=mesa_xsd:GISBinding
name=GISPort
soap:address
location=https://[address]/soap-new?service=TSW_WS_REQUEST_LODGE_RESPONSEa
mp;TP=B2BE/
/wsdl:port
/wsdl:service
And below are summary Stub Code generated by cxf:
Binary.java
public class Binary {
protected byte[] value;
protected DataHandler href;
...
}
GISPortType.java
public interface SubmitLodgementPortType {
public void executeTSWBPREQUESTRESPONSE(parameters,
javax.xml.ws.HolderRequestResponseResponse parameters1,
javax.xml.ws.HolderBinary attachment);
}
Below is my main Client code:
public class WSClient
{
public static void main(String[] args)
{
TSWWSREQUESTLODGERESPONSE service = new
TSWWSREQUESTLODGERESPONSE();
GISPortType port = service.getGISPort();
try
{
Client client = ClientProxy.getClient(proxy);
client.getInInterceptors().add(new
LoggingInInterceptor());
Re: Schema Validation with non-WSDL endpoint?
Hi, I am not sure how you want to set it up. Where do you expect the corresponding schema to be specified? Specified in the message arbitrarily to just validate it own validity claim or some out of bands schemas are specified for the endpoint to accept or reject messages? regards, aki 2015-06-17 11:28 GMT+02:00 Jens smix...@dzbank.de: Hi, I have a (Camel) CXF endpoint that has no WSDL attached because it can receive messages for various services. I'd still like the endpoint to validate requests, though, ideally by looking up the schema to use from an XML catalog or the like. I have enabled schema validation on the endpoint, and it works fine if I supply a WSDL, but it doesn't work without the WSDL. Is there a way to have CXF validate the request with a setup like that? Thanks, Jens -- View this message in context: http://cxf.547215.n5.nabble.com/Schema-Validation-with-non-WSDL-endpoint-tp5758353.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: Schema Validation with non-WSDL endpoint?
Ideally, CXF would just peek at the namespace on the message, pick the schema corresponding to that namespace from the XML catalog and validate against that. Cheers, Jens Aki Yoshida-3 wrote Hi, I am not sure how you want to set it up. Where do you expect the corresponding schema to be specified? Specified in the message arbitrarily to just validate it own validity claim or some out of bands schemas are specified for the endpoint to accept or reject messages? regards, aki 2015-06-17 11:28 GMT+02:00 Jens lt; smixdev@ gt;: Hi, I have a (Camel) CXF endpoint that has no WSDL attached because it can receive messages for various services. I'd still like the endpoint to validate requests, though, ideally by looking up the schema to use from an XML catalog or the like. I have enabled schema validation on the endpoint, and it works fine if I supply a WSDL, but it doesn't work without the WSDL. Is there a way to have CXF validate the request with a setup like that? Thanks, Jens -- View this message in context: http://cxf.547215.n5.nabble.com/Schema-Validation-with-non-WSDL-endpoint-tp5758353.html Sent from the cxf-user mailing list archive at Nabble.com. -- View this message in context: http://cxf.547215.n5.nabble.com/Schema-Validation-with-non-WSDL-endpoint-tp5758353p5758419.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: (WS-Security) Authentication Only with X509
Hi,
We don't support BinarySecurityToken SupportingToken policies on their own
in CXF (i.e. without a security binding). The reason being is that they are
largely pointless - you mention wanting an X.509 cert for authentication,
but as there is no signature, there is no proof-of-possession associated
with the certificate. Hence no authentication at all - all the client is
proving is that they are in possession of the certificate, nothing more.
However, it should be very easy enough for you to support this use-case if
you are willing to do a small bit of implementation. We have a core class
that should process the BinarySecurityToken here:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/BinarySecurityTokenInterceptor.java;h=d086673fa8ad54441261c1f7698073851abb02c7;hb=HEAD
For Kerberos we extend it just to assert some policies:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/KerberosTokenInterceptor.java;h=de83d7b453472743d6dc2aa7931ff3f81b765339;hb=HEAD
You will need to likewise to assert the X509Token policies. Then you need
to register your interceptor. This is how the Kerberos registration is done:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=rt/ws/security/src/main/java/org/apache/cxf/ws/security/policy/interceptors/KerberosTokenInterceptorProvider.java;h=7d93cb3330029d00246d6e4c6bc1ab1937065080;hb=HEAD
Colm.
On Mon, Jun 15, 2015 at 2:05 PM, Chad Sturtz sturt...@gmail.com wrote:
Hello,
I'm working on WS-Security based authentication with an X509 certificate
for a JAXWS service. I'm looking for help/confirmation on what a valid
Policy would look like in the WSDL. Most X509 policy examples include
signing/encryption, which I do not need (based solely on my requirements).
Below is the policy I have come up. If you see any errors or can offer any
thoughts on its correctness, I'd appreciate it.
wsp:Policy wsu:Id=MyBindingPolicy
wsp:ExactlyOne
wsp:All
sp:SupportingTokens
wsp:Policy
sp:X509Token
sp:IncludeToken=
http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient
wsp:Policy/
/sp:X509Token
/wsp:Policy
/sp:SupportingTokens
/wsp:All
/wsp:ExactlyOne
/wsp:Policy
I wouldn't be here if I could get authentication working on my service with
this policy. When I invoke the service, I end up with the stack trace you
can see at the bottom of this email. Through working with a few example
projects from github, I know that an issue with the Policy can result in
this exception.
Here are some additional details. If there's any more information you'd
like to see, please let me know. Thanks in advance!
CXF Version 2.7.16
Relevant Namespaces Used:
1. xmlns:wsp=http://www.w3.org/ns/ws-policy;
2. xmlns:wsu=
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
3. xmlns:sp=http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702;
4. xmlns:wsse=
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
JAXWS Endpoint Properties:
The only property I'm setting is ws-security.bst.validator. I believe the
defaults for other properties are acceptable to me.
WS-Security Header from a request I'm sending:
soap:Header
wsse:Security
xmlns:wsse=
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
xmlns:wsu=
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
soap:mustUnderstand=1
wsse:BinarySecurityToken
EncodingType=
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary
ValueType=
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3
wsu:Id=SecurityToken-f6f96b4b-23c5-421e-92ff-f1050d531e82MIIBoTCCAQqgA
[...] vONEqd9wa4XuA==
/wsse:BinarySecurityToken
/wsse:Security
/soap:Header
Stack Trace:
08:25:38,153 INFO [stdout] (http-/127.0.0.1:8080-1)
org.apache.cxf.ws.policy.PolicyException: These policy alternatives can not
be satisfied:
08:25:38,154 INFO [stdout] (http-/127.0.0.1:8080-1) {
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SupportingTokens
08:25:38,155 INFO [stdout] (http-/127.0.0.1:8080-1) {
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}X509Token
08:25:38,156 INFO [stdout] (http-/127.0.0.1:8080-1) at
org.apache.cxf.ws.policy.AssertionInfoMap.checkEffectivePolicy(AssertionInfoMap.java:179)
~[cxf-rt-ws-policy-2.7.16.jar:2.7.16]
08:25:38,157 INFO [stdout] (http-/127.0.0.1:8080-1) at
org.apache.cxf.ws.policy.PolicyVerificationInInterceptor.handle(PolicyVerificationInInterceptor.java:101)
~[cxf-rt-ws-policy-2.7.16.jar:2.7.16]
08:25:38,157 INFO [stdout] (http-/127.0.0.1:8080-1) at
Re: Issue with the renew of SCT in Secure Conversation
Could you create JIRAs in WSS4J + CXF and attach the patches there? Colm. On Wed, Jun 17, 2015 at 3:44 PM, Freddy Exposito expos...@gmail.com wrote: Secure Conversation Renew is not working from a .NET client because ws:Instance is missing in the SecurityContextToken. Reading into the standard here - http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/os/ws-secureconversation-1.4-spec-os.html says the following: The initial issuance need not contain a wsc:Instance element, however, all subsequent issuances with different keys MUST have a wsc:Instance element with a unique value. Also a reference seems to be required in the SecurityTokenRefernce according to this: If a specific key instance needs to be referenced, then the global attribute wsc:Instance is included in the wsse:Reference sub-element (only when using wsc:Identifier references) The following patches for wss4j (2.0.x branch) wss4j-sct-with-instance.patch http://cxf.547215.n5.nabble.com/file/n5758363/wss4j-sct-with-instance.patch and cxf (3.0.x branch) cxf-sct-with-instance.patch http://cxf.547215.n5.nabble.com/file/n5758363/cxf-sct-with-instance.patch work for us. Would be possible to include this in the next cxf and wss4j releases? Thanks, Freddy -- View this message in context: http://cxf.547215.n5.nabble.com/Issue-with-the-renew-of-SCT-in-Secure-Conversation-tp5758363.html Sent from the cxf-user mailing list archive at Nabble.com. -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
Re: fed decrypt error
Does your service keystore have the private key for bamssouat in it? Or
just the certificate? What is the output of keytool -list -keystore
keystore.jks -v?
Colm.
On Tue, Jun 16, 2015 at 8:26 PM, Vishnu Radhakrishnan vis...@10point1.com
wrote:
I am getting the below error while decrypting the RST.
All the certificates seems to be in place not sure why its erroring out.
Any
help regarding the below would be great.
Thanks,
Vishnu
[http-bio-8080-exec-10] INFO
org.apache.cxf.fediz.core.FederationProcessorImpl - +DEBUG
INFO+
2015-06-16 19:21:12,261 ERROR Merlin - Cannot find key for alias:
[bamssouat] in keystore of type [JKS] from provider [SUN version 1.7] with
size [7] and aliases: {bamsso_rootcert, bamssouat, bamssoselfsigned,
bamssokeyuat, mykey, bam_devsso, mykeyname}
[http-bio-8080-exec-10] INFO
org.apache.cxf.fediz.core.FederationProcessorImpl - The signature or
decryption was invalid
org.apache.ws.security.WSSecurityException: The signature or decryption was
invalid
at
org.apache.ws.security.processor.EncryptedKeyProcessor.handleToken(Encrypted
KeyProcessor.java:163)
at
org.apache.ws.security.processor.EncryptedKeyProcessor.handleToken(Encrypted
KeyProcessor.java:66)
at
org.apache.ws.security.processor.EncryptedDataProcessor.handleToken(Encrypte
dDataProcessor.java:113)
at
org.apache.cxf.fediz.core.FederationProcessorImpl.decryptEncryptedRST(Federa
tionProcessorImpl.java:295)
at
org.apache.cxf.fediz.core.FederationProcessorImpl.processSignInRequest(Feder
ationProcessorImpl.java:184)
at
org.apache.cxf.fediz.core.FederationProcessorImpl.processRequest(FederationP
rocessorImpl.java:85)
at
org.apache.cxf.fediz.spring.authentication.FederationAuthenticationProvider.
authenticateNow(FederationAuthenticationProvider.java:126)
at
org.apache.cxf.fediz.spring.authentication.FederationAuthenticationProvider.
authenticate(FederationAuthenticationProvider.java:109)
at
com.w1.auth.sso.FedizAuthenticationProvider.authenticate(FedizAuthentication
Provider.java:29)
at
org.springframework.security.authentication.ProviderManager.authenticate(Pro
viderManager.java:156)
at
org.apache.cxf.fediz.spring.web.FederationAuthenticationFilter.attemptAuthen
tication(FederationAuthenticationFilter.java:62)
at
com.w1.auth.sso.InstreamFederationAuthenticationFilter.attemptAuthentication
(InstreamFederationAuthenticationFilter.java:28)
at
org.springframework.security.web.authentication.AbstractAuthenticationProces
singFilter.doFilter(AbstractAuthenticationProcessingFilter.java:195)
at
com.w1.auth.sso.DelegatingAuthenticationProcessingFilter.doFilter(Delegating
AuthenticationProcessingFilter.java:40)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilte
r(FilterChainProxy.java:342)
at
org.springframework.security.web.authentication.AbstractAuthenticationProces
singFilter.doFilter(AbstractAuthenticationProcessingFilter.java:183)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilte
r(FilterChainProxy.java:342)
at
org.springframework.security.web.authentication.logout.LogoutFilter.doFilter
(LogoutFilter.java:105)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilte
r(FilterChainProxy.java:342)
at
org.springframework.security.web.context.SecurityContextPersistenceFilter.do
Filter(SecurityContextPersistenceFilter.java:65)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilte
r(FilterChainProxy.java:342)
at
org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterCha
inProxy.java:192)
at
org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.
java:166)
at
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(Delegati
ngFilterProxy.java:343)
at
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilt
erProxy.java:260)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:241)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:208)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.
java:748)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDis
patcher.java:486)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatch
er.java:411)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher
.java:338)
at
com.w1.auth.sso.AutenticationResource.federationLogout(AutenticationResource
.java:207)
at
com.w1.auth.sso.AutenticationResource$Proxy$_$$_WeldClientProxy.federationLo
gout(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57
)
--
Colm
Re: Regression from 3.0.5 to 3.1.1
Hi Aki, The issue stems from the fact that the policy has multiple security bindings (Symmetric + Transport). CXF 3.0.x checks for Symmetric before Transport, CXF 3.1.x checks for Transport before Symmetric. Therefore, the Body is not encrypted in CXF 3.1.x, as encryption is handled by the transport layer. After thinking about this, I am going to change it to the old behaviour, so it will be fixed for this use-case in 3.1.2. Colm. On Mon, Jun 15, 2015 at 2:43 PM, Aki Yoshida elak...@gmail.com wrote: @Colm Do you have an idea where the difference in the behavior comes from? thanks. regards, aki 2015-06-15 15:18 GMT+02:00 Pröls, Stefan s.pro...@pharmatechnik.de: Hi, here is some more info. I've attached the requests created with 3.0.5 and 3.1.1. They are very different. Actually I've done this twice since I couldn't believe these are the same requests... For instance, in 3.1.1 the body doesn't seem to be encrypted. Best regards, Stefan Am 15.06.2015 um 14:30 schrieb Pröls, Stefan: Hi, there is no difference at all between my 3.0.5 and 3.1.1 setup, other than that I've replaced the jar files from the (binary) CXF distributions. I've also tried to recompile my code against 3.1.1 but that didn't make a difference either. If also tried with 3.1.0 -- same problem. I realize that this is hard for you to analyze without code, certificates and being able to debug the whole thing... Unfortunately it isn't easier for myself either. I was hoping you might be able to identify the problem from the logs I sent with my first message maybe. Or possibly by comparing the WS-Security stuff from the WSDL to your ChangeLogs. I realize the chances ain't very good... Best regards, Stefan Am 15.06.2015 um 14:10 schrieb Aki Yoshida: Hi Stefan, So, we have two separate issues. 1. your request message gets rejected at the server with error code R-206. It seems to say that the certificate used was not the one expected by the server? In other words, the signature itself is not corrupt but it is signed by the wrong certificate? If that is the case, it looks like there is some difference in your 3.0.5 and 3.1.1 configuration? 2. the generated SOAP fault is invalid, as it violates the SOAP 1.2's fault code rule mentioned earlier. This needs to be fixed at the server. For the CXF client, I think we can handle this condition more gracefully and not throwing UndeclaredThrowableException. regards, aki 2015-06-15 13:45 GMT+02:00 Pröls, Stefan s.pro...@pharmatechnik.de: Hi, hmm, actually the server should not return a SOAP fault at all for my request, and it doesn't if I'm creating the request with CXF 3.0.5. I've added a LoggingInInterceptor to catch the SOAP fault, here it is: s:Envelope xmlns:s=http://www.w3.org/2003/05/soap-envelope; xmlns:a=http://www.w3.org/2005/08/addressing; s:Header a:Action s:mustUnderstand=1http://www.w3.org/2005/08/addressing/soap/fault /a:Action a:RelatesTourn:uuid:af9c75b2-3d20-4bd3-a5b1-109d0d0e1d91/a:RelatesTo /s:Header s:Body s:Fault s:Code s:Value xmlns:a=http://mps.avs.abdata.aponet.de/faults;a:Sender/s:Value /s:Code s:Reason s:Text xml:lang=Fehler-Code: R-206#xD; Das zur Signierung der Daten verwendete Zertifikat ist ungültig.#xD; #xD; Bitte wenden Sie sich unter Angabe des Fehler-Codes 'R-206' an ihr Systemhaus.#xD; #xD; Fehler-Code: R-206 /s:Text /s:Reason /s:Fault /s:Body /s:Envelope Das zur Signierung der Daten verwendete Zertifikat ist ungültig translates to The certificate used for signing is not valid. However, I'm sure it is valid. Seems like something in the signature got broken from the 3.0 to the 3.1 series. Best regards, Stefan Am 15.06.2015 um 13:25 schrieb Aki Yoshida: You are using soap 1.2. and soap 1.2 allows only one of the standard fault codes. http://www.w3.org/TR/soap12-part1/#faultcodes http://www.w3.org/TR/soap12-part1/#tabsoapfaultcodes If you were using soap 1.1, there should be no check so your custom code will get accepted. regards, aki 2015-06-15 12:53 GMT+02:00 Pröls, Stefan s.pro...@pharmatechnik.de : Hello, I'm using JDK 1.8.0_45 on Linux with both CXF 3.0.5 and CXF 3.1.1. Best regards, Stefan Am 15.06.2015 um 12:46 schrieb Aki Yoshida: which jdk version are you using? I think this has probably something to do with your jdk version. 2015-06-15 10:53 GMT+02:00 Pröls, Stefan s.pro...@pharmatechnik.de: Hello, I'm having trouble upgrading my WebService-client from CXF 3.0.5 to 3.1.1. It works very well with 3.0.5, but throws a java.lang.reflect.UndeclaredThrowableException at
Re: Calling kerberosmixed endpoint on ADFS
This policy does not look right, try removing it:
KeyValueToken IncludeToken= Optional=
Policy /
/KeyValueToken
Colm.
On Fri, Jun 12, 2015 at 1:09 PM, niranjana.murthy
niranjana.billa...@gmail.com wrote:
I tried with cxf 3.0.1 and ran into some other errors. I have attached my
policy file as well. Please suggest.
Jun 12, 2015 5:33:54 PM
org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl
handleNoRegisteredBuilder
WARNING: No assertion builder for type
{
http://schemas.microsoft.com/ws/06/2004/policy/http}NegotiateAuthentication
registered.
Jun 12, 2015 5:33:54 PM
org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl
handleNoRegisteredBuilder
WARNING: No assertion builder for type
{http://schemas.microsoft.com/ws/2005/07/securitypolicy}RsaToken
registered.
Jun 12, 2015 5:33:54 PM
org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl
handleNoRegisteredBuilder
WARNING: No assertion builder for type KeyValueToken registered.
Jun 12, 2015 5:33:54 PM
org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider
getElementPolicy
WARNING: Failed to build the policy
'CustomBinding_IWSTrust13Async_policy':Invalid Policy
Jun 12, 2015 5:33:54 PM
org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider
getElementPolicy
WARNING: Failed to build the policy
'IssuedTokenWSTrustBinding_IWSTrust13Async_policy':Invalid Policy
Jun 12, 2015 5:33:54 PM
org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider
getElementPolicy
WARNING: Failed to build the policy
'IssuedTokenWSTrustBinding_IWSTrust13Async1_policy':Invalid Policy
Jun 12, 2015 5:33:54 PM
org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider
getElementPolicy
WARNING: Failed to build the policy
'CustomBinding_IWSTrust13Async1_policy':Invalid Policy server-wsdl.wsdl
http://cxf.547215.n5.nabble.com/file/n5758256/server-wsdl.wsdl
Caused by: org.apache.cxf.ws.policy.PolicyException: None of the policy
alternatives can be satisfied.
at
org.apache.cxf.ws.policy.EndpointPolicyImpl.chooseAlternative(EndpointPolicyImpl.java:166)
at
org.apache.cxf.ws.policy.EndpointPolicyImpl.finalizeConfig(EndpointPolicyImpl.java:145)
at
org.apache.cxf.ws.policy.EndpointPolicyImpl.initialize(EndpointPolicyImpl.java:141)
at
org.apache.cxf.ws.policy.PolicyEngineImpl.createEndpointPolicyInfo(PolicyEngineImpl.java:584)
at
org.apache.cxf.ws.policy.PolicyEngineImpl.getEndpointPolicy(PolicyEngineImpl.java:313)
at
org.apache.cxf.ws.policy.PolicyEngineImpl.getClientEndpointPolicy(PolicyEngineImpl.java:294)
at
org.apache.cxf.ws.policy.PolicyDataEngineImpl.getClientEndpointPolicy(PolicyDataEngineImpl.java:61)
at
org.apache.cxf.transport.http.HTTPConduit.updateClientPolicy(HTTPConduit.java:316)
at
org.apache.cxf.transport.http.HTTPConduit.getClient(HTTPConduit.java:850)
at
org.apache.cxf.transport.http.HTTPConduit.configureConduitFromEndpointInfo(HTTPConduit.java:347)
at
org.apache.cxf.transport.http.HTTPConduit.finalizeConfig(HTTPConduit.java:427)
at
org.apache.cxf.transport.http.HTTPTransportFactory.getConduit(HTTPTransportFactory.java:242)
at
org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransportFactory.java:222)
at
org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransportFactory.java:229)
at
org.apache.cxf.endpoint.AbstractConduitSelector.createConduit(AbstractConduitSelector.java:145)
at
org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(AbstractConduitSelector.java:107)
at
org.apache.cxf.endpoint.UpfrontConduitSelector.selectConduit(UpfrontConduitSelector.java:77)
at
org.apache.cxf.endpoint.ClientImpl.getConduit(ClientImpl.java:845)
at
org.apache.cxf.ws.security.trust.AbstractSTSClient.findOperation(AbstractSTSClient.java:681)
at
org.apache.cxf.ws.security.trust.AbstractSTSClient.issue(AbstractSTSClient.java:716)
at
org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:62)
at
org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:56)
at
org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:52)
at
com.mmodal.mmnet.impl.TokenFactoryImpl.getUsernameBasedToken(TokenFactoryImpl.java:269)
--
View this message in context:
http://cxf.547215.n5.nabble.com/Calling-kerberosmixed-endpoint-on-ADFS-tp5758202p5758256.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Schema Validation with non-WSDL endpoint?
If the ServiceInfo object has a Schema.class property on it that would represent all the possible schemas, it should work. Thus, if you can build up a javax.xml.validation.Schema object somehow, you would just need to get that set on the ServiceInfo. This could be done during startup if you can get the ServiceInfo object or via an interceptor that runs early in the chain. Dan On Jun 17, 2015, at 5:28 AM, Jens smix...@dzbank.de wrote: Hi, I have a (Camel) CXF endpoint that has no WSDL attached because it can receive messages for various services. I'd still like the endpoint to validate requests, though, ideally by looking up the schema to use from an XML catalog or the like. I have enabled schema validation on the endpoint, and it works fine if I supply a WSDL, but it doesn't work without the WSDL. Is there a way to have CXF validate the request with a setup like that? Thanks, Jens -- View this message in context: http://cxf.547215.n5.nabble.com/Schema-Validation-with-non-WSDL-endpoint-tp5758353.html Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Issue with the renew of SCT in Secure Conversation
The Jira tickets are: https://issues.apache.org/jira/browse/WSS-542 and https://issues.apache.org/jira/browse/CXF-6468 Thanks, Freddy -- View this message in context: http://cxf.547215.n5.nabble.com/Issue-with-the-renew-of-SCT-in-Secure-Conversation-tp5758363p5758445.html Sent from the cxf-user mailing list archive at Nabble.com.
Querying for the Encryption MGF Algorithm
When processing a security header, you can determine the key transport algorithm through WSSecurityEngineResult.TAG_ENCRYPTED_KEY_TRANSPORT_METHOD. Is there a similar tag that lets you query the new Encryption MGF Algorithm? I couldn't' find anything in WSSecurityEngineResult. Thanx. Stephen W. Chappell
