Highlighted
benze Absent Member.
Absent Member.
1066 views

StackTrace when trying to apply message level security

I'm trying to test out message security by using "SignOnlyWithMutualCertificate", but when I try to submit my request via SoapUI, I get the following stacktrace as a response:

 

Internal server error
The 'http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest' username token has an unsupported password type.
at System.ServiceModel.Security.WSSecurityJan2004.UserNamePasswordTokenEntry.ParsePassword(XmlDictionaryReader reader)
at System.ServiceModel.Security.WSSecurityJan2004.UserNamePasswordTokenEntry.ParseToken(XmlDictionaryReader reader, String& id, String& userName, String& password)
at System.ServiceModel.Security.WSSecurityJan2004.UserNamePasswordTokenEntry.ReadTokenCore(XmlDictionaryReader reader, SecurityTokenResolver tokenResolver)
at System.ServiceModel.Security.WSSecurityTokenSerializer.ReadTokenCore(XmlReader reader, SecurityTokenResolver tokenResolver)
at System.IdentityModel.Selectors.SecurityTokenSerializer.ReadToken(XmlReader reader, SecurityTokenResolver tokenResolver)
at HP.SV.MessageProcessing.SOAPMessageParser.WsSecurity.WsSecurityHandler.ReadSecurityData(XmlReader reader, SecurityVersion version) in y:\SV-3.60.3889.39401\net\Shared\MessageProcessing\SOAPMessageParser\WsSecurity\WsSecurityHandler.cs:line 131
at HP.SV.MessageProcessing.SOAPMessageParser.WsSecurity.Custom.CustomSecurityHandler.ReadSecurityData(XmlElement securityHeader) in y:\SV-3.60.3889.39401\net\Shared\MessageProcessing\SOAPMessageParser\WsSecurity\Custom\CustomSecurityHandler.cs:line 142
at HP.SV.MessageProcessing.SOAPMessageParser.WsSecurity.Custom.CustomSecurityHandler.ProcessIncommingMessage() in y:\SV-3.60.3889.39401\net\Shared\MessageProcessing\SOAPMessageParser\WsSecurity\Custom\CustomSecurityHandler.cs:line 78
at HP.SV.MessageProcessing.SOAPMessageParser.ProtocolProcessors.WSSecurityProcessor.ProcessInputMessage(CannonicalMessage message, IInputProcessingContext context) in y:\SV-3.60.3889.39401\net\Shared\MessageProcessing\SOAPMessageParser\ProtocolProcessors\WSSecurityProcessor.cs:line 24
at HP.SV.MessageProcessing.ProcessingEngine.PerformInput(CannonicalMessage message, InputProcessingContextImpl context, Boolean onServer, Boolean inService, Stream logStream) in y:\SV-3.60.3889.39401\net\Shared\MessageProcessing\ProcessingEngine.cs:line 367
at HP.SV.MessageProcessing.ProcessingEngine.ProcessImpl(TransportMessage transportMessage, ServiceRuntimeMode mode, Action`2 apply, Action`2 postProcess) in y:\SV-3.60.3889.39401\net\Shared\MessageProcessing\ProcessingEngine.cs:line 251
at HP.SV.MessageProcessing.ProcessingEngine.ProcessInput(IDurableMessageContext mc, IVirtualService service, IVirtualServiceEndpoint endpoint, IServiceDescription serviceDescription, ServiceRuntimeMode mode, TransportMessage transportMessage) in y:\SV-3.60.3889.39401\net\Shared\MessageProcessing\ProcessingEngine.cs:line 162
at HP.SV.Server.ServerImpl.CreateCanonicalMessage(TransportMessage transportMessage, IVirtualService service, ServiceRuntimeMode mode, IServiceDescription sd) in y:\SV-3.60.3889.39401\net\Server\Server\ServerImpl.cs:line 363
at HP.SV.Server.ServerImpl.ProcessInputMessageInternal(TransportMessage transportMessage) in y:\SV-3.60.3889.39401\net\Server\Server\ServerImpl.cs:line 273
at HP.SV.Server.ServerImpl.ProcessInputMessage(TransportMessage transportMessage) in y:\SV-3.60.3889.39401\net\Server\Server\ServerImpl.cs:line 252
at HP.SV.AgentServer.AgentManager.ProcessInputMessage(TransportMessage transportMessage) in y:\SV-3.60.3889.39401\net\Server\AgentServer\AgentManager.cs:line 1081
at HP.SV.AgentHosting.AgentHost.ProcessInputMessage(TransportMessage transportMessage) in y:\SV-3.60.3889.39401\net\Server\AgentHosting\AgentHost.cs:line 143
at HP.SV.AgentCommon.Agents.Agent`1.ProcessInputMessage(TransportMessage message) in y:\SV-3.60.3889.39401\net\Agent\AgentCommon\Agents\Agent.cs:line 443
at HP.SV.HttpAgentCommon.EndpointImpl.Forwarder.ProcessRequest(IGenericHttpContext context, EndpointInitData endpoint, String messageId, Int64 timestamp) in y:\SV-3.60.3889.39401\net\Agent\HttpAgentCommon\EndpointImpl\Forwarder.cs:line 131
at HP.SV.HttpEmbeddedAgent.HttpAgent.ProcessRequest(IGenericHttpContext context, Int64 timestamp) in y:\SV-3.60.3889.39401\net\Agent\HttpEmbeddedAgent\HttpAgent.cs:line 235

 

 

 

I am not entirely sure what this is caused by.  I suspect it is something related to the certificate and/or credentials I have entered in the Credential Store, but I am not sure what.  I have tried generating a PKCS12 keystore using openssl without any passwords on the key or the keystore, but it has not made a difference.  Similarly, I have tried it using a PEM keystore but with the same results.

 

Can someone help point me in the right direction?  I'm a little confused what the "username" in the credential store is even used for when providing a PEM or PKCS12 file.

 

I am attaching the test pkcs12 and pem keystores if that helps.  In theory, there should be no passwords associated to either the private key, or the keystore itself.

 

Thanks,


Eric

 

0 Likes
2 Replies
Micro Focus Expert
Micro Focus Expert

Re: StackTrace when trying to apply message level security

benze,

 

Security setting always seem to be tricky partly because people use terms interchangeably when they shouldn't.

 

It sounds like you are trying to set up the following situation:

  • Mutual authentication - this is where the client has a certificate it submits to the server and the server has its certificate that it submits to the client.  In your case, this would mean you had to enter a client certificate in your SOAPUI in order for it to be able to successfully send a message to the real service.  Is this the case?  If this is the case you will need to have access to both the client certificate and the server certificate so SV can work properly.   Why, you may ask, does SV need access to both certificates?  This is because SV is the "man in the middle" and it needs the credentials of both the client and the server so each side will trust it. (SV needs the server cert so it can present it to the client so the client will trust it and SV needs the client cert so it can present it to the server so the server will trust SV)
  • Signed message - With WS Security, you can sign a message which means it gives an assurance to the receiver that the message has not been altered during transportation.  I couldn't tell based on your post if you were signing the message or not.
  • Encrypted message - By the log, it looks like you are encrypting the message (note this is different than sending a SOAP message over HTTPS).

With the files that you attached, could you explain what these certificates are to be used for (mutual auth, encrypted message, etc)?

 

Would you be able to provide a sample message and wsdl for the message you are attempting to use with SV and SOAPUI?

 

If you aren't, then I suggest you contact the HP Support (http://softwaresupport.hp.com/) for them to assist as I know sometimes this type of information can not be shared on public forums such as this.

0 Likes
benze Absent Member.
Absent Member.

Re: StackTrace when trying to apply message level security

Thanks for the reply Dave.

 

My current setup (without the SV) is Message-Level-Security; my client signs the message and submits the request to the service provider (SP).  The SP validates the signatures and responds with a similarly signed message.  The message itself is sent in plain-text over plain HTTP and is not encrypted.  The MLS is to ensure that there has been no tampering of the message itself between the client and the provider.

 

Currently, the client (SoapUI) and the SP (IBM DataPower gateway) have exchanged their public certificates in order for this exchange to work.  Each has the other's in their TrustStore to validate the signatures.   I am trying to replicate this behaviour in SV but am running into several roadblock.

 

My first one was this stack trace.  I think I have finally stumbled around it by disabling PasswordDigest in SoapUI and setting it to PasswordText (cleartext for the pwd).  Not ideal, but functional for the moment.

 

However, I am still having trouble understanding how to properly configure the certificates in SV.  Do I need to have both sets of private/public keys in SV such that SV (as man in the middle) can verify/validate the request from SoapUI and then resign it before sending it to the SP?  And perform a similar mechanism upon returning the reply from the SP to the client?

 

I suspect that I should be using SignWithMutualCertificate option, but there is no documentation that clearly explains the options (or how to use the credential store) so I am doing a lot of trial-and-error.

 

Additionally, is there anyway for SV to simply pass the message through to the SP, or is it required to manipulate the message in transit?  In order to simplify the process, I have even tried to send my request non-signed by SoapUI and hope that the SV could sign on behalf of SV to submit to the SP, but SV generates a different stack trace complaining of an invalid XML missing a root element.  However, the XML is properly structured (using the same request with no MLS) works.

 

The SOAP requests and responses must provide the following elements signed:

  • Body
  • Timestamp
  • serviceContext
  • Action
  • MessageID
  • UsernameToken

 

Please let me know if you still need sample request/wsdls/etc and I can try to provide a example.

 

Thanks,


Eric

 

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.