Lakshmi Hanspal

Subscribe to Lakshmi Hanspal: eMailAlertsEmail Alerts
Get Lakshmi Hanspal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Web Services Security

Web Services Security

Web services is a promising technology for achieving B2B enterprise application integration. However, the challenge of ensuring security in a Web services environment stands as a major obstacle to general acceptance of the technology.

In the first part of this series (WSJ, Vol. 2, issue 10), I discussed traditional approaches to securing Web services and the shortfalls of these approaches, demonstrating the need for a comprehensive, standards-based security framework with a purpose-built solution, such as SOAP Content Inspection, to completely secure Web services.

In this article, I further explore the world of federation in B2B Web services. Distributed-component computing allows the sharing of information among enterprises. But enterprise security policies are likely to be different (say, between a hospital and a bank), which means that data sharing requires translations between enterprise policies. We will also discuss how a security framework approach using the Web Services Proxy unifies federated security

Web Services and Federation
The advent of Web services has altered the economics of application integration by expanding the possibility of EAI (enterprise application integration) to not only high-dollar, large trading partner enterprises, but also to small and medium-size companies that typically lack the sizable IT budgets of their much larger counterparts. By standardizing all APIs as XML format, Web services provides a starting point to enable cooperative computing and federation of applications.

So What's The Catch?
Such federation opens a Pandora's box of security issues. Web services have a huge problem in that they are too open. Companies will need to limit access to their valuable resources, such as patient records, credit card numbers, manufacturing designs, etc. Hence, there is a need to collaborate and share information, but not at the expense of giving away corporate assets.

What Is Federated Security?
The Internet is a prime vehicle for business, community, and personal interactions. The notion of security is a crucial component of this vehicle. Security on the Internet is fragmented across various business providers, such as differing and disparate user identities, security mechanisms, and business access policies. This fragmentation yields isolated services and/or poorly connected business-to-customer relationships and experiences.

Federated security is the key to reducing this fragmentation and realizing new business taxonomies and strategic opportunities, coupled with new economies of scale. A good example is the notion of several different companies cooperating on a single transaction (such as making a reservation that involves airlines, hotel rooms and rental cars: the federated identity could mean a single sign-on and linking all these transactions on different sites). So at its heart, federation means trusting sources to come across your borders and opening up your services to them. Federated identities are portable across normally impervious enterprise boundaries. Federated single-sign on allows users to sign on once with a member of an affiliated group of organizations, and subsequently use various services offered by the group without signing on again

Business Trust Models
Federation works on the principle of a business trust model. As more and more businesses execute their transactions and move XML data across the Internet, they face increasing security challenges as they attempt to protect business-critical data and access to their business with increasingly complex trading relationships. Web services that span multiple trading partners usually require interaction between many entities (users, application components) and integration across different corporate security policies for authentication and authorization.

Consider a trading transaction that spans multiple business processes across multiple enterprise domains (see Figure 1).


A trade request to buy 500 shares of Company XYZ is sent from a trader application in one enterprise domain to a brokerage application at a brokerage company. On approval, the trade is executed and the settlement request is sent to the accounting application (in another company) to debit the appropriate amount from the customer's account. Confirmation of the debit and execution of trade is then sent back as a response to the trader application.

Web services expose the internal network to requests via HTTP that passes through firewalls, requiring trustworthy connections of multitier applications - applications that proxy (delegate) the request to others downstream. Although single sign-on facilitates the ease of use of such application chaining, it alone does not secure application chains; typically it only applies within a corporate or business unit environment. Furthermore, different companies use different security products that don't interoperate. Consequently, the lack of consistent user identities, authentication and authorization policies, and implementations introduce a level of complexity that must be addressed in order to define business trust levels in a federated environment.

First- and Last-Mile Problems
Web services create a jungle of tangled integration processes, from the integration of disparate business applications to the integration of back-end business systems.

Access to most business Web services will need to be restricted to only authenticated clients. Currently, Web services standards efforts do not prescribe any standard mechanisms or measures to describe or package authentication evidence such as userID/ password, certificate, biometric information, etc.) to present to authentication services to authenticate the entity (user, application component, etc.). This leads to lack of bridging for the "first mile" of Web services access.

Second, emerging Web services standards tend to ignore the fact that there are many, many applications and programs in the world that are not XML-centric. Back-end systems are full of applications and programs with proprietary data and interfaces predating the XML era. Web services standards currently do not address integration in this area. This leads to lack of integration with the "last mile," and points to the need for a secure integration bridge between the land of legacy and the promised land of Web services.

Enterprise Policy Mapping
Web services security standards address standardization of data schema and formats. Given that these standards are approved and adhered to, there still remains the issue of data mapping. Although there are emerging standards such as XACML (Extensible Access Control Markup Language) to define standard access-control policies, the semantics of data in these policies is left to interpretation. A simple example is illustrated by the notion of enterprise user roles: the roles of users in each enterprise could be semantically different (each role, e.g., buyer, purchaser, customer, could all mean the same thing in different companies, and yet have different rights in each domain). Enterprise security policies could use enterprise-specific roles for their access-control policy rules. Even within an enterprise, different business units could use different application-specific roles. Here there arises a need for role mapping that can determine equivalency or a unique translation of roles.

Unified Security via WS Proxy
To make Web services successful, security must be in place to handle federation. Companies will not open up corporate networks without proper security. There is a need to protect against external (such as from the Internet) and internal attacks (such as fraudulent trades and trapdoors left by ex-employees to access corporate systems). Furthermore, there is a need for an architectural approach to unify security policy and implementation across different business units and companies.

Enterprise Application Security Integration (EASI) is a standards-based, vendor-neutral security framework that unifies the patchwork of security products and services deployed within the enterprise.

Current and emerging XML Web services security standards include:

  • WS-Security for SOAP message security
  • SAML (Security Assertion Markup Language) for exchange of user credentials between components
  • The Liberty Alliance Project for federated network identity and single sign-on and sign-out.

    So if all security products will eventually use these standards, why do we need EASI?

  • Existing standards do not cover all tiers of computing: Many of the standards play in the middle tier. Hence there are always legacy security needs that can be answered through EASI.
  • Standards do not guarantee compatibility: The hype of standards associated with SOAP and Web services comes with the associated problem of the splintering of those standards. Pseudo-compliance or noncompliance creates pseudo or hybrid systems. EASI helps to connect countless data formats, standards and pseudo-standards.
  • Standards are moving targets: EASI allows applications to take advantage of evolving security services while the framework deals with such complex moving targets because of its plug-and-play approach.
  • Federation means enterprises also need to translate and map security data: Such mapping services are provided by EASI, which insulates the user from the complexities involved and eliminates disconnects in the existing patchwork of point solutions.

    In B2B scenarios, Web services messages may travel over any number of connections and potentially traverse many intermediaries before reaching their destination. In order to support this decoupled interaction, connection-oriented security alone is insufficient, requiring the addition of security on a per-message basis. Consequently, messages must be self-contained with respect to security information and carry all the necessary information and credentials with them. Inspection of message schema is also required to prevent unpredictable behavior of Web services due to poorly formed messages.

    Federation also frustrates accountability (audit). It is harder to keep track of what happened and who penetrated your defenses when an attack could come from outside your sphere of control and from systems that implement different security audit policies and track different user and application identities. Accountability in a federated environment requires a framework to unify audit policies. Audit records should be implemented to unify the meaning of audit events across different auditing services and to allow a means to correlate information collected in an audit repository with information collected in another to understand what actually happened across a distributed transaction in a federated environment.

    Integrating Trust Across Enterprises: The Web Service Proxy
    A key service of the EASI Framework is the Web Service Proxy (WS Proxy), a flexible, standards-based solution that secures SOAP-based transactions for a range of enterprise B2B applications (see Figure 2).


    The WS Proxy uses services provided by the underlying EASI Framework. Its combination of services supports the three principles of Web services security:

  • Trust no one: Requests traverse many domains and applications. Hence a single compromised point may make the system vulnerable if additional checks are not in place. The WS Proxy supports client authentication, thereby providing a bridging solution to the "first mile" problem.
  • Enable interoperability: A single vendor solution does not solve all aspects of security; customers and partners will pick different products, requiring interoperability with other Web services and applications using incompatible security The WS Proxy (through the EASI Framework) provides connectivity to back-end systems for request processing, thus eliminating the bottleneck that these systems pose for Web Services and bridging the "last mile."
  • Modularize security: Web services security technology will continue to evolve, so there is a need to maintain flexibility to mix and match emerging security technologies without requiring recoding of applications.

    The WS Proxy in Various Domains
    The WS Proxy provides security for Web services deployed in different domains (see Table 1).


    In each domain, the domain security policies are applied for authentication, authorization, audit , etc. Domain policy metadata relationships can be established using WS Proxy administration. These relationships can be used to translate between differing domain policy data such as roles.

    Web services demand attention to federation of services and security. Developing federated security policy support for Web services is an evolving part of EASI.

    Comprehensive SOAP/XML message security is more than encryption. It requires an application-level security gateway as a flexible, transparent solution that performs message analysis as well as authentication, authorization, and auditing services to protect business-critical Web services.

    The EASI Framework, along with the WS Proxy, enables organizations to leverage their existing investments and easily develop new business relationships with suppliers, vendors and customers, while ensuring adherence to corporate policies to achieve unified security in federated environments. WS Proxy provides comprehensive inspection of messages (message validation, message integrity, and message-origin authentication). Critical integration with enterprise security services (authentication, authorization, audit, SAML interoperability) and SOAP security ensure end-to-end protection and assurance.

  • More Stories By Lakshmi Hanspal

    Lakshmi Hanspal is a Security Architect with Quadrasis, a business unit of Hitachi Computer Products (America). She has extensive experience in the architecture, design and development of security and directory services. Lakshmi also works with customers to provide Enterprise Security Solutions. Lakshmi has a B.S in engineering and currently completely her Masters in Computer Science.
    Speaking Experience: Lakshmi has given technical presentations in Novellís Brainshare (Technology Lab) during 1997 & 1998 in Salt Lake City.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.