1 2 Previous Next 23 Replies Latest reply on Jun 18, 2011 10:49 AM by Glen Mazza Go to original post
      • 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!



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




            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?




            • 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'
                              serviceName='ns0:PicketLinkSTS' xmlns:ns0='urn:picketlink:identity-federation:sts'
                              endpointName='ns1:PicketLinkSTSPort' xmlns:ns1='urn:picketlink:identity-federation:sts'>
                                      <bean class='org.jboss.wsf.stack.cxf.InvokerJSE' />
                                      <entry key="source-preferred-format" value="dom"/>


              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,


              • 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 Saldanha 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 Saldanha 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



                      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




                      • 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'








                        1 2 Previous Next