This section takes a look at the Web service architecture, standards and what technolo-gies exists to enable security.
4.4.1 Web service architecture
Web services introduced a new paradigm for enabling exchange of information across the Internet. The adoption of open industry standards and standards-based technologies using service-oriented architecture means that a client invoking a service does not need to be aware of what system environment the service is running under. This ensures interoperability among Web services providers and requesters [18].
Web services can be described using a simple operational model. The model can be seen in Figure 4.4 on page 53.
The model uses three distinct roles and relationships that define Web service providers and users [18]:
– Service provider: Hosts the Web services and is primarily responsible for de-veloping and deploying the Web services. The service provider also defines the services and publishes them with the service registry.
– Service registry: Hosts the lookup information and descriptions of published services and is primarily responsible for service registration and discovery of the Web services. The service requester uses the service registry to find and subscribe to the required services.
– Service requester: Acts as the Web service client, who is responsible for the service invocation. The requester locates the Web service using the service registry and invokes the service from the service provider.
Figure 4.4: Web services operational model
A typical Web service architecture-based solution relies on these de facto Web ser-vices standards [18]:
– XML (Extensible Markup Language): The XML standard is endorsed by the W3C3. It forms the basis for all Web-services standards and has been widely accepted as the de facto universal language for exchanging information between applications over the Internet. In the Web services architectural model, XML plays a vital role as the common wire format in all forms of communication for expressing complex data structures.
– SOAP (Simple Object Access Protocol): SOAP is a standard for a lightweight XML-based messaging protocol. It enables the exchange of information between two or more peers. SOAP enables the peers to communicate with each other in a decentralized, distributed application environment. It provides transport bindings on top of various Internet protocols such as HTTP, SMTP, and FTP. SOAP is endorsed by the W3C and key industry vendors such as Sun Microsystems, IBM, HP, SAP, and Microsoft.
– WSDL (Web Service Definition Language): The WSDL standard is an XML representation for describing the services as a collection of operations and its access information. It describes how service providers and requesters communicate with each other. Usually the service provider creates Web services by generating a WSDL file from its exposed business applications. Then the public WSDL address for lookup is published in a Web service registry, such as UDDI so that potential service requesters of the Web service can determine the location of the Web service.
WSDL is endorsed by W3C as a standard. The format of an WSDL document will be described in chapter 6.
– UDDI (Universal Description, Discovery, and Integration): UDDI defines standard interfaces and mechanism for use by the electronic registries (the service
3World Wide Web Consortium
registry) that store and publish descriptions of XML-based Web services. Querying a UDDI registry for a service returns the location of the WSDL description. The requester can then construct a SOAP client interface that can communicate with the service provider. UDDI is endorsed by OASIS4as a standard.
4.4.2 Core security issues
Because Web services open up for making business transactions over the Internet, secu-rity has become the most important focus. The Web services need to be secure, reliable and available to the service consumers [18].
Web services are susceptible to all the threats discussed in the Critical application security flaws and exploits-section in chapter 4, but since Web services extensively use XML some of the threats have been somewhat specialized. Below is a list of those threats [18]:
– XML Denial of Service: This is an attack on content-level vulnerabilities. An attacker makes use of malicious XML messages, manipulates parts of an XML document, or sends an oversized XML payload that can cause load-intensive op-erations at the target Web service endpoint. This causes systems to crash or to consume an excessive amount of system resources, both of which result in the inability to respond to further requests or perform operations. This is a hard prob-lem to counter since traditional firewalls are quite ineffective for inspecting XML traffic because they do not provide support for detecting content-level threats.
– XML Schema Tampering: XML Schemas help to verify that an XML message is well-formed and valid. Since XML Schemas are publicly accessible they are liable to attacks. Using a potential loophole, the attacker alters the schema with erroneous and inconsistent information. This makes the Web service endpoint waste resources on failures related to message validation and verification.
– WSDL and UDDI Attacks: Since both WSDL and UDDI provide service-related information in a self-describing XML document that reveals the service location and its exposed operations they are susceptible to attacks. The attacker performs a number of operations with arbitrary input and output parameters using malformed data. The attacker may also inflict changes by tampering with the WSDL descriptions that affect the creation of client side artifacts.
From an end-to-end Web service perspective, the complexity of the security threats and risks adds more difficulty to the security tasks (authentication, authorization, etc).
In real-world Web services, it becomes very important to address these security issues so that they do not interfere with the benefits and successes of Web services adoption in business organizations [18].
4.4.3 Web service security standards
Since Web service 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 system, application infrastructure, and programming language [18].
4Organization for the Advancement of Structured Information Standards
Many companies rely on SSL for protection because SSL provides authentication, confidentiality and message integrity. However, this only protects the data while it is in transit which makes the environment vulnerable to attacks in multi-step transactions.
This results in a need to be able to more specifically address the security challenges. To solve this problem there are several application-level industry standards [4]. These are discussed in the subsequent sections.
Content security
– XML-Signature: Allows signing of any sort of digital content or data objects.
The content that should be signed is digested using a message digest algorithm (such as DSA-SHA1 or RSA-SHA1), and the resulting hash value is placed in an XML element. The XML element is digested and cryptographically signed. The signed form of the XML element represents the XML signature [18].
– XML-Encryption: Allows encryption of any sort of digital content or data objects such as XML, binary data, and images. It builds on existing industry-standard encryption and facilitates a industry-standard XML-based representation and processing model for encryption and decryption [18].
Message-level security
– WS-Security: Uses XML-Encryption for confidentiality and XML-Signature for data integrity. It also includes profiles that specify how to insert different types of binary and XML security tokens in WS-Security headers for authentication and authorization purposes. The tokens can be; Username/password (digest), X.509 certificate, a Kerberos ticket, a SAML assertion (explained in the Trust management section), a REL5document or a XCBF6 document [4].
Secure message delivery
– WS-Addressing: XML framework for identifying Web services endpoints and for securing end-to-end endpoint identification in messages [4].
– WS-ReliableMessaging: Framework for identifying and managing the reliable delivery of messages relying on WS-Security, WS-policy and WS-Adressing. It mandates prerequisites, for example trust between endpoints must be established and the message and endpoints must be formally identified [4].
– WS-ReliableMessaging Policy Assertion: Defines a policy assertion so that a Reliable Messaging destination and source can describe their requirements for a given sequence [4].
Metadata
– WS-Policy: Framework that enables one to specify policy information that can be processed by Web services. A policy is expressed as one or more policy as-sertions representing a Web service’s capabilities or requirements. WS-Policy expressions are associated with various Web service components using the WS-PolicyAttachment specification [4].
5Rights Expression Language
6XML Common Biometric Format
– WS-SecurityPolicy: Defines a set of security policy assertions used in the con-text of the WS-Policy framework. WS-SecurityPolicy assertions describe how mes-sages are secured on a communication path [4].
Trust management
– SAML (Security Assertion Markup Language): Framework for sharing se-curity information on the Internet through XML documents. SAML provides a standard security token (a SAML assertion) that can be used with the WS-Security framework [4].
– WS-Trust: Enables security token interoperability using a security token service that allows a party to request a security token from a trusted authority [4].
– WS-SecureConversation: Defines the creation and sharing of security contexts between communicating parties. Security contexts mitigate the overhead involved in multiple-message exchanges. WS-SecureConversation defines a Security Con-text Token (SCT) element, involving a shared secret used to sign and/or encrypt messages, to support the requirements of security contexts [4].
– WS-Federation: Provides support for the secure propagation (across Internet domains) of identity, attribute, authentication, and authorization information. By relying on the models defined in WS-Security and WS-Trust, WS- Federation enables brokering of trust and security token exchange, support for privacy by hiding identity and attribute information, and federated sign-out. It leverages WS-Policy and WS-MetadataExchange to describe and acquire metadata [4].
Public key infrastructure
– PKCS (Public Key Cryptographic Standards): A set containing 12 specifi-cations developed and maintained by RSA Security [4].
– PKIX (Public Key Infrastructure - X.509): An Internet Engineering Task Force (IETF) working group with the goal to develop Internet standards to fa-cilitate the use of X.509-based PKI environments. These standards cover areas involving X.509 certificates, Certificate Revocation List (CRL), Lightweight Di-rectory Access Protocol (LDAP), Certificate Management Protocol (CMP), and Time-Stamp Protocol (TSP) to mention a few [4].
– XKMS (XML Key Management Specification): Defines a XML based pro-tocol for distributing and registering PKI-based cryptographic keys for use in Web Services. This enables offloading of PKI functionality from the applications to remote trust service providers such as VeriSign. XKMS works in conjunction with XML-Encryption and XML-Signature [18, 4].
Accomplishment
This chapter contains a description of the system that has been developed.
5.1 Planning
In the planning phase a timetable was created containing the different tasks and during what week the different tasks should be performed. By having a plan that can be followed, the risk of failure will decrease since every task can be reviewed against the plan and updated accordingly.
We chose an iterative approach in the development of the project by creating mock-ups and use cases and refining them when the requirements changed and became clearer.