[JBoss JIRA] (JBWS-3432) WebservicesFactory can't parse webservices.xml with javaee:descriptionGroup references
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-3432?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated JBWS-3432:
----------------------------------
Assignee: Jim Ma (was: Alessio Soldano)
> WebservicesFactory can't parse webservices.xml with javaee:descriptionGroup references
> --------------------------------------------------------------------------------------
>
> Key: JBWS-3432
> URL: https://issues.jboss.org/browse/JBWS-3432
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jbossws-cxf, jbossws-integration, jbossws-native
> Reporter: Peter Skopek
> Assignee: Jim Ma
> Fix For: jbossws-cxf-4.0.2, jbossws-native-4.0.2
>
> Attachments: picketlink-sts.war
>
>
> webservices.xml with proper structure is refused to deploy due to parsing/validation error
> {noformat}
> <?xml version="1.0" encoding="UTF-8"?>
> <webservices xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/javaee_web_services_1_3.xsd"
> version="1.3">
> <description>PicketLink STS web service descriptor
> </description>
> <webservice-description>
> <webservice-description-name>
> PicketLinkSTS
> </webservice-description-name>
> <wsdl-file>
> WEB-INF/wsdl/PicketLinkSTS.wsdl
> </wsdl-file>
> <port-component>
> <description>PicketLink STS Port</description>
> <port-component-name>PicketLinkSTSPort</port-component-name>
> <wsdl-port xmlns:tns="urn:picketlink:identity-federation:sts">PicketLinkSTSPort</wsdl-port>
> <!-- TODO: we don't have interface yet
> <service-endpoint-interface>endpoint.WeatherService</service-endpoint-interface>
> -->
> <service-impl-bean>
> <servlet-link>PicketLinkSTS</servlet-link>
> </service-impl-bean>
> </port-component>
> </webservice-description>
> </webservices>
> {noformat}
> Deployer complains about both description tags (webservices/description and webservices/webservice-description/port-component/description).
> See exception:
> {noformat}
> 18:46:59,061 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.unit."picketlink-sts.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."picketlink-sts.war".PARSE: Failed to process phase PARSE of deployment "picketlink-sts.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> Caused by: javax.xml.ws.WebServiceException: Failed to unmarshall:vfs:/content/picketlink-sts.war/WEB-INF/webservices.xml
> at org.jboss.wsf.spi.metadata.webservices.WebservicesFactory.load(WebservicesFactory.java:143)
> at org.jboss.wsf.spi.metadata.webservices.WebservicesFactory.loadFromVFSRoot(WebservicesFactory.java:126)
> at org.jboss.as.webservices.deployers.WebservicesDescriptorDeploymentProcessor.deploy(WebservicesDescriptorDeploymentProcessor.java:48)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
> ... 5 more
> Caused by: java.lang.IllegalStateException: Unexpected element: description
> at org.jboss.wsf.spi.metadata.webservices.WebservicesFactory.parseWebservices(WebservicesFactory.java:237)
> at org.jboss.wsf.spi.metadata.webservices.WebservicesFactory.parse(WebservicesFactory.java:203)
> at org.jboss.wsf.spi.metadata.webservices.WebservicesFactory.load(WebservicesFactory.java:139)
> ... 8 more
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (JBWS-3432) WebservicesFactory can't parse webservices.xml with javaee:descriptionGroup references
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-3432?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated JBWS-3432:
----------------------------------
Summary: WebservicesFactory can't parse webservices.xml with javaee:descriptionGroup references (was: webservices.xml with proper structure is refused to deploy due to parsing/validation error)
Fix Version/s: jbossws-cxf-4.0.2
jbossws-native-4.0.2
> WebservicesFactory can't parse webservices.xml with javaee:descriptionGroup references
> --------------------------------------------------------------------------------------
>
> Key: JBWS-3432
> URL: https://issues.jboss.org/browse/JBWS-3432
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jbossws-cxf, jbossws-integration, jbossws-native
> Reporter: Peter Skopek
> Assignee: Alessio Soldano
> Fix For: jbossws-cxf-4.0.2, jbossws-native-4.0.2
>
> Attachments: picketlink-sts.war
>
>
> webservices.xml with proper structure is refused to deploy due to parsing/validation error
> {noformat}
> <?xml version="1.0" encoding="UTF-8"?>
> <webservices xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/javaee_web_services_1_3.xsd"
> version="1.3">
> <description>PicketLink STS web service descriptor
> </description>
> <webservice-description>
> <webservice-description-name>
> PicketLinkSTS
> </webservice-description-name>
> <wsdl-file>
> WEB-INF/wsdl/PicketLinkSTS.wsdl
> </wsdl-file>
> <port-component>
> <description>PicketLink STS Port</description>
> <port-component-name>PicketLinkSTSPort</port-component-name>
> <wsdl-port xmlns:tns="urn:picketlink:identity-federation:sts">PicketLinkSTSPort</wsdl-port>
> <!-- TODO: we don't have interface yet
> <service-endpoint-interface>endpoint.WeatherService</service-endpoint-interface>
> -->
> <service-impl-bean>
> <servlet-link>PicketLinkSTS</servlet-link>
> </service-impl-bean>
> </port-component>
> </webservice-description>
> </webservices>
> {noformat}
> Deployer complains about both description tags (webservices/description and webservices/webservice-description/port-component/description).
> See exception:
> {noformat}
> 18:46:59,061 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.unit."picketlink-sts.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."picketlink-sts.war".PARSE: Failed to process phase PARSE of deployment "picketlink-sts.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> Caused by: javax.xml.ws.WebServiceException: Failed to unmarshall:vfs:/content/picketlink-sts.war/WEB-INF/webservices.xml
> at org.jboss.wsf.spi.metadata.webservices.WebservicesFactory.load(WebservicesFactory.java:143)
> at org.jboss.wsf.spi.metadata.webservices.WebservicesFactory.loadFromVFSRoot(WebservicesFactory.java:126)
> at org.jboss.as.webservices.deployers.WebservicesDescriptorDeploymentProcessor.deploy(WebservicesDescriptorDeploymentProcessor.java:48)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
> ... 5 more
> Caused by: java.lang.IllegalStateException: Unexpected element: description
> at org.jboss.wsf.spi.metadata.webservices.WebservicesFactory.parseWebservices(WebservicesFactory.java:237)
> at org.jboss.wsf.spi.metadata.webservices.WebservicesFactory.parse(WebservicesFactory.java:203)
> at org.jboss.wsf.spi.metadata.webservices.WebservicesFactory.load(WebservicesFactory.java:139)
> ... 8 more
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (JBWS-3300) MTOM WSDL Binding policy rejects all non MTOM requests when attribute required=false
by Carl Roberts (JIRA)
MTOM WSDL Binding policy rejects all non MTOM requests when attribute required=false
------------------------------------------------------------------------------------
Key: JBWS-3300
URL: https://issues.jboss.org/browse/JBWS-3300
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Carl Roberts
The MTOM WSDL Binding policy rejects all non MTOM requests when attribute required=false.
Here is the MTOM policy and binding reference:
<wsp:Policy wsu:Id="MTOM_BindingPolicy" >
<wsoma:OptimizedMimeSerialization />
</wsp:Policy>
<wsp:PolicyReference URI="#MTOM_BindingPolicy" wsdl:required="false" />
Non MTOM requests are rejected with this exception:
11:12:33,307 WARN [org.apache.cxf.phase.PhaseInterceptorChain] Interceptor for {oracle/documaker/schema/ws/publishing}PublishingService#{oracle/documaker/schema/ws/publishing}
blishFromImport has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: These policy alternatives can not be satisfied:
{http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization}OptimizedMimeSerialization
at org.apache.cxf.ws.policy.AbstractPolicyInterceptor.handleMessage(AbstractPolicyInterceptor.java:47) [:2.3.1]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255) [:2.3.1]
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113) [:2.3.1]
at org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97) [:2.3.1]
at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461) [:2.3.1]
at org.jboss.wsf.stack.cxf.ServletControllerExt.invoke(ServletControllerExt.java:172) [:3.4.1.GA]
at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:57) [:3.4.1.GA]
at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:156) [:3.4.1.GA]
at org.jboss.wsf.stack.cxf.CXFNonSpringServletExt.invoke(CXFNonSpringServletExt.java:90) [:3.4.1.GA]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179) [:2.3.1]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103) [:2.3.1]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) [:1.0.0.Final]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159) [:2.3.1]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324) [:6.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:6.0.0.Final]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [:6.0.0.Final]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [:6.0.0.Final]
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181) [:6.0.0.Final]
at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285) [:1.1.0.Final]
at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261) [:1.1.0.Final]
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88) [:6.0.0.Final]
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100) [:6.0.0.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [:6.0.0.Final]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:6.0.0.Final]
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0.Final]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:6.0.0.Final]
at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53) [:6.0.0.Final]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [:6.0.0.Final]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [:6.0.0.Final]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654) [:6.0.0.Final]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:6.0.0.Final]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Caused by: org.apache.cxf.ws.policy.PolicyException: These policy alternatives can not be satisfied:
{http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization}OptimizedMimeSerialization
at org.apache.cxf.ws.policy.AssertionInfoMap.checkEffectivePolicy(AssertionInfoMap.java:140) [:2.3.1]
at org.apache.cxf.ws.policy.PolicyVerificationInInterceptor.handle(PolicyVerificationInInterceptor.java:99) [:2.3.1]
at org.apache.cxf.ws.policy.AbstractPolicyInterceptor.handleMessage(AbstractPolicyInterceptor.java:45) [:2.3.1]
Per my understanding of required=false attribute, what should occur is that non MTOM requests should still come through and be returned a non MTOM response.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (JBWS-3431) JBossWS-CXF integration hides Apache CXF WebServiceContext::getUserPrincipal implementation
by Alessio Soldano (JIRA)
Alessio Soldano created JBWS-3431:
-------------------------------------
Summary: JBossWS-CXF integration hides Apache CXF WebServiceContext::getUserPrincipal implementation
Key: JBWS-3431
URL: https://issues.jboss.org/browse/JBWS-3431
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-cxf
Reporter: Alessio Soldano
Assignee: Alessio Soldano
Fix For: jbossws-cxf-4.0.2
The JBossWS-CXF WebServiceContextFactory implementation returns an instance of org.jboss.ws.common.invocation.WebServiceContextAdapter wrapping the Apache CXF WebServiceContextImpl. That overrides the getUserPrincipal() and isUserInRole(String role) method, retrieving the information from the HttpServletRequest.
While that's usually, fine, when running WS-Security apps, Apache CXF can get the principal through WSS4J / UsernameToken authentication; the WebServiceContextImpl has proper logic for checking that as well as the data coming from HttpServletRequest when the HTTPDestination is in use.
So we need to use a WebServiceContextDelegate wrapper instead of the WebServiceContextAdapter, to avoid overriding the 2 methods above.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (JBWS-3430) SubjectCreatingPolicyInterceptor does not perform authentication for CXF SecurityContext principals
by Alessio Soldano (JIRA)
Alessio Soldano created JBWS-3430:
-------------------------------------
Summary: SubjectCreatingPolicyInterceptor does not perform authentication for CXF SecurityContext principals
Key: JBWS-3430
URL: https://issues.jboss.org/browse/JBWS-3430
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-cxf
Reporter: Alessio Soldano
Assignee: Alessio Soldano
Fix For: jbossws-cxf-4.0.2
The SubjectCreatingPolicyInterceptor is used for proper JBossAS<-->Apache CXF authentication integration (JAAS) as when a subject is created, the principal needs to be checked with the JBoss AS security layer.
In some usecases, though, the subject is not currently created by the JBoss security layer after having checked the credentials; in such cases (for instance when using UT as supporting token) Apache WSS4J sets its implementation of principal into the wsse results that are processed by CXF, which in turn sets that into the WebServiceContext (WSS4JInInterceptor::doResults), hence bypassing the JBoss authentication/authorization.
We need to have the SubjectCreatingPolicyInterceptor extended to deal with those usecases too (IOW when there's no CXF UsernameToken attached to the Message, but there's a SecurityContext instead).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (JBWS-2893) Support searching for truststore and keystore files on the classpath like Spring-WS can
by Aleksander Adamowski (JIRA)
Support searching for truststore and keystore files on the classpath like Spring-WS can
---------------------------------------------------------------------------------------
Key: JBWS-2893
URL: https://jira.jboss.org/jira/browse/JBWS-2893
Project: JBoss Web Services
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: ws-security
Reporter: Aleksander Adamowski
JBoss-WS should be able to search for truststore and keystore files on the classpath, not on a fixed path.
Currently it can be done with Spring-WS, e.g. in spring-ws-servlet.xml I can specify the following:
<bean id="keystore" class="org.springframework.ws.soap.security.wss4j.support.CryptoFactoryBean">
<property name="keyStorePassword" value="password" />
<property name="keyStoreLocation" value="classpath:/wssec-server.jks" />
<property name="defaultX509Alias" value="server" />
</bean>
This way we don't have to put the same keystores and truststores in all the WARs that compose the full enterprise application EAR.
We couldn't find any similar functionality for JBoss-WS. Here are the example paths in the wsse configuration file:
<jboss-ws-security xmlns="http://www.jboss.com/ws-security/config"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.com/ws-security/config
http://www.jboss.com/ws-security/schema/jboss-ws-security_1_0.xsd">
<key-store-file>META-INF/bob-sign.jks</key-store-file>
<key-store-password>password</key-store-password>
<key-store-type>jks</key-store-type>
<trust-store-file>META-INF/wsse10.truststore</trust-store-file>
<trust-store-password>password</trust-store-password>
The paths are either:
1) filesystem-absolute, which makes configuration, deployment and general management of server environments a nightmare: keystores have to be placed in exactly the same locations on all servers in all dev, test and production environments regardless of OS - this completely eliminates the possibility of using an OS with incompatible filesystems layout, like MS Windows, in the development chain,
2) or relative to the root of the WAR archive, which requires placing keystore copies in all WARs and complicates production deployment: all cryptographic keys must be replaced by key staff, which isn't qualified to mess with the EARs and WARs inside them.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months