Tip

Making sense of Web services security standards

Because Web-services solutions are implemented using standards-based technologies, it is important to adopt standards-based security mechanisms that facilitate and support interoperability and remain independent of operating systems, application infrastructures and programming languages.

With participation from leading technology companies, several industry-standard initiatives on Web services security standards are in progress. Let's explore the role and motivation of some of the most prominent XML standards and specifications that contribute to Web services security.

XML Signature (XML DSIG)
The XML Signature specification forms the basis for securely exchanging XML documents and conducting secure business transactions. The goal of XML Signature is to ensure data integrity, message authentication and non-repudiation of services. It is an evolving standard for creating and representing digital signatures using XML syntax and processing for XML-based data communication.

XML Signature evolved from the joint effort by the World Wide Web Consortium (W3C) and Internet Engineering Task Force (IETF) working groups. In a business scenario involving multiple parties, applying a digital signature to a complete document restricts the document to one party, and adding any further modifications by that party invalidates the originally signed document. To meet those requirements, XML-based digital signature mechanisms are designed to facilitate data

    Requires Free Membership to View

integrity in secure XML communication and to provide support for multiple parties.

XML Signature defines the syntax and processing rules that provide the flexibility to add multiple signatures to the different fragments of an XML document. Signatures intended for multiple parties associated with the content of the document can thus be preserved.

To find out the current status of XML Signature specifications from the W3C working group, refer to the W3C Web site.

XML Encryption (XML ENC)
XML Encryption specifications form the basis of securing the data and communication in order to conduct secure business transactions between partners. It is an evolving standard for encrypting and decrypting data and then representing that data using XML.

XML Encryption has emerged from the W3C as an industry-standard initiative for expressing encryption and decryption of digital content in XML. Traditionally SSL/TLS provides encryption for point-to-point communication, and during communication it facilitates encryption of the complete message or document in its entirety. SSL/TLS falls short of key mechanisms intended for XML-based business transactions, which require applying encryption for portions of a message, applying multiple encryptions to different parts of a message and then leaving selected portions of message unencrypted.

This mandates an XML-based digital encryption mechanism that meets the requirements of secure XML communication. These include message-level encryption and multiple encryptions to a message meant for multiple parties, a workflow, or a multi-hop communication.

Questions?
Get answers to your Web services security questions via SearchAppSecurity's Ask the Expert feature.

XML Encryption defines the syntax and processing rules that provide the flexibility of applying encryption or decryption to different fragments or a complete XML document while preserving the encrypted data intended for multiple parties in a workflow or a multi-hop communication involving intermediaries.

To find out the current status of XML Encryption specifications from the W3C working group, refer to the W3C Web site.

XML Key Management Service (XKMS)
XML Key Management Service (XKMS) specifications form the basis for registration, subscription and management of keys in XML Web services. XKMS facilitates PKI Key management functionality and services such as certificate issuance, processing, validation, revocation, status checking and so forth. These services are suitable for use with XML Signature and XML Encryption. XKMS enables offloading of PKI functionalities to remote trust service providers. XML Web services developers need to know only how to invoke these remote services by locating, registering and subscribing to the services.

In the case of Web services, using PKI solutions from multiple vendors mandates interoperability. XKMS introduces an easy solution for managing PKI-related functionalities by offloading PKI from applications to a trusted service provider. The trusted service provider facilitating XKMS service "under the hood" provides a PKI solution. That means client applications and Web services relying on XKMS do not require a PKI solution. Instead, they delegate all PKI-related responsibilities to an XKMS provider (trusted service) and issue XML-based requests for obtaining PKI services from them.

To find out the current status of XKMS specifications from the W3C working group, refer to the W3C Web site.

Web Services Security (WS-Security)
The WS-Security specification (also referred to as OASIS WSS or SOAP Message Security) is an industry-standard effort to secure Web services by collectively supporting and integrating multiple security standards and technologies.

WS-Security forms the basis for building interoperable Web services security infrastructure by defining end-to-end message-level security mechanisms for SOAP messages. With industry support, WS-Security is emerging as the de facto standard for securing Web services and promoting security interoperability in Web services.

In Web services communication, SOAP defines the structure of an XML document and the rules and mechanisms that can be used to enable communication between applications. SOAP does not define or address any specific security mechanisms. Using SOAP headers provides a way to define and add features, enabling application-specific security mechanisms such as digital signature and encryption.

The WS-Security specification incorporates a standard set of SOAP extensions required for securing Web services and implementing message authentication, message integrity, message confidentiality and security token propagation. WS-Security defines mechanisms for defining security tokens that include representing username and password combination, binary security tokens (e.g., X.509 certificate, Kerberos v5 ticket) and XML security tokens (e.g., SAML, REL). WS-Security also adopts signature and encryption mechanisms by building on the W3C XML Signature and XML Encryption specifications for defining the usage of various elements and a processing model for signing and encrypting messages.

To find out the current status of WS-Security specifications from the OASIS working group, refer to the OASIS Web site.

WS-I Basic Security Profile
The Web Services Interoperability Organization (WS-I) started as an industry initiative by leading technology vendors and organizations. Its ultimate goal is to promote interoperability in Web services implementations across platforms, applications, programming languages and devices. As part of its deliverables plan, WS-I introduced the notion of WS-I profiles to address the interoperability issues due to specification versions, dependencies, requirements and vendor interpretations.

The WS-I Basic Security Profile Version 1.x provides a set of requirements and guidelines to promote interoperability by adhering to standards and specifications that contribute to Web services security.

To find out the current status of WS-I Basic Security Profile from the WS-I working group, refer to the WS-I Web site.

Security Assertions Markup Language (SAML)
SAML is an XML–based framework for exchanging security assertion information about subjects. Subjects are entities that have identity-related information specific to a security domain.

SAML plays a vital role in delivering standards-based infrastructure for enabling single sign-on for heterogeneous applications without requiring the use of a single vendor's security architecture. However, SAML does not provide the underlying user authentication mechanism. In addition, SAML provides benefits in terms of interoperability among security providers, enabling remote authorization to support multiple applications under a domain or multiple domains and without duplicating user directory information associated with target applications.

SAML is also designed to be used with other standards. The Liberty Alliance Project, the Shibboleth project and the OASIS WS-Security standards have all adopted SAML as a technological underpinning to support identity management.

To find out the current status of SAML specifications from the OASIS working group, refer to the OASIS Web site.

XML Access Control Markup Language (XACML)
XACML defines a standard format for the expression of authorization rules and polices along with a standard way of evaluating rules and policies to produce authorization decisions. XACML also defines an optional format for making authorization decision requests and responses.

XACML can handle both XML documents and non-XML systems, though it can also handle non-XML objects using a custom context handler. It uses a declarative data model similar to CIM policy. It is generic to all industry sectors, but it is flexible enough to include new functionalities. In some ways, XACML complements SAML 2.0 by providing functionality that handles complex policy sets and rules.

To find out the current status of XACML specifications from the OASIS working group, refer to the OASIS Web site.

-------------------------------------
About the author: Ramesh Nagappan, CISSP, is a Java Technology Architect at Sun Microsystems who specializes in Java distributed computing architectures for mission-critical enterprise applications, Identity assurance and Access Management. Ramesh is the co-author of Core Security Patterns and also three other books on topics related to J2EE, EAI and Web Services. He frequently speaks at industry conferences related to Java, XML and Security. His current technology focus is on Web services security, identity assurance and strong authentication technologies using PKI, smart cards and biometrics.


This was first published in September 2006

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.