Web Services are emerging as the preeminent method for program-to-program communication across corporate networks as well as the Internet. Securing web Services has been a challenge until recently, as typical Web authentication and authorization techniques employed browser-to-server architectures (not program-to-program). This resulted in user identity ending at the Web Application Server, forcing the Web Services Provider to trust blindly that the Web Services Requester had established identity and trust with the end user.
white paper
Identity-Enabled Web Services
Standards-based identity for Web 2.0-today
OverviewWeb Services are emerging as the preeminent method for program-to-program communication across corporate networks as well as the Internet. Securing Web Services has been a challenge until recently, as typical Web authentication and authorization techniques employed browser-to-server architectures (not program-to-program). This resulted in user identity ending at the Web Application Server, forcing the Web Services Provider to trust blindly that the Web Services Requester had established identity and trust with the end user. Moreover, this mechanism did not provide any way for the Web Services Provider to verify the authenticity of the request. What was needed is a way to provide end-to-end federated identity that spans all the way from the Web browser to the Web Services Provider-Identity-Enabled Web Services.The convergence of Internet security standards has enabled Web Services and Web 2.0 to become a reality. Security Assertion Markup Language (SAML), an OASIS standard, has emerged as the lingua franca between Web browsers, Web application servers and Web Services Providers that use Simple Object Access Protocol (SOAP). SAML provides a common mechanism that allows identity to be passed through all layers. A WS-Trust Security Token Service (STS) is a "Rosetta Stone," translating between domain-specific security tokens and SAML-the glue that makes it all happen. Deploying an STS is the quickest, simplest and most scalable route to Identity-Enabled Web Services.white paper
Introduction Web Services are a gateway technology that provides interoperability across a wide variety of other software technologies. Typical enterprise deployments include using Web Services to enable ("webify") legacy systems, mainframe, ERP and CRM systems. What all of these "back-end" technologies have in common is that they are vital to the enterprise's long-term interest, and they generally lack the ability to communicate with modern systems like Web and application servers. Web Services are a set of technologies that communicate using modern, open standards like HTTP and XML to enable connectivity to the enterprise's core transactional and data-rich back-end legacy systems.The latest incarnation of distributed computing frameworks are Service Oriented Architecture (SOA), which are most often implemented with SOAP and REST (Representational State Transfer) Web Services. Some of the major architectural principles driving the adoption of Web Service-based architectures are the ability to use open standards (e.g. XML, SOAP, WS-Security, and HTTP) and a focus on interoperability, reuse and loose coupling. Fundamentally, when a Web Service Requester and a Web Service Provider communicate with one another, they should not know or be dependent upon the underlying details of each other's implementation-they are loosely coupled using a message-based integration.Message-based integration separates Web Services architecture from its predecessors. For example, in the 1990s, J2EE application servers like WebLogic® and WebSphere® were integration workhorses. J2EE clients communicated with J2EE servers using proprietary, binary protocols and formats such as a WebLogic client talking to a WebLogic server. The advent of XML enabled replacement of proprietary interfaces with XML-based open standards.The Web Services Identity ChallengeUntil now, most Web Services deployments relied on application- or system-level authentication to establish trusted user identity. In effect, a Web Services Provider validates the identity of the Web Service Requester-the application issuing the SOAP request-requiring it to trust whatever is contained in the message body. This trust model is not fully secure, however, because this scheme lacks any way to verify the authenticity of the request, leaving the door open for potential attack. A typical incremental improvement over blindly trusting the request is to use mutual authentication mechanisms available in transport protocols such as HTTP and TLS. This approach markedly improves the channel security so that the Web Service provider has high confidence that a trusted host sent the message. However, the contents of the message, such as data payload, are still unverifiable, which still leaves the potential for an inside-the-firewall attack. The net result is that the business logic and decisions executed by the... [download for more]
