That's the right source. Hmm could you paste the first output message that CXF is sending?
Colm. On Tue, Feb 3, 2015 at 2:32 PM, Mark Durant <[email protected]> wrote: > Ah, I see … I thought you were talking about the order of the > interceptors. > > I’m not entirely familiar with the structure you have there, but I > pulled the source from > https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=snapshot;h=refs/heads/2.7.x-fixes;sf=tgz > b/c it seemed to have your change from > https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blobdiff;f=rt/ws/security/src/main/java/org/apache/cxf/ws/security/policy/interceptors/SecureConversationOutInterceptor.java;h=cf67507e46185722150ff9cb9332557a00f60e33;hp=2b377e6bebd7aa58633f0adae6d64b86f63a54bb;hb=ce6515c77b67dedec519079caf0a6d65b45fa035;hpb=53d151b659e5f41e914416370b838bc4388353f5. > Should I try someplace else? > > Here’s the request now: > > > {ws-security.sts.client=org.apache.cxf.ws.security.trust.STSClient@4b42f44a, > ws-security.spnego.client.action=com.nexidia.neat.test.Tester$XRMSpnegoClientAction@18b44ce0, > ws-security.callback-handler=org.apache.cxf.interceptor.security.NamePasswordCallbackHandler@652312cb, > ws-security.kerberos.spn=RestrictedKrbHost/nxesideploy4, > java.lang.reflect.Method=public abstract java.lang.Integer > com.nexidia.neat.webservices.clients.nia.agentinventory.IAgentInventoryService.save(com.nexidia.neat.webservices.clients.nia.agentinventory.AgentUser) > throws > com.nexidia.neat.webservices.clients.nia.agentinventory.IAgentInventoryServiceSaveGeneralFaultFaultFaultMessage,com.nexidia.neat.webservices.clients.nia.agentinventory.IAgentInventoryServiceSaveArgumentFaultFaultFaultMessage, > org.apache.cxf.jaxws.context.WrappedMessageContext.SCOPES={org.apache.cxf.message.Message.ENDPOINT_ADDRESS=APPLICATION}, > ws-security.kerberos.jaas.context=spnego-client, > org.apache.cxf.message.Message.ENDPOINT_ADDRESS= > http://nxesideploy4/NxIA/WebServices/AgentInventoryService.svc} > > Thanks, > Mark > > > > On Feb 3, 2015, at 9:07 AM, Colm O hEigeartaigh <[email protected]> > wrote: > > Well in your email you said: > > So the call to issue(…) creates this XML request successfully in > AbstractSTSClient: > > https://gist.github.com/anonymous/adaad47ef5643686dade > . > > AbstractSTSClient then makes a call to CXF’s ClientImpl.invoke(…), and > ClientImpl’s doInvoke ultimately is passed this: > > > That gist appears to be gone, however it was a SecureConversation call not > a SPNego call. What does the first outbound message look like now? By > latest source, do you mean from git or maven (it should be the former)? > > Colm. > > > On Tue, Feb 3, 2015 at 1:59 PM, Mark Durant <[email protected]> wrote: > > Hi Colm, > I grabbed the latest source for 2.7.15, built that, adjusted my project’s > libraries, and I’m still caught in a loop. Interceptor order calls don’t > appear to be changing, either. > > You mention a SecureConversation call, but I was never hitting the > SecureConversationOutInterceptor, and it’s not hitting it now, either. I > do see your changes to the ordering in there. > > Am I missing something? > > Mark > > > On Feb 2, 2015, at 10:47 AM, Colm O hEigeartaigh <[email protected] > <mailto:[email protected] <[email protected]>>> wrote: > > Hi Mark, > > Looking at your debugging email, I noticed that the first call is the > SecureConversation call instead of the Spnego call. As the > SecureConversation stuff is (almost) always "outside" of the Spnego (or > IssuedToken) call, I've changed the interceptor ordering to reflect this. > > Could you try again with the latest CXF 3.0.x or 2.7.x SNAPSHOT code? I > just merged the fix so it will take a while to deploy - the quickest way is > to grab the latest source + build it yourself locally. > > Colm. > > On Mon, Feb 2, 2015 at 12:58 PM, Mark Durant <[email protected]<mailto: > [email protected]>> wrote: > Thanks, Colm. I sent the WSDL privately a few days ago, but think we may > be caught up in each other’s spam filters. Just trying to sync back up > through here…. > > Mark > > > On Jan 28, 2015, at 10:16 AM, Colm O hEigeartaigh <[email protected] > > <mailto:[email protected] <[email protected]>>> wrote: > > > It looks like this is the issue that I've run into before, where it is > continually looping + getting new tokens. Could you attach the WSDL so > > that > > I can see the exact security policy? > > Colm. > > On Tue, Jan 27, 2015 at 2:23 PM, Mark Durant <[email protected] > > <mailto:[email protected] <[email protected]>>> wrote: > > > Hi Colm, > I don’t see any obvious errors, but I’ll step through and describe what > I’m seeing. You asked for the issueToken(…) call, which is down beneath > the “-----“ break below if you want to skip to it, but I’m going to step > through a few earlier steps and show a few things first, just in case > there’s anything in there that’s helpful. > > So the call to issue(…) creates this XML request successfully in > AbstractSTSClient: > > https://gist.github.com/anonymous/adaad47ef5643686dade. > > AbstractSTSClient then makes a call to CXF’s ClientImpl.invoke(…), and > ClientImpl’s doInvoke ultimately is passed this: > > > - ClientCallback - null > - BindingOperationInfo - [BindingOperationInfo: { > http://schemas.xmlsoap.org/ws/2005/02/trust/wsdl}RequestSecurityToken > > ] > > - params - One DOMSource object, with a single node: > [wst:RequestSecurityToken: null] > - context (below*) > - Exchange - null > > > ( * context: {ResponseContext={}, > > > RequestContext={ws-security.sts.client=org.apache.cxf.ws.security.trust.STSClient@423b8ab3 > , > > > > ws-security.spnego.client.action=com.nexidia.neat.test.Tester$XRMSpnegoClientAction@530f0fbd > , > > > > ws-security.callback-handler=org.apache.cxf.interceptor.security.NamePasswordCallbackHandler@1d26be5 > , > > ws-security.kerberos.spn=RestrictedKrbHost/nxesideploy4, SOAPAction= > http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT, > ws-security.kerberos.jaas.context=spnego-client}} ) > > It sets up everything without complaint, then gets to the point where it > calls chain.doIntercept(message) with this message: > > {org.apache.cxf.invocation.context={ResponseContext={}, > > > RequestContext={ws-security.sts.client=org.apache.cxf.ws.security.trust.STSClient@423b8ab3 > , > > > > ws-security.spnego.client.action=com.nexidia.neat.test.Tester$XRMSpnegoClientAction@530f0fbd > , > > > > ws-security.callback-handler=org.apache.cxf.interceptor.security.NamePasswordCallbackHandler@1d26be5 > , > > ws-security.kerberos.spn=RestrictedKrbHost/nxesideploy4, SOAPAction= > http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT, > ws-security.kerberos.jaas.context=spnego-client}}, > > > ws-security.spnego.client.action=com.nexidia.neat.test.Tester$XRMSpnegoClientAction@530f0fbd > , > > org.apache.cxf.service.model.MessageInfo=[MessageInfo INPUT: { > > http://schemas.xmlsoap.org/ws/2005/02/trust/wsdl > }RequestSecurityTokenMsg], > > > > ws-security.callback-handler=org.apache.cxf.interceptor.security.NamePasswordCallbackHandler@1d26be5 > , > > ws-security.kerberos.spn=RestrictedKrbHost/nxesideploy4, > org.apache.cxf.client=true, org.apache.cxf.message.inbound=false, > ws-security.kerberos.jaas.context=spnego-client, > > > org.apache.cxf.binding.soap.SoapVersion=org.apache.cxf.binding.soap.Soap12@16d9e492 > , > > > > ws-security.sts.client=org.apache.cxf.ws.security.trust.STSClient@423b8ab3 > , > > SOAPAction=http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT, > > > org.apache.cxf.service.model.BindingMessageInfo=org.apache.cxf.service.model.BindingMessageInfo@3b2d38f6 > , > > Content-Type=application/soap+xml, > org.apache.cxf.transport.Conduit=conduit: class > > > org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduit368491732target: > > http://nxesideploy4/NxIA/WebServices/AgentInventoryService.svc} > > PhaseInterceptor gets it next, and it iterates over its interceptors: > PolicyOutInterceptor intercepts without complaint, then > > MapAggregatorImpl, > > SoapHeaderOutFilterInterceptor, SecurityVerificationOutInterceptor, > > SoapPreProtocolOutInterceptor, MessageSenderInterceptor, > > and then it hits SpnegoContextTokenOutInterceptor, where it gets caught. > > ----- > > In SpnegoContextTokenOutInterceptor.issueToken(…), then, > SpnegoTokenContext in the wss4j library successfully authenticates to > > the > > TGT, gets the token successfully, and then says it’s successfully > > retrieved > > a service ticket before control goes back to > SpnegoContextTokenOutInterceptor. That guy then hits the “initiating > ws-trust exchange”-commented part of the code, where it sets up the > > client > > successfully, and then it makes this call: > > SecurityToken tok = client.requestSecurityToken(s, > Base64.encode(spnegoToken.getToken())); > > All of the params there look good (the token’s there, and s looks > right), but the call to requestSecurityToken then brings us full circle > back to the AbstractSTSClient.issue(…) call, and that’s where we’re > > stuck. > > > Here’s my test code source, if it helps: > https://gist.github.com/anonymous/0e9907d427148c5f5478. > > Thanks again for your help with this! > > All best, > Mark > > > On Jan 27, 2015, at 7:19 AM, Colm O hEigeartaigh <[email protected] > > <mailto:[email protected] <[email protected]>>> > > wrote: > > Hi Mark, > > > The SpnegoContextTokenOutInterceptor is never reaching the point where > > tok > > > is non-null, b/c it’s trying to get tokenID from the message first and > > is > > failing there. I did set a breakpoint at the line where it’s trying to > > get > > the token ID from the message (line 59 in 2.7.14), though, and was able > > to > > create a new SecurityToken with a dummy ID, and then execute your test > > code > > against that with no problem. After running it, I pulled the token ID > > and > > token from both the Exchange and the TokenStore without issue. > > > If the tokenID is null, then it tries to get a new token. So something > > is > > clearly going wrong with this. Could you try debugging through the call > > to > > "issueToken" and see where the error is being thrown? > > Colm. > > > > On the security policy, I’m not sure how to tell … can you point me in > > the > > right direction? > > Thanks for the help! > > Mark > > > On Jan 26, 2015, at 6:41 AM, Colm O hEigeartaigh <[email protected] > > <mailto:[email protected] <[email protected]>>> > > > wrote: > > > Can you see in the SpnegoContextTokenOutInterceptor via a debugger > > whether > > it is actually storing the message ID successfully? > > message.getExchange().put(SecurityConstants.TOKEN_ID, tok.getId()); > NegotiationUtils.getTokenStore(message).add(tok); > > If it is then it might be a problem with the security policy. I've seen > something similar with WS-MEX before. Can you post the exact security > policy here? > > Colm. > > On Fri, Jan 23, 2015 at 6:31 PM, Mark Durant <[email protected] > > <mailto:[email protected] <[email protected]>>> > > > wrote: > > > Hi all, > I’ve been trying to create and test a CXF client that’s consuming a web > service secured with SPNEGO/Kerberos authentication on a Windows 2008 > server. I’m neither a Windows nor a security guru by any stretch of the > imagination, but mainly following Groovy Tom’s advice at > http://groovyjava-tom.blogspot.com/2012/01/cxf-and-ms-crm-2011.html, I > believe I’ve gotten very close to making this work. I’ve hit a snag > > near > > the end, though, that I’m hoping someone here can provide me some > > insight > > into. > > I’ve created the web service client from the WSDL using CXF without > > issue, > > and my test code is essentially wrapping the basics there with what I > > found > > in the blog post. Here’s the code: > > System.setProperty("java.security.auth.login.config", > "/home/developer/apache-cxf-2.7.14/login.conf"); > System.setProperty("java.security.krb5.conf", > "/home/developer/apache-cxf-2.7.14/krb5.conf"); > System.setProperty("sun.security.krb5.debug", "true"); > > AgentInventoryService service = new AgentInventoryService(); > IAgentInventoryService port = > service.getWSHttpBindingIAgentInventoryService(); > > Client client = ClientProxy.getClient(port); > > client.getRequestContext().put("ws-security.kerberos.jaas.context", > "spnego-client"); > client.getRequestContext().put("ws-security.kerberos.spn", > "RestrictedKrbHost/nxesideploy4"); > client.getRequestContext().put("ws-security.spnego.client.action", new > XRMSpnegoClientAction()); > > Bus bus = ((EndpointImpl) client.getEndpoint()).getBus(); > PolicyInterceptorProviderRegistry pipr = > bus.getExtension(PolicyInterceptorProviderRegistry.class); > pipr.register(new XRMAuthPolicyProvider()); > > CallbackHandler callbackHandler = new NamePasswordCallbackHandler(kuser, > kpass); > client.getRequestContext().put("ws-security.callback-handler", > callbackHandler); > > STSClient sts = new STSClient(bus); > sts.setFeatures(Arrays.asList(new Feature() { > @Override > public void initialize(Server server, Bus bus) { > } > > @Override > public void initialize(Client client, Bus bus) { > bus.getProperties().put("soap.no.validate.parts", true); > } > > @Override > public void initialize(InterceptorProvider interceptorProvider, Bus > > bus) { > > } > > @Override > public void initialize(Bus bus) { > } > })); > client.getRequestContext().put("ws-security.sts.client", sts); > > AgentUser agentUser = new AgentUser(); > agentUser.setAgentId("007-DEF"); > agentUser.setFirstName("Mark"); > agentUser.setLastName("Durant"); > > Integer result = port.save(agentUser); > > System.out.println("result = " + result); > > I’ve tested my krb5.conf with kinit, and it’s working fine. With > > Kerberos > > debugging on, I can see that that part of the application is working, > > too. > > After getting that token, though, the library seems to gets caught in a > loop, continually reaching out to the domain controller for a new token. > The looping starts in SpnegoContextTokenOutInterceptor's > handleMessage(SoapMessage) call: It tries to get the " > > ws-security.token.id<http://ws-security.token.id/>" > > from the message, but it's not there; so seeing that it has a null > > token, > > it requests a security token from the STSClient, and that request gets > caught up in the same interceptor where the ws-security.token.id< > > http://ws-security.token.id/> is > > > null, > > and it just keeps rolling from there under I get a StackOverflow error. > Here’s the stack trace: > > Jan 23, 2015 12:46:23 PM org.apache.cxf.phase.PhaseInterceptorChain > doDefaultLogging > WARNING: Interceptor for { > > http://schemas.xmlsoap.org/ws/2005/02/trust/wsdl}SecurityTokenService#{ > http://schemas.xmlsoap.org/ws/2005/02/trust/wsdl}RequestSecurityToken > > has thrown exception, unwinding now > org.apache.cxf.interceptor.Fault: General security error (An error > occurred in trying to obtain a TGT: java.lang.StackOverflowError > at java.net.PlainDatagramSocketImpl.receive0(Native Method) > at > > > > > java.net.AbstractPlainDatagramSocketImpl.receive(AbstractPlainDatagramSocketImpl.java:145) > > > at java.net.DatagramSocket.receive(DatagramSocket.java:786) > at sun.security.krb5.internal.UDPClient.receive(NetClient.java:207) > at sun.security.krb5.KdcComm$KdcCommunication.run(KdcComm.java:386) > at sun.security.krb5.KdcComm$KdcCommunication.run(KdcComm.java:339) > at java.security.AccessController.doPrivileged(Native Method) > at sun.security.krb5.KdcComm.send(KdcComm.java:323) > at sun.security.krb5.KdcComm.send(KdcComm.java:219) > at sun.security.krb5.KdcComm.send(KdcComm.java:191) > at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:319) > at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:364) > at > > > > > com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:721) > > > at > > > > > com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:580) > > > at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source) > at > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(Method.java:601) > at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784) > at > > javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) > > at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) > at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) > at java.security.AccessController.doPrivileged(Native Method) > at > > javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) > > at javax.security.auth.login.LoginContext.login(LoginContext.java:594) > at > > > > > org.apache.ws.security.spnego.SpnegoTokenContext.retrieveServiceTicket(SpnegoTokenContext.java:121) > > > at > > > > > org.apache.ws.security.spnego.SpnegoTokenContext.retrieveServiceTicket(SpnegoTokenContext.java:89) > > > at > > > > > org.apache.ws.security.spnego.SpnegoTokenContext.retrieveServiceTicket(SpnegoTokenContext.java:70) > > > at > > > > > org.apache.cxf.ws.security.policy.interceptors.SpnegoContextTokenOutInterceptor.issueToken(SpnegoContextTokenOutInterceptor.java:114) > > > at > > > > > org.apache.cxf.ws.security.policy.interceptors.SpnegoContextTokenOutInterceptor.handleMessage(SpnegoContextTokenOutInterceptor.java:73) > > > at > > > > > org.apache.cxf.ws.security.policy.interceptors.SpnegoContextTokenOutInterceptor.handleMessage(SpnegoContextTokenOutInterceptor.java:46) > > > at > > > > > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) > > > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:572) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:481) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:382) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:335) > at > > > > > org.apache.cxf.ws.security.trust.AbstractSTSClient.issue(AbstractSTSClient.java:855) > > > at > > > > > org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:62) > > > at > > > > > org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:56) > > > at > > > > > org.apache.cxf.ws.security.policy.interceptors.SpnegoContextTokenOutInterceptor.issueToken(SpnegoContextTokenOutInterceptor.java:134) > > > at > > > > > org.apache.cxf.ws.security.policy.interceptors.SpnegoContextTokenOutInterceptor.handleMessage(SpnegoContextTokenOutInterceptor.java:73) > > > at > > > > > org.apache.cxf.ws.security.policy.interceptors.SpnegoContextTokenOutInterceptor.handleMessage(SpnegoContextTokenOutInterceptor.java:46) > > > at > > > > > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) > > > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:572) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:481) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:382) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:335) > at > > > > > org.apache.cxf.ws.security.trust.AbstractSTSClient.issue(AbstractSTSClient.java:855) > > > at > > > > > org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:62) > > > at > > > > > org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:56) > > > at > > > > > org.apache.cxf.ws.security.policy.interceptors.SpnegoContextTokenOutInterceptor.issueToken(SpnegoContextTokenOutInterceptor.java:134) > > > at > > > > > org.apache.cxf.ws.security.policy.interceptors.SpnegoContextTokenOutInterceptor.handleMessage(SpnegoContextTokenOutInterceptor.java:73) > > > at > > > > > org.apache.cxf.ws.security.policy.interceptors.SpnegoContextTokenOutInterceptor.handleMessage(SpnegoContextTokenOutInterceptor.java:46) > > > at > > > > > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) > > > > That repeats until the application dies. > > This is all done with CXF 2.7.14. I tried it with 3.0.3 originally, and > hit the same problem, but backed down to 2.7 since that was where the > > blog > > post was successful. > > If there’s anything else I can provide that might give a hint about > > what’s > > happening, please let me know. > > Thanks, > Mark > > > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com<http://coders.talend.com/> > > > > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com<http://coders.talend.com/> > > > > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com<http://coders.talend.com/> > > > > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com<http://coders.talend.com/> > > > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com > > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
