cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: spnego/kerberos-secured web service problem
Date Wed, 04 Feb 2015 10:58:29 GMT
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 <MDurant@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 <coheigea@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 <MDurant@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 <coheigea@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 <MDurant@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 <coheigea@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 <coheigea@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 <MDurant@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 <coheigea@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 <coheigea@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 <MDurant@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message