DOC

Securing Web Services with Visual Basic 6 - xSynthesis

By Hazel Gordon,2014-10-01 06:56
7 views 0
Securing Web Services with Visual Basic 6 - xSynthesis

Securing Web Services with Visual

    Basic 6.0 and MS SOAP Toolkit 2.0

Zoran Zaev

This month, Zoran Zaev shows you how to secure your web services by implementing transport

    level authentication with Visual Basic. Then, he calls the web services from Visual Basic,

    VBScript/ASP, and PERL. Finally, he implements transport level SSL encryption to the web services used in his examples.

    By now, you’ve probably heard quite a bit about web services and how to build web services in your favorite environment. If you haven’t, make sure you check some of our past issues for the introductory coverage on web services as well as specific advice on implementing web services in various programming languages and platforms.

    As you start thinking of actually deploying your web services in production, an essential question comes into your attention: how can I make sure that my web services are secure? Even more so, perhaps you have already deployed your web service and have only glanced over the topic of security. Or, maybe your web service was deployed in an internal environment where you didn’t think much security is necessary. In any of these situations, you will likely want to look into how you can apply enough security for your web service, such that misuse or malicious use is prevented.

    In this article, I’ll talk a lot about web services security, but let’s first clearly state what I will and will not cover. Security is a complex subject and I will need much more then one article to cover all of the important security aspects as it relates to web services. When you are implementing security to a system or an application, you have to take an integrated approach and examine all of the components in your system, all of your applications, and modules, but also your business policies and processes.

    Systems or application security itself, consists of distinctive areas of concern, such as authentication, authorization, auditing and logging, integrity and encryption, privacy and encryption, nonrepudiation (not rejecting that an agreement was actually signed) and digital signatures, and the often left out topic of availability with tasks such as load balancing, failover, and backup. Web security in particular, can be addressed at two different levels: at the transport level, such as the level of HTTP, and at the application level, such as at the level of SOAP messages. As you can see, security is a large topic. Therefore, for the purposes of this article, I’ll particularly focus on authentication, and briefly touch upon encryption.

    Furthermore, I’ll cover transport level security, and HTTP in particular. I’ll use Visual Basic 6.0 and MS SOAP Toolkit 2.0 in the examples shown in this article. In one of the following issues, I’ll look at implementing web services security with Microsoft’s new .NET platform. Visual Basic 6 and COM+

    system are so numerous and they will very likely be out there for quite some time.

Getting Started With A Sample Web Service

    I will use a sample web service that I had created for the October 2001 issue of XML Developer and show you how to add security to it. This web service was created with Visual Basic 6.0 and using the MS SOAP Toolkit 2.0. This sample web service is a job submittal service, part of a sample Job Bank system. Partners will be allowed to submit new job postings to this web service. You can easily image that companies that host job banks could easily use this kind of a service to which other companies could submit new job postings. I said in the October 2001 issue that in a real world scenario, this web service will likely be more complex, and security will be applied, so that not everybody can submit a new job posting.

    Before we get started, make sure that you have the necessary software. If you don’t have the MS SOAP Toolkit 2.0, you would have to obtain it from http://msdn.microsoft.com/webservices/ and install it on your computer. I built this web service on a Windows 2000 Server machine with IIS 5, but you should be able to

    use Windows 2000 Professional with IIS on it, if you like. Additionally, I used Visual Basic 6.0 with SP4 to create the server component to this web service. The client components of the web service are built in few different languages: Visual Basic 6, VBScript (under ASP), Jscript (under ASP), and just to show you that you can call this web service from a language environment that is substantially different and that is not COM+ based, I created a web service client in PERL.

In creating the server side of this web service, you will do it exactly in the same way as if you didn’t have

    to worry about security at all. I will create a COM object using Visual Basic 6. The COM object will consist of one class and one function that can be called to add jobs to the Job Bank system. This function would be as follows:

     Public Function JobAdd( _ ByVal companyID As Integer, _ ByVal expireDate As Date, _ ByVal jobTitle As String, _ ByVal jobDesc As String, _ salaryAmount As Double) As String If companyID = "1" Then JobAdd = "Your job with title: " & _ jobTitle & " and description: " & _ jobDesc & " was received " & _ "successfully on " & Now() & _ ". The salary requested is: " & _ salaryAmount & " and the expiration" & _ "date of this posting is: " & _ expireDate & "." Else JobAdd = "Your company is not allowed" & _ " to post jobs to our Job Bank." End If End Function

    If this COM object was not compiled on your server, then you would have to register it on the server by typing regsvr32 wsJobBank.dll at the command prompt within the directory where you have this file

    (you can download this file from the code download for this month or you can create it by using the code provided and compile it using Visual Basic 6). I’m not going to go into further detail on this code or some

    of the other files needed for the server side of the web service implementation (for ex. the WSDL file, the WSML file, etc.)

    The second part of the server side web service setup is to setup your web server such that it receives the requests for your web service. For this you will need to create a virtual directory under IIS. I created a virtual directory within the web server (IIS or Internet Information Server) with the name of “wsJobBankSec” pointing to the physical location where the WSDL and WSML files are located.

    This time, however, I’ll use the ASP listener instead of the ISAPI listener used in the October 2001 issue. The ISAPI listener works as an ISAPI application that handles any WSDL requests. This works very good for many situations. However, when it comes to implementing basic authentication there are some challenges in doing that. The ASP listener is slower, but it is more flexible and it allows you to do additional processing such as parsing or verifying input, as well as verifying security.

    In order to implement the ASP listener, you would want to create the file wsJobBankListener.asp and place it within your web service virtual directory. This file’s security settings should be set to “basic authentication” and “anonymous” should not be allowed (I explain little later in this article how to do these settings). This file is very simple:

     <%@ LANGUAGE = VBScript %> <% Response.ContentType = "text/xml" %> <% set soapserver = server.CreateObject _ ("MSSOAP.SoapServer") wsdl = Server.MapPath("wsJobBank.WSDL") wsml = Server.MapPath("wsJobBank.wsml")

call soapserver.init(wsdl, wsml) call soapserver.SoapInvoke(request, response, "") %>

    The ASP listener simply takes the web service request and sends it over to the SOAP server for execution, returning the result of the web service back as an XML document. Finally, you will want to modify the element, “location” attribute of your WSDL file to reflect the change that you want to use the ASP listener now. The modified section of your WSDL file will look like this:

     "http://localhost/wsJobBankSec/wsJobBankListener.asp"/>

Adding Security to the Server Side of the Sample Web Service

So, you may wonder if the code on the server side of the web server is no different then the “unsecured”

    code, then how do you secure your web service? In this case, since you are using the HTTP transport level security, the difference on the server side comes within the web server configuration. Let’s see what that

    means. You would want your users to authenticate before they can access your web service. Of course, you can require them to submit username/ password credentials within the SOAP message itself. This would be an example of implementing security at the application level and in such a case you would have to change your server side web service implementation, in order for this model to be supported. However, if you are implementing your authentication at the transport protocol level (in this case HTTP), you will want to leverage the typical HTTP authentication capabilities, such as basic authentication.

    Basic authentication is a simple authentication protocol that is part of the HTTP protocol. Virtually all web servers, browsers, and web services implementations support basic authentication. Basic authentication works well across most firewalls and proxy servers. This widespread availability and support is one of the strongest reasons to use basic authentication. However, the negative aspect to basic authentication is that sends the password in Base64 encoding format that is so easy to decode that you might as well consider it clear text. The way to overcome this serious drawback of basic authentication is to use SSL (Secured Sockets Layer) encryption. I’ll cover this approach towards the end of this article.

    Enabling basic authentication on your server for your web service is quite easy. Under IIS, you would open your web server management console of Internet Services Manager (MMC or Microsoft Management Console), typically found under your Administrative Tools. Within the MMC, locate the name of your web server and expand its branch. This will show you the various directories and virtual directories on your web server. Right click on your web service virtual directory (in this case that is “wsJobBankSec”) and select “Properties”. Next, go to the Directory Security tab and click “Edit” under the “Anonymous access and authentication control”. Within the “Authentication Methods” window that opens up, select “Basic

    Authentication” and unselect all other options. If you like you may want to select a default domain for your client web service requests, by clicking on the “Edit” button within the “Authentication Access” section. There is one other configuration setting, and that is to change the authentication of the WSDL file within this directory. This file needs to be accessible by everybody, so you will want to enable “Anonymous” access to this file.

Enabling Authentication within the Web Services Client

    The Visual Basic 6 web services client is quite simple, with only couple of extra lines of code from a code that does not implement any authentication. Here it is:

     Private Sub txtExecute_Click() Dim soapClient Set soapClient = CreateObject _ ("MSSoap.SoapClient") soapClient.mssoapinit txtWSDL soapClient.ConnectorProperty _ ("AuthUser") = "XMLDevUser"

     soapClient.ConnectorProperty _ ("AuthPassword") = "1234" txtResult.Text = soapClient.JobAdd _ (1, #12/31/2001 11:15:00 AM#, _ "XML Project Manager", _ "Must have 10 years of technical " & _ "experience...", 80000) Set soapClient = Nothing End Sub

    The most important lines here, that specify the authentication credentials are the ConnectorProperty lines that set username and password needed to obtain access to the web service.

    Here’s an example of a client web service implementation in VBScript/ ASP (in the code download from XML Developer you will also find a version done in Jscript/ ASP):

     <%@Language = "VBScript"%> <% Set objSoapClient = _ Server.CreateObject ("MSSOAP.soapClient") strWSDL = "http://localhost/wsJobBankSec/" & _ "wsJobBank.WSDL" objSoapClient.ClientProperty _ ("ServerHTTPRequest") = True objSoapClient.mssoapinit (strWSDL) objSoapClient.ConnectorProperty _ ("AuthUser") = "XMLDevUser" objSoapClient.ConnectorProperty _ ("AuthPassword") = "1234" Response.Write ("" & _ </span><span style="font-family:Microsoft YaHei;font-weight:bold;font-size:10.5px;color:#000000;"> "JobBank: Add Jobs Via VBScript" & _ </span><span style="font-family:Microsoft YaHei;font-weight:bold;font-size:10.5px;color:#000000;"> "The Response " & _ "from the Web Service is: " & "

")
Response.Write (objSoapClient.JobAdd (1, _ "12/31/2001 11:15:00 AM", _ "XML Project Manager", _ "Must have 10 years of technical " & _ "experience...", 80000)) Response.Write ("") Set objSoapClient = Nothing %>

    The key section here is the section that specifies the “ConnectionProperty” settings. Little different under the script environment is that you have to specify that the “ServerHTTPRequest” and load the WSDL file before setting up the “ConnectionProperty”.

    The PERL web service client is quite similar as what we would have if we did not have to authenticate. Here I’m using the SOAP::Lite PERL library (for more on PERL web services implementation see

    the ????? article). The difference between the file supporting authentication and the one that does not, is in the leading subroutine that overwrites the default basic authentication implementation and provides the username/ password credentials. Keep in mind that if you do not remove the application mapping for WSDL, the PERL client can use the ISAPI access to your web service, which if not secured, can be a potential security hole.

     use SOAP::Lite; sub SOAP::Transport::HTTP::Client::get_basic_credentials { return 'XMLDevUser' => '1234'; } print "HTTP/1.0 201 Ok \n"; print "Content-type:text/html\n\n";

print "JobBank:". </span><span style="font-family:Microsoft YaHei;font-weight:bold;font-size:10.5px;color:#000000;"> "Add Jobs Via PERL"; </span><span style="font-family:Microsoft YaHei;font-weight:bold;font-size:10.5px;color:#000000;">print "The Response ". "from the Web Service is: "; print "

";
print SOAP::Lite ->uri ("http://tempuri.org/message/") ->on_action(sub { return '"http://tempuri.org/action/clsJobs.JobAdd"'}) ->proxy ("http://localhost/wsJobBankSec/". "wsJobBankListener.asp") ->JobAdd (SOAP::Data->type(short => 1)-> name('companyID'), SOAP::Data->type(dateTime => '2001-12-31T16:15:00Z')-> name('expireDate'), SOAP::Data->type(string => 'XML Project Manager')-> name('jobTitle'), SOAP::Data->type(string => 'Must have 10 years of technical '. 'experience...')->name('jobDesc'), SOAP::Data->type(double => 80000)-> name('salaryAmount')) ->result; print "";

How About Encrypting Those Credentials?

    As I had said earlier, basic authentication is not secure, because the username and password are exchanged in plain text format. One way to address this issue is to use SSL and encrypt the data exchange. This would encrypt both the authentication credential exchange and the data exchange. SSL is much slower then HTTP traffic without SSL, so that is something you would want to consider. An appropriate approach may be to encrypt the initial authentication credentials exchange, and then switch to an unencrypted communication. This hybrid approach, as well as other application level web services approaches I’ll have to leave for some of the future issues.

    Adding SSL to your web service implementation does not require that you change anything to your server side implementation of your web service. It requires you to go to a Certificate Authority (CA), such as VeriSign at http://www.verisign.com, Thawte at http://www.thawte.com, Entrust at

    http://www.entrust.com, or your own company CA if you have one, and request a web server certificate for IIS. You can even request a test certificate, if you just want to use one for testing purposes (for example VeriSign offers test server certificates). I’m not going to go through the details of obtaining a certificate

    and installing it, as that is somewhat lengthy discussion. The CAs’ web sites tend to have pretty good instructions for how to do this, and I would recommend that you follow their directions. Once you install your certificate to your web server, you would need to enable SSL. You can do this by opening the Internet Information Server or IIS MMC, go to your web server, right click on it and select “Properties”, select the “Directory Security” tab, and click on “Edit” under the “Secure Communications” section. The “Secure Communications” window will open up. Here, you can select to “Require secure channel (SSL)” for the web site. You can also setup to require SSL only to a particular directory, such your web service directory, or you can choose to be even more specific and do this at the level of the ASP listener page.

    Finally, you would have to modify the WSDL file to reflect the fact that the ASP listener is now only accessible by SSL. Also, this line has to have the correct name that is stated on the certificate (in my case that is the name of my server “titan” – this name of course can be a full domain name such as

    www.xmldevelopernewsletter.com).

     "https://titan/wsJobBankSec/wsJobBankListener.asp"/>

    That’s all for this issue. Your VB project now will go to the web service listener via SSL. No further modification to the client side of the web services code is necessary, either.

    Zoran Zaev works as the Principal Software Architect for xSynthesis LLC, a software and technology services company in the Washington, D.C. area. He enjoys helping others realize the potential of technology and when he is not working, he spends considerable time writing articles such as this one, and books (for example, he co-authored Professional XML Web Services and Professional XML 2nd Edition with Wrox Press). Zoran’s research interests include complex systems that often involve XML, highly distributed architectures, systems integration, web systems, web system usability, as well as the application of these concepts in newer areas such as biotechnology. When not programming or thinking of exciting system architectures, you will find Zoran traveling, reading, and exploring various learning opportunities.

Report this document

For any questions or suggestions please email
cust-service@docsford.com