1 2 Previous Next 23 Replies Latest reply: Jun 18, 2011 10:49 AM by Glen Mazza Go to original post RSS
  • 15. Re: SAML Token Profile (WS-Security) using PL for JBoss WS
    Alessio Soldano Master

    I confirm the saml ws integration test is working against vanilla AS 5.1.0

  • 16. Re: SAML Token Profile (WS-Security) using PL for JBoss WS
    Daniel Bevenius Master

    There must be something I'm doing wrong in the case of the ESB example then. I'll investigate further and see what I can find.

     

    Thanks for your help!

     

    /Dan

  • 17. Re: SAML Token Profile (WS-Security) using PL for JBoss WS
    Riccardo Serafin Newbie

    Hello,

     

     

    as you know I'm trying to make this work with the CXF-stack and you've said you've tested it successfully on a vanilla AS5.1.0.

     

    Well, I did the same, got 5.1.0, installed jbossws-cxf 3.4.0.GA, changed the sample project according to your post. Everything deploys fine, but it seems the STS service has a problem parsing the token creation request (I'm running on jdk 1.6.0_20).

     

    The error is the following one:

     

     

    Caused by: javax.xml.ws.WebServiceException: Exception parsing token request: [com.ctc.wstx.exc.WstxLazyException] Unexpected EOF in prolog
     at [row,col {unknown-source}]: [1,0]
              at org.picketlink.identity.federation.core.wstrust.PicketLinkSTS.invoke(PicketLinkSTS.java:96)
              at org.picketlink.identity.federation.core.wstrust.PicketLinkSTS.invoke(PicketLinkSTS.java:57)
              at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
              at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
              at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
              at java.lang.reflect.Method.invoke(Method.java:597)
              at org.jboss.wsf.common.invocation.AbstractInvocationHandlerJSE.invoke(AbstractInvocationHandlerJSE.java:129)
              at org.jboss.wsf.stack.cxf.AbstractInvoker._invokeInternal(AbstractInvoker.java:164)
              ... 40 more
    Caused by: [com.ctc.wstx.exc.WstxLazyException] com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog
     at [row,col {unknown-source}]: [1,0]
              at com.ctc.wstx.exc.WstxLazyException.throwLazily(WstxLazyException.java:45)
              at com.ctc.wstx.evt.FilteredEventReader.hasNext(FilteredEventReader.java:72)
              at org.picketlink.identity.federation.core.parsers.wst.WSTrustParser.parse(WSTrustParser.java:48)
              at org.picketlink.identity.federation.core.parsers.AbstractParser.parse(AbstractParser.java:91)
              at org.picketlink.identity.federation.core.wstrust.PicketLinkSTS.invoke(PicketLinkSTS.java:92)
              ... 47 more
    Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog
     at [row,col {unknown-source}]: [1,0]
              at com.ctc.wstx.sr.StreamScanner.throwUnexpectedEOF(StreamScanner.java:686)
              at com.ctc.wstx.sr.BasicStreamReader.handleEOF(BasicStreamReader.java:2134)
              at com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2040)
              at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1069)
              at com.ctc.wstx.evt.WstxEventReader.peek(WstxEventReader.java:306)
              at com.ctc.wstx.evt.FilteredEventReader.peek(FilteredEventReader.java:120)
              at com.ctc.wstx.evt.FilteredEventReader.hasNext(FilteredEventReader.java:70)
              ... 50 more
    
    

     

    which I believe must be some silly XML library problem. Any idea?

     

    Thanks,

    Riccardo.

  • 18. Re: SAML Token Profile (WS-Security) using PL for JBoss WS
    Riccardo Serafin Newbie

    Hello again,

     

    it seems I've been able to solve the problem that I was having (running PicketLink STS with JBossWS-CXF stack, version 3.4.0). In case anyone else gets into the same situation, the problem is due to the fact that, since version 2.3 of CXF, the default source type provided to a Provider<Source> changed from a DOMSource to a SAXSource (http://cxf.apache.org/23-migration-guide.html). As the PicketLinkSTS service is expecting the DOMSource and uses a transformer over it, with the new type of source the transformer was emitting and empty stream result.

     

    The solution, as suggested on the page mentioned above, was to force CXF to provide a DOMSource via a configuration property that must be set on the endpoint. So, I've added a jboss-cxf.xml configuration file to the WEB-INF folder in the PicketLinkSTS war, containing the following:

     

     

    beans xmlns='http://www.springframework.org/schema/beans'
            xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns:beans='http://www.springframework.org/schema/beans'
            xmlns:jaxws='http://cxf.apache.org/jaxws' xmlns:wsa='http://cxf.apache.org/ws/addressing'
            xmlns:jms='http://cxf.apache.org/transports/jms' xmlns:soap='http://cxf.apache.org/bindings/soap'
            xsi:schemaLocation='http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://cxf.apache.org/transports/jms http://cxf.$
            <jaxws:endpoint id='PicketLinkSTS'
                    address='http://localhost:8080/picketlink-sts'
                    implementor='org.picketlink.identity.federation.core.wstrust.PicketLinkSTS'
                    serviceName='ns0:PicketLinkSTS' xmlns:ns0='urn:picketlink:identity-federation:sts'
                    endpointName='ns1:PicketLinkSTSPort' xmlns:ns1='urn:picketlink:identity-federation:sts'>
                    <jaxws:invoker>
                            <bean class='org.jboss.wsf.stack.cxf.InvokerJSE' />
                    </jaxws:invoker>
                    <jaxws:properties>
                            <entry key="source-preferred-format" value="dom"/>
                    </jaxws:properties>
            </jaxws:endpoint>
    </beans>
    
    

     

    And that solved the problem for me. Unfortunately, this makes the PicketLinkSTS war stack-specific, and maybe a better solution could be found.

     

    Hope this helps,

    Riccardo.

  • 19. Re: SAML Token Profile (WS-Security) using PL for JBoss WS
    Alessio Soldano Master

    Thanks a lot for sharing this, Riccardo. Very much appreciated.

    Regarding a different/better solution.. perhaps the picketlink sts service can be modified to be able to deal with SAXSource too, basically removing the assumption on the kind of source...

  • 20. SAML Token Profile (WS-Security) using PL for JBoss WS
    Anil Saldhana Master

    Ricardo/Alessio,  I am putting out a build of PL2 next week.  I can make the STS to check for the type of source (DOMSource or SAXSource) and appropriately use it.  I am hoping that you can lend an hand in testing once the build is out.

     

    Unless the WS world has a specified type of source, if PL has to be stack agnostic, we have to handle all types of sources.

  • 21. SAML Token Profile (WS-Security) using PL for JBoss WS
    Anil Saldhana Master

    Ricardo,  I don't know why you are having trouble.  In our integration tests, we do test against CXF 3.3.1 as shown by:

     

    <property name="JBWS_CXF_ZIP" location="${basedir}/../common-dist/jbossws/3.3.1.GA/jbossws-cxf-3.3.1.GA.zip"/>

     

    The integration tests are here: http://anonsvn.jboss.org/repos/picketlink/integration-tests/trunk/picketlink-sts-tests/

     

    Also the STS invoke method passes the Source object directly to the transformer. We have no expectation of it being DOMSource.

     

    Only on the return do we generate a DOMSource which I am guessing the CXF stack handles properly.

  • 22. SAML Token Profile (WS-Security) using PL for JBoss WS
    Riccardo Serafin Newbie

    Hi,

     

    I'm using a different version. I'm using the latest version of jbossws, 3.4.1, and with version 3.4.0 of the cxf stack the included version of cxf has been changed to 2.3.1, which is the version of cxf that introduced the change (as you can see in the link above). For this reason your test pass, but mine don't.

     

    As for the transformer, I've been rereading the code and in fact there is no expectation there. I believe the problem is that the transformer utils picks the default transformer and this, at least on my configuration (which is using the endorsed xml lib from JBoss) translates to org.apache.xalan.transformer.TransformerIdentityImpl, which seems to ignore the SAX source, although as far as I can see the documentation says otherwise. I can only state that if a SAX source is passed the result is empty, if a DOM source is passed the result is the one expected

     

    Best,

    Riccardo.

  • 23. Re: SAML Token Profile (WS-Security) using PL for JBoss WS
    Glen Mazza Newbie

    Thanks for posting this -- I'm running into the same problem with JBAS 6.0 Final and a CXF 2.4.1 client, unfortunately your sample jboss-cxf.xml didn't fix it for me--same error message.

     

    It would be good for others if you could repost all the attributes of the <beans> element in your jboss-cxf.xml -- it got truncated from your sample above and so doesn't work as-is.  I used this but don't know if it is sufficient/correct:

     

    <beans xmlns='http://www.springframework.org/schema/beans'

      xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'

      xmlns:beans='http://www.springframework.org/schema/beans'

      xmlns:jaxws='http://cxf.apache.org/jaxws'

      xsi:schemaLocation='http://www.springframework.org/schema/beans

      http://www.springframework.org/schema/beans/spring-beans.xsd

      http://cxf.apache.org/jaxws

      http://cxf.apache.org/schemas/jaxws.xsd'>

1 2 Previous Next