You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Mark Durant <MD...@nexidia.com> on 2015/02/02 13:58:38 UTC
Re: spnego/kerberos-secured web service problem
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 <co...@apache.org> 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 <MD...@nexidia.com> 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 <co...@apache.org>
>> 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 <co...@apache.org>
>>
>> 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 <MD...@nexidia.com>
>>
>> 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"
>>
>> 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 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
>>
>>
>>
>>
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>>
>>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
Re: spnego/kerberos-secured web service problem
Posted by Colm O hEigeartaigh <co...@apache.org>.
It sounds like a CXF bug to be honest. If you have the time, you could try
setting a load of breakpoints in the SpnegoTokenOutInterceptor + really
figure out why it is hitting it twice, or why it can't find the ID of the
token after storing it successfully.
Colm.
On Thu, Feb 5, 2015 at 12:47 PM, Mark Durant <MD...@nexidia.com> wrote:
> Unfortunately, I’m not on the team that owns that web service, and how
> they’ve done it is something of a mystery to me … I was just tasked with
> trying to consume it. They’ve had problems with the way they’ve secured
> their services with other non-Windows libraries/clients, too, and are
> planning to revise them to make them more accessible. This will just help
> to spur that on, I suspect.
>
> Thanks for all of your time looking into it … I’m sorry we couldn’t get
> to a more satisfying resolution!
>
> All best,
> Mark
>
>
> On Feb 5, 2015, at 7:02 AM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> I can't replicate the issue with a CXF-based test-case unfortunately. Is
> there any chance you can create a test-case that I could run to reproduce
> the issue?
>
> Colm.
>
> On Wed, Feb 4, 2015 at 1:39 PM, Mark Durant <MD...@nexidia.com> wrote:
>
>> Sorry, meant to add that there’s a lot of repetition in the output, and
>> it goes on well beyond what’s in this file, but I tried to capture what
>> looks like a couple of bigger iterations through the interceptors.
>>
>>
>> On Feb 4, 2015, at 8:36 AM, Mark Durant <MD...@nexidia.com> wrote:
>>
>> Hi Colm,
>> I didn’t get any output setting the logging level to INFO, but I set it
>> to FINE and got this:
>> https://gist.github.com/anonymous/e83e510d3927b27b9401.
>>
>> Thanks,
>> Mark
>>
>>
>> On Feb 4, 2015, at 5:58 AM, Colm O hEigeartaigh <co...@apache.org>
>> wrote:
>>
>> What I'm looking for is to see the output messages that are generated
>> by the CXF client. You can do this by enabling the CXF logging feature, and
>> setting the logging levels to INFO. We don't fully support secure
>> conversation + spnego on the service side, but I did some hacking to get it
>> working, and the client appears to be working fine.
>>
>> Colm.
>>
>>
>>
>>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: spnego/kerberos-secured web service problem
Posted by Mark Durant <MD...@nexidia.com>.
Unfortunately, I’m not on the team that owns that web service, and how they’ve done it is something of a mystery to me … I was just tasked with trying to consume it. They’ve had problems with the way they’ve secured their services with other non-Windows libraries/clients, too, and are planning to revise them to make them more accessible. This will just help to spur that on, I suspect.
Thanks for all of your time looking into it … I’m sorry we couldn’t get to a more satisfying resolution!
All best,
Mark
On Feb 5, 2015, at 7:02 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
I can't replicate the issue with a CXF-based test-case unfortunately. Is there any chance you can create a test-case that I could run to reproduce the issue?
Colm.
On Wed, Feb 4, 2015 at 1:39 PM, Mark Durant <MD...@nexidia.com>> wrote:
Sorry, meant to add that there’s a lot of repetition in the output, and it goes on well beyond what’s in this file, but I tried to capture what looks like a couple of bigger iterations through the interceptors.
On Feb 4, 2015, at 8:36 AM, Mark Durant <MD...@nexidia.com>> wrote:
Hi Colm,
I didn’t get any output setting the logging level to INFO, but I set it to FINE and got this: https://gist.github.com/anonymous/e83e510d3927b27b9401.
Thanks,
Mark
On Feb 4, 2015, at 5:58 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
What I'm looking for is to see the output messages that are generated by the CXF client. You can do this by enabling the CXF logging feature, and setting the logging levels to INFO. We don't fully support secure conversation + spnego on the service side, but I did some hacking to get it working, and the client appears to be working fine.
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com<http://coders.talend.com/>
Re: spnego/kerberos-secured web service problem
Posted by Colm O hEigeartaigh <co...@apache.org>.
I can't replicate the issue with a CXF-based test-case unfortunately. Is
there any chance you can create a test-case that I could run to reproduce
the issue?
Colm.
On Wed, Feb 4, 2015 at 1:39 PM, Mark Durant <MD...@nexidia.com> wrote:
> Sorry, meant to add that there’s a lot of repetition in the output, and
> it goes on well beyond what’s in this file, but I tried to capture what
> looks like a couple of bigger iterations through the interceptors.
>
>
> On Feb 4, 2015, at 8:36 AM, Mark Durant <MD...@nexidia.com> wrote:
>
> Hi Colm,
> I didn’t get any output setting the logging level to INFO, but I set it to
> FINE and got this: https://gist.github.com/anonymous/e83e510d3927b27b9401
> .
>
> Thanks,
> Mark
>
>
> On Feb 4, 2015, at 5:58 AM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> What I'm looking for is to see the output messages that are generated by
> the CXF client. You can do this by enabling the CXF logging feature, and
> setting the logging levels to INFO. We don't fully support secure
> conversation + spnego on the service side, but I did some hacking to get it
> working, and the client appears to be working fine.
>
> Colm.
>
>
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: spnego/kerberos-secured web service problem
Posted by Mark Durant <MD...@nexidia.com>.
Sorry, meant to add that there’s a lot of repetition in the output, and it goes on well beyond what’s in this file, but I tried to capture what looks like a couple of bigger iterations through the interceptors.
On Feb 4, 2015, at 8:36 AM, Mark Durant <MD...@nexidia.com>> wrote:
Hi Colm,
I didn’t get any output setting the logging level to INFO, but I set it to FINE and got this: https://gist.github.com/anonymous/e83e510d3927b27b9401.
Thanks,
Mark
On Feb 4, 2015, at 5:58 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
What I'm looking for is to see the output messages that are generated by the CXF client. You can do this by enabling the CXF logging feature, and setting the logging levels to INFO. We don't fully support secure conversation + spnego on the service side, but I did some hacking to get it working, and the client appears to be working fine.
Colm.
Re: spnego/kerberos-secured web service problem
Posted by Mark Durant <MD...@nexidia.com>.
Hi Colm,
I didn’t get any output setting the logging level to INFO, but I set it to FINE and got this: https://gist.github.com/anonymous/e83e510d3927b27b9401.
Thanks,
Mark
On Feb 4, 2015, at 5:58 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
What I'm looking for is to see the output messages that are generated by the CXF client. You can do this by enabling the CXF logging feature, and setting the logging levels to INFO. We don't fully support secure conversation + spnego on the service side, but I did some hacking to get it working, and the client appears to be working fine.
Colm.
Re: spnego/kerberos-secured web service problem
Posted by Colm O hEigeartaigh <co...@apache.org>.
What I'm looking for is to see the output messages that are generated by
the CXF client. You can do this by enabling the CXF logging feature, and
setting the logging levels to INFO. We don't fully support secure
conversation + spnego on the service side, but I did some hacking to get it
working, and the client appears to be working fine.
Colm.
On Tue, Feb 3, 2015 at 3:19 PM, Mark Durant <MD...@nexidia.com> wrote:
> Not sure I have exactly the right place here, so let me know where to look
> if I’m wrong, but this looks like the first message going out (getting
> passed to chain.doIntercept(message) in ClientImpl.doInvoke, anyway):
>
> {org.apache.cxf.invocation.context={ResponseContext={},
> RequestContext={ws-security.sts.client=org.apache.cxf.ws.security.trust.STSClient@13b6249f,
> ws-security.spnego.client.action=com.nexidia.neat.test.Tester$XRMSpnegoClientAction@1b1e4cd5,
> ws-security.callback-handler=org.apache.cxf.interceptor.security.NamePasswordCallbackHandler@624641db,
> 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}},
> ws-security.spnego.client.action=com.nexidia.neat.test.Tester$XRMSpnegoClientAction@1b1e4cd5,
> org.apache.cxf.service.model.MessageInfo=[MessageInfo INPUT: {
> http://www.nexidia.com/2012/services/AgentInventory}IAgentInventoryService_Save_InputMessage],
> ws-security.callback-handler=org.apache.cxf.interceptor.security.NamePasswordCallbackHandler@624641db,
> 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.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@5bd789e4,
> org.apache.cxf.message.Message.ENDPOINT_ADDRESS=
> http://nxesideploy4/NxIA/WebServices/AgentInventoryService.svc,
> ws-security.sts.client=org.apache.cxf.ws.security.trust.STSClient@13b6249f,
> org.apache.cxf.jaxws.context.WrappedMessageContext.SCOPES={org.apache.cxf.message.Message.ENDPOINT_ADDRESS=APPLICATION},
> org.apache.cxf.service.model.BindingMessageInfo=org.apache.cxf.service.model.BindingMessageInfo@6fe9d6f6,
> Content-Type=application/soap+xml,
> org.apache.cxf.transport.Conduit=conduit: class
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduit1257983800target:
> http://nxesideploy4/NxIA/WebServices/AgentInventoryService.svc}
>
> Mark
>
>
> > On Feb 3, 2015, at 9:45 AM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
> >
> > 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 <MD...@nexidia.com> 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 <co...@apache.org>
> >> 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 <MD...@nexidia.com>
> 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 <coheigea@apache.org
> >> <mailto:coheigea@apache.org <co...@apache.org>>> 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 <MDurant@nexidia.com
> <mailto:
> >> MDurant@nexidia.com>> 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 <coheigea@apache.org
> >>
> >> <mailto:coheigea@apache.org <co...@apache.org>>> 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 <MDurant@nexidia.com
> >>
> >> <mailto:MDurant@nexidia.com <MD...@nexidia.com>>> 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 <coheigea@apache.org
> >>
> >> <mailto:coheigea@apache.org <co...@apache.org>>>
> >>
> >> 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 <coheigea@apache.org
> >>
> >> <mailto:coheigea@apache.org <co...@apache.org>>>
> >>
> >>
> >> 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 <MDurant@nexidia.com
> >>
> >> <mailto:MDurant@nexidia.com <MD...@nexidia.com>>>
> >>
> >>
> >> 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
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: spnego/kerberos-secured web service problem
Posted by Mark Durant <MD...@nexidia.com>.
Not sure I have exactly the right place here, so let me know where to look if I’m wrong, but this looks like the first message going out (getting passed to chain.doIntercept(message) in ClientImpl.doInvoke, anyway):
{org.apache.cxf.invocation.context={ResponseContext={}, RequestContext={ws-security.sts.client=org.apache.cxf.ws.security.trust.STSClient@13b6249f, ws-security.spnego.client.action=com.nexidia.neat.test.Tester$XRMSpnegoClientAction@1b1e4cd5, ws-security.callback-handler=org.apache.cxf.interceptor.security.NamePasswordCallbackHandler@624641db, 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}}, ws-security.spnego.client.action=com.nexidia.neat.test.Tester$XRMSpnegoClientAction@1b1e4cd5, org.apache.cxf.service.model.MessageInfo=[MessageInfo INPUT: {http://www.nexidia.com/2012/services/AgentInventory}IAgentInventoryService_Save_InputMessage], ws-security.callback-handler=org.apache.cxf.interceptor.security.NamePasswordCallbackHandler@624641db, 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.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@5bd789e4, org.apache.cxf.message.Message.ENDPOINT_ADDRESS=http://nxesideploy4/NxIA/WebServices/AgentInventoryService.svc, ws-security.sts.client=org.apache.cxf.ws.security.trust.STSClient@13b6249f, org.apache.cxf.jaxws.context.WrappedMessageContext.SCOPES={org.apache.cxf.message.Message.ENDPOINT_ADDRESS=APPLICATION}, org.apache.cxf.service.model.BindingMessageInfo=org.apache.cxf.service.model.BindingMessageInfo@6fe9d6f6, Content-Type=application/soap+xml, org.apache.cxf.transport.Conduit=conduit: class org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduit1257983800target: http://nxesideploy4/NxIA/WebServices/AgentInventoryService.svc}
Mark
> On Feb 3, 2015, at 9:45 AM, Colm O hEigeartaigh <co...@apache.org> wrote:
>
> 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 <MD...@nexidia.com> 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 <co...@apache.org>
>> 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 <MD...@nexidia.com> 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 <coheigea@apache.org
>> <mailto:coheigea@apache.org <co...@apache.org>>> 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 <MDurant@nexidia.com<mailto:
>> MDurant@nexidia.com>> 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 <coheigea@apache.org
>>
>> <mailto:coheigea@apache.org <co...@apache.org>>> 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 <MDurant@nexidia.com
>>
>> <mailto:MDurant@nexidia.com <MD...@nexidia.com>>> 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 <coheigea@apache.org
>>
>> <mailto:coheigea@apache.org <co...@apache.org>>>
>>
>> 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 <coheigea@apache.org
>>
>> <mailto:coheigea@apache.org <co...@apache.org>>>
>>
>>
>> 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 <MDurant@nexidia.com
>>
>> <mailto:MDurant@nexidia.com <MD...@nexidia.com>>>
>>
>>
>> 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
Re: spnego/kerberos-secured web service problem
Posted by Colm O hEigeartaigh <co...@apache.org>.
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 <MD...@nexidia.com> 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 <co...@apache.org>
> 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 <MD...@nexidia.com> 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 <coheigea@apache.org
> <mailto:coheigea@apache.org <co...@apache.org>>> 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 <MDurant@nexidia.com<mailto:
> MDurant@nexidia.com>> 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 <coheigea@apache.org
>
> <mailto:coheigea@apache.org <co...@apache.org>>> 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 <MDurant@nexidia.com
>
> <mailto:MDurant@nexidia.com <MD...@nexidia.com>>> 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 <coheigea@apache.org
>
> <mailto:coheigea@apache.org <co...@apache.org>>>
>
> 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 <coheigea@apache.org
>
> <mailto:coheigea@apache.org <co...@apache.org>>>
>
>
> 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 <MDurant@nexidia.com
>
> <mailto:MDurant@nexidia.com <MD...@nexidia.com>>>
>
>
> 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
Re: spnego/kerberos-secured web service problem
Posted by Mark Durant <MD...@nexidia.com>.
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 <co...@apache.org>> 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 <MD...@nexidia.com>> 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 <co...@apache.org>
<ma...@apache.org>> 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 <MD...@nexidia.com><mailto:
MDurant@nexidia.com<ma...@nexidia.com>>> 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 <co...@apache.org>
<ma...@apache.org>> 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 <MD...@nexidia.com>
<ma...@nexidia.com>> 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 <co...@apache.org>
<ma...@apache.org>>
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 <co...@apache.org>
<ma...@apache.org>>
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 <MD...@nexidia.com>
<ma...@nexidia.com>>
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/>
Re: spnego/kerberos-secured web service problem
Posted by Colm O hEigeartaigh <co...@apache.org>.
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 <MD...@nexidia.com> 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 <coheigea@apache.org
> <ma...@apache.org>> 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 <MDurant@nexidia.com<mailto:
> MDurant@nexidia.com>> 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 <coheigea@apache.org
> <ma...@apache.org>> 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 <MDurant@nexidia.com
> <ma...@nexidia.com>> 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 <coheigea@apache.org
> <ma...@apache.org>>
> >> 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 <coheigea@apache.org
> <ma...@apache.org>>
> >>
> >> 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 <MDurant@nexidia.com
> <ma...@nexidia.com>>
> >>
> >> 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
Re: spnego/kerberos-secured web service problem
Posted by Mark Durant <MD...@nexidia.com>.
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 <co...@apache.org>> 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 <MD...@nexidia.com>> 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 <co...@apache.org>> 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 <MD...@nexidia.com>> 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 <co...@apache.org>>
>> 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 <co...@apache.org>>
>>
>> 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 <MD...@nexidia.com>>
>>
>> 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/>
Re: spnego/kerberos-secured web service problem
Posted by Colm O hEigeartaigh <co...@apache.org>.
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 <MD...@nexidia.com> 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 <co...@apache.org>
> 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 <MD...@nexidia.com>
> 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 <co...@apache.org>
> >> 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 <co...@apache.org>
> >>
> >> 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 <MD...@nexidia.com>
> >>
> >> 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"
> >>
> >> 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 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
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Colm O hEigeartaigh
> >>
> >> Talend Community Coder
> >> http://coders.talend.com
> >>
> >>
> >>
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com