- Web Services Trends
- Basic Web Services Workflow
- Service-Driven Architectures
- Enterprise Security
- Security In a Web Services Context
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Security In a Web Services Context
The three golden rules of enterprise security (securing access to resources, securing the message, and securing the wire) are very much applicable to Web services. In fact, many of the standards and technologies we will discuss later fit perfectly into these broad categories.
So, what is the big difference?
Well, it's this:
The way Web service applications evolve and interact are totally different from what we have seen in the past (all sorts of client-server interactions). This has necessitated a complete rethinking and redefinition of what we mean by security in a service-driven world.
Web service technologies have been governed by organizations and consortia that dictate platform-independent/vendor-neutral standards using XML. This has resulted in further challenges in terms of evolving consensus and dictating appropriate standards that are acceptable to most, if not all.
Let's discuss these two aspects in detail.
Impact of Web Service Interactions in the Security Realm
Web service technologies provide the much-required flexibility in application-to-application integration. This provides room for complex interactions across disparate systems scattered along the network and the Web.
Web services promote many-to-many models (several services interacting with several others) instead of the many-to-one model (several clients interacting with one server). This has serious impact on the security methodologies that have been adopted so well in the past. For example, in a client-server model, it is enough if we authenticate and authorize a person or application during login process; and as long as the session is valid, the server-side applications can continue to serve the requests. But the same is not applicable in case of Web services because the services themselves may not be available in a single server or network. Sharing session and authentication information across the network—across disparate application—is not only difficult, but resource-intensive, as well. Suppose that one client request associated with five different services—authenticating and authorizing each time—results in 10 database calls. If the client makes five requests, it results in 50 database calls! Even if we were to appoint a dedicated service for authentication/authorization in front of the business service, each service would have to validate the session information with this security service, which is highly resource-intensive.
The level of trust placed over a given client request might vary across different services. For example, a request from the company's employee through an intranet might enjoy more privileges than a similar request from a business partner through the Internet. When each of these Web services tend to evolve their own privilege matrix, it becomes difficult to assemble them to evolve more meaningful services. This complexity has inspired companies to evolve a separate trust layer like the Microsoft's Trust Framework.
As service federations (pools of related services) evolve with the promotion of service-driven architectures, it becomes important to distinguish a peer service's request from that of an outsider. This means the evolution of common security infrastructure for all federal services in the domain and shared privileges and access rights (Federated identity). The grammar security architecture will depend upon the complexity of interactions within the federation. An even more complex scenario is "dynamic Web service federations," in which service federations emerge just in time, based on the nature of client requests!
As Web services result in highly decentralized application interactions, it becomes difficult to share and distribute secret cryptographic keys. As a direct result, messaging security layers that ensure integrity, confidentiality, and non-repudiation of a given request are all affected. Ensuring a safe pipe from end to end becomes complex.
Web services technologies are touted as platform-independent and language neutral standards, relying solely on XML and its offshoots at their base. This means we cannot readily make use of the existing/proven security solutions in the market that are available in different flavors for different runtime environments to secure Web services. Many of them, being platform-specific, may not be flexible enough to extend themselves to an XML-driven security architecture.
Web Services Security: Technologies and Standards
Industry-neutral bodies and consortia—such as W3C (http://www.w3c.org), IETF (http://www.ietf.org), and OASIS (http://www.oasis.org)—propel Web services technologies and standards. Individual business entities such as Microsoft and IBM submit their technologies as proposals to these bodies, where they undergo suitable revisions by participating members before being recommended as an industry standard. Core Web services technologies such as SOAP and WSDL evolved in this way.
Although such efforts have promoted platform- and language-independent standards, they have also slowed down the overall progress and growth of Web services technologies. Evolving consensus across competing standards and business bodies becomes difficult because each company wants to take competitive advantage over the others by making its own technology a W3C standard. Some companies have even forged independent partnership deals and alliances with their close allies in dictating Web service security standards, leaving the rest behind.
All these issues have slowed down the evolution of Web service security standards and technologies. A genuine enterprise developer is left with two choices for securing his Web service: Wait for the standards to evolve or go ahead with proprietary mechanisms dominated by vendor-specific security frameworks.
Despite this gloomy scenario, a few technologies have established themselves in the Web services security realm, and are well worth being considered as industry standards, including the following:
Security Assertion Markup Language (SAML) for Authentication/Authorization
XML Access control markup language (XACML) for Authentication/Authorization
XML Key Management Specifications (XKMS) for Cryptography
XML Encryption for Confidentiality
XML Digital Signatures for Integrity and Non-repudiation
SOAP security extensions for Integrity and Non-repudiation
In addition, attempts are being made to evolve common security architectures and frameworks in which different pieces of technology can fit like a jigsaw puzzle. This includes Microsoft/IBM's WS Security (http://www-106.ibm.com/developerworks/library/ws-secmap), the Liberty alliance project, XML Trust services, Hosted identity services, Web services for J2EE (JSR109—http://www.jcp.org/jsr/detail/109.jsp) and Microsoft's .Net security.
In the following weeks, we will be exploring many of these technologies and standards, in detail.
So, stay tuned!