ASP.NET

Security is a very broad field. Even if you have been reading all sorts of security books, monitoring all SecurityFocus mailing lists, subscribing to various RSS feeds, and reading new security whitepapers, virus writers can still exploit the latest vulnerability and successfully carry out zero-day attacks. These attacks spread so quickly that professionals have no time to react, which leaves you, the system architect or solution developer, the responsibility to employ security strategies and technologies to defend against attack and minimize damage.

In this article, we will focus on how to implement WSE 2.0 to secure business integration systems. Since we've implemented large integrated solutions that manage hundreds of thousands of transactions per day, we will show you the security issues we deal with on a daily basis.

A Real-World Scenario
Enterprise Application Integration (EAI) is the practice of seeking to integrate applications internally within a business or an organization. Microsoft provides a whole family of products to support this scenario. The benefit of using Microsoft products is that you may leverage the security features shared among them, thus maximizing interoperability and minimizing custom-made code (see Figure 1).

For example, starting from the left of this figure, an employer may submit an employment evaluation form by filling in an InfoPath form or by using a Web application. InfoPath renders the user data as XML and sub-mits it to a .NET Web service. The web service preprocesses the user data and sends a request to a message broker, such as Microsoft's BizTalk Server. BizTalk executes the workflow and determines that the user data should be stored in the file system, in a SharePoint Portal Server, and in an SQL database.

Threat Modeling
Threat modeling is an iterative and systematic approach to identifying the attackers' viewpoint to your system. While threat modeling is strongly encouraged, most companies do not include this in the system design process because of limited budget or just because they haven't been trained to think about security.

It is important for the architects and developers to have a threat model in mind. The core idea of threat modeling is to identify assets and threats. Take a minute to imagine if you were the attacker, what would be worth attacking? Is it the employee record database, or the data integrity between the applications? The more you are worried about an asset being compromised, the more time and effort you should spend designing the security features.

If you are completely new to threat modeling, do not let the term frighten you. Threat modeling simply identifies threats using STRIDE and ranks the threats using DREAD. STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege) is a well-known methodology for categorizing threats. DREAD (Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability), is a common method of ranking threats by decreasing risk. You may want to refresh your memory by Googling these terms.

In our scenario, you may have identified the following threats (not exhaustive):

• Only managers can submit the employment review form (you want to prevent Elevation of privilege)
• The employment review form cannot be read by sniffing network traffic (you want to prevent Information disclosure)
• The employment review will not be modified after being stored into the database (you want to prevent Tampering)

After threats are identified, you may construct threat trees with mitigation plans. Frank Swiderski, a Microsoft Security Software Engineer, has built a Threat Modeling Tool to assist architects through this whole threat modeling process. For the sake of our article we will focus on preventing information disclosure, which leads us to our discussion of WSE 2.0.

WSE 2.0
Web Services Enhancements version 2.0 (WSE 2.0) is certainly a commonly discussed new toolset supporting many of the latest Web services protocol specifications, specifically in the realm of security. If you are worried about the authentication, integrity, and confidentiality of Web services, WSE 2.0 is the way to go.

Among other things, WSE 2.0 allows message-level authentication, which addresses our requirement in this scenario. By creating a UsernameToken with a valid username and password, you can sign and encrypt your messages such that the Web service can identify whether you have permission to access some resources. A client application has three options to create a UsernameToken.

UsernameToken token = new 
 UsernameToken("USERNAME", "PASSWORD", PasswordOption.
   SendPlainText);
UsernameToken token = new 
 UsernameToken("USERNAME", "PASSWORD", PasswordOption.
 SendHashed);
UsernameToken token = new 
 UsernameToken("USERNAME", "PASSWORD", PasswordOption.SendNone);

The three options allow you to specify what is to be sent through the network. If you are wise enough not to choose SendPlainText, but use SendHashed or SendNone instead, you will have to implement a UsernameTokenManager class in the Web service.

Let's briefly see how this works.
1)  Your client application cre-ates a UsernameToken from your username and password
2)  Your Web service, using the UsernameTokenManager, creates another Token with a valid username and password
3)  The Web service compares the two UsernameTokens

The Windows operating system stores account passwords in the registry or in SAM file as hashes. There is no easy way to derive the passwords from the hashes; therefore, you have to specify a means to retrieve a valid password in the UsernameTokenManager. You may store it in a secure resource such as a local database.

Not only can an application work with WSE 2.0, but BizTalk Server, the messaging broker in this scenario, also supports the exact same functionality. Figure 2 shows the configuration screen for the recently released WSE 2.0 Adapter for BizTalk, which allows you to configure a connection to a WSE 2.0-enabled Web service.

Also, UsernameToken can be configured in exactly the same manner, which is shown in Figure 3.

These new features have drastically increased the security profile of data communication between systems. In our scenario we may consider using WSE 2.0 to protect the messages between the Web service and the BizTalk orchestration.

There are many more security features that Microsoft products support. For instance, if you want to secure intranet Web applications, you may use the new .NET 2.0 DPAPI to encrypt partial web.config.

When we implement business integration systems, bear in mind that if you spent a lot of time implementing a solution with a lot of code, you are probably on the wrong track. Microsoft strongly encourages using their off-the-shelf components. A lot of security measures are implemented via configuration wizards and settings. Custom code tends to be more error-prone, more difficult to maintain, and is likely at risk of "breaking" with subsequent version releases of framework classes.

Conclusion
As technical architects and developers, we must always have security in mind. Even with Microsoft providing a robust infrastructure to create secure systems, it is disappointing to see that many business analysts consider security to be the last "feature" to implement - a "nice-to-have" that is often among the first to be discarded as budget and timeline pressures increase. It is our responsibility to remind them of the importance of security within systems.

The future of security, as a practice within software engineering, has a lot of room to grow, but WSE 2.0 is the kind of tool that should make it easier to do the right thing.

SIDEBAR

Writing Your First WSE 2.0 Application
WSE 2.0 is particularly applicable to the business integration platform because of its flexibility. Especially when you are working with existing networks, sometimes adding security would impact the infrastruction of existing applications, which you do not want to happen. WSE 2.0 allows message-level authentication, integrity, and confidentiality. In this section, I am going to show you how authentication (Is it really you?) and authorization (Are you allowed?) can be implemented with WSE 2.0.

Let's say you will write a C# application. It will send a request to a Web service, and it should return to you the motivation quote of the day. The Web service accepts one parameter, which is a string. How do you add security in this scenario?

First, create a local user called "FunnyUser" with password "password" (security worst practice), and a local group called "FunnyGroup." Add FunnyUser to the FunnyGroup.

For the Web service, Listing 1 shows you how to add WSE 2.0 functionalities. After you have this code, you need to enable WSE 2.0 on the Web service, and tell it to use this UsernameTokenManager. Right-click on your Web service project in Solution Explorer, choose WSE Settings 2.0, and follow these steps:
1)  In the General tab, check "Enable this project for Web Service Enhancements."
2)  In Diagnostics tab, check "Enable Message Trace."
3)  In the Security tab, under "Security Tokens

Managers," click add, and fill in the following details:

• Type: FunWebService.MyUsernameTokenManager, FunWebService
• Namespace: http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-wssecurity-secext-1.0.xsd
• wsse: UsernameToken

Now compile the project. The Web service should be compiled success-fully. For the client, basically you create a token with your credentials, add the credential to your request, and send the request. Listing 2 shows the code.

Now you need to enable WSE 2.0 for this application too. Right-click on your project in Solution Explorer, choose WSE Settings 2.0, and make sure that:
1)  In the General tab, you have checked "Enable this project for Web Service Enhancements"
2)  In the Diagnostics tab, you have checked "Enable Message Trace"

This would not be successful if you had specified incorrect "myName" and "myPassword" values. Now let's check whether we really have secured the Web request. In the last step, you have enabled message trace. In your application's bin folder, you should be able to find an OutputTrace.webinfo file. It will contain the content shown in Listing 3.

You will see that no password is sent through the network in plain text. Besides what is displayed above, you can also add a signature to the message, so you do not need to send the password across the network. You may encrypt the SOAP request so keep your message confidential too.

Congratulations on writing your first WSE 2.0-enabled Web service and client!