> When I run client, I was seeing following > java.lang.ClassNotFoundExceptionon the STS server side.....
Thanks, I've made this change. Colm. On Thu, Jul 12, 2012 at 6:44 PM, Gina Choi <[email protected]> wrote: > Hi Colm, > > Thanks for your response. It was very helpful and I made good progress. > > 1. > <<< > No afaik as it'll get overwritten by the CXF runtime. > >>> > Thanks for clarification. > > 2. > <<< > Yes, as they are independent of each other. Of course you could always put > shared config in a separate configuration file and import it. > >>> > Good idea. I created ldap-config.xml file and put ldap related > configuration in there. I also made each endpoint import it. > > 3. > <<< > The config files for the STS each define (one or more) JAX-WS endpoints for > a particular port that is defined in the same WSDL, and each defines it's > own address. Therefore when you look at the WSDL that is published for a > particular endpoint, you will see the correct address in the WSDL only for > that particular endpoint. > > In other words, the "Transport_UT" port configuration uses the address > "/STSService" and hence when you look at the WSDL available via " > https://wkengchoi.global.sdl.corp:9443/fedizidpsts/STSService?wsdl"; you > see > the correct address for this port, but not for the other ports. The > "Transport" port uses the address "/STSServiceTransport" and so if you look > at the WSDL available at " > https://wkengchoi.global.sdl.corp:9443/fedizidpsts/STSServiceTransport?wsdl > " > you will see the correct address for this port, etc. > >>> > I used > http://wkengchoi.global.sdl.corp:9080/fedizidpsts/UTEncrypted?wsdlfor > UTEncrypted_Port and it worked. > > 4. Type Error > When I run client, I was seeing following > java.lang.ClassNotFoundExceptionon the STS server side. This is > because of > org.apache.cxf.sts.war.PasswordCallbackHandler referenced in > cxf-encrypted-ut.xml. This may need to be replaced by > org.apache.cxf.fediz.service.sts.PasswordCallbackHandler. > org.apache.cxf.sts.war.PasswordCallbackHandler is referenced in both > cxf-ut.xml and cxf-x509.xml as well. > > > <bean id="encryptedUtSTSProperties" > > class="org.apache.cxf.sts.StaticSTSProperties"> > > <property name="signaturePropertiesFile" > value="stsKeystore.properties"/> > > <property name="signatureUsername" > value="mystskey"/> > > <property name="callbackHandlerClass" > value=" *org.apache.cxf.sts.war.PasswordCallbackHandler *"/> > > <property name="encryptionPropertiesFile" > value="stsKeystore.properties"/> > > <property name="issuer" > value="DoubleItSTSIssuer"/> > > </bean> > > <jaxws:endpoint id="EncryptedUTSTS" > > implementor="#encryptedUtSTSProviderBean" > > address="/UTEncrypted" > > > wsdlLocation="/WEB-INF/wsdl/ws-trust-1.4-service.wsdl" > > xmlns:ns1=" > http://docs.oasis-open.org/ws-sx/ws-trust/200512/"; > > serviceName="ns1:SecurityTokenService" > > endpointName="ns1:UTEncrypted_Port"> > > <jaxws:properties> > > <entry > key="ws-security.callback-handler" value=" * > org.apache.cxf.sts.war.PasswordCallbackHandler* "/> > > <entry > key="ws-security.ut.validator" value-ref="jaasUTValidator"/> > > > <entry > key="ws-security.signature.properties" value="stsKeystore.properties"/> > > <entry > key="ws-security.signature.username" value="mystskey"/> > > </jaxws:properties> > > </jaxws:endpoint> > > > > Jul 12, 2012 12:55:20 PM > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor handleMessage > > WARNING: > > org.apache.ws.security.WSSecurityException: > org.apache.cxf.sts.war.PasswordCallbackHandler > > at > > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.getCallback(WSS4JInInterceptor.java:627) > > at > > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.getCallback(WSS4JInInterceptor.java:610) > > at > > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:251) > > at > > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:97) > > at > > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262) > > at > > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:122) > > at > > org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:211) > > at > > org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:213) > > at > > org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:193) > > at > > org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:129) > > at > > org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:187) > > at > > org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:110) > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:641) > > at > > org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:166) > > at > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) > > at > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > > at > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225) > > at > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169) > > at > > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) > > at > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) > > at > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) > > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927) > > at > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) > > at > > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:999) > > at > > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:565) > > at > > org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:309) > > at > > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > > at > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > > at java.lang.Thread.run(Thread.java:662) > > *Caused by: java.lang.ClassNotFoundException: > org.apache.cxf.sts.war.PasswordCallbackHandler* > > at > > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1711) > > at > > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1556) > > at > > org.apache.cxf.common.classloader.ClassLoaderUtils.loadClass2(ClassLoaderUtils.java:271) > > at > > org.apache.cxf.common.classloader.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:245) > > at > > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.getCallback(WSS4JInInterceptor.java:625) > > > On Thu, Jul 12, 2012 at 10:43 AM, Colm O hEigeartaigh > <[email protected]>wrote: > > > > I have following content in this file. Value of the location attribute > > of the <soap:address> seems doesn't matter. I even set an > > > empty string on that, but it didn't make any difference. Are there any > > rules to set value for "location"? > > > > No afaik as it'll get overwritten by the CXF runtime. > > > > > 2. End point for cxf-transport.xml and cxf-encrypted-ut.xml seems > > independent to each other. I configured end point for > > > cxf-transport.xml to be connected to OpenLDAP. Is that mean that I need > > to configure cxf-encrypted-ut.xml to reference to > > > OpenLDAP so that UserName token is validated against OpenLDAP rather > > than hard coded by default? > > > > Yes, as they are independent of each other. Of course you could always > put > > shared config in a separate configuration file and import it. > > > > > > > 3. I don't think that I understand your previous email. > > > > The config files for the STS each define (one or more) JAX-WS endpoints > > for a particular port that is defined in the same WSDL, and each defines > > it's own address. Therefore when you look at the WSDL that is published > for > > a particular endpoint, you will see the correct address in the WSDL only > > for that particular endpoint. > > > > In other words, the "Transport_UT" port configuration uses the address > > "/STSService" and hence when you look at the WSDL available via " > > https://wkengchoi.global.sdl.corp:9443/fedizidpsts/STSService?wsdl"; you > > see the correct address for this port, but not for the other ports. The > > "Transport" port uses the address "/STSServiceTransport" and so if you > look > > at the WSDL available at " > > > https://wkengchoi.global.sdl.corp:9443/fedizidpsts/STSServiceTransport?wsdl > " > > you will see the correct address for this port, etc. > > > > Colm. > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
