Review of web service security
In this article, we will provide an overview of Web Service Security. We will look at the the basic security mechanims including transport level security, basic and mutual authentication, SSL and many of features available for ensuring the integrity and privacy of your communications. This is part of a larger series of articles to help you prepare for the web service developer exam. You can review the last article, “Tutorial:Review of Building Web Services for the Web Service Developer Exam” if needed.
Introduction to Web Service Security
The advent of web services reveals new issues that previously were inexistent in closed environments. The new levels of openness, data exchange and interoperability brings new challenges to securing data as well as identities:
It is now possible to access numerous corporate applications as well as their interfaces over the public internet. Most of these are available over port 80, which is generally accepted as one of the main hole in all firewalls used for HTTP traffic flows. Applications providing front ends for critical data are increasingly being exposed through HTTP and accessible to anyone in the outside world.
Data is wrapped in SOAP envelopes provides a way to discern the structure and meaning of data being sent over the wire. Since the sending and receiving parties systems are implemented on different platforms with different security libraries often from different vendors. This leads to a need for a set of standardized, platform-independent security solutions.
XML is extremely verbose. Wrapping data in XML can increase the size of the data that needs to be encrypted tremendously. This can get expensive due to the cost associated with encryption
Web services enable spontaneous supply-chain communities or trading communities via dynamic discovery. These types of complex interactions involve SOAP message traversing multiple intermediaries. Some of these intermediaries might not be part of pre-existing business arrangements as well as being built on a different infrastructure. How does one manage encryption keys in such an environment?
These are the types of challenges that Web services bring. In a Web service world, there are security mechanisms that protect the confidentiality and integrity of information in transit. Data and messages are exchanged between a client and the Web service and the information is stored in a Web host. The protection of the information goes beyond simple two-way client-server interactions extending to more complex interactions involving business processes implemented through multiple Web services. Providing end-to-end security through distributed and heterogeneous security mechanisms requires the development of standards for Web services security that has the objective of making the security functions interoperable across different implementations. The key vendors in
- Web service space (including IBM and Microsoft) have developed a comprehensive framework of Web service security in accordance with the following criteria:
- Web services security standards must to be independent of specific underlying technologies.
- Web services security standards need to be composable.
- Web services standards must be organized in layers, so that standards at the upper level can use and extend standards at a lower level.
- Web services standards have to be extensible in order to deal with new requirements and technologies.
We look in detail at WS-Security explaining the basic security mechanisms that these standards address moving up from the communication layer up through to the application layer. The figure below shows the Web Service security standards framework:
The Web Services Security Standards Framework
The Web Services Security (WSS) framework encompasses different specifications, each of which address a specific aspect of security. According to the framework the different aspects have the following purpose:
- WS-Security - provides a message security model and specification of the mechanisms to attach signature and encryption headers to SOAP messages.
- WS-Policy - provides a means to describe the security policies. This includes the required security tokens, supported encryption algorithms, as well as the general policies adopted by a Web service. It also provides the mechanisms by which a trusted SOAP message exchanges can be built.
- WS-Trust - provides a means to define the model through the establishment of both direct and brokered trust relationships through the creation of security token issuance services. These relationships includes third parties and intermediaries.
- WSPrivacy - defines a model for embedding a privacy language into WS-Policy and associating privacy claims with a message with WS-Security.
Built on top of these standards are:
- WS-SecureConversation - provides a means of extending the single message security provided by WS-Security to a conversations consisting of multiple message exchanges. WS-Federation - provides a means to describe how to manage and broker trust relationships in a heterogeneous federated environment.
- WS-Authorization - is used to support the specification of authorization policies and for managing authorization data.
Note that the WS-Authorization and WSPrivacy specifications were not developed in the same manner as other of the roadmap. WS-Authorization is a replacement for eXtensible Access Control Markup Language (XACML). And WS-Privacy was addressed by manufacturer proposals such as the IBM Enterprise Privacy Authorization Language (EPAL).
Low Level security standards
Secure Socket Layer (SSL) and Transport Layer Security (TLS) is a protocol layer located between a reliable connection-oriented network layer protocol (i.e. TCP) and the application protocol layer (i.e. HTTP). This is shown in the figure below:
We use SSL/TLS to provide point-to-point secure sessions through the use of server authentication to the client, optional client authentication to the server, data message authentication, data confidentiality, and data integrity. For SSL, TLS includes an optional session caching scheme in order to minimize the number of connections that must be established. This optimization reduces the computational load of cryptographic operations, especially those using public keys. SSL/TLS provides for the following:
- confidentiality, through the use of symmetric cryptography for data encryption such as DES and RC4.
- data integrity through the use of a Message Authentication Code (MAC) generated by a secure hash function (MD5);
- authentication through the use of certificates and public keys.
- SSL/TLS provides fairly secure for point-to-point communications. But it alone cannot provide the end-to-end communication protection that is required for Web services. In fact, setting a message transmitted by a client such as a browser or an application could be processed or routed by amy number of intermediary applications or services before reaching its final recipient. SSL/TLS only protects the message contents while in transit between pairwise endpoints. The message,once processed by SSL/TLS at a receiving end is delivered decrypted to the application layer.
This is illustrated in the figure below:
The intermediary application or service might inadvertently or maliciously examine or possibly modify the message before transmitting it on to the next recipient. Finally the other key inadequacy of SSL/TLS in that it doesn’t allow one to selectively encrypt parts of the payload to be transmitted.
XML Data Security
As XML is the language of choice for representing data exchanged between Web services, securing XML data by protecting their integrity and confidentiality as well as their authenticity is a key requirement that needs to be fulfilled. You can achieve Integrity and confidentiality while exchanging data between Web service through the use of encryption mechanisms. Verifying the authenticity of the data is achieved by the use of digital signatures. The standards in place to achieve this are XML encryption and XML Signature. They specify how to represent and convey encrypted data as well as providing a digital signature for an XML document in a standard way.
The XML Encryption specification is a W3C Recommendation as well as the cornerstone of the Web services Security Framework defining a standard model for encrypting both binary and textual data. It also serves as the means for communicating the information needed by recipients to decrypt the contents of received messages. SSL/TLS provides confidentiality at the transport layer and XML Encryption provides confidentiality at the application layer. This assures end-to-end confidentiality of messages traversing multiple Web services. The figure below shows how XML Encryption is used:
The XML Encryption specification describes how to use XML to represent a digitally encrypted Web resource including XML data. It separates the encryption information from the encrypted data, specifies how to represent information about the encryption key and algorithm as well as supporting referencing mechanisms for addressing encryption information from encrypted data sections and vice-versa.
Encryption doesn’t guarantee by itself the integrity of the encrypted data. When integrity is required, the signatures represented by the XML Signature standard are required to be used. The combination of digital signatures and encryption over a common XML element can introduce security vulnerabilities. More precisely encrypting digitally signed data may leave the messages vulnerable to plaintext guessing attacks if the digital signature in clear. These types of vulnerabilities can be mitigated by using secure hashes and the nonces in the text being processed. Also denial of service attacks are possible since the recursive processing of XML Encryption. For example, EncryptedKey A requires EncryptedKey B to be decrypted, which itself requires EncryptedKey A. An attacker might also submit an EncryptedData element for decryption that references network resources that are very large or continually redirected. Consequently, XML Encryption implementations should be able to restrict arbitrary recursion and the total amount of processing and networking resources a request can consume.
XML Signature is a jointly produced specification produced by W3C and IETF. It specifies how to represent a digital signature as an XML element as well as how to create and verify this XML element. It applies to both XML and non-XML data similar to XML encryption. You can sign an entire XML document, any number of XML elements, or files containing any type of digital data items. XML Signature allows you to sign multiple data with a single signature. Although it was already possible to digitally sign an XML document, using the PKCS#7 Signature, you couldn’t use PKCS#7 to selectively sign parts of an XML document, or to represent the signature in a standardized XML format. With XML-Signature, you can place the signature using different “packaging” strategies such as enveloping signature, enveloped signature, and detached signature. An enveloping XML signature is one where the signed data is contained within the XML signature structure itself. An enveloped XML signature is one contained within the signed document itself. And a detached signature is separate from the signed entity. The signed entity is referenced via a URI and can be, in principle, any digital content. If the URI of a detached signature cannot be dereferenced, then the signature breaks. Therefore you could use a detached signature in order to guarantee the integrity of online resources.
An XML signature can be used alone to assure data integrity. When it is linked to the signer’s identity, it then provides for non-repudiation of data content, and possibly the authentication of the signer. The XML Signature standard does not address the way in which encryption keys are associated with individuals or institutions, nor with the meaning of the data being referenced and signed. So you cannot use it by itself to address all application security or trust concerns especially those relating to using signed XML as the basis of human-to-human communication and agreement.
Security Assertions Markup Language (SAML)
The Security Assertion Markup Language (SAML) which is an OASIS standard specification is a framework for the exchange of security-related information, expressed as assertions, between trusting parties. Security assertions are one basic building block of standards related to the security of SOAP messages, as well as of standards related for security policies, access control, and federated identity management.
In SAML, security information is expressed as assertions about subjects, where a subject is an entity (be it human or computer) having an identity in some security domain. For example, a subject is a person, identified by their email address from a particular Internet DNS domain. This is shown in the figure below:
These assertions can convey various pieces of information about the attributes of subjects, or about authentications previously performed by subjects, or even about authorization decisions concerning access certain resources. SAML supports three kinds of assertions:
- attribute - states that the subject S is associated with a set of attributes Ai with values Bi such as subject James is associated with attribute “University” with value “Syracuse”
- authentication - states that the subject S was authenticated by means M at a certain time. It is normally issued by the party that has successfully authenticated the subject. For example, a SAML authentication assertion could state that “James was originally authenticated using a password mechanism at 201203-13T09:33:27”.
- authorization decision assertions - states the actions that the subject S is entitled to execute on a resource R. For example, a user has been authorized to use a given service.
The listing below provides an example of a SAML assertion:
A single SAML assertion may contain assertion statements about authentication, authorization, and attributes of the subject. Assertions are issued by SAML authorities. There are many types of authorities around. There are authorities for authentication, attributes, or policy decision points. You can also use SAML to make assertions about credentials, but it does not provide mechanisms to check or revoke credentials. Therefore the party accepting a SAML assertion as true is trusting the issuing SAML authority. A service provider may need also to hold detailed information about the type and strength of authentication used by an identity provider when it authenticates the user. SAML uses the authentication context to carry this information. This information is conveyed in or referenced by an assertion’s authentication statement. SAML’s framework is designed to support a number of real-world business scenarios. These range from scenarios where the client is a browser to complex ones using multiple Web services. The scenarios supported by SAML are the following:
MajorVersion="1" MinorVersion="1" AssertionID="biuEZCGxcGiF4gIkL5PNltwU7duY1az"
- Web single sign-on (SSO) scenario where the user authenticates to one Web site and then is able to access resources at another site. SAML enables Web SSO through the communication of an authentication assertion from the first site to the second one. If the second site is confident of the origin of the assertion, it can decide to allow the user to log in as if he had authenticated directly.
- Attribute-based authorization scenario where one web site communicates identity information about a subject to another Web site in support of some transaction. This is similar to the Web SSO but the identity information required by the receiving Web site may refer to some characteristic of the subject such as the person’s role in a B2B scenario instead of or possibly in addition to information about when and how the subject was authenticated. This uses the attribute-based authorization model if the subject’s particular identity is either not important or should not be shared for reasons of privacy or is insufficient on its own.
- Securing SOAP messages scenario where SAML assertions are used within SOAP messages to transport security and identity information between actors in Web service transactions. The OASIS WS-Security TC’s SAML Token Profile specifies how SAML assertions should be used to implement this scenario. The Liberty Alliance’s Identity Web Service Framework (ID-WSF) also uses SAML assertions as the base security tokens for enabling secure and privacy respecting access to Web services.
SAML also provides a threat model that identifies the assumptions, the scope, and the security techniques that one should adopt for deploying SAML-based solutions. The threat model considers the concerns arising in communications when using the request response protocol, or when SAML is used by a receiving party. The SAML threat model assumes the following:
- Endpoints used in a SAML transaction are uncompromised, but the attacker has complete control over the communications channel.
- A valid participant in an SAML transaction can use the information maliciously in another transaction.
- SAML allows one to make authentication and authorization statements, but it doesn’t specify how authentications are executed or how authorizations are established. The consequence of this is the security of a system that is based on assertions as inputs also depends on the security of the system used to generate these assertions. There is a risk of security compromises taking place from consuming false but validly issued assertions when determining what issuers to trust. This is especially the case where the assertions are used as inputs to authentication or authorization decisions. The trust policies between asserting and relying parties should always be written to specify liability as well as ensuring that the implementation provides an audit trail.
- Once an assertion is issued, the issuer is no longer in control. As such, the issuer has neither control how long the assertion will persist in the consumer’s systems nor does the issuer have control over the parties with whom the consumer share the assertion information. Finally, there is also the issue of a malicious attacker who can see the unencrypted content of assertions in transit.
- SAML protocol is prone to Denial of Service (DOS) attacks. These attacks can be averted by requiring client authentication at a lower level, by requiring signed requests from a client, or by restricting the ability to issue SAML requests to a limited number of known parties.
SOAP Message Security
SOAP messages provide the unit of communication in Web services whose integrity and confidentiality must always be protected. SOAP messages can be expected to be subjected to the following types of attacks:
- Message is modified or read by an attacker.
- Attacker sends to a Web service well-formed messages lacking appropriate security claims to warrant processing.
- Attacker alters a message while preserving the structure and form. When this is sent to the Web service it causes the service to process the request and respond to the client for an incorrect request.
As SOAP messages can traverse multiple applications or intermediaries as well as multiple trust domains between business entities, there is a need to provide end to end protection over multiple hops in order to assure the SOAP message’s integrity and confidentiality while verifying the requester’s identity. One can achieve this by the use of XML encryption and XML signatures, but you will need to standardize the representation of the additional security information within SOAP messages in order that the SOAP processor, can properly manage the security information. This is shown in the figure below:
WS-Security is considered the de facto standard for securing SOAP messages in the Web. WS-Security specifies the necessary extensions to SOAP to allow for the selective encryption or signing of parts of SOAP messages. This includes encrypting different parts of a SOAP message for different recipients. This is done by leveraging the XML Signature standard to protect message integrity as well as the XML Encryption standard in order to protect the messages’ confidentiality. WS-Security applies to a single SOAP message. If you want to secure exchanges composed of multiple SOAP messages, the extensions were defined in the WS-SecureConversation standard that we will look at later.
When you look at a security token, you will discover that it is a collection of declarations or claims made by an entity concerning some its own properties that are relevant for security purposes. WS-Security specification supports multiple security token formats, multiple trust domains, multiple signature formats as well as multiple encryption technologies. The properties that a security token holds are the name, identity, a key, a privilege, and a capability. All of these security-related pieces of information are conveyed via X.509 certificates, Kerberos tickets and authenticators, SIM card’s mobile device security tokens, username, SAML assertions, etc.
A security token can be also signed or certified by a specific third-party authority different from the entity to whom the assertion refers. An example would be a X.509 certificate or a Kerberos ticket. A signed security token is used as a means to authenticate the claim made by the entity. The semantics and token formats used for a signed security token is defined in the associated profile documents. They take the form of SOAP header elements (i.e. wsse, ws security elements) carrying security-related data. These are extensions introduced by WS-Security. The figure below shows the extensions added:
There is a general purpose mechanism specified within WS-Security for referencing and including so-called security tokens within SOAP messages. WS-Security is indifferent to the type of security token used. There are numerous security token formats that have been specified for use in WS-Security such as username/password, SAML assertions, XrML/REL tokens, X.509 certificates as well as Kerberos tickets. Some of these security tokens are not encoded in XML such as X.509 certificates and Kerberos tickets. For these, WSSecurity provides a mechanism for encoding binary security tokens. WS-Security security has the flexibility to accommodate specific purposes and specific security architectures as well as being extensible to handle the profiles or new security tokens.
The integrity of messages within WS-Security is handled by using XML Signature in conjunction with security tokens. This may contain or imply key data. Again, WS-Security is flexible enough to support multiple signatures from potentially multiple parties and can also be extended to support additional signature formats. The signatures can reference a security token. WS-Security will assure the message confidentiality by encrypting the relevant portions of the SOAP message in accordance with XML Encryption standard in conjunction with security tokens. There is similar flexibility in the encryption mechanisms WS-Security is designed to support as it can use additional encryption technologies, processes, and operations by multiple parties. The encryption can also reference a security token.
Despite the flexibility and comprehensiveness of WS-Security, since it only defines a protocol, there is always the risk that the implementation of the protocol is vulnerable to a attack. As such, WS-Security specification provides a non-exhaustive list of security concerns, such as replay attacks, man-in-the middle attacks, token substitution attacks, etc.
Completing a meaningful transaction requires a client and a Web service often to exchange multiple SOAP messages. In this context, it is important to secure multiple SOAP messages. WSSecureConversation is an OASIS standard that allows the two communicating parties to establish and manage a session at the SOAP message level. It’s starting point is extensions to WS-Conversation, based on WS-Security and WS-Trust, where the objective is to provide secure communication across multiple messages via the authentication of multiple messages. These extensions use the establishment and sharing of a security context between the communicating parties and on the derivation of keys from the established security contexts. The security context between the communicating parties is shared for the lifetime of a communication session and is represented by a security context token that conveys a secret or a key. The secret could be used for signing and/or encrypting SOAP messages, but it is recommended in the specification to use of derived keys for signing and encrypting messages associated only with the security context.
SOAP messages within the same message exchange can reference the same security context token. This approach achieves a more efficient exchange of keys or new key information facilitating an increase in the overall performance and security of the subsequent exchanges. The security context needs to be created and shared by the communicating parties before it is used. For this, WS-SecureConversation defines the following three different strategies for establishing a security context between the parties of a secure communication:
- The context initiator requests an Security Token Service (STS) that is defined by WS-Trust, to create a security context token.
- A security context token is created by one of the communicating parties and then propagated within a particular message. In this scenario that parties would already need to have a trust relation in order to share a secret key.
- A security context token is created when required by negotiation between the participants. This scenario is necessary when the message exchange participants must negotiate and agree the contents of the security context token. In most cases this will be a shared secret.
In order to guaranteeing the integrity and confidentiality of the SOAP messages, vendors have agreed the WS-Reliability standard that defines a messaging protocol to manage the reliable delivery of messages between exactly two parties, a source and a destination. The name given for the parties for the reliable delivery of messages is the Reliable Messaging (RM) Source and RM Destination. The delivery guarantee is assured by middleware components implementing the “store & forward” paradigm. This could be Microsoft Message Queue or IBM Messaging and Queuing for example.
WS-Reliability makes no assumption about the implementation of the messaging processor service. So it could be an application, a queuing or logging system, a database, a SOAP node, or just the next handler in the message processing chain. Instead, WS-Reliability addresses the interoperability of heterogeneous reliable messaging middleware. It defines a “wire” protocol. This is the specific message headers and specific message choreographies between the sending application and the receiving application. It also defines the protocol to be used between the application and the reliable messaging middleware. The reliable messaging middleware implements a Quality of Service (QoS) contract between the application and the underlying messaging processor service. This is shown in the figure below:
The Quality of Service (QoS) contract consists of four operations (i.e. Submit, Deliver, Respond, and Notify) and has four basic delivery assurances:
- The AtMostOnce assurance guarantees that messages will be delivered at most once without duplication or an error will be raised at at least one endpoint. If there are messages in a sequence, it is possible that some messages may not be delivered.
- The AtLeastOnce assurance guarantees that every message sent will be delivered or an error will be raised at at least one endpoint. In this case, some messages may be delivered more than once.
- The ExactlyOnce assurance guarantees that every message sent will be delivered without duplication or an error will be raised at at least one endpoint.
- The InOrder assurance guarantees that messages will be delivered in the order in which they were sent. This delivery assurance can be combined with any of the above delivery assurances. There is no assurance given in respect to message duplications or omissions.
Key and Trust Management Standards
Public keys are one of the basic building block for signatures and digital certificates. Public key management is comprised of the creation, safe storage, distribution, use and cancellation of public keys. They can either be created by a software package running on the platform of the customer application and then registered to a Public Key Infrastructure (PKI) Certification Authority (CA) or the customer application can request a CA participating to a PKI infrastructure to issue them.
When a party uses a public key, the party needs to ascertain its validity by verifying that the public key has not expired or has been revoked. One can have public keys that have been issued by different CAs as well as having a given party having more than one public key associated with it. The current PKIs use proprietary toolkits to make the interactions between the client applications and the PKI costly and difficult. Often this forces the client applications to implement signature validation, chain validation and revocation checking by themselves. These operations are very expensive so there is the need to simplify the task of the relying parties when using public keys. It should also be possible to allow different CAs’, or even different PKIs, to interoperate among them. Note that public keys can be represented in XML, and serve as the basis of XML Encryption and XML Signature.
WS-Security defines the basic mechanisms for secure messaging. Any SOAP message protected by WS-Security has three possible issues with regard to security tokens:
- security token format incompatibility
- namespace differences
- the trustworthiness of the security token.
To address these issues, there was the need to define standard extensions to WS-Security in order to provide methods for issuing, renewing, and validating security tokens. As well there was a need to establish and assess the presence of, and broker, trust relationships. These requirements led to the development of the WS-Trust standard.
The WS-Trust Specification is an OASIS standard. It defines extensions to WS-Security providing a framework for requesting and issuing security tokens as well as assessing the presence of trust relationships and brokering trust relationships. In WS-Trust, trust relationships are conveyed via security tokens. In WS-Trust, security tokens are issued by a so-called Security Token Service (STS). The STS issues assertions are based on evidence that it trusts and is directed towards those who trusts the STS. It can be implemented by a Kerberos Key Distribution Center (KDC) or by a public key infrastructure which means that the issuing authority is the STS.
WS-Trust assumes a Web service security model in which:
- A Web service can require that an incoming message proves a set of claims such as name, key, permission, and capability.
- A Web service can indicate its required claims and related information in its policy according to the WS-Policy and WS-PolicyAttachment specifications.
A Web service is equipped with a trust engine that:
- verifies the claims in the token are sufficient to comply with the policy and ensures that the message conforms to the policy.
- verifies the attributes of the claimant are proved by the signatures. In brokered trust models, the signature may not verify the identity of the claimant but only verify the identity of the intermediary who is simply asserting the identity of the claimant.
- verifies the issuers of the security tokens, including all related and issuing security tokens, are trusted to issue the claims they have made. In this case, the trust engine may need to externally verify or send tokens to a STS in order to exchange them for other security tokens that it can use directly in its evaluation.
An STS service provides a series of functions to clients. It handles client’s request for a new security token, or a set of security tokens. The client can optionally specify the type of the requested security token, the desired valid time range of the security token, as well as the scope the security token for which it is required. This could be for the services to which it applies. The STS also handles client requests to renew an already issued security token and to cancel a previously issued security token when it is no longer needed. A STS can also cancel a security token on its own initiative. Finally, an STS handles client’s request to validate a security token. The validation can result in a status, a new token, or both.
Web Services Policy Framework (WS-Policy)
The Web Services Policy Framework (WS-Policy) standard provides an extensible model allowing Web services to describe their policies in a consistent manner. The WS-Policy standard provides a general model, suitable for expressing all types of domain-specific policy models, from transport-level security, to resource usage policy, QoS characteristics, and end-to-end business-process-level policy. The model is based on the concept of policy assertion specifying a behavior (i.e. a requirement or a capability, of a policy subject). The semantics of the assertions is domain specific such as security or transactions. As such WS-Policy has adopted a policy defining domain-specific assertions in separate specifications. They can be public specifications such as WS-SecurityPolicy and WS-PolicyAssertion or they can be by a private entity that owns a particular Web service. The policy assertions based on public specifications are called standard assertions and can be understood by any client. An example of standard domain-specific assertion is confidentiality and integrity requirements for SOAP messages that are defined as protection assertions in the WSSecurityPolicy standard specification. The figure below shows a configuration for typical public facing Web service:
A WS-SecurityPolicy integrity assertion specifies the parts of a SOAP message that must be signed. Note that this assertion can be satisfied by using SOAP Message Security mechanisms such as WS-Security, or by using other mechanisms such as HTTPS. The subject to which the policy applies to is a Message Policy subject (i.e. a SOAP message). The WS-PolicyAttachment standard specifies to which WSDL entity or UDDI entity the policy applies. Policy assertions can be combined in policy alternatives into collection of policy alternatives. This collection would be considered one policy.
WS-Policy adopts a normal form schema that basically expresses a policy as an (exclusive) ORed set of ANDed sets of statements. This is shown in the listing below:
The listing shows the normal form schema of a policy according to WS-Policy. The * indicates zero or more occurrences of an item, while [ ] indicates that the contained items must be treated as a group. An example of a policy adhering to the WS-Policy specification is shown below:
<wsp:Policy ... >
[<wsp:All> [<Assertion ...> ... </Assertion> ]* </wsp:All> ]*
The listing above shows two policy alternatives, each composed by a single policy assertion. One would interpret the policy in the following manner:
<wsp:Policy xml:base=http://acme.com wsu:Id=AcmePolicy>
if the first alternative is selected, only the Kerberos token type is supported; otherwise if the second alternative is selected, only the X.509 token type is supported.
Implementations of Web Services Security Standards
On the Java platform, the Java Web Service Development Platform (WSDP) defined the XWS-Security framework providing security functionalities for JAX-WS applications. This framework supports the following security options:
- XML Digital Signature: An implementation using Apache’s XML-DSig based on the XML Signature specification.
- XML Encryption: The Apache’s XML-Enc implementation based on the XML Encryption specification.
- Username Token Profile and X.509 Certificate Token Profile support, based on the OASIS WSS Username Token Profile 1.0 and the OASIS WSS X.509 Certificate Token Profile 1.0, respectively.
To determine exactly the security stack is on your preferred Java EE 5 application server, you will need to check with your vendor. Note that if you are looking for an open source vendor providing full support for OASIS Web service Security standard, you can look at Project Glassfish.
Above and beyond your success in completing the Web service developer exam, Web service security standards raise a number of interrelated technical and management issues. The technical issues concern specific security threats posed by the Web service security standards themselves, them implementations, addressing security concerns during the Web service life cycle, the degree of interoperability achievable by their adoption and finally the performance overhead incurred when deploying software solutions implementing the standards. The management issues include the tradeoff between the organization interoperability requirements and the organization security requirement, the costs incurred of deploying and using standard compliant features provided on the development and deployment platform, the training required to provide developers and operational management personnel the skills required to properly learn and use standardized security functions in an effective way. How you handle these issues within your organization will determine how secure your web services are to attack.