3 Replies Latest reply on Jan 17, 2011 6:01 AM by Alessio Soldano

    Attaching a WS-Security policy forces use of "Standard WSSecurity Endpoint" configuration

    Riccardo Serafin Newbie



      I'm trying to use WS-Security with WS-Policy and a custom endpoint configuration in one of my services, but it seems that when the policy is parsed during deployment a standard endpoint configuration is forced. 


      This is  an extract of the relevant parts of my service declaration:


      @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
      @EndpointConfig(configFile = "META-INF/cmr-basic-endpoint-config.xml", configName = "CMR-basic")
      @Policy(policyFileLocation = "META-INF/cmr-basic-security-policy.xml", scope = PolicyScopeLevel.WSDL_BINDING))
      public class DOCServiceBasicImpl extends DOCServiceUnsercureImpl {


      As you can see, I'd like to use the CMR-basic endpoint config, which I've already setup to use the WS-Security handler, like this 


                         <javaee:handler-name>Seam SOAP Request Handler</javaee:handler-name>
                       <javaee:handler-name>WSSecurity Handler</javaee:handler-name>

      And I'm trying to attach the following policy:



      <wsp:Policy wsu:Id="ws-security"
        xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702"
        <sp:timestamp ttl="359" />
        <sp:usernameAuth />
        <sp:username />




      When the service is deployed, the following error is produced:



      18:19:23,415 INFO  [org.jboss.ws.extensions.policy.metadata.PolicyMetaDataBuilder] Deploying Annotated Policy = META-INF/cmr-basic-security-policy.xml
      18:19:23,590 ERROR [STDERR] org.jboss.ws.WSException: Cannot obtain config: Standard WSSecurity Endpoint
      18:19:23,593 ERROR [STDERR]           at org.jboss.ws.metadata.config.JBossWSConfigFactory.getConfig(JBossWSConfigFactory.java:165)
      18:19:23,593 ERROR [STDERR]           at org.jboss.ws.metadata.umdm.EndpointMetaData.initEndpointConfigMetaData(EndpointMetaData.java:874)
      18:19:23,593 ERROR [STDERR]           at org.jboss.ws.metadata.umdm.EndpointMetaData.createEndpointConfigMetaData(EndpointMetaData.java:841)
      18:19:23,593 ERROR [STDERR]           at org.jboss.ws.metadata.umdm.EndpointMetaData.setConfigNameInternal(EndpointMetaData.java:823)
      18:19:23,593 ERROR [STDERR]           at org.jboss.ws.metadata.umdm.EndpointMetaData.setConfigName(EndpointMetaData.java:801)
      18:19:23,593 ERROR [STDERR]           at org.jboss.ws.extensions.policy.deployer.domainAssertion.WSSecurityAssertionDeployer.deployServerSide(WSSecurityAssertionDeployer.java:69)
      18:19:23,593 ERROR [STDERR]           at org.jboss.ws.extensions.policy.deployer.PolicyDeployer.deployAssertionServerSide(PolicyDeployer.java:227)
      18:19:23,593 ERROR [STDERR]           at org.jboss.ws.extensions.policy.deployer.PolicyDeployer.deployAlternativeServerSide(PolicyDeployer.java:195)
      18:19:23,594 ERROR [STDERR]           at org.jboss.ws.extensions.policy.deployer.PolicyDeployer.deployServerside(PolicyDeployer.java:118)
      18:19:23,594 ERROR [STDERR]           at org.jboss.ws.extensions.policy.metadata.PolicyMetaDataBuilder.deployPolicyServerSide(PolicyMetaDataBuilder.java:288)
      18:19:23,594 ERROR [STDERR]           at org.jboss.ws.extensions.policy.metadata.PolicyMetaDataBuilder.deployPolicy(PolicyMetaDataBuilder.java:270)
      18:19:23,594 ERROR [STDERR]           at org.jboss.ws.extensions.policy.metadata.PolicyMetaDataBuilder.processPolicyAnnotations(PolicyMetaDataBuilder.java:132)
      18:19:23,594 ERROR [STDERR]           at org.jboss.ws.metadata.builder.jaxws.JAXWSWebServiceMetaDataBuilder.buildWebServiceMetaData(JAXWSWebServiceMetaDataBuilder.java:161)
      18:19:23,594 ERROR [STDERR]           at org.jboss.ws.metadata.builder.jaxws.JAXWSServerMetaDataBuilder.setupProviderOrWebService(JAXWSServerMetaDataBuilder.java:50)
      18:19:23,594 ERROR [STDERR]           at org.jboss.ws.metadata.builder.jaxws.JAXWSMetaDataBuilderEJB3.buildMetaData(JAXWSMetaDataBuilderEJB3.java:76)


      which i believe is caused by the following code in WSSecurityAssertionDeployer:


      public void deployServerSide(PrimitiveAssertion assertion, ExtensibleMetaData extMetaData) throws UnsupportedAssertion
            ByteArrayOutputStream stream = new ByteArrayOutputStream();
            if (extMetaData instanceof EndpointMetaData)
               EndpointMetaData ep = (EndpointMetaData) extMetaData;
               WSSecurityConfiguration securityConfiguration;
                  //GET XML of security assertion
                  PrimitiveAssertionWriter.newInstance().writePrimitiveAssertion(assertion, stream);
                  StringReader reader = new StringReader(stream.toString());
                  //Set security configuration 
                  securityConfiguration = WSSecurityOMFactory.newInstance().parse(reader);
                  WSSecurityConfigFactory.newInstance().initKeystorePath(ep.getRootFile(), securityConfiguration);
                  //set up handler chain as defined in standard file
                  ep.setConfigName("Standard WSSecurity Endpoint");
               catch (Exception e)
                  throw new UnsupportedAssertion();


      which, instead of checking if the proper WSSecurity handler is installed, forces the use of "Standard WSSecurity Endpoint" configuration. 


      Is this expected? Why can't I use my own policy configuration? 


      Btw, the obvious workaround is to rename my endpoint configuration to "Standard WSSecurity Endpoint", but that is a bit annoying, as I have several configuration that requires WS-Security in combination with other WS-* standards that I use for my services, and this forces me to separate them in several configuration files to be able to replace the "Standard WSSecurity Endpoint" with what I need. 





      PS: I'm using a vanilla JBoss 5.1.0.GA, which comes with jbossws 3.1.2.GA, but I've checked the code of the last 3.4 version (3.4.1.GA I believe) and it is the same.

        • 1. Attaching a WS-Security policy forces use of "Standard WSSecurity Endpoint" configuration
          Alessio Soldano Master

          Ciao Riccardo,

          basing the handlers configuration for ws-security on the "Standard WSSecurity Endpoint" conf there is most likely something that should be changed (having that as a configurable option would be better)... the point is that the WS-Policy usage here should basically allow the engine to setup WS-Security without the need of user provided security handler configuration.

          This said, however, the WS-Policy engine in JBossWS-Native is experimental and no real WS-*Policy implementation was ever based on that (mainly because at the time that code was written, the multiple-stack support work was being started and then we decided to go for CXF/Metro integration stacks, especially for the WS-* support). While there's indeed some initial code for WS-SecurityPolicy in native, that's not finished.

          So, if you need a real support for WS-Policy (especially for WS-Security Policy), you should really evaluate moving to JBossWS-CXF stack. If you can't afford also moving to JBoss AS 6 Final and want to stay on 5.1.0, JBossWS-CXF 3.4.0 is the version for you (see http://community.jboss.org/wiki/JBossWS-SupportedTargetContainers)

          • 2. Attaching a WS-Security policy forces use of "Standard WSSecurity Endpoint" configuration
            Riccardo Serafin Newbie

            Grazie Alession,


            I was in fact thinking to switch to CXF, but the native stack seemed more simple for what I needed. I'm trying to integrate with the PIcketLink-STS, where the integration, as far as I know, is based on the native stack.


            In any case the change needed to avoid the problem should be fairly easy, just checking if the correct handler is already in the chain and if not loading the standard configuration. Or I'm missing something? I'll try to create a patch for that in the next week and submit it.


            Btw, what's the focus of the native stack at the moment? I've seen the roadmap, but as you have said it seems that much of the WS-* support has been left aside in favor of CFX (Metro support has been discontinued, right?). Are you planning on filling the gap, or will the native stack be left just for experimental stuff?




            • 3. Attaching a WS-Security policy forces use of "Standard WSSecurity Endpoint" configuration
              Alessio Soldano Master

              Riccardo Serafin wrote:


              Grazie Alession,


              I was in fact thinking to switch to CXF, but the native stack seemed more simple for what I needed. I'm trying to integrate with the PIcketLink-STS, where the integration, as far as I know, is based on the native stack.

              Yes PicketLink has been initially targetting jbossws-native, but as far as I know the dev team there is also considering jbossws-cxf lately. I've provided few contribution on ws stack agnostic integration in the past months (http://community.jboss.org/thread/157409), so something should indeed already work with jbossws-cxf.


              Regarding a patch for the specific configuration issue here, that would be welcome for sure, but to be honest I expect you to have further more complex issue with WS-SecurityPolicy once you're done with that.


              Regarding the future of jbossws stacks, with jbossws-cxf installed by default on AS 6 now, new features are going to provided on it (at least on it first). As of today, JBossWS future is mainly on the CXF based stack. However, JBossWS-Native is going to remain supported for long time, at least because it's part of the Red Hat enterprise offering. Right, JBossWS-Metro development has been discontinued.