Abstract
In the last three years, a number of new standards related to Information Security have been developed. The most recognized of these are Web Services Security (WSS), the Security Assertion Markup Language (SAML), and the Extensible Access Control Markup Language (XACML). This article provides a brief overview of all three, including how they were developed, why they are needed, how they are used, and how they relate to one another and existing security standards. Future articles will examine each in more detail.

Introduction
WSS, SAML and XACML all have some things in common. Perhaps the most obvious is that they all represent information using XML. Less obviously, while all three enable security services that have been used for years in computer systems, they each have specific features intended to make them suitable for large-scale, distributed environments, such as the Internet. Additionally, all three reference and incorporate existing security standards and attempt to minimize the extent to which they duplicate prior capabilities.

There are two primary reasons why these standards use XML. First, XML enables them to be extended conveniently to meet special requirements in a way that was not possible using older formats. Second, XML allows implementers to make use of the large number of software tools available for processing. In the case of WSS, there is the further reason that it is designed to integrate closely with the syntax and processing model of SOAP, which is defined in XML.

SAML
Authorization and audit trail are familiar security services. Previously, most systems were designed under the assumption that a single system would posses all of the information necessary to make access control decisions and have all of the data to record in the audit trail. However, large-scale distributed systems are always built by multiple organizations with a mixture of products. This means that users may be authenticated by different authorities using different methods. In addition, different authorities will retain different information about user properties and attributes. Centralizing all of these capabilities and information is just not practical. SAML provides standard formats to express authentication and user attributes and the protocols to ask for it and receive it. This is known as Identity Federation.

During the initial phase of development at OASIS, SAML specified only communication between producers and consumers of this identity information. SAML defined how to make assertions about user attributes and authentication events, as well as how to obtain them in a way that was both flexible and could be extended to meet other requirements. SAML also defined in great detail some common scenarios, such as Web single sign-on (SSO), to ensure interoperability.

SAML was further enhanced and extended by the Liberty Alliance Project and the Internet2 Shiboleth group. Features were added to enable communication between SAML authorities, describing authentication methods in more detail, logging out users, and protecting privacy. This work was submitted back to OASIS and incorporated into SAML 2.0, which became an OASIS Standard in March 2005. SAML is designed for use in many different environments, using many different methods of authentication and cryptography. It supports a variety of different message flows and may even be applied in legacy environments, which do not otherwise use XML.

XACML
XACML, also developed at OASIS, is a language for expressing access control policies. Most computer professionals are familiar with access controls based on permissions or access control lists (ACLs). However, these mechanisms lack the ability to express the complex policies often required in real-world systems. As a result, access control policies are often embedded into application code. This makes changing policies or even discovering what policies are being enforced very difficult.

XACML is capable of using practically any available information to decide if access to a resource should be permitted. It can also associate additional actions, called obligations, with the decision, for example, requiring that the requested data be destroyed after 90 days.

XACML can base its decisions on a resource's properties, including its content or on environmental factors, such as date, time, or location. It may also take into account properties of the parties associated with the request, such as role or group membership. This might include not only the party making the request, but also others such as the party receiving the data or intermediaries to the request.

XACML 2.0 was approved as an OASIS Standard in February 2005. It operates well in large-scale environments where there are multiple administrators creating policies. Just as SAML works with any access control system, XACML can be used with or without SAML, but specific features have been specified to enable them to work together.

WSS
WSS specifies how to protect SOAP messages as they pass over a network. It includes authentication, integrity protection, and confidentiality. It does not specify how access control is to be done, but instead provides information that may be used for it. Prior to WSS, the most common approach to protecting messages was to use the SSL or TLS protocols. These continue to be perfectly adequate for many applications. However, WSS provides more capabilities and flexibility.

Where SSL and TLS encrypt the entire message, WSS allows encryption to be applied selectively. For example, this allows application firewalls to inspect the unencrypted portion. Also, WSS enables the complex multi-party interactions that will be needed to conduct sophisticated e-commerce transactions.

In addition, WSS allows more flexibility in infrastructure choices. Like SSL and TLS, it can utilize X.509 technology, but also can use Kerberos, SAML or plain old username and password. Since WSS operates at the SOAP layer, it can travel with the message throughout the network and even persist when the message is queued or stored.

WSS makes use of the XML Digital Signature and XML Encryption standards developed at the W3C. WSS operates by inserting an XML element called Security into the SOAP header. This contains all of the information about authentication, digital signatures, and encryption that have been applied to the message. It gives the receiver the information necessary to decrypt and validate the message. The keys and authorization information may be specified using X.509 certificates, Kerberos tickets, SAML assertions, or other methods.

In 2004, WSS 1.0 became an OASIS Standard in two phases. Today, WSS 1.1 is nearing completion. Due to the flexibility permitted by WSS, interoperability between different products may be difficult. To deal with this challenge, the Web Services Interoperability Organization (WS-I) is developing a profile that reduces the variability and indicates best practices for the use of WSS (as well as SSL and TLS). Draft versions of this Basic Security Profile (BSP) have been made public and it should be final in early 2006. WS-I members are also building a Sample Application that illustrates the correct use of WSS and Test Tools that can inspect messages to see if they comply with the BSP.

Summary
The three security standards described above are designed with considerable flexibility, which they achieve in part by using XML. SAML and XACML support authorization services in almost any environment, but are particularly well suited to large-scale distributed systems. WSS provides message protection specifically in a SOAP environment, but offers considerable choice in software infrastructure. With XML as a common denominator, all three standards may be effectively applied together or used separately.

References
[URL=http://www.oasis-open.org/home/index.php]OASIS[/URL] homepage
[URL=http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss]WSS[/URL] homepage
[URL=http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security]SAML[/URL] homepage
[URL=http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml]XACML[/URL] homepage
dev2dev [URL=http://dev2dev.bea.com/webservices/]Web Services[/URL] Technology Center
[URL=http://dev2dev.bea.com/blog/neilsmithline/archive/2005/08/quick_wls_90_sa.html]Quick WLS 9.0 SAML Overview[/URL] - Neil Smithline's blog (dev2dev, August 2005)
[URL=http://dev2dev.bea.com/pub/au/3299]Harold Lockhart[/URL] is a principal engineering technologist in the Standards and Architecture Group at BEA. An internationally known author and speaker, he has been an active contributor in the OASIS Web Services Security and SAML technical committees.