Skip to main content

Trouble with recent nightly builds

36 replies [Last post]
amason
Offline
Joined: 2007-02-26

I want to start a separate thread from this:

http://forums.java.net/jive/thread.jspa?messageID=224740

We are running WLS 9.2 with IssuedToken message security and were running fine on 3/23 build. I tried the 6/28 build to try to resolve a SOAP fault problem but now am experiencing new issues. I have attached the WSDL,XSD for reference but this was previously running fine albeit with a 3 month old versio of WSIT.

1) On startup am getting what appear to be non-fatal errors on JMX registration related to a recent change in WSEndpointImpl.java

2) On service invocation (non-fault) from java client am getting NullPointerException.

: java.lang.NullPointerException
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.handleEncryptedData(SecurityRecipient.java:479)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.handleSecurityHeader(SecurityRecipient.java:346)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.cacheHeaders(SecurityRecipient.java:250)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.validateMessage(SecurityRecipient.java:205)
at com.sun.xml.wss.jaxws.impl.SecurityPipeBase.verifyInboundMessage(SecurityPipeBase.java:424)
at com.sun.xml.wss.jaxws.impl.SecurityClientPipe.process(SecurityClientPipe.java:231)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
shyam_rao
Offline
Joined: 2006-05-05

Hi Amason,

Sorry for responding late. I forgot to set "watch on this moved discussion forum", so was not getting any mails.

You are saying, now you see digest validation problem on client side. right ? If yes, then do you still see empty cipher value in the response message ?

I see there is no "attachment" option here. Can you send me the complete log message to my id shyam.rao@sun.com ?

Thanks
-- Shyam

Message was edited by: shyam_rao

amason
Offline
Joined: 2007-02-26

No the problem has moved backwards. The digest validation problem is on server-side. I'll send the log to your email. I don't get a response anymore as the problem occurs withe request when I switch to WoodStox.

I've since reproduced the original problem outside our env on WLS 9.2.1 examples server if that's helpful to you so it's not caused by anything we are customizing at the 3rd party jar or system environment. I have a simple ear that can be deployed to the standard WLS 9.2.1 examples server and unsecured web service works while secure doesn't. It still may be a class loading issue as we have to use WLS filtering class loading directives ot get WSIT to work on WLS 9.2.1. This will change in WLS 10 since they have adopted the WSIT stack in that version. Typically, the class loading issues we've seen though are obvious because an exception occurs in WSIT so we have figured it out on our own. This one though has no exception at all so hard to pinpoint.

I still go back to it's a problem with encryption (if I disable encryption java client works). Something fundamental seems to have changed between 3/26 and now on encryption. Was there a major change to use something different or architecture change in this area?

Thanks for any help, Alex

amason
Offline
Joined: 2007-02-26

So without RequiredDerivedKeys I still get NullPointerException on client and the logging shows even less output than before.

amason
Offline
Joined: 2007-02-26

Hi.

Well, I will attach the compressed server log I have. I think you will see there's nothing of interest in it. Typically, if an exception occurs with WSIT I see it right on the console of the window from which I started WebLogic. In this case, I see no error. Furthermore, we've already established that messages are beign create so the error must not be that dramatic or it is being suppressed. I would like to know what the log files that I sent tell you. You had been concerned before about the encryption key. Does the log file confirm there is an encryption key and it is being used to encrypt? What possibly happens next?

Additionally, I do not think I am losing messages (truncated anymore) as I changed the FileHandler properties limit from 50000 to 500000 as well as changing the count (number of files) from 1 to 10. The current file I have is not exhausted at it's current size.

Thanks, Alex

shyam_rao
Offline
Joined: 2006-05-05

I am not able to figure out the problem with all your attached logs. Only option i have is "setup an environment with WLS same as yours to reproduce it"

> What possibly happens next?
I am expecting log message like the following after the last record in your attached log file:

WSS1951: Encrypted Data is:

Can you switch to woodstox once and give it a try ? and send us the complete server log.

How to switch to woodstox :
=====================

1) unjar webservices-rt.jar
2) replace the entries in the following META-INF files :

META-INF/services/javax.xml.stream.XMLInputFactory with com.ctc.wstx.stax.WstxInputFactory
META-INF/services/javax.xml.stream.XMLOutputFactory with com.ctc.wstx.stax.WstxOutputFactory
META-INF/services/javax.xml.stream.XMLEventFactory with com.ctc.wstx.stax.WstxEventFactory
3) jar the unjared webservices-rt.jar again
4) deploy it in WLS

amason
Offline
Joined: 2007-02-26

I tried the WoodStox and get the following error on startup. It doesn't look like WoodStox is included in WSIT distro.

Jul 17, 2007 5:36:21 PM com.sun.xml.ws.transport.http.servlet.WSServletContextLi
stener contextInitialized
INFO: WSSERVLET12: JAX-WS context listener initializing
Jul 17, 2007 5:36:22 PM com.sun.xml.ws.transport.http.servlet.WSServletContextLi
stener contextInitialized
SEVERE: WSSERVLET11: failed to parse runtime descriptor: javax.xml.stream.Factor
yConfigurationError: Provider com.ctc.wstx.stax.WstxInputFactory not found
javax.xml.stream.FactoryConfigurationError: Provider com.ctc.wstx.stax.WstxInput
Factory not found
at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:72)
at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:163)
at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:92)
at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:136
)
at com.sun.xml.ws.api.streaming.XMLStreamReaderFactory.(XMLStrea
mReaderFactory.java:86)
at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(Deploy
mentDescriptorParser.java:144)
at com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contex
tInitialized(WSServletContextListener.java:108)
at weblogic.servlet.internal.EventsManager$FireContextListenerAction.run

As fas as the message you're expecting, is it possible the code is taking a different path. What source file are you referring to? CryptoProcessor.java?

Thanks, Alex

amason
Offline
Joined: 2007-02-26

OK. I downloaded stable build of WoodStox 3.1.2 and added to WebLogic APP-INF/lib and that seemed to make the startup error go away. I also had to add to classpaht of Java client. Now, I get an incoming problem of digest validation.

amason
Offline
Joined: 2007-02-26

Also, I currently seem to have no way to upload the log file as there's nothing letting me add attachments.

shyam_rao
Offline
Joined: 2006-05-05

We are still not able to narrow down the problem with your attached both logs.

Didn't you use the following logging properties along with the ones suggested by the user jdg6688 to get the server side log ? If not, then can you please put these logging properties also for your server side log.
============================================
com.sun.xml.wss.logging.impl.opt.level = FINEST
com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST
com.sun.xml.wss.logging.impl.opt.signature.level = FINEST
com.sun.xml.wss.logging.impl.opt.token.level = FINEST
============================================

As, i don't see any log messages from the above packages in your 2nd attached log.

BTW, can your uncomment RequireDeriveKeys element from your wsdl and try once ?
In my previous post, i had attached my wsdl. Do you see any difference with yours ?

Also seems, your attached both logs are not complete. Can you attach the complete server side log ?

Message was edited by: shyam_rao

amason
Offline
Joined: 2007-02-26

Well, I've attached a zip with wsdl, log and such but I have to manually configure JDK logging so perhaps that's why there's no "complete" log. Am not really sure what WebLogic is using but you're messages show up in this file when I configure JDK logging. What's also baffling ot me is when I configure both sets of logging properties I get less output than the previous one. The previous one at least showed me that some sort of encryption was happening at one point and then apparently was lost. I will now experiment with dropppign the RequireDerivedKeys. THe WSDL doesn't look much different than yours, I don't believe but take a look. You have some extra Headers but I don't think that's the issue.

Alex

shyam_rao
Offline
Joined: 2006-05-05

Hi Amason,

I am attaching a patch of 2 classes ( SecurityUtil.class & CryptoProcessor.class). Please apply this patch to latest wsit jar (webservices-rt.jar), that you are using and send us the complete server side log ?

How to update webservices-rt.jar with the patch :
====================================
1) unjar webservices-rt.jar
2) copy the classes of the attached patch into appropriate directories of unjared webservices-rt.jar (i.e. com\sun\xml\ws\security\opt\impl\enc\CryptoProcessor.class & com\sun\xml\wss\impl\misc\SecurityUtil.class
3) jar the unjared webservices-rt.jar again
4) deploy it in WLS.

Thanks
-- Shyam

amason
Offline
Joined: 2007-02-26

My apologies. I think I was probably configuring the FileHandler incorrectly so that it was continually overwriting the same file. I have adjusted the logging.properties now and have included a the log, logging properties, client and server wsdl that corresponds to last night's build patched with your two code changes. Hopefully, this will give some good information. Still get NullPointerException on client.

Thanks for your diligence on this...

Alex

shyam_rao
Offline
Joined: 2006-05-05

Last record of your attached log file is below. We should get log messages after this also. Can you find out logs are getting truncated after this ? Can you find out any other server log, where we can see exception with complete stack trace. I had put few Throwable statements in the patch files. If something comes to these statements, then exception can be found in server log but not in jdk logging.

you can have a look at http://edocs.bea.com/wls/docs81/ConsoleHelp/logging.html#1048117 for "Viewing Server Logs from the Administration Console" on WLS.

=============================================================

2007-07-16T16:47:08
1184604428027
985
com.sun.org.apache.xml.internal.security.algorithms.JCEMapper
FINE
com.sun.org.apache.xml.internal.security.algorithms.JCEMapper
translateURItoJCEID

13 Request for URI http://www.w3.org/2001/04/xmlenc#aes128-cbc

=============================================================

amason
Offline
Joined: 2007-02-26

One very simple difference is that you appear to be doing java-first whereas I am doing wsdl-first. Not sure it matters.

jdg6688
Offline
Joined: 2005-11-02

Can you try a simple scenario of client to service without STS in your paltform?

So we can see it is for STS or more general.

amason
Offline
Joined: 2007-02-26

OK. I've reproduced with problem with UsernameToken security (no STS). At first, I thought the problem was gone because the operation worked, but then I realized that we did not have encryption enabled on the operations of the target webservice (unlike our STS) so I enabled encryption and, sure enough, get a NullPointerException on the java client which seems to corresponding to an empty Cipher in the response message.

Please advise on what to do next as we'd really like to upgrade

shyam_rao
Offline
Joined: 2006-05-05

Hi Amason,

I am still not able to reproduce this problem. I am attaching my wsdl, check whether it is the same what you are using. If yes, then can you remove the SignedSupportingToken from the wsdl and try.

Attach the keystores/truststores that you are using.

BTW, are you using any other xmlsec jars besides wsit jars on server side?

Thanks
-- Shyam

amason
Offline
Joined: 2007-02-26

Thanks for you help. I really want to get to bottom of this. As far as other xmlsec jars, we are using WLS 9.2 so am not really sure. We also have a xercesImpl.jar and xml-api.jar that we add on classpath. Again, we were working fine with 3/26 build and I can revert just the WSIT jars and everything works fine.

As far as the keystores, we are just using the posted server-keystore both as a key and truststore which is incorrect, but has worked so far. Am not really sure that's the problem.

If you take a look at the second java0.log I posted in reply to ritzmann, you'll see what looks like encrypted data to me. Somehow after that point, it's lost so what happens next? Signing? Transforms? It must be something that loses what clearly seems to be encrypted. Look at the WSS1757 message for the Body

Thanks again, Alex

amason
Offline
Joined: 2007-02-26

Keystore attached....

amason
Offline
Joined: 2007-02-26

OK:

I have changed STS and target webservice to use server-truststore with xws-security-client and change the STS client config to use client keystore (xws-security-client) and client truststore (xws-security-server) and the same exact stack trace occurs on the Java client..namely NullPointerException.

shyam_rao
Offline
Joined: 2006-05-05

In your attached response message, i see cipherValue is empty for both references which causes the NPE on client side. Can you put the following logging properties to FINEST in your jdk's logging config file and send use the whole server log. It may be because, the key used for encryption might be null on sts.
==================================================
com.sun.xml.wss.logging.impl.opt.level = FINEST
com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST
com.sun.xml.wss.logging.impl.opt.signature.level = FINEST
com.sun.xml.wss.logging.impl.opt.token.level = FINEST
==================================================

I have developed a sts sample but not able to reproduce your problem, its working fine. The only difference in our wsdls are, i am not using soapfault in the service wsdl.

amason
Offline
Joined: 2007-02-26

Attached is JDK log file. App Server log (WLS) appears to us other than JDK logging. I also remove SOAP faults from WSDL definition and seems to have no impact on issue.

shyam_rao
Offline
Joined: 2006-05-05

JDK log file didn't help. Do you see any log message on WLS log file regarding encryption, cipher value, cipher data?

I would like you to try your sample with the latest wsit milestone release build (i.e. milestone5 build dated 28th May) at https://jax-ws.dev.java.net/files/documents/4202/59194/wsit-1_0-fcs-bin-...

amason
Offline
Joined: 2007-02-26

Unfortuntately this build causes us some other issues that have since been resolved. This issue occurs because WLS is a J2EE 1.4 server and this JTA stuff assumes a JEE 5 server. The issue has since been fixed, so we need a later build. This issue occurs on startup of the application server.

SEVERE: WSSERVLET11: failed to parse runtime descriptor: java.lang.NoClassDefFou
ndError: com/sun/xml/ws/tx/common/TransactionManagerImpl : javax/transaction/Tra
nsactionSynchronizationRegistry
java.lang.NoClassDefFoundError: com/sun/xml/ws/tx/common/TransactionManagerImpl
: javax/transaction/TransactionSynchronizationRegistry
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12
4)
at weblogic.utils.classloaders.GenericClassLoader.defineClass(GenericCla
ssLoader.java:338)
at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(Generic
ClassLoader.java:291)
at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClass
Loader.java:259)
at weblogic.utils.classloaders.ChangeAwareClassLoader.findClass(ChangeAw
areClassLoader.java:54)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClass
Loader.java:158)
at weblogic.utils.classloaders.ChangeAwareClassLoader.loadClass(ChangeAw
areClassLoader.java:35)
at com.sun.xml.ws.tx.common.Util.isJTAAvailable(Util.java:54)
at com.sun.xml.ws.assembler.PipelineAssemblerFactoryImpl$WsitPipelineAss
embler.isTransactionsEnabled(PipelineAssemblerFactoryImpl.java:425)
at com.sun.xml.ws.assembler.PipelineAssemblerFactoryImpl$WsitPipelineAss
embler.createServer(PipelineAssemblerFactoryImpl.java:274)
at com.sun.xml.ws.api.pipe.TubelineAssemblerFactory$TubelineAssemblerAda
pter.createServer(TubelineAssemblerFactory.java:104)
at com.sun.xml.ws.server.WSEndpointImpl.(WSEndpointImpl.java:138)
at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.
java:203)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:453)
at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parseAdapter
s(DeploymentDescriptorParser.java:237)
at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(Deploy
mentDescriptorParser.java:133)
at com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contex
tInitialized(WSServletContextListener.java:94)
at weblogic.servlet.internal.EventsManager$FireContextListenerAction.run
(EventsManager.java:376)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(Authenticate
dSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:
121)
at weblogic.servlet.internal.EventsManager.notifyContextCreatedEvent(Eve
ntsManager.java:82)
at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAp
pServletContext.java:1609)
at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletCon
text.java:2764)
at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.jav
a:889)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:333)

amason
Offline
Joined: 2007-02-26

So, where to from here? I can debug and get information at least from our STS impl or from our custom SAML Issue Contract Impl. I really would like to get upgraded to the latest nightly and get to the bottom of this issue. Is it possible to get some temporary well-placed log messages that would indicate the problem? You indicate perhaps a problem with the encryption key. Perhaps I can identify that in the debugger if you tell me what to look for?

Thanks again for any help...Alex

amason
Offline
Joined: 2007-02-26

So, am trying to eliminate what might be different about my STS. I have switched out our custom IssueSAMLTokenContractImpl for the STSAttributeProvider and this seems to have made no difference at all.

One other thing that is different is that because we are on WLS, we are using a custom RealmAuthenticator. Could this be the problem? Here's the contents ... again this worked fine up until recent builds.

public class WebworksRealmAuthenticationAdapter extends RealmAuthenticationAdapter
{
public boolean authenticate(Subject callerSubject, String username, String password) throws XWSSecurityException
{
boolean retVal = false;

try {
Subject subject = JAASUtilities.getSubject(username, password);
callerSubject.getPrincipals().addAll(subject.getPrincipals());
callerSubject.getPrivateCredentials().addAll(subject.getPrivateCredentials());
callerSubject.getPublicCredentials().addAll(subject.getPublicCredentials());
retVal = true;
} catch (LoginException e) {
//!! Perhaps log the login failure?
;
}

return retVal;
}
}

jdg6688
Offline
Joined: 2005-11-02

Doesn't look like this will make a difference?
Still you need to get the server side debug information to figure out what is wrong.

WLS logging framework should be based on java logging api. You should have a way to print out the logging information with setting for:

com.sun.xml.wss.logging.impl.dsig.level = FINEST
org.jcp.xml.dsig.internal.level = FINER
com.sun.org.apache.xml.internal.security.level = FINER

amason
Offline
Joined: 2007-02-26

Thanks for your help. I've attached the log where I've configured JDK logging as you've indicated. It does seem like encyption is happening at some point, doesn't it? Anyway, hopefully, this will help you narrow down where our problem lies.

Thanks, Alex

amason
Offline
Joined: 2007-02-26

Here's a request and response. It seems like it didn't make it much past the STS interaction so am guessing the client side runtime is where the NullPointerException happens.

shyam_rao
Offline
Joined: 2006-05-05

Can you send us the complete client side stack trace and client configuration file for sts ?

In your STS wsdl, truststore assertion uses the alias from server-keystore.jks, whereas it has to use alias from truststore(server-truststore.jks) and alias name would be xws-security-client.
==============================================================


===============================================================

And in your client configuration for sts, keystore should point to client-keystore.jks with alias name "xws-security-client" and truststore element should point to client-truststore.jks

amason
Offline
Joined: 2007-02-26

Here's the output (including stack trace) from running the client (JUnit test) through IntelliJ. Attached is the wsit-client.xml and the STS client WSDL and the target service client WSDL

D:\bea\wlp921\jdk1.5.0_11\bin\java -DWSIT_HOME=d:/release/v80/Webworks/weblogic/config/vendor/jaxws-wsit -Djava.security.auth.login.config=d:/release/v80/Webworks/weblogic/config/properties/webworks_jaas.config -Didea.launcher.port=7539 -Didea.launcher.bin.path=D:\devtools\Idea6.0\bin -Dfile.encoding=windows-1252 -classpath D:\release\v80\Webworks\weblogic\config\classes;D:\release\v80\Webworks\weblogic\config\properties;D:\release\v80\Webworks\weblogic\config\resources;D:\release\v80\Webworks\weblogic\config\xsd;D:\release\v80\Webworks\weblogic\config\vendor\backport-util-concurrent.jar;D:\release\v80\Webworks\weblogic\config\vendor\aspectjrt-1.2.1.jar;D:\release\v80\Webworks\weblogic\config\vendor\cactus-1.7.jar;D:\release\v80\Webworks\weblogic\config\vendor\commons-logging-1.0.4.jar;D:\release\v80\Webworks\weblogic\config\vendor\junit-3.8.1.jar;D:\release\v80\Webworks\weblogic\config\vendor\commons-httpclient-2.0.2.jar;D:\release\v80\Webworks\weblogic\config\vendor\jakarta-regexp.jar;D:\release\v80\Webworks\weblogic\config\vendor\jcschart.jar;D:\release\v80\Webworks\weblogic\config\vendor\mail.jar;D:\release\v80\Webworks\weblogic\config\vendor\ojdbc14.jar;D:\release\v80\Webworks\weblogic\config\vendor\xbean.jar;D:\temp\tx_hack\txmgr_hack.jar;D:\release\v80\Webworks\ear\webworks\jaxws-wsit\webservices-rt.jar;D:\release\v80\Webworks\ear\webworks\jaxws-wsit\webservices-extra-api.jar;D:\release\v80\Webworks\ear\webworks\jaxws-wsit\webservices-api.jar;D:\release\v80\Webworks\ear\webworks\jaxws-wsit\webservices-extra.jar;D:\bea\wlp921\jdk1.5.0_11\jre\lib\charsets.jar;D:\bea\wlp921\jdk1.5.0_11\jre\lib\deploy.jar;D:\bea\wlp921\jdk1.5.0_11\jre\lib\javaws.jar;D:\bea\wlp921\jdk1.5.0_11\jre\lib\jce.jar;D:\bea\wlp921\jdk1.5.0_11\jre\lib\jsse.jar;D:\bea\wlp921\jdk1.5.0_11\jre\lib\plugin.jar;D:\bea\wlp921\jdk1.5.0_11\jre\lib\rt.jar;D:\bea\wlp921\jdk1.5.0_11\jre\lib\ext\dnsns.jar;D:\bea\wlp921\jdk1.5.0_11\jre\lib\ext\localedata.jar;D:\bea\wlp921\jdk1.5.0_11\jre\lib\ext\sunjce_provider.jar;D:\bea\wlp921\jdk1.5.0_11\jre\lib\ext\sunpkcs11.jar;D:\bea\wlp921\weblogic92\server\lib\weblogic.jar;D:\bea\wlp921\weblogic92\server\lib\webservices.jar;D:\devtools\Idea6.0\lib\idea_rt.jar com.intellij.rt.execution.application.AppMain com.intellij.rt.execution.junit.JUnitStarter -ideVersion5 ut.com.manu.webworks.publicapi.securityservices.UTSecurityServicesTestCase,testGetResourceAccess_HasAccessToResource
Jul 2, 2007 4:14:05 PM [com.sun.xml.ws.policy.jaxws.PolicyConfigParser] parseModel
INFO: WSP1049: Loaded WSIT configuration from file: file:/D:/release/v80/Webworks/weblogic/config/properties/wsit-client.xml
Jul 2, 2007 4:14:05 PM [com.sun.xml.ws.policy.EffectiveAlternativeSelector] selectBestAlternative
WARNING: WSP0075: Policy assertion "{http://www.w3.org/2005/08/addressing}UsingAddressing" was evaluated as "UNKNOWN".
Jul 2, 2007 4:14:05 PM [com.sun.xml.ws.policy.EffectiveAlternativeSelector] selectBestAlternative
WARNING: WSP0019: Suboptimal policy alternative selected on the client side with fitness "PARTIALLY_SUPPORTED".
Jul 2, 2007 4:14:05 PM [com.sun.xml.ws.policy.EffectiveAlternativeSelector] selectBestAlternative
WARNING: WSP0075: Policy assertion "{http://schemas.sun.com/2006/03/wss/server}KeyStore" was evaluated as "UNSUPPORTED".
Jul 2, 2007 4:14:05 PM [com.sun.xml.ws.policy.EffectiveAlternativeSelector] selectBestAlternative
WARNING: WSP0075: Policy assertion "{http://schemas.sun.com/2006/03/wss/server}TrustStore" was evaluated as "UNSUPPORTED".
Jul 2, 2007 4:14:05 PM [com.sun.xml.ws.policy.EffectiveAlternativeSelector] selectBestAlternative
WARNING: WSP0019: Suboptimal policy alternative selected on the client side with fitness "PARTIALLY_SUPPORTED".
Jul 2, 2007 4:14:08 PM [com.sun.xml.ws.policy.jaxws.PolicyConfigParser] parseModel
INFO: WSP1049: Loaded WSIT configuration from file: file:/D:/release/v80/Webworks/weblogic/config/properties/wsit-client.xml
Jul 2, 2007 4:14:08 PM [com.sun.xml.ws.policy.EffectiveAlternativeSelector] selectBestAlternative
WARNING: WSP0075: Policy assertion "{http://www.w3.org/2005/08/addressing}UsingAddressing" was evaluated as "UNKNOWN".
Jul 2, 2007 4:14:08 PM [com.sun.xml.ws.policy.EffectiveAlternativeSelector] selectBestAlternative
WARNING: WSP0019: Suboptimal policy alternative selected on the client side with fitness "PARTIALLY_SUPPORTED".

java.lang.NullPointerException
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.handleEncryptedData(SecurityRecipient.java:479)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.handleSecurityHeader(SecurityRecipient.java:346)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.cacheHeaders(SecurityRecipient.java:250)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.validateMessage(SecurityRecipient.java:205)
at com.sun.xml.wss.jaxws.impl.SecurityPipeBase.verifyInboundMessage(SecurityPipeBase.java:424)
at com.sun.xml.wss.jaxws.impl.SecurityClientPipe.process(SecurityClientPipe.java:231)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.client.Stub.process(Stub.java:248)
at com.sun.xml.ws.client.dispatch.DispatchImpl.doInvoke(DispatchImpl.java:180)
at com.sun.xml.ws.client.dispatch.DispatchImpl.invoke(DispatchImpl.java:206)
at com.sun.xml.ws.security.trust.impl.TrustPluginImpl.invokeRST(TrustPluginImpl.java:361)
at com.sun.xml.ws.security.trust.impl.TrustPluginImpl.process(TrustPluginImpl.java:232)
at com.sun.xml.wss.jaxws.impl.SecurityClientPipe.invokeTrustPlugin(SecurityClientPipe.java:375)
at com.sun.xml.wss.jaxws.impl.SecurityClientPipe.process(SecurityClientPipe.java:159)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.client.Stub.process(Stub.java:248)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:134)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:244)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:224)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:117)
at $Proxy40.getResourceAccess(Unknown Source)
at ut.com.manu.webworks.publicapi.securityservices.UTSecurityServicesTestCase.testGetResourceAccess_HasAccessToResource(UTSecurityServicesTestCase.java:64)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)

Process finished with exit code -1

ashutoshshahi
Offline
Joined: 2006-01-27

Hi,

Can you send the soap messages exchanged for this scenario? I see that you have commented EncryptedParts assertion in the service, so not sure what we are trying to decrypt here.

amason
Offline
Joined: 2007-02-26

My understanding is that regardless of the EncryptedParts policy the header information is encrypted so since that also appears in the stack I am think that it's a problem in the headers. We are following a policy of sign headers only, no encryption currently. What procedure exaclt do you follow to grab the message exchanges with an STS involved as I attempted and there seems to be some issues. I have wsmonitor and just changed the client WSDL for the target service to go through the wsmonitor proxy port but am not sure am getting a complete message exchange.

shyam_rao
Offline
Joined: 2006-05-05

Can you send us the STS wsdl ?

amason
Offline
Joined: 2007-02-26

Attached are the STS WSDL and XSD. Let me know if you see something majorly wrong with any of this, but as I said we've been running OK with a 3/23 (I know, old) build for some time.

Thanks, Alex

shyam_rao
Offline
Joined: 2006-05-05

wsdl seems to be ok.

Can you pass the following as the jvm argument for your server:
com.sun.xml.ws.transport.http.HttpAdapter.dump=true

It will give the complete message exchange in your server log.