Addressing critics who cite Web services security concerns, part one |
 |
|
| > |
QUESTION POSED ON: 03 June 2003
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.
|
|
| > |
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.
|
|
|
|
|
|
|
|
Search and Browse the Expert Answer Center
Search and browse more than 25,000 question and
answer pairs from more than 250 TechTarget industry experts.
|
|
|
|
|
|
|
|
|
|
|
|
