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]<mailto:[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]<mailto:[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]> <mailto:[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]><mailto: [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]> <mailto:[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]> <mailto:[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]> <mailto:[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]> <mailto:[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]> <mailto:[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<http://coders.talend.com/>
