-
15. Re: SAML Token Profile (WS-Security) using PL for JBoss WS
asoldano Oct 28, 2010 9:07 AM (in response to anil.saldhana)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
beve Oct 29, 2010 2:01 AM (in response to asoldano)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
barakka Jan 17, 2011 4:31 PM (in response to asoldano)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
barakka Jan 23, 2011 11:21 AM (in response to barakka)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
asoldano Jan 24, 2011 4:17 AM (in response to barakka)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 Jan 26, 2011 9:37 PM (in response to asoldano)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 Jan 26, 2011 11:11 PM (in response to anil.saldhana)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
barakka Jan 27, 2011 6:00 AM (in response to anil.saldhana)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
mazzag Jun 18, 2011 10:49 AM (in response to barakka)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