Ask the Expert

Addressing critics who cite Web services security concerns, part one

How do you respond to critics who say that Web services security hasn't yet reached the point where it's safe for organizations to implement Web services? I've been hearing that a lot lately.

    Requires Free Membership to View

This is a very good question, especially at this stage of Web services development. The answer depends on the type of Web services interaction that you are implementing. Therefore, I'll categorize the interactions first based on the relationship between the requesting client and the Web service provider and then modify the answer based on an important security principle, risk management. An additional aspect is that there are two categories of protection, which I will classify as traditional security, such as SSL and Kerberos, and the newer Web services security such as WS-Security. Today, both Microsoft's .NET sdk and IBM's Websphere sdk have an offering of WS-Security, which support such capabilities as username/password, X.509 certificates, digital signature and encryption. Traditional security protocols such as SSL and Kerberos are readily available and can be used in certain situations to protect Web services transactions and can also be used in conjunction with WS-Security. On the authorization side, traditional security such as Access Control Lists (ACLs) and the method permission approach defined in J2EE, are available and are adequate for many Web services security transactions.

We'll divide Web services communication into three broad areas:
1.) Interaction within a single company, which we classify as an intranet communication
2.) Tightly controlled interaction between a predefined set of companies, which we classify as an extranet communication; and
3.) Loosely controlled interaction between companies, which we classify as an internet or federated communication.

Intranet Web services communication can usually be carried out securely today. Since the two sides of the communication have a known relationship, the requestor could use password in a WS-Security SOAP header as its authentication evidence and a point-to-point transport security like SSL for protection over the wire. Bringing risk management into the equation, if the value of the service offered is high you might not want to rely on password, which is a weak type of authentication. In that case you could require that the requesting client use X.509 certificates. Traditional authorization methods would be adequate in the intranet case.

Read part two of this answer.

This was first published in June 2003

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: