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.
The following list includes the core Web services concepts:
- Web services
- Web services are self-contained, modular applications that you can describe,
publish, locate, and invoke over a network.
- Web Services for J2EE specification
- The Web services for Java 2 Platform, Enterprise Edition (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 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. You can map XML to
Java types with standards supported by the JAX-RPC specification, but there
are limited XML schema types, therefore you can 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. You can use protocols with the transport such as SOAP and
Remote Method Invocation (RMI). You can 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 that is 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. WebSphere Application Server 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 WebSphere Application Server Version 6 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 Version 6 and later include a number of enhancements
for securing Web services.
- High-level architecture for Web services security
- WebSphere Application Server Version 6 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 you 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 Web Developer,
the Application Server Toolkit, and the WebSphere Application Server administrative
console.
- Security model mixture
- There can be multiple protocols and channels in the WebSphere Application
Server Version 6 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, you 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 WebSphere Application Server Version 6 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 WebSphere
Application Server Version 6 and later. The default implementations of the
service provider interfaces for WebSphere Application Server Version 5.x are
not described in this document. Instead, see Securing Web services for Version
5.x applications based on WS-Security for the Version 5.x implementations
that are deprecated in Version 6.0.x and later.
- Default configuration
- WebSphere Application Server Version 6 and later provide a variety of
sample configurations that you 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
- You can use the UsernameToken element to propagate a user name and, optionally,
password information. Also, you can 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, Version 6 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 Version 3 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. You 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 Version 3 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 (Version 2 only) and ebXML registries. It is part of the J2EE specification.
For a complete list of the specifications and standards that are supported
by WebSphere Application Server, see the topic "Specifications and API documentation."