Lakshmi Hanspal

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


Related Topics: Java EE Journal

J2EE Journal: Article

Web Services Security

Web Services Security

Web services is a promising technology with the potential to greatly simplify B2B enterprise application integration. This is good news for any organization trying to provide seamless access to their business applications for their customers and partners.

Along with these increased integration opportunities, however, arises a new-and daunting-set of security challenges.

What is a Web Service?
From a business perspective, a Web service is an innovative, new approach to integration. Existing applications can be reused, or new Web service applications can be deployed to promote integration - within an organization's intranet, over extended (partner) virtual private networks, or over the Internet.

From a technical perspective, a Web service is a collection of one or more related operations described by service descriptions (XML) and network accessible through standardized XML messaging. Thus, a Web service can be described, published, discovered, invoked, and integrated (with other services).

Security Challenges and Solutions
While Web services offer many integration advantages, they do present security challenges. Indeed, the absence of security seems to be the single largest obstacle to the general acceptance of Web services. Additionally, some misconceptions about what constitutes "adequate" security have further muddled the understanding of security needs with Web services. The following are examples of common misconceptions:

  • Transport and/or message security are good enough for Web service applications.
    Security is a system-wide concern. While transport security (e.g., SSL) or message security (e.g., SOAP security, including digital signature and encryption) can play a part in providing one layer of security, protection against unauthorized access to Web services themselves, the Web services registry, and enterprise applications and their data, and support for secure single sign-on (SSO) for accessing Web services within and across business domains must also be addressed.

  • Analysts predict that until security considerations for Web services are resolved, Web services are likely to first be deployed in an enterprise's intranet.
    Though this notion is reasonable, cyber threats come from many quarters. Even employees with valid system access can abuse their privileges. According to a survey of companies and government agencies commissioned in 2001 by the FBI and the Computer Security Institute, while 70% of computer attacks came from outside via the Internet, attacks from within accounted for most of the financial losses. This requires that security be addressed with equal importance in all enterprise tiers.

    Let's examine some of the security challenges that plague the world of Web services, and discuss solutions. It's important to recognize that each of these solution mechanisms offers specific security services catering to certain security policy requirements. Any multitier, multidomain security solution would include a combination of one or more of these security mechanisms with additional mechanisms to provide unified security.

    Transport Security
    Transport security provides privacy and data integrity for data transported between two communicating applications, as well as authentication of the communicating end points. The most commonly used transport security model on the Internet is a combination of HTTP Basic Authentication and SSL. HTTP Basic Authentication requires a user ID and password to visit Web sites that are protected using this mechanism. SSL is a protocol for transmitting data securely using encryption methods.

    Is transport security alone enough?
    Basic authentication is useful, but on its own not secure enough because the user ID and password are virtually unprotected. With SSL, it is possible to address a combination of server authentication and basic authentication to achieve authentication, confidentiality, and integrity.

    Depending on requirements, this level of transport security is usually not enough. Basic authentication may not fit all situations and there may be a need for certificate-based or smart-card authentication because of inherent weaknesses in password-based mechanisms.

    SSL is useful for ensuring confidentiality between service requester and service provider. However, at least two problems remain in the context of Web services messaging:

    1.   SOAP messages can include third-party intermediaries that might need to read all or part of the message. Inherently, SSL assumes that communication occurs only directly between two parties.

    2.   Because SSL encrypts the entire message, individual parts of a message cannot be encrypted or decrypted. SOAP security using encryption helps to partially solve this problem.

    Message Security
    Message security focuses on two critical security concerns: first, protecting message content from being disclosed to unauthorized individuals (confidentiality); and second, preventing illegal modification of message content (integrity).

    With respect to the exchange of XML messages between two parties, the XML Digital Signature provides a means to identify the sending party (identification), and to demonstrate that the message has not been modified (integrity). The SOAP Digital Signature specification defines how to embed the signature element of XML Digital Signature in a SOAP message as a header entry.

    XML Encryption defines how to encrypt data and represent the result as XML. The SOAP Encryption specification defines how to embed these elements in a SOAP message (header and body). The entire SOAP message or parts of a SOAP message can be encrypted to ensure confidentiality of the message contents when the message is sent to SOAP intermediaries.

    Is message security alone enough?
    Message security can be considered complementary to transport security. However, it deals with a smaller subset of the security issues for Web services. Although it covers identification, confidentiality, and integrity, it fails to address other important requirements, such as propagation of asserted identity across domains audit, etc. These requirements cannot be met by SOAP security alone, but by a combination of SOAP extensions and bindings to third-party security services (if necessary).

    Firewall Security
    Firewalls are used at the trust boundaries of enterprise networks. Firewall security enforces an access-control policy between two networks by blocking certain types of traffic and permitting others.

    In the early days of firewalls, a few well-known protocols, such as HTTP, Telnet, and FTP, required support. With the advent of newer protocols the demand arose for firewall policies to permit these protocols, an approach that was not recommended. To avoid making changes to firewall policies, "tunneling" was used to transport proprietary protocols over common protocols.

    Is firewall security alone enough?
    The rise of SOAP as the basis of Web services meant that HTTP tunneling could be increasingly common. However, the current generation of firewalls provides protection only at the network level, with minimal application awareness. Security for Web services requires the addition of application-level firewalls that inspect SOAP data content to protect against external attacks, as well as limit the effects of malicious software being transferred unintentionally among business partners.

    Component Security
    The advent of Web services has created a far greater challenge to the effectiveness and completeness of security services in the area of components. Ironically, security models within existing enterprise components - considered fairly recent adoptions within the enterprise business frameworks - have already been tagged as "legacy" in terms of what they can offer.

    Typically in a Web service, requests/ invocations are delegated to well-defined endpoints hosting the request-processing service. For example, in the J2EE platform, these endpoints typically tend to be enterprise business components like J2EE EJBs, servlets, JSP, Java Web Services (JWS), portals, or Remote Portlet Web Services. It would seem logical to use the security provided by these existing components, such as J2EE Role-Based Access Control and/or JAAS. Such a security mechanism could be programmatic or declarative.

    Is component security alone enough?
    The inherent security model of components (such as in J2EE) generally provides minimal security, such as coarse-grained access control (through roles). Often, once these applications have been Web services-enabled, additional security demands are placed on them in terms of complex, fine-grained access control and the portability of security information. Depending on component securities alone could lead to a single point of failure if compromised, as security is a cooperative effort among layers of protection.

    Existing Security Approaches for Web Services Security Integration
    Web services solutions in transport and message security have existed for a while and have been quite widely adopted by the Web services vendor community. But there are other parts of the Web services framework with security needs that have yet to be addressed for a standards-based solution. Hence, vendors of Web services environments (developer toolkits, runtime environments) are providing their own security mechanisms for access to registry, service, components, etc.

    Security by vendor extensions
    A common pattern in vendor-provided message security has been to place the security extensions in the SOAP header, in accordance with SOAP Header Extension Mechanism. The extensions may contain additional data to allow modular addition of features and services like transaction management, conversation state management, digital signatures, user credentials, and message routing (e.g., specifying the recipient). In this way, the message context information can be propagated along the process chain of invocation.

    Another pattern among vendor-provided Web services security approaches has been to make the security extensions part of the configuration information (XML file) for the Web services environment (container). Yet another pattern is to state security policies as tag extensions (similar to those used for javadocs) in the source code of the Web service implementations. Examples of such extensions include the authentication type to be used for the Web services, the delegation model (impersonation, etc.), and permissions for authorization based on roles.

    Are security-by-vendor extensions alone enough?
    When examined closely, we see that vendor-security extension has both pros and cons. Since this security is integrated with the deployment and runtime environment of Web services, it is readily available. However, configuration extensions are linked with the environment configuration, not the Web service definition, and thus lose portability across various deployment environments. Tag extensions (such as ones within source code) could lead to security policy inconsistencies, nonreusability, and maintainability issues.

    Additionally, integration with third-party security products may become essential depending on the complexity of security required and the reuse of existing security harnesses deployed within the enterprise. However, vendor-provided security may not support such integration. The W3C has a Web Service Description Group working on enhancing Web services description information to include (among other things) security. This could not only improve runtime security, but also provide accurate access control at the time of publishing and brokering at the service registry.

    Web Services Registry Security
    With Web services, two kinds of service registries are planned. The global business registry disseminates service descriptions to the public. Private registries may be more selective and could restrict access and content.

    Security concerns for all registries include prevention of unauthorized modification of registry content. Responsibility for administration of registry contents should rest with the content provider, who should be able to modify or delete content. Some security requirements for private registries include:

  • The registry authentication scheme should ensure that only known entities can access the registry information. A session-based security scheme could be provided.
  • The registry authorization scheme should provide granular access control to both public and private areas within the registry.
  • Messages between registry clients and services must be confidential.
  • The content submitted to a registry must be maintained in the registry without any tampering en-route or within the registry, guaranteeing integrity.
  • Though most of the security challenges for the service registry are in the areas of authentication, authorization, integrity, and confidentiality, more challenges unfold when we take into consideration registry replication and referral.

    Registry security has yet to be addressed by a standards-based solution. For now, registry hosts and vendors provide their own security solutions, sometimes simply relying on underlying OS security. Given the potential diversity of possible registries, a framework-based multidomain approach seems to be required to ensure registry security.

    Recommended Approach: Unified Security
    From the preceding analysis of the shortfalls of existing Web services security solutions, it is apparent that transport, message, firewall, vendor, or component security alone may be insufficient to secure an entire system. Existing security requirements and any unaddressed residual security issues demand a specific framework-based approach - one that brings together various security services and solutions throughout a Web services environment, unifying security and making it ubiquitous.

    What Is Unified Security?
    Unified security means integrating existing and planned security technologies and products across the perimeter, middle, and legacy tiers, providing seamless, end-to-end security for your enterprise

    The Need for EASI
    Just as enterprise application integration (EAI) technologies addressed the problems of data access and resource management across the enterprise by integrating applications and business processes into a single, virtual "business engine," companies now need a set of easy-to-use tools and technologies to control access to those same applications and processes. Today, a new class of technology, Enterprise Application Security Integration (EASI), is emerging to ensure that the distributed enterprise is protected.

    The EASI Security Framework
    The Enterprise Application Security Integration Framework is a standards-based, vendor-neutral security framework approach to unify the patchwork of security products and services deployed within the enterprise. The framework secures Web services traffic between .NET and J2EE environments, and integrates security across multitiered Web applications. It dynamically brokers security interactions across a range of security products, enterprise applications, application platforms, and Web services platforms at a transaction level. It supports all categories of security products for authentication, authorization, accountability, administration, and cryptography.

    By linking multiple security technologies and creating a common security infrastructure, the EASI Framework enables organizations to avoid potentially less secure and far more costly custom-built security solutions. It represents a cost-effective solution for unified security that is flexible, scalable, highly available, and reliable, positioning the enterprise-wide security infrastructure for future growth and change.

    We have seen that we cannot buy "partial security" when it comes to deploying Web services. Traditional firewall security can't peek into the message envelope and decipher XML traffic. Content inspection is critical for improved Web services security.

    SOAP Content Inspection
    Within SOAP-based Web services environments, a key service of the EASI framework is SOAP Content Inspection (see Figure 1). This flexible, standards-based solution secures SOAP-based transactions for a range of enterprise B2B applications.

     

    SOAP Content Inspection acts as an application-level firewall capable of inspecting the contents of communication. It provides a new layer of security for Web services - one that sits above transport or session layer security and examines the XML data itself. This XML data may be security or authentication information, such as an XML Signature or a SAML Assertion that could be evaluated using a security policy, or it could be a rogue Web service request designed to attack the service.

    SOAP Content Inspection addresses the challenges of Web services security by:

  • Authenticating and authorizing SOAP message originators, using identity and attribute information to determine if a user is authorized to access the Web service.
  • Establishing security context for authenticated users.
  • Securing messages using XML-based encryption and digital signatures.
  • Providing security audit capabilities for Web service access and usage.
  • Enabling establishment of enterprise security services policies that are consistently enforced during authentication, authorization and auditing. This policy-based approach means protection strength can be set independently of the application.
  • Facilitating cross-domain security interoperability by mapping user attributes from the originating enterprise domain to attributes in the destination enterprise domain using the Attribute-Mapping Service. This allows each processing domain to continue to function normally without requiring changes to existing code and policies.
  • Relieving application programmers of the burden of implementing additional, security-oriented functionality - reducing development time, while improving inter-business interoperability.

    SOAP Content Inspection can use Security Assertion Markup Language (SAML) to provide a standards-based approach for security information portability. SAML is an initiative orchestrated by OASIS (Organization for the Advancement of Structured Information Standards), an organization that has been a driving force in defining emerging standards for security information portability and security policies. More information on SAML is available at www.oasis-open.org/committees/security.

    It is ideal that SOAP Content Inspection uses the services of the underlying EASI Security Framework (see Figure 2), which supports access to multiple underlying security service providers. In this way, any component that does SOAP Content Inspection, acts as an "appliance" (a pluggable, easy-to-use component) that uses the framework services.

     

    Conclusion
    Protecting the security and privacy of exchanged information is absolutely critical to the success of any Web services architecture. This security model must be incorporated into the foundational layers of the enterprise Web services framework, supporting an evolving implementation philosophy. Enterprise applications cannot be forced to rely on a single provider for their security services.

    Given these realities, enterprises wishing to tap the advantages of Web services must adopt approaches to enterprise-wide security that enhance both security and flexibility. Implementing a comprehensive, standards-based security framework with purpose-built solutions such as SOAP Content Inspection, meet both critical requirements. Together, they provide a flexible way to unify diverse security solutions across multiple domains and to ensure the security of Web service applications, messages, and data.

    No security architecture for Web services should require enterprises to drastically alter their existing security architecture. Implementing an enterprise-wide security framework enables organizations to leverage existing investments, relationships, and policies for unified security.

  • 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.