[JBoss JIRA] Created: (JBWS-2166) WSA client handler throws exception when installing reference parameters
by Andrew Dinn (JIRA)
WSA client handler throws exception when installing reference parameters
------------------------------------------------------------------------
Key: JBWS-2166
URL: http://jira.jboss.com/jira/browse/JBWS-2166
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.0.1
Reporter: Andrew Dinn
WSAddressingClientHandler.handleOutbound in package org.jboss.ws.extensions.addressing.jaxws is throwing the following exception when inserting reference parameters into a reply:
10:52:44,104 ERROR [SOAPFaultHelperJAXWS] SOAP request exception
javax.xml.ws.WebServiceException: org.w3c.dom.DOMException: WRONG_DOCUMENT_ERR: A node is used in a different document than the one that created it.
at org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.processHandlerFailure(HandlerChainExecutor.java:276)
at org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleMessage(HandlerChainExecutor.java:155)
at org.jboss.ws.core.jaxws.client.ClientImpl.callRequestHandlerChain(ClientImpl.java:191)
at org.jboss.ws.core.CommonClient.invoke(CommonClient.java:298)
at org.jboss.ws.core.jaxws.client.ClientImpl.invoke(ClientImpl.java:302)
at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:172)
at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:152)
at $Proxy93.soapFault(Unknown Source)
at com.arjuna.webservices11.wsaddr.client.SoapFaultClient.sendSoapFault(SoapFaultClient.java:72)
at com.arjuna.webservices11.wsat.client.ParticipantClient.sendSoapFault(ParticipantClient.java:150)
at com.arjuna.wst11.messaging.CoordinatorProcessorImpl.sendInvalidState(CoordinatorProcessorImpl.java:272)
at com.arjuna.wst11.messaging.CoordinatorProcessorImpl.prepared(CoordinatorProcessorImpl.java:176)
at com.arjuna.webservices11.wsat.sei.CoordinatorPortTypeImpl$1.executeTask(CoordinatorPortTypeImpl.java:61)
at com.arjuna.services.framework.task.TaskWorker.run(TaskWorker.java:65)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.w3c.dom.DOMException: WRONG_DOCUMENT_ERR: A node is used in a different document than the one that created it.
at org.apache.xerces.dom.ParentNode.internalInsertBefore(Unknown Source)
at org.apache.xerces.dom.ParentNode.insertBefore(Unknown Source)
at org.apache.xerces.dom.NodeImpl.appendChild(Unknown Source)
at org.jboss.ws.core.soap.NodeImpl.appendChild(NodeImpl.java:477)
at org.jboss.ws.core.soap.SOAPHeaderImpl.appendChild(SOAPHeaderImpl.java:198)
at org.jboss.ws.core.soap.SOAPElementImpl.addChildElement(SOAPElementImpl.java:274)
at org.jboss.ws.core.soap.SOAPHeaderImpl.addChildElement(SOAPHeaderImpl.java:70)
at org.jboss.ws.extensions.addressing.soap.SOAPAddressingPropertiesImpl.appendElement(SOAPAddressingPropertiesImpl.java:374)
at org.jboss.ws.extensions.addressing.soap.SOAPAddressingPropertiesImpl.appendElements(SOAPAddressingPropertiesImpl.java:352)
at org.jboss.ws.extensions.addressing.soap.SOAPAddressingPropertiesImpl.writeHeaders(SOAPAddressingPropertiesImpl.java:306)
at org.jboss.ws.extensions.addressing.jaxws.WSAddressingClientHandler.handleOutbound(WSAddressingClientHandler.java:113)
at org.jboss.ws.core.jaxws.handler.GenericHandler.handleMessage(GenericHandler.java:55)
at org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleMessage(HandlerChainExecutor.java:295)
at org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleMessage(HandlerChainExecutor.java:140)
... 13 more
The situation which manifests this problem is as follows:
Client A attaches WS AddressingProperties to a port for server B, It installs a ReplyTo epr whose address identifies server A. It attaches a reference parameter wsarj:identifier to the epr. Client A then invokes service B.
The implementation method of service B retrieves the request AddressingProperties from its message context and sets up a reply AddressingProperties instance by calling AddressingProperties.initializeAsReply. It obtains a port for service A, installs the reply properties on the port then invokes service A. The client handler under this invocation gets the error.
The problem is that the SOAP implementation does not copy the reference parameter Element instance when it tries to insert them into the outgoing message. intiializeAsReply retrieves these elements from the incoming context ReplyTo/FaultTo and adds them to the element extension list of the reply addressing context. The client handler calls SOAPAddressingHandlerImpl.writeHeaders to add these elements as headers in the outbound message. writeHeaders eventually calls SOAPHeaderImpl.addChildElement to add each reference parameter Element to the outgoing message header. addChildElement tests whether the Element is a SOAP element and, if so, assumes that it can be inserted directly into the outgoing message by calling appendElement. Unfortunately, the incoming reference parameters are associated with a dom node whose document is non-null and this barfs,claiming that someone is attempting a switcheroo on the document.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (JBWS-1932) Unable to narrow port selection for UnifiedPortComponentRef
by Chris Laprun (JIRA)
Unable to narrow port selection for UnifiedPortComponentRef
-----------------------------------------------------------
Key: JBWS-1932
URL: http://jira.jboss.com/jira/browse/JBWS-1932
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-jaxrpc
Affects Versions: jbossws-2.0.2
Reporter: Chris Laprun
Assigned To: Thomas Diesler
Each time my client application tries to retrieve a service endpoint to invoke web service operations, I get the following warning on the console:
WARN [org.jboss.ws.core.client.ServiceObjectFactory] Unable to narrow port selection for
UnifiedPortComponentRef
serviceEndpointInterface=org.jboss.portal.wsrp.core.WSRP_v1_Registration_PortType
portQName=null
enableMTOM=false
portComponentLink=null
callProperties=[]
stubProperties=[]
configName=null
configFile=null
This doesn't seem to have any ill consequences that I can notice in my testing but I'd like to solve the problem if possible.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (JBWS-1999) WS-Security Usename Token Profile JAAS Implementation for JSE based WebServices
by Thomas Diesler (JIRA)
WS-Security Usename Token Profile JAAS Implementation for JSE based WebServices
-------------------------------------------------------------------------------
Key: JBWS-1999
URL: http://jira.jboss.com/jira/browse/JBWS-1999
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Components: jbossws-native
Reporter: Thomas Diesler
Fix For: jbossws-native-2.0.4
Karl de Boer sais:
I created a Username TokenProfile implementation where the userid pwd are verified against the active JAAS SecurityManager
I want to share this with you.
It appears to me there is only support for EJB based webservices for this. So i had to create it myself in the form of a messagehandler and some glue to integrate with JBossSX.
In general i think the focus is to much on EJB Based services. I prefer the WSDL first approach to define a proper SOA.
It is not a perfect implementation. I do'nt do anything with Nonce and Timestamp and i also do not support passwordDigest.
So i also do not use any keystores (PasswordText is protect by the transport layer in my case (SSL)). I saw there is an issue in JIRA where the keystore shoud not be required. This is such a case.
I also was surprised that JBossWS does not check anymore for the requires Username section in Jboss-wsse-server.xml. But for this there is also as JIRA issue
What i did in a separate messagehandler should perhaps be moved to the WSSecurityDispatcher, which takes care of all WSSecurity related stuff.
To activate the messagehandler processing i simply adjusted the default the standard-jaxws-endpoint-config.xml
<endpoint-config>
<config-name>Standard WSSecurity Endpoint</config-name>
<post-handler-chains>
<javaee:handler-chain>
<javaee:protocol-bindings>##SOAP11_HTTP</javaee:protocol-bindings>
<javaee:handler>
<javaee:handler-name>WSSecurity Handler</javaee:handler-name>
<javaee:handler-class>org.jboss.ws.extensions.security.jaxws.WSSecurityHandlerServer</javaee:handler-class>
</javaee:handler>
<javaee:handler>
<javaee:handler-name>UserNameTokenProfileMessageHandler</javaee:handler-name>
<javaee:handler-class>nl.jnc.common.services.wssecurity.UserNameTokenProfileMessageHandler</javaee:handler-class>
</javaee:handler>
</javaee:handler-chain>
</post-handler-chains>
</endpoint-config>
I did not investigate how to link the authenticated user (principal) and associated roles to the WebServiceContext. I directly refer to the SecurityAssociation class which stores Subject and Principal in threadlocal.
In the SEI implementaion is use the princiap and roles like this (cloul be improved):
private boolean isUserInRole(String roleName) {
Subject sub = SecurityAssociation.getSubject();
if (sub != null) {
Set<Principal> set = SecurityAssociation.getSubject().getPrincipals();
if (set!= null) {
for (Principal p : set) {
if (p instanceof SimpleGroup) {
SimpleGroup ng = (SimpleGroup) p;
Enumeration mem = ng.members();
while (mem.hasMoreElements()) {
Principal p1 = (Principal) mem.nextElement();
if (p1.getName().equalsIgnoreCase(roleName)) return true;
}
}
}
}
}
return false;
}
Attached you will find the rest. You are free to use it the way you like.
In the WsSecurityManager you will also find some a method to authenticate a user with a certificate but this is not tested.
I use the security implementation against an LDAP (LdapLoginModule). The users are system accounts, the data(sections) returned by the service are governed by the roles a system users has.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 11 months