.NET Framework Bookmark and Share   
 index > ASMX Web Services and XML Serialization > Add a security header to SOAP message using MSSOAP30
 

Add a security header to SOAP message using MSSOAP30

Hi

I'm really stuck on getting my SOAP messages to work. I've tried many approaches but they all have the same problem in common: they don't have a security header.

The security header needs to contain a username and password. In VB.Net this is done by:


userNameAssertion.UsernameTokenProvider = new
UsernameTokenProvider(username, password);

Policy policy = new Policy();
policy.Assertions.Add(userNameAssertion);
proxy.SetPolicy(policy);


Two routines which I am developing which don't work are at the end of this message. There is a third which uses the MS SOAP Toolkit 3, but this gives so many errors it doesn't seem worth using if it's not necessary. If it is, then the errors alternate on first run are "class not registered" but subsequently "no such interface supported". That error occurs on the line:


Set sc_partservice = New SoapClient30


Any help to get this working will be greatly appreciated!

Thanks

David


Dim ENC As String
Dim XSI As String
Dim XSD As String

Sub SOAPsuds()

'Define Envelope Constants
    ENC = "http://schemas.xmlsoap.org/soap/encoding/"         'Encoding
    XSI = "http://www.w3.org/1999/XMLSchema-instance"         'Schema Instance
    XSD = "http://www.w3.org/1999/XMLSchema"                  'Schema
   
'Define Envelope Variables
    URL = "omitted"                                                             'Web Service
    Uri = "omitted"
    Method = "omitted"                                                          'Web Method
   
'Instantiate things
    Dim Connector As SoapConnector30
    Dim Serializer As SoapSerializer30
    Dim Reader As SoapReader30
    Set Connector = New HttpConnector30
    Set Serializer = New SoapSerializer30
    Set Reader = New SoapReader30
   
'Prepare the Connector to talk to the SOAP Server
    Connector.Property("EndPointURL") = URL
    Call Connector.Connect
    Connector.Property("SoapAction") = Uri & "#" & Method
    Call Connector.BeginMessage
   
'Associate Serializer with Connector
    Serializer.Init Connector.InputStream

'Start the SOAP Envelope and specify the Encoding and XML-Schema
    Serializer.StartEnvelope , ENC
    Serializer.SoapNamespace "xsi", XSI
    Serializer.SoapNamespace "SOAP-ENC", ENC
    Serializer.SoapNamespace "xsd", XSD
   
'Start the body of the message
    Serializer.StartBody
    Serializer.StartElement Method, Uri, , "method"

'Write each method parameter out as a child to the root element
    Serializer.StartElement "Author"
    Serializer.SoapAttribute "type", , "xsd:string", "xsi"
    Serializer.WriteString "Wilde, Oscar"
    Serializer.EndElement
   
'End the root element, the body and the envelope
    Serializer.EndElement
    Serializer.EndBody
    Serializer.EndEnvelope

'Ending the message causes it to be sent
    Connector.EndMessage

'Load the result into the Reader
    Reader.Load Connector.OutputStream
   
'If ok then pull result out of DOM
    If Not Reader.Fault Is Nothing Then
      MsgBox Reader.FaultString.text, vbExclamation
    Else
      Set Result = Reader.Dom
      '//parse the DOM to extract the result set
    End If

End Sub




Dim oDoc As MSXML2.DOMDocument

Private Sub WSTest1()
    On Error GoTo ErrorHandler
   
'Define Services
    Dim PartService
    Set PartService = CreateObject("MSSOAP.SoapClient30")
    PartService.MSSoapInit URL                                'string substituted
   
    xmlSchema "C:\Documents and Settings\User\Desktop\SOAP XML VB\Schemas\Request\GetByIDRequest.xsd"

'Query Services
    test = (PartService.GetByID(oDoc.documentElement))
   
    Exit Sub

'Handle WSDL Errors
ErrorHandler:
    If Err.Number = -2147024809 Then
        MsgBox "run-time error: '" & Err.Number & "':" & Chr(13) & Chr(13) & Err.Description & Chr(13) & "This is a WSDL Error"
    End If

End Sub

Function xmlSchema(StrXML)

        Dim fSuccess As Boolean

        Set oDoc = New MSXML2.DOMDocument
        oDoc.async = False
        oDoc.validateOnParse = False
        fSuccess = oDoc.Load(StrXML)
        If Not fSuccess Then
          MsgBox oDoc.parseError.reason
        End If
   
End Function

m4r5
You know the SOAP Toolkit is obsolete, right? And that it was created before the WS-* standards existed?
John Saunders
WCF is Web Services. They are not two separate things.
Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
Use File->New Project to create Web Service Projects
John Saunders
Hi John

Yes I know, but then everything becomes obsolete after a time. I've actually managed to resolve the issues with the toolkit, but all it does is build a class for you. Once that class exists the tool used to make it is irrelevant. So I have my class, and I can now asign it to an object without any problems. I now need to add a security header to my soap message which is achieved in vb.net by:

userNameAssertion.UsernameTokenProvider = new
UsernameTokenProvider(username, password);
// Set the policy onto the proxy
Policy policy = new Policy();
policy.Assertions.Add(userNameAssertion);
proxy.SetPolicy(policy);

So far I haven't found any articles (or encountered any programmers) which have the information needed to do the same thing in VB. Generally people say you need WSE, which by definition is nonsense. What I hope they mean is "It's easier to use WSE". Regardless, this has to be done in VB or from a library like CSoap. The same issue of the header will exist with CSoap, so I may as well do it all in VB. It has to be VB to plug into the CAD app.

So, I need to add a security header, which I believe is just some xml in the schema made by WSE. According to the whole internet though (this is day 5) no one's ever done that before.
m4r5
The people who say use WSE are badly mistaken. WSE is obsolete. WCF should be used for all new development of web service clients and services.

BTW, I disagree that the tool used is not relevant. If the tool is not supported, bugs won't be fixed. If the tool is badly out of date, you won't find new developers who know how to use it. If the tool does not make it easy to work with modern scenarios, then you'll be stuck with ancient ones (i.e., COM).

John Saunders
WCF is Web Services. They are not two separate things.
Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
Use File->New Project to create Web Service Projects
John Saunders
Well, yes, but the tool just made the classes and they work fine now. Better to use it than to write them all out manually.

I have been surprised by the difficulty of this task. It seems that the availability of modern tools means that very few people actually know what's really going on. I would much rather understand this before using the new tools. That said, I'd just take any solution at the moment. Thing is, .net isn't an option. It might be easy, but we're talking about sending XML over HTTP. It can't be hard. If I knew the format of the header made by WSE - which even the Web Service vendors advise, or some terminology appropriate to the equivilent of userNameAssertion.UsernameTokenProvider in vb6 then i'd be a lot better off.
m4r5
But you're not using a modern tool - you're using an ancient one. The SOAP Toolkit was one of the first tools from Microsoft to deal with web services. It does an OK job of dealing with the web service standards that were in place at the time it was created, but has no flexibility or extensibility. As a result, it is totally incapable of dealing with the changed standards. I doubt it can even deal with SOAP 1.2!

You would find this so much easier if you would use WCF. This is a typical scenario, but by insisting on remaining in the past, you're complicating it enormously.


John Saunders
WCF is Web Services. They are not two separate things.
Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
Use File->New Project to create Web Service Projects
John Saunders
But John it's a toolkit. It made a class. Even if you wrote that class in VB.Net and used WCF you'd still need to add the security header. The toolkit really has no relevence - it's the language. Let's pretend I worte the classes by hand and now want to add security headers in VB. As I've said .Net isn't an option. I could explain why in the next few paragraphs but see no need to. If you don't believe that then fine. It's not like you're helping anyway.
m4r5
No, if you used WCF you would not have to add the security header. Assuming the header was described in the WSDL, it would be done for you.

If the toolkit understands your scenarios, then it can help. A toolkit developed before security headers existed will not be very helpful.

John Saunders
WCF is Web Services. They are not two separate things.
Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
Use File->New Project to create Web Service Projects
John Saunders
Why are you so hung up on this toolkit? It made a class. It isn't relevant AT ALL! For goodness sake. I get that you have a point. You're point is "If you use tools that do the job for you the task will be easier". Thanks very much for that, I never would have worked that out without you repeating it so many times.

I also get that it would be nice if the class already had the security header in it. However, given that WSE doesn't even have that ability I'm not too hung up on the missing feature. If you know how to add the security header then please say so. I have told you lots of times that .net isn't an option, so I don't know why you're wasting my time and yours telling me more about it. I'm sure it will also prove an amusing waste of time for anyone else who reads this thread in the future with the hope of actually achieving something.
m4r5
Wait, "Assuming the header was described in the WSDL, it would be done for you".... Well I know that!! Obviously it isn't in the WSDL else the ancient toolkit that you despise so much would have done it too!
m4r5
It fascinates me how you move between talking about the obsolete SOAP Toolkit and the obsolete WSE (Web Service Extensions). These were replaced for good reason.

Now, as to telling you how to use the obsolete tools to do this job, I don't know, because I never learned how to use the obsolete tools. I'll shut up now, and maybe someone who knows how to use them will answer you.

I simply wanted to make sure you were aware they're obsolete. Some developers find these tools through Google, and don't realize they're obsolete, so I try to make sure everyone is aware of that. If you've decided to use obsolete tools regardless, then go right ahead.

I do suggest you keep an eye on the support status of these tools, however. I expect them to actually become unsupported fairly soon.

John Saunders
WCF is Web Services. They are not two separate things.
Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
Use File->New Project to create Web Service Projects
John Saunders
No. If it was a header defined in one of the WS-* standards, then the tool would not have known about it. The fact that you were also talking about WSE (version 3.0, I hope) suggested that this was a WS-Security header of some kind.


John Saunders
WCF is Web Services. They are not two separate things.
Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
Use File->New Project to create Web Service Projects
John Saunders
WSE, if I were using it, would be relevant as it is called when the code is run. The SOAP Toolkit is not. It can be installed, used, uninstalled and never even known about on the machine where the code is run. Perhaps you can't comprehend the difference. Since you don't even know this I'm inclined to assume you don't know what you're talking about at all; and since you have completely failed to pick up on every relevant point despite them being explained many times I also don't think you're someone worth talking to at all.

The strangest thign about your replies is your love of WCF because "No, if you used WCF you would not have to add the security header. Assuming the header was described in the WSDL, it would be done for you." which is a feature you got in WSE anyway (which I'm not using, remember? and don't want to, remember?) and the Toolkit which just builds a class based on the WSDL. You clearly have a hatred of all thing from the past as can be seen on the main topics page.

And have you picked up on any of my questions and given even a partial answer to anything at all.... erm, no. Neither havve you made any valid points that weren't already obvious to even the most half-witted of individuals.

You also seem to have no idea about real world scenarios. Did it ever occur to you that a web service may belong to a different company and be ASMX? I'm sure it didn't based on what I've seen here. Maybe you'd want to multiply that by a few thousand web services, which incidentally (in this case) have nothing to do with WCF. They ARE different things. Amazon is quite happy to stick with the old methods. That must drive you nuts. Haha. Dont' loose too much sleep over it. You could write to them will all your excellent points like, er, ...oh, well nevermind.


m4r5

If I may, I'd like to go back to a comment that was made earlier in the thread:

>So, I need to add a security header, which I believe is just some xml in the schema made by WSE

Well, yes and no. It's a little bit more than that. WS-Security (the spec from which this particular header is taken) is a protocol, meaning that it defines specific schemas as well as strict rules for processing those schemas. In this case, those rules govern things like the signing and encryption procedures necessary to provide the cryptographic guarantees that motivate the usage of the specification in the first place. Those rules are rather complex and definitely not something the average application developer would want to be attempting to recreate without help from a framework (think of ws-security sort of like SSL -- very few folks want to write their own SSL libraries either).

Things like the SOAP toolkit (which was written before these protocols existed) can generate classes to model the protocol schemas but have no idea about the processing rules that make up the rest of the protocol.

The Microsoft platform has great support for advanced Web Services standards like WS-Security via Windows Communication Foundation (WCF). WCF, as I'm sure you're aware, is a managed framework and as such isn't directly usable from unmanaged VB/VBA. However, there is a way of making this work -- see the COM Moniker sample here: http://msdn.microsoft.com/en-us/library/ms752245.aspx

You might also find this blog entry to be informative, as it describes a somewhat similar situation:
http://www.hanselman.com/blog/BreakingAllTheRulesWithWCF.aspx

I'm sorry that you're finding things to be more complex that you would like. Hopefully the information above helps you move forward.
-steve


Brain.Save() -- http://hyperthink.net/blog
Steve Maine
Hi Steve

That's some excellent info. Thanks.

Perhaps my best bet would be to write a dll in c# and utilise that somehow from VB. I can write the dll easily enough, but I don't know if I'll encounter difficulties in utilising it from VB. Any thoughts?

Thanks

David
m4r5

You can use google to search for other answers

Custom Search

More Threads

• Passing xml string using SOAP httpRequest
• Request/Response/Request??? scenario - is this possible?
• WSE 3.0 bug
• 401 UNAUTHORIZED while accesing the anonymous webservice
• XmlSerialization with Interfaces
• Webservice description not showing array items
• Web App to Web Service
• Is there a way to get legacy SoapHttpClientProtocol Proxy to work with WSE SoapReceivers ?
• Serializing object to XML error: RuntimeMethodInfo is inaccessible due to its protection level.
• .Net 1.1 app calling WCF http web service: The request failed with HTTP status 415