Webservice Security- Perspectives from an SOA standpoint.
The superior man, when resting in safety, does not forget that danger may come. When in a state of security he does not forget the possibility of ruin. When all is orderly, he does not forget that disorder may come. Thus his person is not endangered, and his States and all their clans are preserved. - Confucius
This is part 1 of the two part article.
As SOA initiatives within enterprise deep roots, a new set of core requirements within various groups arises; the requirement for applications to be made SECURED,in a whole new way. The need for securing applications does not reside just among application groups as it never was. With layered approaches in integration and a services based architecture in place, this now becomes a shared responsibility. Again with new ownership models in place, it even becomes one of the key challenges in the implementation process.
Again, as I have always quoted, this need not be as difficult as it seem.
The two major needs:-
As opposed to dinosaurian age, security is not just a security team's responsibility which often is rippled through application groups. With rigid security measures like inspection of code and underlying architecture approval procedures, above all the rough talks that goes to and fro between application groups, security groups, infrastructure and possibly other groups, during the final few moments of release, has again created a need. Such several needs and the resolutions have put pressure on engineers to opt for a better way in implementing security.
Thus a need for a layered approach has complemented the need for service based architecture.
With this in picture, a new set of requirements raised. This would not make things difficult, but would now need some slight shifts in the way we make applications secure. The good part of the story is, now applications have suddenly become easier to maintain, security is more layered and so it is easy to communicate between stakeholders and what needs to be done to make it tightly secured. No more rough talks and disputes on what went wrong and who did that and so on and so forth.
Need A
From lessons learnt, a great deal of effort has been put in place to see that the new approach is measurably a great approach.
Why would this be different at all? What have thou brought forth?
Today's application requests originate from anywhere. In the sense, the call could be either an internal call or from a totally outside source, both are speeding towards the same destination, coming inside the enterprise seeking data. The life cycle of such a request would travel through various phases and would breeze through several protocols. These requests carry packets of data which in today's world are all XML. The evolvement of XML has bought in so powerful feature for business transactions which are semantically rich and structured data, they are text-based, and ready for web in nature; provide both challenges and opportunities for the application of encryption and digital signature operations to XML-encoded data. The data is business centric. As important as protecting the confidentiality of business messages is ensuring their long-term authenticity, data integrity and support for non-repudiation; in other words, functionality that ubiquitous, existing Internet security technologies (e.g., SSL and username/password) do not provide alone. It is clear to us that data needs to be streamed in through various check points and with a service oriented architecture approach, it is required to be verified and may be even inspected for business validations, at different levels. This could cause bottle necks in performance and throughput to a large extent. Thus, the need for XML data, to be protected at various levels, arises. A common infrastructure that would provide authentication and authorization and final packet delivery of untouched data by sniffers or man in the middle, need to be delivered in real-time. Again, as quoted earlier, this XML will be streamed through several check points where it might require some level of authentication, thus raising a key challenge of overcoming performance overheads and throughputs. It could be so cumbersome in certain cases, where incoming requests are high volume and where payloads are huge, that, it would cause networks to cripple down.
Need B
The requests coming in for seeking data today will carry with it huge XML packets. Therefore, at any point of time, network wires will be carrying and shuttling these XML packets, thus creating a need for XML aware network services to be in place, and they better be secured.
Securing XML
Yes. There is no one way or the other. The need is to secure the XML.
As Gartner says, infiltrating a corporate network by tapping into Web services interfaces is potentially more damaging than simply knocking out a Web site, because business-to-business applications expose valuable corporate information. Because XML messages are wrapped in the IP "envelope" that most firewalls are designed to track, corporate networks inspect the envelope but not the contents. Fraudulent XML messages could therefore enter corporate networks undetected.
Managers at corporations and agencies slowly realize that XML, the standard file format for sharing information in Webservices in a Service Oriented Architecture environment, is susceptible to attacks and viruses. Calls to webservices could be fictitious calls and could cause Denials of services and attacks could place malicious code inside the XML packets. Today, Consultants and officials at companies devoted to Webservices security are raising managers' level of awareness.
There are several vendors who play in this field. There are products like XML Firewall, XML Security gateways, Webservices security products and XML security frameworks. With these and XML accelerators, what was then a difficult task seems more seamless.
The implementation Basics:
With all these existing, within an enterprise, where complex systems which are already proven and in good working condition, to change it, for better support and maintenance perspectives and for that purpose, enforce security becomes more easier said, than done. Such a system needs to be approached in a strategic way and needs to be phased out, which many have begun to do so. Several security mechanisms and standards exist today. From XML Signature, XML Encryption, SSL, Certification to WS Security and SAML, different requirements dictate the implementation.
Whether to use WS Security or just SSL or to use simple two way certification where server and client mutually verify each other, all these depend largely on the type of requirement and may vary from projects to projects.
No matter what you do, simply make it all secured. Hackers are not yet ready for attacking a webservice based environment. Those attacks today, the very few, are NOT yet complex. But such attempts which are destructive in nature can be expected soon.
And hence securing your services is imperative.
In the next article, we will look into some code examples to handle different types of security mechanisms mentioned earlier in the article.
The superior man, when resting in safety, does not forget that danger may come. When in a state of security he does not forget the possibility of ruin. When all is orderly, he does not forget that disorder may come. Thus his person is not endangered, and his States and all their clans are preserved. - Confucius
This is part 1 of the two part article.
As SOA initiatives within enterprise deep roots, a new set of core requirements within various groups arises; the requirement for applications to be made SECURED,in a whole new way. The need for securing applications does not reside just among application groups as it never was. With layered approaches in integration and a services based architecture in place, this now becomes a shared responsibility. Again with new ownership models in place, it even becomes one of the key challenges in the implementation process.
Again, as I have always quoted, this need not be as difficult as it seem.
The two major needs:-
As opposed to dinosaurian age, security is not just a security team's responsibility which often is rippled through application groups. With rigid security measures like inspection of code and underlying architecture approval procedures, above all the rough talks that goes to and fro between application groups, security groups, infrastructure and possibly other groups, during the final few moments of release, has again created a need. Such several needs and the resolutions have put pressure on engineers to opt for a better way in implementing security.
Thus a need for a layered approach has complemented the need for service based architecture.
With this in picture, a new set of requirements raised. This would not make things difficult, but would now need some slight shifts in the way we make applications secure. The good part of the story is, now applications have suddenly become easier to maintain, security is more layered and so it is easy to communicate between stakeholders and what needs to be done to make it tightly secured. No more rough talks and disputes on what went wrong and who did that and so on and so forth.
Need A
From lessons learnt, a great deal of effort has been put in place to see that the new approach is measurably a great approach.
Why would this be different at all? What have thou brought forth?
Today's application requests originate from anywhere. In the sense, the call could be either an internal call or from a totally outside source, both are speeding towards the same destination, coming inside the enterprise seeking data. The life cycle of such a request would travel through various phases and would breeze through several protocols. These requests carry packets of data which in today's world are all XML. The evolvement of XML has bought in so powerful feature for business transactions which are semantically rich and structured data, they are text-based, and ready for web in nature; provide both challenges and opportunities for the application of encryption and digital signature operations to XML-encoded data. The data is business centric. As important as protecting the confidentiality of business messages is ensuring their long-term authenticity, data integrity and support for non-repudiation; in other words, functionality that ubiquitous, existing Internet security technologies (e.g., SSL and username/password) do not provide alone. It is clear to us that data needs to be streamed in through various check points and with a service oriented architecture approach, it is required to be verified and may be even inspected for business validations, at different levels. This could cause bottle necks in performance and throughput to a large extent. Thus, the need for XML data, to be protected at various levels, arises. A common infrastructure that would provide authentication and authorization and final packet delivery of untouched data by sniffers or man in the middle, need to be delivered in real-time. Again, as quoted earlier, this XML will be streamed through several check points where it might require some level of authentication, thus raising a key challenge of overcoming performance overheads and throughputs. It could be so cumbersome in certain cases, where incoming requests are high volume and where payloads are huge, that, it would cause networks to cripple down.
Need B
The requests coming in for seeking data today will carry with it huge XML packets. Therefore, at any point of time, network wires will be carrying and shuttling these XML packets, thus creating a need for XML aware network services to be in place, and they better be secured.
Securing XML
Yes. There is no one way or the other. The need is to secure the XML.
As Gartner says, infiltrating a corporate network by tapping into Web services interfaces is potentially more damaging than simply knocking out a Web site, because business-to-business applications expose valuable corporate information. Because XML messages are wrapped in the IP "envelope" that most firewalls are designed to track, corporate networks inspect the envelope but not the contents. Fraudulent XML messages could therefore enter corporate networks undetected.
Managers at corporations and agencies slowly realize that XML, the standard file format for sharing information in Webservices in a Service Oriented Architecture environment, is susceptible to attacks and viruses. Calls to webservices could be fictitious calls and could cause Denials of services and attacks could place malicious code inside the XML packets. Today, Consultants and officials at companies devoted to Webservices security are raising managers' level of awareness.
There are several vendors who play in this field. There are products like XML Firewall, XML Security gateways, Webservices security products and XML security frameworks. With these and XML accelerators, what was then a difficult task seems more seamless.
The implementation Basics:
With all these existing, within an enterprise, where complex systems which are already proven and in good working condition, to change it, for better support and maintenance perspectives and for that purpose, enforce security becomes more easier said, than done. Such a system needs to be approached in a strategic way and needs to be phased out, which many have begun to do so. Several security mechanisms and standards exist today. From XML Signature, XML Encryption, SSL, Certification to WS Security and SAML, different requirements dictate the implementation.
Whether to use WS Security or just SSL or to use simple two way certification where server and client mutually verify each other, all these depend largely on the type of requirement and may vary from projects to projects.
No matter what you do, simply make it all secured. Hackers are not yet ready for attacking a webservice based environment. Those attacks today, the very few, are NOT yet complex. But such attempts which are destructive in nature can be expected soon.
And hence securing your services is imperative.
In the next article, we will look into some code examples to handle different types of security mechanisms mentioned earlier in the article.
info@riverlog.com.
0 Comments:
Post a Comment
<< Home