12.3 Security


Security has always been one of the most important and complex issues in information technologies because it's vital in the business world to protect the data, to ensure the integrity of messages and transactions, and to maintain confidentiality of the information. It was easy in earlier days when the main focus was physical security: all the computers were locked in a room with restricted access and accessed only locally by limited number of people. Internet and web-based environments have changed all that.

Security issues can be addressed at three primary levels: transport level, message or protocol level, and application level. It can be difficult to draw the line between them; for example, HTTP, which is an application protocol on top of TCP, is considered to be the transport level for web services protocols that use it. This section discusses the transport and message levels. Application-level security would be something like the addition of user credentials to the application data that gets transferred and isn't covered here.

12.3.1 Key Concepts

Security means different things to different people, so we generally try to be as specific as possible. For example, is a "secure service" one in which no one but the intended recipients can read the messages? Is it one in which no one but the recipients know they're even exchanging messages? Is it the one in which a hostile third party can't fake messages? Is it all or none of the above? Here are the key concepts:

Security

A system's ability to resist unauthorized attempts at usage or behavior modification, while still providing service to legitimate users.

Identification

The process of presenting an identifier to a system, so that the system can recognize a party and distinguish it from other parties.

Authentication

The process of verifying an identity claimed by or for a party. It's usually executed as validation of the party's credentials that can be as simple as a password or as complex as a X.509 certificate or Kerberos ticket. The more secure the method of authentication, the more confident you can be that parties who interact with the system are who they claim to be.

Authorization

The process of determining whether an authenticated identity is allowed to access the resource or perform a requested action, such as approving the loan, sending a purchase order or viewing the page. The two most widely used methods of access control are based on access control lists (ACL) or roles.

Integrity

The process by which it's ensured that information is intact and not changed by accident or due to malicious intent. The data integrity is protected by applying cryptographic technologies; in most cases, hash functions are used.

Hash Functions and Digital Signatures

A cryptographic hash function is an algorithm that produces a fixed-length hash from a variable-length message and for which it's computationally infeasible to find either (a) message that maps to a predefined hash result or (b) several messages that map to the same hash result. The idea is that if one party computes the hash, and any bytes in the message change, the recomputed hash will change, and it becomes possible to detect tampering. Examples of cryptographic hash functions are MD2 , MD4 , MD5 , SHA , SHA1 , MDC2 , and RIPEMD-160 . MD5 , Digest , or SSLeay modules from CPAN can be used to apply these algorithms.

A keyed hash is a cryptographic hash in which the mapping is varied by a second parameter (the first is the message itself) that is a cryptographic key. It makes such a hash more secure, because when the message changes, a new hash result can't be calculated without knowledge of the secret hey. Examples of the algorithms that produce keyed hashes are HMAC-MD5 , HMAC-SHA , and HMAC-RIPEMD-160 . The Digest::HMAC module from CPAN can be used to apply these algorithms.

A digital signature is a value computed with a cryptographic algorithm and attached to the message, in a way that allows the recipient of the message to verify the message's origin and integrity. Usually, a cryptographic hash function is applied to the message to get a hash result, which then is transformed using a private key from the signer. The signature value is the protected hash, because the algorithm used to create a hash ensures that if the message changes, the digital signature will no longer match it.

Confidentiality

The process of making information unreadable by third parties. It ensures that content may be accessed only by authorized parties, even when an intruder overcomes or bypasses other control mechanisms. In most cases confidentiality is achieved by applying encryption technologies, but other approaches are also possible, ranging from hiding links to the resource ( security by obscurity ) to hiding the existence of information in otherwise accessible content ( steganography and digital watermarking ) to hiding the information in intentionally added junk messages ( chaffing ).

Nonrepudiation

The ability of a party involved in a transaction to enforce the terms of the agreement against the other party. In other words, no party involved in a transaction can successfully deny it had involvement in the completion of the transaction.

Privacy

The state of being free from unauthorized access to personally identifiable information. Encryption technology may be used to achieve confidentiality but can't prevent inappropriate sharing of protected information. Privacy relates to control over what is done with this information and whether it's made available to other parties without the owner's concern; it's usually accomplished by a combination of technical and legal means.

Auditing

The process of maintaining a trail of all actions acted upon the system. Audit trails generally serve two purposes: they can spot attacks on the system (even though it may be too late to stop it), and they also can check for unacceptable behavior.

Digital rights management

The process of ensuring that content is used according to license agreement. Normally, access rules are incorporated with the content, and the client is responsible for enforcing constraints.

12.3.2 Transport Level Security

Basic authentication is commonly used on the Internet and unfortunately it provides very weak security protection. With basic authentication, username and password travel as clear text and are only weakly protected through a Base64 encoding. Moreover, because of the stateless nature of the HTTP protocol, the requestor must authenticate itself every time it accesses the protected resource, giving network sniffers many chances to intercept passwords.

It's easy to create code that provides basic authentication using the LWP::UserAgent module:

 #!perl -w     use LWP::UserAgent;     my $url = shift     'http://soaplite:authtest@services.soaplite.com/auth/examples.cgi'; my $rsp = LWP::UserAgent->new->request(new HTTP::Request GET => $url); print $rsp->is_success ? $rsp->content : $rsp->status_line; 

In a similar fashion, SOAP resources protected by basic authentication can be accessed using the SOAP::Lite module (note that this example shows how to provide username and password using the get_basic_credentials method, instead of embedding them in URI directly):

 #!perl -w     use SOAP::Lite;     sub SOAP::Transport::HTTP::Client::get_basic_credentials {    return 'soaplite' => 'authtest'; # username => password }     print SOAP::Lite   -> uri('http://www.soaplite.com/My/Examples')   -> proxy('http://services.soaplite.com/auth/examples.cgi')   -> getStateName(21)   -> result; 

Digest authentication was introduced in 1997 with HTTP 1.1 to address problems with basic authentication. While it still carries all the risks of any password-based authentication scheme that's dependent on the quality of the password, it uses a challenge/response technique to confirm that the requestor knows the proper name and password without actually transmitting the password information across the network. The LWP::UserAgent module also supports this method of authentication.

NTLM challenge/response authentication is a proprietary authentication scheme designed and implemented by Microsoft. It's similar to digest authentication, but unfortunately, uses a different challenge/response mechanism, and so the two are incompatible. Even though NTLM authentication is officially supported only for Microsoft products, there are several modules available on CPAN that work with this method: Apache::AuthenNTLM provides server-side support for Apache servers, and the NTLM and Authen-NTLM packages provide client-side support.

The Secure Sockets Layer (SSL) provides transport layer security. It is also known as Transport Layer Security (TLS) protocol defined by the Internet standard RFC 2246, which can be found at http://www.ietf.org/rfc/rfc2246.txt. SSL/TLS offers several security features including authentication (through client and server certificates), data integrity, and data confidentiality. The protocol known as HTTPS is really HTTP over SSL/TLS. Because HTTP's integration with SSL is transparent for the implementation of HTTP services (although it comes with some hit on performance), it can readily be used with any implementation that sits on top of an HTTPS-aware infrastructure. A web service over HTTPS with basic authentication is probably the most common way to implement transport security.

IP Security Protocol (IPSec) is another standard for transport security. Similar to SSL/TLS, it also provides secure sessions with host authentication, data integrity, and confidentiality. It also serves a larger issue of transport beyond one particular protocol: it's the base of most modern Virtual Private Networks (VPN).

Secured/Multipurpose Internet Mail Extensions (S/MIME) is a specification for encoding any content into ASCII character representation. It provides message integrity and allows for authentication. Because S/MIME uses client-side certificates, it suffers from the problems typical for those certificates: they have to be installed on the client side, they are difficult to revoke and invalidate, and they don't allow delegation of trust to allow other agents to act on someone else's behalf .

There is one more aspect that hasn't been discussed yet but is a hot topic for many security experts who talk about web services and transport security: firewalls. Most web services calls use HTTP as a transport and hence go through port 80, bypassing the firewall security or requiring some additional steps to filter the XML traffic.

As discussed earlier, the current version of the SOAP specification (1.1) includes a SOAPAction header. This header lets the transport infrastructure know it's a SOAP request, so that the infrastructure may act accordingly . However, this header is made optional in the current draft of the new SOAP specification (1.2) and likely will go away. People tend to agree that even if it may seem like a hole in the firewall security, sending an RPC request isn't very different from sending a document that triggers some action on a server side (those differences will be discussed later in this chapter) and as such, it should bear similar security constraints.

12.3.3 XML Security

XML security standards provide a set of technical specifications to meet security requirements of XML-based systems and applications. This section covers the general XML security standards; their integration with web services will be outlined in Section 12.3.4.

There are five core security standards:

  • XML Signature Syntax and Processing (XML Signature): for integrity

  • XML Encryption: for confidentiality

  • XML Key Management (XKMS): for key management

  • Security Assertion Markup Language (SAML): for authentication and authorization assertions

  • XML Access Control Markup Language (XACML): for stating authorization rules

There are also other specifications, such as Extensible Rights Markup Language (XrML) for digital rights management and Platform for Privacy Preferences (P3P) for expressing privacy preferences and policies, but they aren't detailed here.

These standards leverage and extend existing XML and security technologies as follows :

  • The XML security standards reuse existing cryptographic and security technologies, and leverage existing XML standards to support current XML efforts. For example, several crytographic algorithms are used by XML security specifications by associating unique URIs with them. XPath expressions are used by the XML Signature specification to refer to fragments of XML for processing.

  • The XML security standards define a shared meaning for the XML vocabularies that represent security information. One example is the KeyInfo element defined in XML Signature recommendation and used in other specifications, such as XML Encryption and WS-Security (all are discussed later in this chapter).

  • XML security technologies allow security techniques to be applied to the entire XML document, to fragments of the XML document, to XML elements and element content, as well as to binary documents.

  • The XML security standards allow implementation of end-to-end security, which is especially important when the message is routed through a number of intermediaries. Being associated with the content, rather than with a transport, persistent security also allows documents to be stored preserving the security context. Still, transport level security can be applied when necessary.

The XML Signature, XML Encryption, and XML Key Management specifications are produced by the World Wide Web Consortium (W3C), whereas Security Assertion Markup Language and XML Access Control Markup Language are specifications developed by the Organization for the Advancement of Structured Information Standards (OASIS). Even though the specifications developed by the two standards bodies complement each other, they go through different processes. Companies are becoming increasingly concerned about the complexity and speed of the W3C standardization process, and the recent submission of the WS-Security specification to OASIS rather than to W3C highlights that.

W3C Standardization Process

W3C is a consortium founded by Tim Berners-Lee in 1994. The goal was to create an international body to further develop the Web, which was rapidly taking off at that time.

The main products of the W3C are the specifications it produces. The highest status a specification can get inside the W3C is Recommendation. Before becoming a Recommendation, a specification undergoes several steps:

  1. A specification begins as a Working Draft (WD). Working drafts are written by Working Groups (WG) and generally represent work in progress and a commitment by the W3C to pursue work in a particular area. For example, working drafts of the SOAP Version 1.2 specification [1] were prepared by XML Protocol Working Group . [2]

  2. Last Call Working Draft is a special public instance of a Working Draft for which the Working Group seeks technical review form other groups, W3C members , and the public.

  3. When the review period is completed, a specification becomes a Candidate Recommendation (CR). At this period the specification is on active trial for a period of time to see if implementations succeed in conforming to it and become interoperable.

  4. As soon as a specification is believed to meet all the relevant requirements of the Working Group and any accompanying requirements document, it becomes a Proposed Recommendation (PR).

  5. Finally, the specification becomes a Recommendation.

Some specifications start with a request by one or more members or working groups, while others start as a concrete proposal to the W3C, in the form of a submission. Those submissions are published by the W3C as nonnormative Notes. For example, the XSL, SOAP, and XKMS specifications started as Notes.

[1] http://www.w3.org/TR/soap12

[2] http://www.w3.org/2000/xp/Group/

12.3.3.1 XML Signature Syntax and Processing (XML Signature)

The XML Signature Syntax and Processing specification can be found at:

http://www.w3.org/TR/xmldsig-core/

It defines mechanisms for creating and representing digital signatures.

An XML Signature can be applied to arbitrary digital content (the actual binary data being operated on by an application). The specification also defines techniques that address the variations allowed in XML, such as whitespaces, encoding, or attributes order. The reason for the concern is that cryptographic algorithms don't distinguish between markup and content and always operate on exact text, while XML allows some flexibility in physical representation for logically equivalent XML documents. The process of generating the common physical representation is called canonicalization (defined in XML Canonicalization specification, http://www.w3.org/TR/xml-c14n) and has to be applied before a digital signature is generated and validated .

Symmetric and Asymmetric Cryptography

Symmetric cryptography (also called secret-key or private-key cryptography) is a set of algorithms that employ the same key for encryption and decryption, or signature creation and verification. Both parties share the same key they must keep secret (hence the name secret-key cryptography). Examples of these algorithms are DES , DES-EDE3 , IDEA , RC2 , RC4 , RC5 , Blowfish , and CAST . Crypt-DES , Crypt-DES_EDE3 , Crypt-IDEA , Crypt-RC4 , Crypt-RC5 , and Crypt-Blowfish modules from CPAN can be used to apply these algorithms.

Asymmetric cryptography (also called public-key cryptography) is a set of algorithms that use a pair of keys (a public key and a private key. The public key is for verification of signature and encryption, and the private key is for creating a digital signature and decryption. Examples of these algorithms are Diffie-Hellman , DSA , RSA , El Gamal , and Rijndael . Crypt-DH , Crypt-DSA , Crypt-RSA , Crypt-IDEA , and Crypt-Rijndael modules from CPAN can be used to apply these algorithms.

An XML Signature can be applied to the content of one or more resources in different ways, depending on the desired application. The result of the processing is the Signature element that includes created signature and related information. Depending on the location of the signature and signed content, three types of signatures can be generated.

An enveloped signature is included in the signed element, as in this example (note that the definition for PurchaseOrder element has to allow this kind of enclosure):

 <PurchaseOrder Id="1234567">   ....   <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">      <SignedInfo>       <CanonicalizationMethod           Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>        <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>        <Reference URI="#1234567">...</Reference>     </SignedInfo>      <SignatureValue>...</SignatureValue>    </Signature> </PurchaseOrder> 

An enveloping signature includes content being signed in the signature, within an Object element:

 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">    <SignedInfo>     <CanonicalizationMethod         Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>      <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>      <Reference URI="#1234567">...</Reference>   </SignedInfo>    <SignatureValue>...</SignatureValue>    <Object>      <PurchaseOrder Id="1234567">...</PurchaseOrder>   </Object> </Signature> 

A detached signature is created over data external to the signature element. It usually applies to separate data objects but can also refer to data objects that reside within the same XML document but are sibling elements.

 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">    <SignedInfo>      <CanonicalizationMethod         Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>      <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>      <Reference URI="http://www.foo.org/purchaseOrder.xml">...</Reference>    </SignedInfo>    <SignatureValue>MC0C...</SignatureValue>  </Signature> 

Signature attributes (these are properties of a signature and have no relationship to XML attributes), such as time of signing, can be optionally signed by identifying them from within a Reference element.

The XML Signature specification supports the application of multiple signature to an XML document or sections of the document. The Transform mechanism allows doing that by permitting you to sign data derived from processing of the content. For example, an application that wishes to sign a form but permit users to modify limited field data without invalidating a previous signature might use XPath to exclude those portions that the user needs to change. Transforms are a very powerful mechanism and can include operations such as canonicalization, encoding/decoding (including compression/inflation), XSLT, XPath, or XML Schema validation.

12.3.3.2 XML Encryption

The XML Encryption specification can be found at:

http://www.w3.org/TR/xmlenc-core/

It defines a process for encrypting data and representing the result in XML.

Similar to XML Signature specification, XML Encryption can be applied at a fine level of granularity to XML content: to arbitrary data (including an XML document), to an XML element, or to XML element content. The result of the processing is the EncryptedData element that replaces the element or content in the encrypted version of the XML document.

In addition to the fine granularity of the encryption process, the specification also allows for the super-encryption of data (in other words, encrypting of XML in which some elements are already encrypted) and provides a separation of encryption information from encrypted data. The specification defines a simple encryption mechanism (yet it supports the variety of encryption algorithms and techniques) and doesn't address authentication, authorization, access control and trust issues.

The flexibility of the specification allows implementation of the end-to-end protection that protects not only data in transit, but also in storage, and allows part of the information to be revealed to intermediaries (if necessary). Consider this fictitious PurchaseOrder element:

 <PurchaseOrder>   <Number>...</Number>   <Date>...</Date>   <Details>...</Details> </PurchaseOrder> 

While it's possible to apply the encryption to the whole element, it's also possible to allow intermediaries to access the Number and Date but not the Details element. The PurchaseOrder element is encrypted:

 <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' MimeType='text/xml'>   <CipherData>     <CipherValue>MC0C...</CipherValue>   </CipherData> </EncryptedData> 

Here, only the Details element is encrypted:

 <PurchaseOrder>   <PurchaseOrderNumber>...</PurchaseOrderNumber>   <OrderDate>...</OrderDate>   <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'      xmlns='http://www.w3.org/2001/04/xmlenc#'>     <CipherData>       <CipherValue>AD0A...</CipherValue>     </CipherData>   </EncryptedData> </PurchaseOrder> 

Because the document can be not only encrypted but also signed, it brings an interesting question: how is the order of the processing determined? It's important to know, because if an element is signed and then encrypted, it has to be decrypted first, otherwise the signature won't match. The XML Decryption Transform specification, (found at http://www.w3.org/TR/xmlenc-decrypt), defines a resolution to the decryption/verification ordering issue.

Note the ability to sign the content that includes markup may pose additional security risks, particularly those that are associated with a known plaintext attack. Knowledge about particular text that was encrypted can make it easier to break the encryption and the availability of schema definition for a particular document makes plaintext attacks more likely.

12.3.3.3 XML Key Management (XKMS)

The XML Key Management specification can be found at:

http://www.w3.org/TR/xkms/

It specifies protocols for distributing and registering public keys, suitable for use in combination with XML Signature and XML Encryption specifications.

The XKMS specification comprises two parts ”the XML Key Information Service Specification (X-KISS) and the XML Key Registration Service Specification (X-KRSS). The X-KRSS specification defines a protocol for a web service that accepts registration of public key information. Once registered, the public key may be used in conjunction with other web services including X-KISS. The X-KISS specification defines a protocol for a trust service that resolves public key information contained in XML Signature elements. The entire process of registering, obtaining, and revoking keys can be delegated to the trust service, freeing the application from part or all of the tasks required to process key information. As a result, an application can be abstracted from the implementation details of the underlying Public Key Infrastructure (PKI) used to establish and carry on trust relationships.

The protocol defined by the X-KISS specification allows location and validation of the information required for signature verification or encryption. In both cases, public key information is returned. However there is one important difference: the locate service doesn't validate or report the revocation status and trustworthiness of used certificate.

The protocol defined by the X-KRSS specification allows registration, revocation, and key recovery. Note that the XKMS specification doesn't define how key management is secured. Implementations are responsible for protecting the confidentiality and integrity of the exchanged information.

Even though the message syntax presented in both specifications is designed to allow use of SOAP and WSDL specifications, it's possible to express the messages in a syntax other than XML and over protocols other than SOAP.

12.3.3.4 Security Assertion Markup Language (SAML)

The XML Security Assertion Markup Language specification can be found at:

http://www.oasis- open .org/ committees /security/

It defines an XML vocabulary for sharing authentication and authorization assertions, enabling third-party management of these functions. Assertions convey information about authentication acts performed by subjects, and authorized decisions about whether subjects are allowed to access certain resources.

An assertion is a declaration of facts about subject. SAML allows an issuer to make three different kinds of assertion statements:

Authentication

The specified subject is authenticated by a particular means at a particular time. SAML allows assertions to specify which type of authentication mechanism is used and supports several such mechanisms. Note that this assertion describes only the fact of authentication that happened previously and doesn't verify or revoke credentials this authentication is established on.

Attribute

The specified subject is associated with the provided attribute, which has a particular value.

Authorization decision

The request to allow the specified subject to access a particular resource if the specified evidence has been granted or denied .

Even though SAML assertions may be generated and exchanged using a variety of protocols, SAML also specifies a message exchange protocol that defines how the issuer can be queried for available assertion statements. Three types of queries are defined:

Authentication

"What authentication assertions are available for this subject?" A successful response includes assertions containing authentication elements.

Attribute

"What is the value of the requested attribute for this subject?" A successful response includes assertions containing attribute assertions.

Authorization decision

"Is this subject allowed to access this resource in the specified manner, given the specified evidence?" A successful response includes assertions containing authorization decision statements.

SAML defines an XML-based protocol by which clients can request assertions from SAML authorities. It also defines one SOAP binding (mapping of SAML request/response message exchanges into standard communication protocol) and two Web Browser Single Sign-On profiles (sets of rules describing how to embed and extract SAML into a framework or protocol).

12.3.3.5 XML Access Control Markup Language (XACML)

The XML Access Control Markup Language specification can be found at:

http://www.oasis-open.org/committees/xacml/

It defines an XML vocabulary for expressing access-control techniques in the form of policy statements for a variety of information systems and devices. This can then provide a consolidated view of the policy in effect across many systems and devices, which in turn aids in the enforcement of such policies.

XACML defines not only a vocabulary for expressing authorization rules but also a vocabulary for expressing a variety of conditions to be used to create rules. The specification defines rules as targets, effects, and conditions. A target defines the set of resources, subjects, and actions. XACML is designed to be used in combination with SAML; for example, XACML uses the SAML definitions for subjects and actions. An effect indicates the intended consequence of an evaluation for the rule and may have a value of either "permit" or "deny."

An important aspect of the specification is that it allows rules to be combined and describes how this is done. In addition to the simple combination of rules, they can also be collected into policy statements that include a target, rule-combining algorithm, a set of rules, and obligations. The target of a policy statement determines whether a policy is applicable and may be declared either explicitly (by the policy writer) or implicitly (derived from targets of component rules). An obligation is an action that is performed once the authorization decision is made (one of the examples included in the specification sends a notification email each time a patient's medical record is accessed).

12.3.4 Web Services Security

The XML security standards described in the previous section form the basis for providing security to other XML-related initiatives, such as web services. The Web Services Security specifications link together web services protocols (such as SOAP) and security specification (such as XML Signature and XML Encryption). Knowledge that data can be securely transmitted, processed , and stored is essential to the future of web services.

12.3.4.1 Web Services Security Language (WS-Security)

The Web Services Security Language specification can be found at:

http://www.ibm.com/developerworks/library/ws-secure/

Released by Microsoft and IBM, it subsumes and expands upon earlier specifications in this field (namely SOAP Security Extensions, WS-License, and older versions of WS-Security), and aims to describe a unified, flexible, and extensible security framework for web services.

WS-Security defines a SOAP extension to provide end-to-end message integrity, confidentiality, and single message authentication. It specifies how to associate security tokens with messages and is designed to be extensible and allow support for multiple security token formats, including but not limited to Kerberos tickets and X.509 certificates.

The WS-Security specification defines a Security element to be used in the SOAP message headers as a container for all other elements defined in the specification. For instance, the code in the following example shows how a SOAP request with simple UsernameToken may look:

 <s:Envelope xmlns:s="http://www.w3.org/2001/12/soap-envelope"             xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext">     <s:Header>             ...         <wsse:Security>             <wsse:UsernameToken>                 <wsse:Username>PaulK</wsse:Username>                 <wsse:Password>GooReria</wsse:Password>             </wsse:UsernameToken>         </wsse:Security>             ...     </s:Header>     ... </s:Envelope> 

To generate this header using the SOAP::Lite module, use the following code:

 use SOAP::Lite maptype => {  };      my $wsse = "http://schemas.xmlsoap.org/ws/2002/04/secext"; my $securityHeader = SOAP::Header->name(Security => {   UsernameToken => {     Username => SOAP::Data->type('' => 'PaulK'),     Password => SOAP::Data->type('' => 'GooReria'),   } })->uri($wsse)->prefix('');     my $result = SOAP::Lite   # include header as an additional parameter   ->securedMethod(@parameters, $securityHeader);   ... 

A BinarySecurityToken element might be used instead of the UsernameToken element to allow binary or other non-XML formats to be included in the message:

 <wsse:BinarySecurityToken   xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext"    ValueType="wsse:X509v3"   EncodingType="wsse:Base64Binary">   A0CD... </wsse:BinarySecurityToken> 

In this example, ValueType identifies the type of the security token (X.509v3 certificate), and EncodingType describes the method used to encode the data: Base64 or hex.

Integrity of the header and body elements may be provided using the XML Signature specification. As covered in the previous section, the Signature element can be used to carry on signature information. Confidentiality of the information in the message may be protected by means of XML Encryption. As already discussed in the section on XML Encryption, the encrypted element is replaced by an EncryptedData element; for every portion of SOAP message that is encrypted, one subelement has to be added to the Security header block. It can be a ReferenceList or EncryptedKey element that refers to encrypted fragment, or an EncryptedData element when non-XML attachments are encrypted.

When the message contains an invalid signature, invalid or unsupported type of security token, or produces a decryption failure, it has to be rejected, and an error may be reported using SOAP's fault mechanism. All errors are grouped in two classes: unsupported and failure.

The WS-Security specification cooperates well with the other XML security standards and defines two profiles for XML-based tokens: one for SAML and another for XrML. For more information, check out http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-security-xml-tokens.asp.

Using WS-Security, SAML assertions can be attached to SOAP messages by placing them inside the Security header element:

 <s:Envelope xmlns:s="...">     <s:Header>         <wsse:Security xmlns:wsse="...">             <saml:Assertion xmlns:saml="..." ...>                 ...             </saml:Assertion>             ...         </wsse:Security>     </s:Header>     <s:Body>         ...     </s:Body> </s:Envelope> 

In a similar fashion, XrML licenses can be attached to SOAP messages by placing the license element inside the Security header element:

 <s:Envelope xmlns:s="...">     <s:Header>         <wsse:Security xmlns:wsse="...">             <xrml:license xmlns:xrml="...">                 ...             </xrml:license>             ...         </wsse:Security>     </s:Header>     <s:Body>         ...     </s:Body> </s:Envelope> 

Given all that, WS-Security provides a flexible way for the message sender to claim the security properties by associating security tokens with the message.

12.3.4.2 WS-Policy, WS-Trust, WS-Privacy, WS-SecureConversations, WS-Federation, andWS-Authorization

The Web Services Security architecture and roadmap document can be found at:

http://www.ibm.com/developerworks/ webservices /library/ws-secmap/

It indicates plans for other specifications, which are still only plans at the time of writing:

WS-Policy

Describes the security capabilities, constraints and policies on intermediaries and endpoints (e.g., required security tokens, supported encryption algorithms, privacy rules)

WS-Trust

Describes a security trust model that enables web services to securely interoperate across multiple trust domains

WS-Privacy

Describes a model for web services clients and services to state and enforce privacy preferences and organizational privacy practice statements

Follow-up specifications are layered on top of the previous specifications and include WS-SecureConversations, WS-Federation, and WS-Authorization:

WS-SecureConversations

Describes how to establish message exchanges between parties including security context exchange across trust domains using key exchange

WS-Federation

Describes how to manage identities in a heterogeneous federated environment

WS-Authorization

Describes how to manage authorization data and policies in a web services environment

Some of the proposed and existing security standards have considerable overlap and the relationships between WS-* specifications and XKMS, SAML, and XACML specifications aren't immediately clear.



Programming Web Services with Perl
Programming Web Services with Perl
ISBN: 0596002068
EAN: 2147483647
Year: 2000
Pages: 123

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net