If you choose to deploy Web services, security will be a major issue. This tip from InformIT looks at the various...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
security issues related to deploying Web services and is a good starting point for contemplating the impact of these issues.
Security issues with Web services
By Scott Seely, Deon Schaffer, Eric A. Smith
When deploying a Web service, you have to think about how you will secure that service. Yes, even if you decide to open up access to the service to everyone and anyone, you still have to think about security — For example, protecting yourself against people seeking to deny access to your service. Security encompasses the following:
- Equipment deployment
- Authenticating users
- Guarding data so that users only see what they should see
- Tracking user activity
Any and all of these items may be a part of your overall security plan. In this chapter, we will take a look at all of these items and show how you can use them to make your Web service more secure.
One of the easiest things to do to secure your corporate data is to use hardware in an intelligent way. When deploying a publicly accessible Web service, you will want to expose as little of your internal infrastructure as necessary. There are a number of things you will want to do:
- Put your database machines behind a firewall.
- Use hardware to protect your equipment. For example, rely on routers instead of software firewalls. Hardware is typically faster at routing and is easier to lockdown. The software firewall may have unknown interactions with which to deal.
- Make use of a demilitarized zone (DMZ). In other words, only put the machine serving the Web service on the public Internet.
The basic theme in equipment deployment, as you have just seen, is that you should strive to keep the majority of your machines behind some sort of protective firewall.
You authenticate a user to learn his or her identity. The identity information might be used to make sure a person should have access to the Web service. You may also use the identity to track the user's activities. When it comes to authenticating your users, you have several options:
- Application-level authentication — Users identify themselves via credentials supplied in the SOAP message.
- HTTP basic authentication — The username and password are sent as clear text. This is not useful for secure applications, but it can be useful in combination with other identification techniques.
- HTTP digest authentication — This tool sends a hashed version of the basic authentication credentials so that only the server can decode them.
- Client certificates — Using a certificate provided by a certificate authority, the client can prove its identity during SSL authentication.
- Windows authentication — Through HTTP basic/digest authentication or client certificates, IIS can map a user identity to a real Windows user.
All of these options have different uses.
When you make your data, you can use the user authentication mechanisms discussed to guard it. You can use Access Control Lists to guard files and SQL-based security to guard data in your database. As part of your security for the Web service, consider using a combination of user identity and other security mechanisms as a way to protect your data. For example, SQL server allows you to limit who can and cannot access various databases, tables and stored procedures. NTFS limits what files a particular user can access. Active Directory can be used to limit the network resources the user can access. An effective security plan uses a combination of methods to keep things safe. By authenticating the user using Windows Integrated Authentication and denying anonymous access to the Web service, the Web method will impersonate the caller when it executes. Any rights given to that caller will be enforced. This includes access to files, network resources and database objects.
Tracking user activity
Many applications require that you give users access to sensitive resources. When the users are using those resources, you will want to be able to see what was done. What did they look at? What actions did they fire? What data did they change? Most of the time, the users will not abuse their privileges. However, when the users are new and are trying to do something wrong, you want to see what they did. It will help you back out the changes the newbie made. As a forensic tool, tracking the changes will help you identify who did what and when.
All of this involves creating some sort of an auditing strategy. In the best of all worlds, you will know exactly who is calling you. Auditing was discussed as a debugging tool in chapter five, "Troubleshooting Web services/consumers." For security, you can use auditing to determine what the user did and when he or she did it. What information do you track when auditing user activity? This set of data is specific to security:
- User identity (if available) — This lets you know who executed the action.
- IP address of caller — This allows you to track the call back to a specific machine. This comes in handy, even if the user is coming through some sort of proxy server.
- Free text field — You will want some sort of generic field that allows you to put all audit data into one table. Within this field, you can enter information particular to the action the user was performing. Think of putting in information that would be helpful when capturing details about what happened.
- Time of action — By knowing when things happened, you will be able to figure out the order of the actions and string together what the user did.
Keep in mind that a lot of this information will be used only when something odd happens. Depending on what the Web service allows users to do, you may want to write programs that analyze the audit data, looking for use patterns that look suspicious. So, what would this logging mechanism look like? Ideally, the auditing mechanism would use some sort of delayed write mechanism, such as inserting the item in to a queue and having a listener actually log the item to a database. I will highlight the one function you would want to adapt to actually use Microsoft Message Queue (MSMQ) instead of writing to a file, as is done in the example.
The code presents a class named Audit that handles extracting the audit data from the Web service and storing the audit to a file. This class is used by a HelloWorld Web Method.
You will need to use more than one technique to secure your Web service. The combination of techniques depends on what your security requirements are. Pay attention to where you deploy the Web service, and make sure that your critical data is protected from the public Internet. Web services, by providing a well-defined interface, can offer quite a bit of data protection by putting the Web service on the public Internet and allowing only the Web service server to get at the data.
By locking down the boxes and allowing only authenticated users to access the data, you lock out a number of malicious users. Of the users you do allow through, you will want to monitor what they are doing and store that data in a log. Even if you allow everyone through, you should include logging mechanisms and design these early in the development process. Adding logging after the fact is error prone and time consuming.
If you follow the recommendations in this chapter, you will have a more secure Web service. By monitoring who is calling the Web service, you will be able to figure out how it is being used. If you notice abuse, you will be able to figure out what group of machines is misusing the service and block them from any more transgressions.
Read more of this article at InformIT. Free registration is required.