Introduction: Web services
Explore the key concepts pertaining to Web services applications. Web services are self-contained, modular applications that can be described, published, located, and invoked over a network. They implement a services oriented architecture (SOA), which supports the connecting or sharing of resources and data in a very flexible and standardized manner. Services are described and organized to support their dynamic, automated discovery and reuse.
- Web services
- Web services are self-contained, modular applications that we can describe, publish, locate, and invoke over a network.
- Web Services for J2EE specification
- The Web services for J2EE specification defines the programming model and run-time architecture for implementing Web services based on the Java language. Another name for the Web Services for J2EE specification is the Java Specification Requirements (JSR) 109. The specification includes open standards for developing and implementing Web services.
- JAX-RPC
- The Java API for XML-based RPC (JAX-RPC) specification enables you to develop SOAP-based interoperable and portable Web services and Web service clients. JAX-RPC provides core APIs for developing and deploying Web services on a Java platform and is a required part of the J2EE platform. The J2EE platform allows you to develop portable Web services. Web services can also be developed and deployed on J2EE 1.3 containers.
- SOAP
- SOAP is a specification for the exchange of structured information in a decentralized, distributed environment. As such, it represents the main way of communication between the three key actors in a SOA: service provider, service requestor and service broker. The main goal of its design is to be simple and extensible. A SOAP message is used to request a Web service.
- SOAP with Attachments API for Java interface
- SOAP with Attachments API for Java (SAAJ) is used for SOAP messaging that works behind the scenes in the JAX-RPC implementation. We can map XML to Java types with standards supported by the JAX-RPC specification, but there are limited XML schema types, therefore use the SOAPElement interface to create a custom data binder.
- Web Services-Interoperability Basic Profile
- The Web Services-Interoperability (WS-I) Basic Profile is a set of non-proprietary Web services specifications that promote interoperability.
- RMI-IIOP using JAX-RPC
- JAX-RPC is the Java standard API for invoking Web services through remote procedure calls. A transport is used by a programming language to communicate over the Internet. Use protocols with the transport such as SOAP and RMI. Use Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) with JAX-RPC to support non-SOAP bindings.
- WS-I Attachments Profile
- The WS-I Attachments Profile is a set of non-proprietary Web services specifications that promote interoperability. This profile compliments the WS-I Basic Profile to add support for interoperable SOAP messages with attachments-based Web services.
- Service-oriented architecture
- A SOA is a collection of services that communicate with each other, for example, passing data from one service to another or coordinating an activity between one or more services.
- Web services approach to a service-oriented architecture
- The Web services approach implements a SOA. A major focus of Web services is to make functional building blocks accessible over standard Internet protocols that are independent from platforms and programming languages. These services can be new applications or just wrapped around existing legacy systems to make them network-enabled. A service can rely on another service to achieve its goals.
- Web services business models supported
- The properties and benefits of using a SOA, such as Web services is well-suited for binding small modules that perform independent tasks within a highly heterogeneous e-business model. Web services can be easily wrapped around existing applications in your business model and plugged into different business processes.
- Custom data binders
- A custom data binder is used to map XML schema types with Java objects. Custom data binders provide bindings for XML schema types that are not supported by the current JAX-RPC specification.
- Custom binding providers
- A custom binding provider is the packaging of custom data binder classes with a declarative metadata file. The main purpose of a custom binding provider is to aggregate related custom data binders to support particular user scenarios. The custom binding provider is used to plug the custom data binders into the emitter tools and the run time system so that the emitter tools can generate the appropriate artifacts and the run time system can augment its existing type mapping system to reflect the applied custom data binders and invoke them.
- Securing Web services applications at the transport level
- Transport level security is based on SSL or Transport Layer Security (TLS) that runs beneath HTTP. Transport level security can be used to secure Web services messages. However, transport-level security functionality is independent from functionality provided by WS-Security or HTTP Basic Authentication.
- Authenticating Web services clients using HTTP basic authentication
- HTTP basic authentication uses a user name and password to authenticate a service client to a secure endpoint. WAS can have several resources, including Web services, protected by a J2EE security model.
- WSDL
- Web Services Description Language (WSDL) is an Extensible Markup Language (XML)-based description language. This language was submitted to the World-Wide Web Consortium (W3C) as the industry standard for describing Web services. The power of WSDL is derived from two main architectural principles: the ability to describe a set of business operations and the ability to separate the description into two basic units. These units are a description of the operations and the details of how the operation and the information associated with it are packaged.
- What is new for securing Web services
- In WAS V6 and later, there are many security enhancements for Web services. The enhancements include supporting sections of the Web services security specifications and providing architectural support for plugging in and extending the capabilities of security tokens.
- Web services security enhancements
- WebSphere Application Server V6 and later include a number of enhancements for securing Web services.
- High-level architecture for Web services security
- WebSphere Application Server V6 and later use the J2EE Web services deployment model to implement Web services security. The Web services security constraints are specified in the IBM extension of the Web services deployments descriptors and bindings. The Web services security run time enforces the security constraints specified in the deployment descriptors. One of the advantages of deployment model is that we can define the Web services security requirements outside of the application business logic. With the separation of roles, the application developer can focus on the business logic and the security expert can specify the security requirement.
- Overview of platform configuration and default bindings
- The Web services security constraints are defined in an IBM extension of the Web services deployment descriptor for J2EE. The IBM extension deployment descriptor and binding for Web services security are IBM proprietary. Due to the complexity of these files, it is not recommended that you edit the deployment descriptor and binding files manually with a text editor because they might cause errors. It is recommended, however, that you use the tools provided by IBM to configure the Web services security constraints for an application. These tools are the Rational Application Developer, Rational Web Developer, the Application Server Toolkit, and the WAS administrative console.
- Security model mixture
- There can be multiple protocols and channels in the WebSphere Application Server V6 and later programming environments. For example, you might access a Web-based application through the HTTP transport. For example, a servlet, JavaServer pages (JSP) file, HTML and so on. You might access an enterprise application through the Remote Method Invocation over the Internet Inter-ORB (RMI/IIOP) protocol and a Web service application through the Simple Object Access Protocol (SOAP) over HTTP, SOAP over the Java Message Service (JMS) or SOAP over RMI/IIOP protocol. Each of these applications serve different business needs. More importantly, Web services are often implemented as servlets with a JavaBean or EJB file. Therefore, we can mix and match the Web services security model with the J2EE security model for Web and EJB components. It is intended that Web service security compliment the J2EE role-based security and the security run time for WAS V6 and later.
- Default implementations of the Web services security service provider programming interfaces
- The following information describes the default implementations of the service provider interfaces (SPI) for Web services security within WAS V6 and later. The default implementations of the service provider interfaces for WAS V5.x are not described in this document. Instead, see Securing Web services for Version 5.x applications based on WS-Security for the V5.x implementations that are deprecated in v6.x and later.
- Default configuration
- WebSphere Application Server V6 and later provide a variety of sample configurations that we can configure through the administrative console. The configurations that you specify are reflected on the cell or server level. Do not use these configurations in a production environment as they are for sample and testing purposes only. To make modifications to these sample configurations, it is recommended that you use the administrative console provided by WebSphere Application Server.
- Nonce, a randomly generated token
- Nonce is a randomly generated, cryptographic token used to prevent replay attacks. Although Nonce can be inserted anywhere in the SOAP message, it is typically inserted in the UsernameToken element.
- XML digital signature
- XML-Signature Syntax and Processing (XML digital signature) is a specification that defines XML syntax and processing rules to sign and verify digital signatures for digital content. The specification was developed jointly by the W3C and the Internet Engineering Task Force (IETF).
- Collection certificate store
- A collection certificate store is a collection of non-root, certificate authority (CA) certificates and certificate revocation lists (CRLs). This collection of CA certificates and CRLs is used to check the signature of a digitally signed SOAP message.
- Trust anchor
- A trust anchor specifies the key stores that contain trusted root certificates. These certificates are used to validate the X.509 certificate that is embedded in the SOAP message.
- Key locator
- A key locator, or the com.ibm.wsspi.wssecurity.keyinfo.KeyLocator class, is an abstraction of the mechanism that retrieves the key for digital signature and encryption.
- Trusted ID evaluator
- A trusted ID evaluator (com.ibm.wsspi.wssecurity.id.TrustedIDEvaluatorImpl) is an abstraction of the mechanism that evaluates whether the given ID name is trusted.
- XML encryption
- XML encryption is a specification developed by the W3C in 2002 that contains the steps to encrypt data, the steps to decrypt encrypted data, the XML syntax to represent encrypted data, the information used to decrypt the data, and a list of encryption algorithms such as triple DES, AES, and RSA.
- Security token
- A security token represents a set of claims made by a client that might include a name, password, identity, key, certificate, group, privilege, and so on.
- Username token
- Use the UsernameToken element to propagate a user name and, optionally, password information. Also, use this token type to carry basic authentication information. Both a user name and a password are used to authenticate the message. A UsernameToken containing the user name is used in identity assertion, which establishes the identity of the user based on the trust relationship.
- Binary security token
- The ValueType attribute identifies the type of the security token, for example, a Lightweight Third Party Authentication (LTPA) token. The EncodingType type indicates how the security token is encoded, for example, Base64Binary. The BinarySecurityToken element defines a security token that is binary encoded. The encoding is specified using the EncodingType attribute. The value type and space are specified using the ValueType attribute. The Web services security implementation for WebSphere Application Server, V6 and later supports both LTPA and X.509 certificate binary security tokens.
- Web services security specification—a chronology
- This document describes the process used to develop the Web services security specifications.
- Web services security and Java 2 Platform, Enterprise Edition security relationship
- This document describes the relationship between Web services security (message level security) and J2EE platform security. It also includes information on J2EE role-based authorization checks.
- Goals of WSIF
- WSIF aims to extend the flexibility provided by SOAP services into a general model for invoking Web services, irrespective of the underlying binding or access protocols.
- WSIF Overview
- The Web Services Invocation Framework (WSIF) provides a Java API for invoking Web services, independent of the format of the service or the transport protocol through which it is invoked. This framework addresses all of the issues identified in "The goals of WSIF."
- Overview of the V3 UDDI registry
- The Universal Description, Discovery and Integration (UDDI) specification defines a way to publish and discover information about Web services. The term 'Web service' describes specific business functionality exposed by a company, usually through an Internet connection, to allow another company, or its subsidiaries, or software program to use the service. We can find the UDDI specification on the OASIS UDDI Web page.
- Database considerations for production use of the UDDI registry
- The UDDI registry fully supports a number of databases (see An overview of the V3 UDDI registry for details) and can be used for development and test purposes, however you should be aware of the following factors when considering which database is appropriate for your anticipated UDDI registry production use.
- Access control for UDDI registry interfaces
- Access to UDDI registry interfaces is controlled by a combination of J2EE declarative security using role mappings, and UDDI properties and policies such as the registering of users as UDDI publishers.
- UDDI registry security additional considerations
- In addition to the configuration of UDDI registry security, there a number of other UDDI registry settings which may affect the behavior of the UDDI registry. Some of these settings are security specific, others are points to bear in mind when configuring security.
- UDDI registry Administrative (JMX) Interface
- The UDDI registry Administrative Interface allows you to inspect and manage the runtime configuration of a UDDI application. This includes managing the information and the activation state about a UDDI node, updating properties and policies, setting publish tier limits, registration of UDDI publishers, and controlling value set support. The operations of the UDDI registry Administrative Interface can be read and invoked using standard JMX (Java Management Extensions) interfaces.
- Java API for XML Registries (JAXR) provider for UDDI
- The Java API for XML Registries (JAXR) is a Java client API for accessing both UDDI (V2 only) and ebXML registries. It is part of the J2EE 1.4 specification.
Related concepts
Web services