Developing Web Services Applications
For Use with Red Hat JBoss Enterprise Application Platform 7.1
Abstract
Chapter 1. Introduction to Web Services Copy linkLink copied to clipboard!
Web services provide a standard means of interoperating among different software applications. Each application can run on a variety of platforms and frameworks.
Web services facilitate internal, heterogeneous subsystem communication. The interoperability increases service reuse because functions do not need to be rewritten for various environments.
Chapter 2. Developing JAX-RS Web Services Copy linkLink copied to clipboard!
JAX-RS is the Java API for RESTful web services. It provides support for building web services using REST, through the use of annotations. These annotations simplify the process of mapping Java objects to web resources.
RESTEasy is the Red Hat JBoss Enterprise Application Platform 7 implementation of JAX-RS and is fully compliant with the JSR-000339 Java API for RESTful Web Services 2.0 specification. It also provides additional features to the specification.
To get started with JAX-RS, see the helloworld-rs, jaxrs-client, and kitchensink quickstarts that ship with Red Hat JBoss Enterprise Application Platform 7.
JBoss EAP does not support the resteasy-crypto, resteasy-yaml-provider, and jose-jwt modules.
2.1. JAX-RS Application Copy linkLink copied to clipboard!
When creating providers and web resources, you have the following options for declaring them:
-
Simple subclassing of
javax.ws.rs.core.Applicationwithout aweb.xmlfile. -
Using a
web.xmlfile. -
Subclassing
javax.ws.rs.core.Applicationand providing a custom implementation.
2.1.1. Simple Subclassing javax.ws.rs.core.Application Copy linkLink copied to clipboard!
You can use the javax.ws.rs.core.Application class to create a subclass that declares those providers and web resources. This class is provided by the RESTEasy libraries included with JBoss EAP.
To configure a resource or provider using javax.ws.rs.core.Application, simply create a class that extends it and add an @ApplicationPath annotation.
Example: Application Class
2.1.2. Using web.xml Copy linkLink copied to clipboard!
Alternatively, if you do not want to create a class that extends javax.ws.rs.core.Application, you can add the following to your web.xml file.
Example: web.xml
2.1.3. Subclassing javax.ws.rs.core.Application with a Custom Implementation Copy linkLink copied to clipboard!
When subclassing javax.ws.rs.core.Application you can choose to provide a custom implementation for any of the existing methods. The getClasses and getSingletons methods return a collection of classes or singletons that must be included in the published JAX-RS application.
-
If either
getClassesandgetSingletonsreturns a non-empty collection, only those classes and singletons are published in the JAX-RS application. -
If both
getClassesandgetSingletonsreturn an empty collection, then all root resource classes and providers that are packaged in the web application are included in the JAX-RS application. RESTEasy will then automatically discover those resources.
2.2. JAX-RS Client Copy linkLink copied to clipboard!
2.2.1. JAX-RS 2.0 Client API Copy linkLink copied to clipboard!
JAX-RS 2.0 introduces a new client API to send HTTP requests to remote RESTful web services. It is a fluent request-building API with 3 main classes:
-
Client -
WebTarget -
Response
The Client interface is a builder of WebTarget instances. The WebTarget represents a distinct URL or URL template to build subresource WebTargets or invoke requests on.
There are two ways to create a client: the standard way, or using the ResteasyClientBuilder class. The advantage of using the ResteasyClientBuilder class is that it provides a few more helper methods to configure your client.
Using the Standard Way to Create a Client
The following example shows one of the standard ways to create a client:
Client client = ClientBuilder.newClient();
Client client = ClientBuilder.newClient();
Alternatively, you can use another standard way to create a client as shown in the example below:
Client client = ClientBuilder.newBuilder().build();
WebTarget target = client.target("http://foo.com/resource");
Response response = target.request().get();
String value = response.readEntity(String.class);
response.close(); // You should close connections!
Client client = ClientBuilder.newBuilder().build();
WebTarget target = client.target("http://foo.com/resource");
Response response = target.request().get();
String value = response.readEntity(String.class);
response.close(); // You should close connections!
Using the ResteasyClientBuilder Class to Create a Client
ResteasyClient client = new ResteasyClientBuilder().build();
ResteasyWebTarget target = client.target("http://foo.com/resource");
ResteasyClient client = new ResteasyClientBuilder().build();
ResteasyWebTarget target = client.target("http://foo.com/resource");
RESTEasy automatically loads a set of default providers that includes all classes listed in the META-INF/services/javax.ws.rs.ext.Providers file. Additionally, you can manually register other providers, filters, and interceptors through the configuration object provided by the method call Client.configuration(). Configuration also lets you set configuration properties that might be needed.
Each WebTarget has a configuration instance that inherits the components and properties registered with the parent instance. This lets you set specific configuration options for each target resource, for example, the username and password.
Using RESTEasy Client Classes
You must add the following dependency for users of the Maven project:
<dependency> <groupId>org.jboss.resteasy</groupId> <artifactId>resteasy-client</artifactId> <version>VERSION_IN_EAP</version> </dependency>
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-client</artifactId>
<version>VERSION_IN_EAP</version>
</dependency>
See the jaxrs-client and resteasy-jaxrs-client quickstarts that ship with JBoss EAP for working examples that use the RESTEasy client classes.
Client-side Filters
The client side has two types of filters:
ClientRequestFilter-
A
ClientRequestFilterruns before an HTTP request is sent over the wire to the server. TheClientRequestFilteris also allowed to abort the request execution and provide a canned response without going over the wire to the server. ClientResponseFilter-
A
ClientResponseFilterruns after a response is received from the server, but before the response body is unmarshalled. TheClientResponseFiltercan modify the response object before it is handed to the application code. For example:
Register Client-side Filters to the Client Request
The following example shows how to register the client-side filters to the client request:
client = ClientBuilder.newClient();
WebTarget base = client.target(generateURL("/") + "get");
base.register(ClientExceptionsCustomClientResponseFilter.class).request("text/plain").get();
client = ClientBuilder.newClient();
WebTarget base = client.target(generateURL("/") + "get");
base.register(ClientExceptionsCustomClientResponseFilter.class).request("text/plain").get();
Client-side Cache
RESTEasy has the ability to set up a client-side cache. This cache looks for cache-control headers sent back with a server response. If the cache-control headers specify that the client is allowed to cache the response, RESTEasy caches it within the local memory.
ResteasyWebTarget target = client.target(generateBaseUrl()); target.register(BrowserCacheFeature.class);
ResteasyWebTarget target = client.target(generateBaseUrl());
target.register(BrowserCacheFeature.class);
Chunked Encoding Support
RESTEasy provides the client API the ability to specify that requests should be sent in a chunked transfer mode. There are two ways of specifying the chunked transfer mode, as shown below.
You can configure the
org.jboss.resteasy.client.jaxrs.ResteasyWebTargetto send all the requests in chunked mode:ResteasyClient client = new ResteasyClientBuilder().build(); ResteasyWebTarget target = client.target("http://localhost:8081/test"); target.setChunked(b.booleanValue()); Invocation.Builder request = target.request();ResteasyClient client = new ResteasyClientBuilder().build(); ResteasyWebTarget target = client.target("http://localhost:8081/test"); target.setChunked(b.booleanValue()); Invocation.Builder request = target.request();Copy to Clipboard Copied! Toggle word wrap Toggle overflow Alternatively, you can configure a particular request to be sent in chunked mode:
ResteasyClient client = new ResteasyClientBuilder().build(); ResteasyWebTarget target = client.target("http://localhost:8081/test"); ClientInvocationBuilder request = (ClientInvocationBuilder) target.request(); request.setChunked(b);ResteasyClient client = new ResteasyClientBuilder().build(); ResteasyWebTarget target = client.target("http://localhost:8081/test"); ClientInvocationBuilder request = (ClientInvocationBuilder) target.request(); request.setChunked(b);Copy to Clipboard Copied! Toggle word wrap Toggle overflow Unlike the
javax.ws.rs.client.Invocation.Builderclass,org.jboss.resteasy.client.jaxrs.internal.ClientInvocationBuilderis a RESTEasy class.
The ability to send the requests in chunked mode depends on the underlying transport layer. In particular, it depends on the implementation of the org.jboss.resteasy.client.jaxrs.ClientHttpEngine class being used. Currently, only the default implementation ApacheHttpClient43Engine and the previous implementation ApacheHttpClient4Engine support the chunked mode. Both these are available in the org.jboss.resteasy.client.jaxrs.engines package. See section Implementing RESTEasy with HTTP Client for more information.
2.2.2. Implementing RESTEasy with HTTP Client Copy linkLink copied to clipboard!
Network communication between the client and server is handled by default in RESTEasy. It uses the HttpClient from the Apache HttpComponents project. The interface between the RESTEasy client framework and the network is defined by the ClientHttpEngine interface.
RESTEasy ships with four implementations of this interface. The default implementation is ApacheHttpClient43Engine. This implementation uses Apache 4.3.
ApacheHttpClient4Engine is an implementation that uses the versions earlier than Apache 4.3. This class provides backward compatibility. RESTEasy automatically selects one of these two ClientHttpEngine implementations based on the detection of the Apache version. InMemoryClientEngine is an implementation that dispatches requests to a server in the same JVM, and URLConnectionEngine is an implementation that uses java.net.HttpURLConnection.
A client executor can be passed to a specific ClientRequest:
ResteasyClient client = new ResteasyClientBuilder().httpEngine(engine).build();
ResteasyClient client = new
ResteasyClientBuilder().httpEngine(engine).build();
RESTEasy and HttpClient make the default decisions to use the client framework without referencing HttpClient. However, for some applications it might be necessary to drill down into the HttpClient details. ApacheHttpClient43Engine and ApacheHttpClient4Engine can be supplied with an instance of org.apache.http.client.HttpClient and org.apache.http.protocol.HttpContext, which can carry additional configuration details into the HttpClient layer. For example, authentication can be configured as follows:
HttpContextProvider is an interface provided by RESTEasy, using which you can supply a custom HttpContext to the ApacheHttpClient43Engine and ApacheHttpClient4Engine implementations.
It is important to understand the difference between releasing a connection and closing a connection. Releasing a connection makes it available for reuse. Closing a connection frees its resources and makes it unusable.
RESTEasy releases the connection without notification. The only counter example is the case in which the response is an instance of InputStream, which must be closed explicitly.
On the other hand, if the result of an invocation is an instance of Response, the Response.close() method must be used to release the connection.
WebTarget target = client.target("http://localhost:8081/customer/123");
Response response = target.request().get();
System.out.println(response.getStatus());
response.close();
WebTarget target = client.target("http://localhost:8081/customer/123");
Response response = target.request().get();
System.out.println(response.getStatus());
response.close();
You may execute this in a try-finally block. Releasing a connection makes it available for another use. It does not normally close the socket.
ApacheHttpClient4Engine.finalize() closes any open sockets, if it created the HttpClient that it has been using. It is not safe to rely on JDK to call finalize(). If an HttpClient is passed to the ApacheHttpClient4Executor, the user must close the connections, as shown below:
HttpClient httpClient = new HttpClientBuilder.create().build(); ApacheHttpClient4Engine executor = new ApacheHttpClient4Engine(httpClient); ... httpClient.getConnectionManager().shutdown();
HttpClient httpClient = new HttpClientBuilder.create().build();
ApacheHttpClient4Engine executor = new ApacheHttpClient4Engine(httpClient);
...
httpClient.getConnectionManager().shutdown();
If ApacheHttpClient4Engine has created its own instance of HttpClient, it is not necessary to wait for finalize() to close open sockets. The ClientHttpEngine interface has a close() method for this purpose.
Finally, if the javax.ws.rs.client.Client class has created the engine automatically, call Client.close(). This call cleans up any socket connections.
2.3. JAX-RS Request Processing Copy linkLink copied to clipboard!
2.3.1. Asynchronous HTTP Request Processing Copy linkLink copied to clipboard!
Asynchronous request processing allows you to process a single HTTP request using non-blocking input and output and, if required, in separate threads.
Consider an AJAX chat client in which you want to push and pull from both the client and the server. This scenario has the client blocking for a long time on the server’s socket, waiting for a new message. In case of synchronous HTTP processing, where the server is blocking on incoming and outgoing input and output, you have one separate thread consumed per client connection. This model of request processing consumes a lot of memory and valuable thread resources.
Asynchronous processing separates the connection accepting and the request processing operations. It allocates two different threads: one to accept the client connection; the other to handle heavy, time-consuming operations. In this model, the container works as follows:
- It dispatches a thread to accept a client connection, which is the acceptor.
- Then it hands over the request to the processing thread, which is the worker.
- Finally, it releases the acceptor thread.
The result is sent back to the client by the worker thread. Hence, the client’s connection remains open, thereby improving the server’s throughput and scalability.
2.3.1.1. Server Asynchronous Response Processing Copy linkLink copied to clipboard!
On the server side, asynchronous processing involves suspending the original request thread and initiating the request processing on a different thread, which releases the original server-side thread to accept other incoming requests.
2.3.1.1.1. AsyncResponse API Copy linkLink copied to clipboard!
The JAX-RS 2.0 specification has added asynchronous HTTP support using two classes: the @Suspended annotation and the AsyncResponse interface.
Injecting an AsyncResponse as a parameter to your JAX-RS method prompts RESTEasy to detach the HTTP request and response from the thread being executed currently. This ensures that the current thread does not try to automatically process the response.
The AsyncResponse is the callback object. The act of calling one of the resume() methods causes a response to be sent back to the client and also terminates the HTTP request. The following is an example of asynchronous processing:
2.3.1.2. AsyncInvoker Client API Copy linkLink copied to clipboard!
Similarly, on the client side, asynchronous processing prevents blocking the request thread since no time is spent waiting for a response from the server. For instance, a thread that issued a request may also update a user interface component. If that thread is blocked waiting for a response, the user’s perceived performance of the application will suffer.
2.3.1.2.1. Using Future Copy linkLink copied to clipboard!
In the code snippet below, the get() method is called on the async() method rather than the request. This changes the call mechanism from synchronous to asynchronous. Instead of responding synchronously, the async() method returns a future object. When you call the get() method, the call is blocked until the response is ready. The future.get() method will be returned whenever the response is ready.
2.3.1.2.2. Using InvocationCallback Copy linkLink copied to clipboard!
The AsyncInvoker interface allows you to register an object that will be called back when the asynchronous invocation is ready for processing. The InvocationCallback interface provides two methods: completed() and failed(). The completed() method is called whenever the processing is finished successfully and the response is received. Conversely, the failed() method is called whenever the request processing is not successful.
2.4. Viewing RESTEasy Endpoints Copy linkLink copied to clipboard!
You can use the read-resource operation of the jaxrs subsystem to view structured output of each RESTEasy endpoint. An example of the management CLI command and the expected outcome is provided below.
In the example above, the output information is grouped by the resource-class and ordered as per the resource-path:
-
resource-pathis the address to access the endpoint. -
resource-classdefines the class, where the endpoint is defined. -
rest-resource-pathsincludes the Java methods that define the resource path, HTTP method, consumes and produces of the endpoint. -
java-methodspecifies the name of the Java method and its parameters. It also contains information about the following JAX-RS annotations, if defined:@PathParam,@QueryParam,@HeaderParam,@MatrixParam,@CookieParam,@FormParamand@DefaultValue.
Alternatively, you can use the read-resource operation without the rest-resource parameter defined and get the information about all the endpoints, as shown in the example below:
/deployment=DEPLOYMENT_NAME/subsystem=jaxrs:read-resource(include-runtime=true,recursive=true)
/deployment=DEPLOYMENT_NAME/subsystem=jaxrs:read-resource(include-runtime=true,recursive=true)
2.5. URL-Based Negotiation Copy linkLink copied to clipboard!
2.5.1. Mapping Extensions to Media Types Copy linkLink copied to clipboard!
Some clients, such as browsers, cannot use the Accept and Accept-Language headers to negotiate the representation media type or language. RESTEasy can map file name suffixes to media types and languages to deal with this issue.
To map media types to file extensions using the web.xml file, you need to add a resteasy.media.type.mappings context param and the list of mappings as the param-value. The list is comma separated and uses colons (:) to delimit the file extension and media type.
Example web.xml Mapping File Extensions to Media Types
<context-param>
<param-name>resteasy.media.type.mappings</param-name>
<param-value>html : text/html, json : application/json, xml : application/xml</param-value>
</context-param>
<context-param>
<param-name>resteasy.media.type.mappings</param-name>
<param-value>html : text/html, json : application/json, xml : application/xml</param-value>
</context-param>
2.5.2. Mapping Extensions to Languages Copy linkLink copied to clipboard!
Some clients, such as browsers, cannot use the Accept and Accept-Language headers to negotiate the representation media type or language. RESTEasy can map file name suffixes to media types and languages to deal with this issue. Follow these steps to map languages to file extensions, in the web.xml file.
To map media types to file extensions using the web.xml file, you need to add a resteasy.language.mappings context param and the list of mappings as the param-value. The list is comma separated and uses colons (:) to delimit the file extension and language type.
Example web.xml Mapping File Extensions to Language Types
<context-param>
<param-name>resteasy.language.mappings</param-name>
<param-value> en : en-US, es : es, fr : fr</param-name>
</context-param>
<context-param>
<param-name>resteasy.language.mappings</param-name>
<param-value> en : en-US, es : es, fr : fr</param-name>
</context-param>
2.6. Content Marshalling and Providers Copy linkLink copied to clipboard!
2.6.1. Default Providers and Default JAX-RS Content Marshalling Copy linkLink copied to clipboard!
RESTEasy can automatically marshal and unmarshal a few different message bodies.
| Media Types | Java Types |
|---|---|
|
| JAXB annotated classes |
|
| org.w3c.dom.Document |
| * / * | java.lang.String |
| * / * | java.io.InputStream |
|
| primitives, java.lang.String, or any type that has a String constructor, or static valueOf(String) method for input, toString() for output |
| * / * | javax.activation.DataSource |
| * / * | java.io.File |
| * / * | byte |
|
| javax.ws.rs.core.MultivaluedMap |
2.6.1.1. Text Media Types and Character Sets Copy linkLink copied to clipboard!
According to the JAX-RS specification, implementations must adhere to application-supplied character set metadata when writing responses. If a character set is not specified by the application or if the application specifies a character set that is not supported, then the implementations must use UTF-8 character set.
On the contrary, according to the HTTP specification, when no explicit charset parameter is provided by the sender, media subtypes of the text type are defined to have a default charset value of ISO-8859-1 when received via HTTP. Data in character sets other than ISO-8859-1 or its subsets must be labeled with an appropriate charset value.
In the absence of a character set specified by a resource or resource method, RESTEasy uses UTF-8 as the character set for text media types. In order to do so, RESTEasy adds an explicit charset parameter to the content-type response header.
To specify the original behavior, in which UTF-8 is used for text media types but the explicit charset parameter is not appended, set the context parameter resteasy.add.charset to false. The default value of this parameter is true.
Text media types include:
-
Media types with type
textand any subtype. -
Media types with type
applicationand subtype beginning withxml. This includesapplication/xml-external-parsed-entityandapplication/xml-dtd.
2.6.2. Content Marshalling with @Provider classes Copy linkLink copied to clipboard!
The JAX-RS specification allows you to plug in your own request/response body readers and writers. To do this, you annotate a class with @Provider and specify the @Produces types for a writer and @Consumes types for a reader. You must also implement a MessageBodyReader/Writer interface.
The RESTEasy ServletContextLoader automatically scans the WEB-INF/lib and classes directories for classes annotated with @Provider, or you can manually configure them in the web.xml file.
2.6.3. Providers Utility Class Copy linkLink copied to clipboard!
javax.ws.rs.ext.Providers is a simple injectable interface that allows you to look up MessageBodyReaders, Writers, ContextResolvers, and ExceptionMappers. It is very useful for implementing multipart providers and content types that embed other random content types.
A Providers instance is injectable into MessageBodyReader or Writers:
2.6.4. Configuring Document Marshalling Copy linkLink copied to clipboard!
XML document parsers are subject to a form of attack known as the XXE (XML eXternal Entity) attack, in which expanding an external entity causes an unsafe file to be loaded. For example, the following document could cause the /etc/passwd file to be loaded.
By default, the RESTEasy built-in unmarshaller for org.w3c.dom.Document documents does not expand external entities. It replaces them with an empty string. You can configure it to replace external entities with values defined in the DTD. This is done by setting the resteasy.document.expand.entity.references context parameter to true in the web.xml file.
Example: Setting the resteasy.document.expand.entity.references Context Parameter
<context-param> <param-name>resteasy.document.expand.entity.references</param-name> <param-value>true</param-value> </context-param>
<context-param>
<param-name>resteasy.document.expand.entity.references</param-name>
<param-value>true</param-value>
</context-param>
Another way of dealing with the problem is by prohibiting DTDs, which RESTEasy does by default. This behavior can be changed by setting the resteasy.document.secure.disableDTDs context parameter to false.
Example: Setting the resteasy.document.secure.disableDTDs Context Parameter
<context-param> <param-name>resteasy.document.secure.disableDTDs</param-name> <param-value>false</param-value> </context-param>
<context-param>
<param-name>resteasy.document.secure.disableDTDs</param-name>
<param-value>false</param-value>
</context-param>
Documents are also subject to Denial of Service Attacks when buffers are overrun by large entities or too many attributes. For example, if a DTD defined the following entities, the expansion of &foo6; would result in 1,000,000 foos.
By default, RESTEasy limits the number of expansions and the number of attributes per entity. The exact behavior depends on the underlying parser. The limit can be turned off by setting the resteasy.document.secure.processing.feature context parameter to false.
Example: Setting the resteasy.document.secure.processing.feature Context Parameter
<context-param> <param-name>resteasy.document.secure.processing.feature</param-name> <param-value>false</param-value> </context-param>
<context-param>
<param-name>resteasy.document.secure.processing.feature</param-name>
<param-value>false</param-value>
</context-param>
2.6.5. Using MapProvider Copy linkLink copied to clipboard!
You can use MapProvider to accept and return a map with JAX-RS resources.
Example: Resource Accepting and Returning a Map
You can also send and receive maps to JAX-RS resources using the client.
Example: Client
2.6.6. Converting String Based Annotations to Objects Copy linkLink copied to clipboard!
JAX-RS @*Param annotations, including @QueryParam, @MatrixParam, @HeaderParam, @PathParam, and @FormParam, are represented as strings in a raw HTTP request. These types of injected parameters can be converted to objects if these objects have a valueOf(String) static method or a constructor that takes one String parameter.
If you have a class where the valueOf() method or the string constructor does not exist or is inappropriate for an HTTP request, the JAX-RS 2.0 specification provides the javax.ws.rs.ext.ParamConverterProvider and javax.ws.rs.ext.ParamConverter to help convert the message parameter value to the corresponding custom Java type. ParamConverterProvider must be either programmatically registered in a JAX-RS runtime or must be annotated with @Provider annotation to be automatically discovered by the JAX-RS runtime during a provider scanning phase.
For example: The steps below demonstrate how to create a custom POJO object. The conversion from message parameter value such as @QueryParam, @PathParam, @MatrixParam, @HeaderParam into POJO object is done by implementation of ParamConverter and ParamConverterProvider interfaces.
Create the custom POJO class.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the custom POJO Converter class.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the custom POJO Converter Provider class.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the custom MyResource class.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.6.7. Serializable Provider Copy linkLink copied to clipboard!
Deserializing Java objects from untrusted sources is not safe. Therefore, org.jboss.resteasy.plugins.providers.SerializableProvider is disabled by default. It is not recommended to use this provider.
2.6.8. JSON Provider Copy linkLink copied to clipboard!
2.6.8.1. JsonFilter Support in RESTEasy Jackson2 Copy linkLink copied to clipboard!
JsonFilter facilitates dynamic filtering by allowing you to annotate a class with @JsonFilter. The following example defines mapping from the nameFilter class to the filter instances, and then filtering out bean properties when serializing the instances to JSON format.
@JsonFilter annotates the resource class to filter out the property that should not be serialized in the JSON response. To map the filter ID and instance, you must create another Jackson class and add the ID and filter instance map to it, as shown in the example below.
In the example above, the method modify() takes care of filtering all properties except the name property before writing the response. For this to work, RESTEasy must know about this mapping information. You can set the mapping information either in a WriterInterceptor or a servlet filter, as shown in the examples below.
Example: Setting ObjectFilterModifier Using WriterInterceptor
Example: Setting ObjectFilterModifier Using Servlet Filter
Now, RESTEasy can get the ObjectFilterModifier from the ThreadLocal variable and configure it to modify ObjectWriter before writing the response.
2.6.9. JAXB Providers Copy linkLink copied to clipboard!
2.6.9.1. JAXB and XML Provider Copy linkLink copied to clipboard!
RESTEasy provides JAXB provider support for XML.
@XmlHeader and @Stylesheet
RESTEasy provides setting an XML header using the @org.jboss.resteasy.annotations.providers.jaxb.XmlHeader annotation.
Example: Using the @XmlHeader Annotation
The @XmlHeader ensures that the XML output has an XML-stylesheet header.
RESTEasy has a convenient annotation for stylesheet headers.
Example: Using the @Stylesheet Annotation
2.6.9.2. JAXB and JSON Provider Copy linkLink copied to clipboard!
RESTEasy allows you to marshal JAXB annotated POJOs to and from JSON using the JSON provider. This provider wraps the Jackson JSON library to accomplish this task. It has a Java Beans based model and APIs similar to JAXB.
While Jackson already includes JAX-RS integration, it was expanded by RESTEasy. To include it in your project, you need to update the Maven dependencies.
Maven Dependencies for Jackson
The default JSON provider for RESTEasy is Jackson2. Previous versions of JBoss EAP included the Jackson1 JSON provider. For more details on migrating your existing applications from the Jackson1 provider, see the JBoss EAP Migration Guide. If you still want to use the Jackson1 provider, you have to explicitly update the Maven dependencies to obtain it.
The default JSON provider for RESTEasy in previous versions of JBoss EAP was Jettison, but is now deprecated in JBoss EAP 7. For more details, see the JBoss EAP Migration Guide.
Example JSON Provider
2.6.9.2.1. Jackson Module Support for Java 8 Copy linkLink copied to clipboard!
This section provides the Maven dependencies and shows how to register the Jackson modules needed to support Java 8 features, when the core Jackson modules do not require Java 8 runtime environment. These Jackson modules include:
- Java 8 data types
- Java 8 date/time
Add the following Maven dependencies:
You can find and register all the modules using findAndRegisterModules() or ObjectMapper.registerModule(), as shown in the examples below:
ObjectMapper mapper = new ObjectMapper(); mapper.findAndRegisterModules();
ObjectMapper mapper = new ObjectMapper();
mapper.findAndRegisterModules();
ObjectMapper mapper = new ObjectMapper() .registerModule(new ParameterNamesModule()) .registerModule(new Jdk8Module()) .registerModule(new JavaTimeModule());
ObjectMapper mapper = new ObjectMapper()
.registerModule(new ParameterNamesModule())
.registerModule(new Jdk8Module())
.registerModule(new JavaTimeModule());
Example: Duration Data Type
Example: Optional Data Type
You must use the custom implementation of the ContextResolver in order to use these Jackson modules in RESTEasy.
2.6.9.2.2. Switching the Default Jackson Provider Copy linkLink copied to clipboard!
JBoss EAP 7 includes Jackson 2.6.x or greater and resteasy-jackson2-provider is now the default Jackson provider.
To switch to the default resteasy-jackson-provider that was included in the previous release of JBoss EAP, exclude the new provider and add a dependency for the previous provider in the jboss-deployment-structure.xml application deployment descriptor file.
2.6.10. Creating JAXB Decorators Copy linkLink copied to clipboard!
RESTEasy’s JAXB providers have a pluggable way to decorate Marshaller and Unmarshaller instances. You can create an annotation that can trigger either a Marshaller or Unmarshaller instance, which can be used to decorate methods.
Create a JAXB Decorator with RESTEasy
Create the Processor class.
-
Create a class that implements
DecoratorProcessor<Target, Annotation>. The target is either the JAXB Marshaller or Unmarshaller class. The annotation is created in step two. -
Annotate the class with
@DecorateTypes, and declare the MIME types the decorator should decorate. Set properties or values within the decorate function.
Example: Processor Class
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Create a class that implements
Create the annotation.
-
Create a custom interface that is annotated with the
@Decoratorannotation. Declare the processor and target for the
@Decoratorannotation. The processor is created in step one. The target is either the JAXBMarshallerorUnmarshallerclass.Example: Custom Interface with
@DecoratorAnnotationCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Create a custom interface that is annotated with the
- Add the annotation created in step two to a function so that either the input or output is decorated when it is marshaled.
You have now created a JAXB decorator, which can be applied within a JAX-RS web service.
2.6.11. Multipart Providers in JAX-RS Copy linkLink copied to clipboard!
The multipart MIME format is used to pass lists of content bodies embedded in one message. One example of a multipart MIME format is the multipart/form-data MIME type. This is often found in web application HTML form documents and is generally used to upload files. The form-data format in this MIME type is the same as other multipart formats, except that each inlined piece of content has a name associated with it.
RESTEasy allows for the multipart/form-data and multipart/* MIME types. RESTEasy also provides a custom API for reading and writing multipart types as well as marshalling arbitrary List (for any multipart type) and Map (multipart/form-data only) objects.
There are a lot of frameworks doing multipart parsing automatically with the help of filters and interceptors, such as org.jboss.seam.web.MultipartFilter in Seam or org.springframework.web.multipart.MultipartResolver in Spring. However, the incoming multipart request stream can be parsed only once. RESTEasy users working with multipart should make sure that nothing parses the stream before RESTEasy gets it.
2.6.11.1. Input with Multipart Data Copy linkLink copied to clipboard!
When writing a JAX-RS service, RESTEasy provides the org.jboss.resteasy.plugins.providers.multipart.MultipartInput interface to allow you to read in any multipart MIME type.
MultipartInput is a simple interface that allows you to get access to each part of the multipart message. Each part is represented by an InputPart interface, and each part has a set of headers associated with it. You can unmarshal the part by calling one of the getBody() methods. The genericType parameter can be null, but the type parameter must be set. RESTEasy will find a MessageBodyReader based on the media type of the part as well as the type information you pass in.
2.6.11.1.1. Input with multipart/mixed Copy linkLink copied to clipboard!
Example: Unmarshalling Parts
The above example assumes the Customer class is annotated with JAXB.
Sometimes you may want to unmarshal a body part that is sensitive to generic type metadata. In this case you can use the org.jboss.resteasy.util.GenericType class.
Example: Unmarshalling a Type Sensitive to Generic Type Metadata
Use of GenericType is required because it is the only way to obtain generic type information at runtime.
2.6.11.1.2. Input with multipart/mixed and java.util.List Copy linkLink copied to clipboard!
If the body parts are uniform, you do not have to manually unmarshal each and every part. You can just provide a java.util.List as your input parameter. It must have the type it is unmarshalling with the generic parameter of the List type declaration.
Example: Unmarshalling a List of Customers
The above example assumes the Customer class is annotated with JAXB.
2.6.11.1.3. Input with multipart/form-data Copy linkLink copied to clipboard!
When writing a JAX-RS service, RESTEasy provides an interface that allows you to read in multipart/form-data MIME type. multipart/form-data is often found in web application HTML form documents and is generally used to upload files. The form-data format is the same as other multipart formats, except that each inlined piece of content has a name associated with it. The interface used for form-data input is org.jboss.resteasy.plugins.providers.multipart.MultipartFormDataInput.
Example: MultipartFormDataInput Interface
It works in much the same way as MultipartInput described earlier.
2.6.11.1.4. java.util.Map with multipart/form-data Copy linkLink copied to clipboard!
With form-data, if the body parts are uniform, you do not have to manually unmarshal each and every part. You can just provide a java.util.Map as your input parameter. It must have the type it is unmarshalling with the generic parameter of the List type declaration.
Example: Unmarshalling a Map of Customer objects
The above example assumes the Customer class is annotated with JAXB.
2.6.11.2. Output with Multipart Data Copy linkLink copied to clipboard!
RESTEasy provides a simple API to output multipart data.
To output multipart data, you need to create a MultipartOutput object and call the addPart() method. RESTEasy will automatically find a MessageBodyWriter to marshal your entity objects. Similar to MultipartInput, sometimes you might have marshalling that is sensitive to generic type metadata. In that case, use the GenericType. Usually, passing in an object and its MediaType should be enough.
Example: Returning a multipart/mixed Format
The above example assumes the Customer class is annotated with JAXB.
2.6.11.2.1. Multipart Output with java.util.List Copy linkLink copied to clipboard!
If the body parts are uniform, you do not have to manually marshal each and every part or even use a MultipartOutput object. You can provide a java.util.List which must have the generic type it is marshalling with the generic parameter of the List type declaration. You must also annotate the method with the @PartType annotation to specify the media type of each part.
Example: Returning a List of Customer Objects
The above example assumes the Customer class is annotated with JAXB.
2.6.11.2.2. Output with multipart/form-data Copy linkLink copied to clipboard!
RESTEasy provides a simple API to output multipart/form-data.
To output multipart/form-data, you must create a MultipartFormDataOutput object and call the addFormData() method. RESTEasy will automatically find a MessageBodyWriter to marshal your entity objects. Similar to MultipartInput, sometimes you might have marshalling that is sensitive to generic type metadata. In that case, use the GenericType. Usually, passing in an object and its MediaType should be enough.
Example: Returning multipart/form-data Format
The above example assumes the Customer class is annotated with JAXB.
2.6.11.2.3. Multipart FormData Output with java.util.Map Copy linkLink copied to clipboard!
If the body parts are uniform, you do not have to manually marshal every part or use a MultipartFormDataOutput object. You can just provide a java.util.Map which must have the generic type it is marshalling with the generic parameter of the Map type declaration. You must also annotate the method with the @PartType annotation to specify the media type of each part.
Example: Returning a Map of Customer Objects
The above example assumes the Customer class is annotated with JAXB.
2.6.11.3. Mapping Multipart Forms to POJOs Copy linkLink copied to clipboard!
If you have an exact knowledge of your multipart/form-data packets, you can map them to and from a POJO class. This is accomplished using the org.jboss.resteasy.annotations.providers.multipart.MultipartForm annotation (@MultipartForm) and the JAX-RS @FormParam annotation. To do so, you need to define a POJO with at least a default constructor and annotate its fields and/or properties with @FormParams. These @FormParams must also be annotated with org.jboss.resteasy.annotations.providers.multipart.PartType (@PartType) if you are creating output.
Example: Mapping Multipart Forms to a POJO
After defining your POJO class you can then use it to represent multipart/form-data.
Example: Submit CustomerProblemForm
The @MultipartForm annotation tells RESTEasy that the object has @FormParam and that it should be marshaled from that. You can also use the same object to receive multipart data.
Example: Receive CustomerProblemForm
2.6.11.4. XML-binary Optimized Packaging (XOP) Copy linkLink copied to clipboard!
If you have a JAXB annotated POJO that also holds some binary content, you may choose to send it in such a way that the binary does not need to be encoded in any way such as base64 or hex. This is accomplished using XOP and results in faster transport while still using the convenient POJO.
RESTEasy allows for XOP messages packaged as multipart/related.
To configure XOP, you first need a JAXB annotated POJO.
Example: JAXB POJO
@XmlMimeType tells JAXB the mime type of the binary content. This is not required to do XOP packaging but it is recommended to be set if you know the exact type.
In the above POJO myBinary and myDataHandler will be processed as binary attachments while the whole XOP object will be sent as XML. In place of the binaries, only their references will be generated. javax.activation.DataHandler is the most general supported type. If you need a java.io.InputStream or a javax.activation.DataSource, you need to use the DataHandler. java.awt.Image and javax.xml.transform.SourceSome are available as well.
Example: Client Sending Binary Content with XOP
The above example assumes the Customer class is annotated with JAXB.
The @Consumes(MultipartConstants.MULTIPART_RELATED) is used to tell RESTEasy that you want to send multipart/related packages, which is the container format that holds the XOP message. @XopWithMultipartRelated is used to tell RESTEasy that you want to make XOP messages.
Example: RESTEasy Server for Receiving XOP
@Consumes(MultipartConstants.MULTIPART_RELATED) is used to tell RESTEasy that you want to read multipart/related packages. @XopWithMultipartRelated is used to tell RESTEasy that you want to read XOP messages. You can configure a RESTEasy server to produce XOP values in a similar way by adding a @Produces annotation and returning the appropriate type.
2.6.11.5. Overwriting the Default Fallback Content Type for Multipart Messages Copy linkLink copied to clipboard!
By default, if no Content-Type header is present in a part, text/plain; charset=us-ascii is used as a fallback. This is defined by the MIME RFC. However some web clients, such as many browsers, may send Content-Type headers for the file parts, but not for all fields in a multipart/form-data request. This can cause character encoding and unmarshalling errors on the server side. The PreProcessInterceptor infrastructure of RESTEasy can be used to correct this issue. You can use it to define another, non-RFC compliant fallback value, dynamically per request.
Example: Setting * / *; charset=UTF-8 as the Default Fallback
2.6.11.6. Overwriting the Content Type for Multipart Messages Copy linkLink copied to clipboard!
Using an interceptor and the InputPart.DEFAULT_CONTENT_TYPE_PROPERTY attribute allows you to set a default Content-Type. You can also override the Content-Type in any input part by calling org.jboss.resteasy.plugins.providers.multipart.InputPart.setMediaType().
Example: Overriding the Content-Type
2.6.11.7. Overwriting the Default Fallback charset for Multipart Messages Copy linkLink copied to clipboard!
In some cases, part of a multipart message may have a Content-Type header with no charset parameter. If the InputPart.DEFAULT_CONTENT_TYPE_PROPERTY property is set and the value has a charset parameter, that value will be appended to an existing Content-Type header that has no charset parameter.
You can also specify a default charset using the constant InputPart.DEFAULT_CHARSET_PROPERTY (resteasy.provider.multipart.inputpart.defaultCharset).
Example: Specifying a Default charset
If both InputPart.DEFAULT_CONTENT_TYPE_PROPERTY and InputPart.DEFAULT_CHARSET_PROPERTY are set, then the value of InputPart.DEFAULT_CHARSET_PROPERTY will override any charset in the value of InputPart.DEFAULT_CONTENT_TYPE_PROPERTY.
2.6.11.8. Send Multipart Entity with RESTEasy Client Copy linkLink copied to clipboard!
In addition to configuring multipart providers, you can also configure the RESTEasy client to send multipart data.
Using RESTEasy Client Classes
To use RESTEasy client classes in your application, you must add the Maven dependencies to your project’s POM file.
Example: Maven Dependencies
Sending Multipart Data Using the RESTEasy Client
To send multipart data, you first need to configure a RESTEasy Client and construct a org.jboss.resteasy.plugins.providers.multipart.MultipartFormDataOutput object to contain your multipart data. You can then use the client to send that MultipartFormDataOutput object as a javax.ws.rs.core.GenericEntity.
Example: RESTEasy Client
2.6.12. RESTEasy Atom Support Copy linkLink copied to clipboard!
The RESTEasy Atom API and Provider is a simple object model that RESTEasy defines to represent Atom. The main classes for the API are in the org.jboss.resteasy.plugins.providers.atom package. RESTEasy uses JAXB to marshal and unmarshal the API. The provider is JAXB based, and is not limited to sending Atom objects using XML. All JAXB providers that RESTEasy has can be reused by the Atom API and provider, including JSON.
2.6.12.1. Using JAXB with Atom Provider Copy linkLink copied to clipboard!
The org.jboss.resteasy.plugins.providers.atom.Content class allows you to unmarshal and marshal JAXB annotated objects that are the body of the content.
Example: Entry with a Customer
The Content.setJAXBObject() method lets you specify the content object you send to JAXB to marshal appropriately. If you are using a different base format other than XML, that is application/atom+json, the attached JAXB object is marshalled in the same format. If you have an Atom document as input, you can also extract JAXB objects from Content using the Content.getJAXBObject(Class clazz) method.
Example: Atom Document Extracting a Customer Object
2.6.13. YAML Provider Copy linkLink copied to clipboard!
The resteasy-yaml-provider module is not supported. Its use is not recommended due to a security issue in the SnakeYAML library used by RESTEasy for unmarshalling.
RESTEasy comes with built in support for YAML using the SnakeYAML library.
In releases prior to JBoss EAP 7.1, the YAML provider setting was enabled by default and you only needed to configure the Maven dependencies for YAML to use it in your application. This has changed in JBoss EAP 7.1. The YAML provider is now disabled by default and must be explicitly enabled in the application.
Enable the YAML Provider
To enable the YAML provider in your application, follow these steps:
-
Create or update a file named
javax.ws.rs.ext.Providers. Add the following content to the file.
org.jboss.resteasy.plugins.providers.YamlProvider
org.jboss.resteasy.plugins.providers.YamlProviderCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Place the file in the
META-INF/services/folder of your WAR or JAR file.
YAML Provider Maven Dependencies
To use the YAML provider in your application, you must add the snakeyaml JAR dependencies to the project POM file of your application.
Example: Maven Dependencies for YAML
YAML Provider Code Example
The YAML provider recognizes three mime types:
- text/x-yaml
- text/yaml
- application/x-yaml
The following is an example of how to use YAML in a resource method.
Example: Resource Producing YAML
2.7. Using the JSON API for JSON Processing (JSON-P) Copy linkLink copied to clipboard!
The JSON API for JSON Processing (JSON-P) is a part of the Java EE 7 specification and is defined in JSR 353. JSON-P defines an API to process JSON. JBoss EAP has support for javax.json.JsonObject, javax.json.JsonArray, and javax.json.JsonStructure as request or response entities.
The JSON API for JSON Processing (JSON-P) is different from JSON with Padding (JSONP).
JSON-P will not conflict with Jackson if they are on the same classpath.
To create a JsonObject, use the JsonObjectBuilder by calling Json.createObjectBuilder() and building the JSON object.
Example: Create javax.json.JsonObject
JsonObject obj = Json.createObjectBuilder().add("name", "Bill").build();
JsonObject obj = Json.createObjectBuilder().add("name", "Bill").build();
Example: Corresponding JSON for javax.json.JsonObject
{
"name":"Bill"
}
{
"name":"Bill"
}
To create a JsonArray, use the JsonArrayBuilder by calling Json.createArrayBuilder() and building the JSON array.
Example: Create javax.json.JsonArray
JsonArray array =
Json.createArrayBuilder()
.add(Json.createObjectBuilder().add("name", "Bill").build())
.add(Json.createObjectBuilder().add("name", "Monica").build()).build();
JsonArray array =
Json.createArrayBuilder()
.add(Json.createObjectBuilder().add("name", "Bill").build())
.add(Json.createObjectBuilder().add("name", "Monica").build()).build();
Example: Corresponding JSON for javax.json.JsonArray
JsonStructure is a parent class of JsonObject and JsonArray.
Example: Create javax.json.JsonStructure
You can use JsonObject, JsonArray, and JsonStructure directly in JAX-RS resources.
Example: JAX-RS Resources with JSON-P
You can also use JSON-P from a client to send JSON.
Example: Client Using JSON-P
WebTarget target = client.target(...);
JsonObject obj = Json.createObjectBuilder().add("name", "Bill").build();
JsonObject newObj = target.request().post(Entity.json(obj), JsonObject.class);
WebTarget target = client.target(...);
JsonObject obj = Json.createObjectBuilder().add("name", "Bill").build();
JsonObject newObj = target.request().post(Entity.json(obj), JsonObject.class);
2.8. RESTEasy/EJB Integration Copy linkLink copied to clipboard!
To integrate RESTEasy with EJB, add JAX-RS annotations to the EJB classes that you want to expose as JAX-RS endpoints. You can also apply the annotations on the bean’s business interface. There are two ways to activate the beans as endpoints:
-
Using the
web.xmlfile. -
Using
javax.ws.rs.core.Application.
To make an EJB function as a JAX-RS resource, annotate a stateless session bean’s @Remote or @Local interface with JAX-RS annotations:
Note that the Library interface is referenced by fully qualified name, whereas LibraryBean is referenced only by the simple class name.
Then, manually register the EJB with RESTEasy using the resteasy.jndi.resources context parameter in the RESTEasy web.xml file:
You can also specify multiple JNDI names of EJBs, separated by commas, for the resteasy.jndi.resources context parameter.
An alternate Java EE-standard way to activate EJBs as RESTEasy endpoints is by using javax.ws.rs.core.Application. This is achieved by including the EJB implementation class into the set returned by the application’s getClasses() method. This approach does not need anything to be specified in the web.xml file.
See the kitchensink, helloworld-html5, and managed-executor-service quickstarts that ship with JBoss EAP for working examples that demonstrate RESTEasy integration with EJBs.
2.9. Spring Integration Copy linkLink copied to clipboard!
Your application must have an existing JAX-WS service and client configuration.
RESTEasy integrates with Spring 4.2.x.
Maven users must use the resteasy-spring artifact. Alternatively, the JAR is available as a module in JBoss EAP.
RESTEasy comes with its own Spring ContextLoaderListener that registers a RESTEasy specific BeanPostProcessor that processes JAX-RS annotations when a bean is created by a BeanFactory. This means that RESTEasy automatically scans for @Provider and JAX-RS resource annotations on your bean class and registers them as JAX-RS resources.
Add the following to your web.xml file to enable the RESTEasy/Spring integration functionality:
The SpringContextLoaderListener must be declared after ResteasyBootstrap as it uses ServletContext attributes initialized by it.
See the spring-resteasy quickstart that ships with JBoss EAP for a working example of a web application that demonstrates RESTEasy integration with Spring.
2.10. CDI Integration Copy linkLink copied to clipboard!
Integration between RESTEasy and CDI is provided by the resteasy-cdi module.
Both the JAX-RS and CDI specifications introduce their own component models. Every class placed in a CDI archive, which fulfills a set of basic constraints, is implicitly a CDI bean. Explicit declaration of your Java class with @Path or @Provider is required for it to become a JAX-RS component. Without the integration code, annotating a class suitable for being a CDI bean with JAX-RS annotations gives a faulty result and the JAX-RS component is not managed by the CDI. The resteasy-cdi module is a bridge that allows RESTEasy to work with class instances obtained from the CDI container.
During a web service invocation, the resteasy-cdi module asks the CDI container for the managed instance of a JAX-RS component. Then, this instance is passed to RESTEasy. If a managed instance is not available for some reason, such as the class being placed in a JAR file that is not a bean deployment archive, RESTEasy falls back to instantiating the class itself.
As a result, CDI services like injection, lifecycle management, events, decoration, and interceptor bindings can be used in JAX-RS components.
2.10.1. Default Scope Copy linkLink copied to clipboard!
A CDI bean that does not explicitly define a scope is @Dependent scoped by default. This pseudo-scope means that the bean adapts to the lifecycle of the bean that it is injected into. Normal scopes, including request, session, and application, are more suitable for JAX-RS components as they designate the component’s lifecycle boundaries explicitly. Therefore, the resteasy-cdi module alters the default scoping in the following way:
- If a JAX-RS root resource does not define a scope explicitly, it is bound to the request scope.
-
If a JAX-RS provider or
javax.ws.rs.Applicationsubclass does not define a scope explicitly, it is bound to the application scope.
Since the scope of all beans that do not declare a scope is modified by the resteasy-cdi module, this affects session beans as well. As a result, a conflict occurs if the scope of a stateless session bean or singleton is changed automatically as the specification prohibits these components to be @RequestScoped. Therefore, you need to explicitly define a scope when using stateless session beans or singletons. This requirement is likely to be removed in future releases.
The resteasy-cdi module is bundled with JBoss EAP. Therefore, there is no need to download the module separately or add any additional configuration. See the kitchensink quickstart that ships with JBoss EAP for a working example of using CDI beans with a JAX-RS resource.
2.11. RESTEasy Filters and Interceptors Copy linkLink copied to clipboard!
JAX-RS 2.0 has two different concepts for interceptions: filters and interceptors. Filters are mainly used to modify or process incoming and outgoing request headers or response headers. They execute before and after request and response processing.
2.11.1. Server-side Filters Copy linkLink copied to clipboard!
On the server side, you have two different types of filters: ContainerRequestFilters and ContainerResponseFilters. ContainerRequestFilters run before your JAX-RS resource method is invoked. ContainerResponseFilters run after your JAX-RS resource method is invoked.
In addition, there are two types of ContainerRequestFilters: pre-matching and post-matching. Pre-matching ContainerRequestFilters are designated with the @PreMatching annotation and execute before the JAX-RS resource method is matched with the incoming HTTP request. Post-matching ContainerRequestFilters are designated with the @PostMatching annotation and execute after the JAX-RS resource method is matched with the incoming HTTP request.
Pre-matching filters often are used to modify request attributes to change how it matches to a specific resource method, for example to strip .xml and add an Accept header. ContainerRequestFilters can abort the request by calling ContainerRequestContext.abortWith(Response). For example, a filter might want to abort if it implements a custom authentication protocol.
After the resource class method is executed, JAX-RS runs all ContainerResponseFilters. These filters allow you to modify the outgoing response before it is marshalled and sent to the client.
Example: Request Filter
Example: Response Filter
2.11.2. Client-side Filters Copy linkLink copied to clipboard!
More information on client-side filters can be found in the JAX-RS 2.0 Client API section of this guide.
2.11.3. RESTEasy Interceptors Copy linkLink copied to clipboard!
2.11.3.1. Intercept JAX-RS Invocations Copy linkLink copied to clipboard!
RESTEasy can intercept JAX-RS invocations and route them through listener-like objects called interceptors.
While filters modify request or response headers, interceptors deal with message bodies. Interceptors are executed in the same call stack as their corresponding reader or writer. ReaderInterceptors wrap around the execution of MessageBodyReaders. WriterInterceptors wrap around the execution of MessageBodyWriters. They can be used to implement a specific content-encoding. They can be used to generate digital signatures or to post or pre-process a Java object model before or after it is marshalled.
ReaderInterceptors and WriterInterceptors can be used on either the server or client side. They are annotated with @Provider, as well as either @ServerInterceptor or @ClientInterceptor so that RESTEasy knows whether or not to add them to the interceptor list.
These interceptors wrap around the invocation of MessageBodyReader.readFrom() or MessageBodyWriter.writeTo(). They can be used to wrap the Output or Input streams.
Example: Interceptor
The interceptors and the MessageBodyReader or Writer are invoked in one big Java call stack. ReaderInterceptorContext.proceed() or WriterInterceptorContext.proceed() are called in order to go to the next interceptor or, if there are no more interceptors to invoke, the readFrom() or writeTo() method of the MessageBodyReader or MessageBodyWriter. This wrapping allows objects to be modified before they get to the Reader or Writer, and then cleaned up after proceed() returns.
The example below is a server-side interceptor that adds a header value to the response.
2.11.3.2. Registering an Interceptor Copy linkLink copied to clipboard!
To register a RESTEasy JAX-RS interceptor in an application, list it in the web.xml file under the resteasy.providers parameter in the context-param element, or return it as a class or as an object in the Application.getClasses() or Application.getSingletons() method.
<context-param>
<param-name>resteasy.providers</param-name>
<param-value>my.app.CustomInterceptor</paramvalue>
</context-param>
<context-param>
<param-name>resteasy.providers</param-name>
<param-value>my.app.CustomInterceptor</paramvalue>
</context-param>
2.11.4. GZIP Compression and Decompression Copy linkLink copied to clipboard!
RESTEasy supports GZIP compression and decompression. To support GZIP decompression, the client framework or a JAX-RS service automatically decompresses a message body with a Content-Encoding of gzip, and it can automatically set the Accept-Encoding header to gzip, deflate so that you do not have to set this header manually. To support GZIP compression, RESTEasy compresses the outgoing message if the client framework is sending a request or if the server is sending a response with the Content-Encoding header set to gzip. You can use the @org.jboss.resteasy.annotation.GZIP annotation to set the Content-Encoding header.
The following example tags the outgoing message body order to be gzip compressed.
Example: GZIP Compression
Example: GZIP Compression Tagging Server Responses
2.11.4.1. Configuring GZIP Compression and Decompression Copy linkLink copied to clipboard!
RESTEasy disables GZIP compression and decompression by default in order to prevent decompression of an entity that might be huge in size but has been compressed by an attacker and sent to the server.
There are three interceptors that are relevant to GZIP compression and decompression:
-
org.jboss.resteasy.plugins.interceptors.GZIPDecodingInterceptor: If theContent-Encodingheader is present and has the valuegzip,GZIPDecodingInterceptorinstalls anInputStreamthat decompresses the message body. -
org.jboss.resteasy.plugins.interceptors.GZIPEncodingInterceptor: If theContent-Encodingheader is present and has the valuegzip,GZIPEncodingInterceptorinstalls anOutputStreamthat compresses the message body. org.jboss.resteasy.plugins.interceptors.AcceptEncodingGZIPFilter: If theAccept-Encodingheader does not exist,AcceptEncodingGZIPFilteraddsAccept-Encodingheader with the valuegzip, deflate. If theAccept-Encodingheader exists but does not containgzip,AcceptEncodingGZIPFilterinterceptor appends the value, gzip.NoteEnabling GZIP compression or decompression does not depend on the presence of the
AcceptEncodingGZIPFilterinterceptor.
Enabling GZIP decompression sets an upper limit on the number of bytes the GZIPDecodingInterceptor can extract from the compressed message body. The default limit is 10,000,000.
2.11.4.2. Server-side GZIP Configuration Copy linkLink copied to clipboard!
You can enable the interceptors by including their class names in the javax.ws.rs.ext.Providers file on the class path. The upper limit on deflated files is set using the web application context parameter resteasy.gzip.max.input. If this limit is exceeded on the server side, GZIPDecodingInterceptor returns a response with status 413 - Request Entity Too Large and a message specifying the upper limit.
2.11.4.2.1. Client-side GZIP Configuration Copy linkLink copied to clipboard!
You can enable the GZIP interceptors by registering them with, for example, a Client or WebTarget. For example:
Client client = new ResteasyClientBuilder() // Activate gzip compression on client:
.register(AcceptEncodingGZIPFilter.class)
.register(GZIPDecodingInterceptor.class)
.register(GZIPEncodingInterceptor.class)
.build();
Client client = new ResteasyClientBuilder() // Activate gzip compression on client:
.register(AcceptEncodingGZIPFilter.class)
.register(GZIPDecodingInterceptor.class)
.register(GZIPEncodingInterceptor.class)
.build();
You can configure the upper limit on deflated files by creating an instance of GZIPDecodingInterceptor with a specific value:
Client client = new ResteasyClientBuilder() // Activate gzip compression on client:
.register(AcceptEncodingGZIPFilter.class)
.register(new GZIPDecodingInterceptor(256))
.register(GZIPEncodingInterceptor.class)
.build();
Client client = new ResteasyClientBuilder() // Activate gzip compression on client:
.register(AcceptEncodingGZIPFilter.class)
.register(new GZIPDecodingInterceptor(256))
.register(GZIPEncodingInterceptor.class)
.build();
If the upper limit is exceeded on the client side, GZIPDecodingInterceptor throws a ProcessingException with a message specifying the upper limit.
2.11.5. Per-Resource Method Filters and Interceptors Copy linkLink copied to clipboard!
Sometimes you want a filter or interceptor to only run for a specific resource method. You can do this in two different ways:
Implement the DynamicFeature Interface
The DynamicFeature interface includes a callback method, configure(ResourceInfo resourceInfo, FeatureContext context), which is invoked for each and every deployed JAX-RS method. The ResourceInfo parameter contains information about the current JAX-RS method being deployed. FeatureContext is an extension of the Configurable interface. You can use the register() method of this parameter to bind the filters and interceptors that you want to assign to this method.
Example: Using the DynamicFeature Interface
In the example above, the provider that you register using AnimalTypeFeature must implement one of the interfaces. This example registers the provider AnimalFilter that must implement one of the following interfaces: ContainerRequestFilter, ContainerResponseFilter, ReaderInterceptor, WriterInterceptor, or Feature. In this case AnimalFilter will be applied to all resource methods annotated with GET annotation. See DynamicFeature Documentation for details.
Use the @NameBinding Annotation
@NameBinding works a lot like CDI interceptors. You annotate a custom annotation with @NameBinding and then apply that custom annotation to your filter and resource method.
Example: Using @NameBinding
See NameBinding Documentation for details.
2.11.6. Ordering Copy linkLink copied to clipboard!
Ordering is accomplished by using the @Priority annotation on your filter or interceptor class.
2.11.7. Exception Handling with Filters and Interceptors Copy linkLink copied to clipboard!
Exceptions associated with filters or interceptors can occur on either the client side or the server side. On the client side, there are two types of exceptions you will have to handle: javax.ws.rs.client.ProcessingException and javax.ws.rs.client.ResponseProcessingException. A javax.ws.rs.client.ProcessingException will be thrown on the client side if there was an error before a request is sent to the server. A javax.ws.rs.client.ResponseProcessingException will be thrown on the client side if there was an error in processing the response received by the client from the server.
On the server side, exceptions thrown by filters or interceptors are handled in the same way as other exceptions thrown from JAX-RS methods, which tries to find an ExceptionMapper for the exception being thrown. More details on how exceptions are handled in JAX-RS methods can be found in the Exception Handling section.
2.12. Logging RESTEasy Providers and Interceptors Copy linkLink copied to clipboard!
RESTEasy logs the used providers and interceptors in the DEBUG level of logging. You can use the following management CLI commands to enable all the log levels related to RESTEasy:
2.13. Exception Handling Copy linkLink copied to clipboard!
2.13.1. Creating an Exception Mapper Copy linkLink copied to clipboard!
Exception mappers are custom components provided by applications that catch thrown exceptions and write specific HTTP responses.
When you create an exception mapper, you create a class that is annotated with the @Provider annotation and implements the ExceptionMapper interface.
An example exception mapper is provided below:
To register an exception mapper, list it in the web.xml file, under the resteasy.providers context-param, or register it programmatically through the ResteasyProviderFactory class.
2.13.2. Managing Internally Thrown Exceptions Copy linkLink copied to clipboard!
| Exception | HTTP Code | Description |
|---|---|---|
| BadRequestException | 400 | Bad Request. The request was not formatted correctly, or there was a problem processing the request input. |
| UnauthorizedException | 401 | Unauthorized. Security exception thrown if you are using RESTEasy’s annotation-based role-based security. |
| InternalServerErrorException | 500 | Internal Server Error. |
| MethodNotAllowedException | 405 | There is no JAX-RS method for the resource to handle the invoked HTTP operation. |
| NotAcceptableException | 406 | There is no JAX-RS method that can produce the media types listed in the Accept header. |
| NotFoundException | 404 | There is no JAX-RS method that serves the request path/resource. |
| ReaderException | 400 | All exceptions thrown from MessageBodyReaders are wrapped within this exception. If there is no ExceptionMapper for the wrapped exception, or if the exception is not a WebApplicationException, then by default, RESTEasy returns a 400 code. |
| WriterException | 500 | All exceptions thrown from MessageBodyWriters are wrapped within this exception. If there is no ExceptionMapper for the wrapped exception, or if the exception is not a WebApplicationException, then by default, RESTEasy returns a 400 code. |
| JAXBUnmarshalException | 400 | The JAXB providers (XML and Jackson) throw this exception on reads which might wrap JAXBExceptions. This class extends ReaderException. |
| JAXBMarshalException | 500 | The JAXB providers (XML and Jackson) throw this exception on writes which might wrap JAXBExceptions. This class extends WriterException. |
| ApplicationException | N/A | Wraps all exceptions thrown from application code, and it functions in the same way as InvocationTargetException. If there is an ExceptionMapper for wrapped exception, then that is used to handle the request. |
| Failure | N/A | Internal RESTEasy error. Not logged. |
| LoggableFailure | N/A | Internal RESTEasy error. Logged. |
| DefaultOptionsMethodException | N/A |
If the user invokes |
| UnrecognizedPropertyExceptionHandler | 400 | RESTEasy Jackson provider throws this exception when JSON data is determined to be invalid. |
2.14. Securing JAX-RS Web Services Copy linkLink copied to clipboard!
RESTEasy supports the @RolesAllowed, @PermitAll, and @DenyAll annotations on JAX-RS methods. However, you must enable role-based security in order for these annotations to be recognized.
2.14.1. Enable Role-Based Security Copy linkLink copied to clipboard!
Follow these steps to configure the web.xml file to enable role-based security.
Do not activate role-based security if the application uses EJBs. The EJB container will provide the functionality, instead of RESTEasy.
Enable Role-Based Security for a RESTEasy JAX-RS Web Service
-
Open the
web.xmlfile for the application in a text editor. Add the following
<context-param>to the file, within the<web-app>tags.<context-param> <param-name>resteasy.role.based.security</param-name> <param-value>true</param-value> </context-param>
<context-param> <param-name>resteasy.role.based.security</param-name> <param-value>true</param-value> </context-param>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Declare all roles used within the RESTEasy JAX-RS WAR file, using the
<security-role>tags.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Authorize access to all URLs handled by the JAX-RS runtime for all roles.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Define the appropriate login configuration for this application.
<login-config> <auth-method>BASIC</auth-method> <realm-name>jaxrs</realm-name> </login-config>
<login-config> <auth-method>BASIC</auth-method> <realm-name>jaxrs</realm-name> </login-config>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Role-based security has been enabled within the application, with a set of defined roles.
Example: Role-Based Security Configuration
2.14.2. Securing JAX-RS Web Services Using Annotations Copy linkLink copied to clipboard!
To secure JAX-RS web services using an annotation, complete the following steps.
- Enable role-based security.
Add security annotations to the JAX-RS web service. RESTEasy supports the following annotations:
@RolesAllowed-
Defines which roles can access the method. All roles should be defined in the
web.xmlfile. @PermitAll-
Allows all roles defined in the
web.xmlfile to access the method. @DenyAll- Denies all access to the method.
Below is an example that uses the @RolesAllowed annotation to specify that the admin role can access the web service.
@RolesAllowed("admin")
@Path("/test")
public class TestService {
...
}
@RolesAllowed("admin")
@Path("/test")
public class TestService {
...
}
2.14.3. Setting Programmatic Security Copy linkLink copied to clipboard!
JAX-RS includes a programmatic API for gathering security information about a secured request. The javax.ws.rs.core.SecurityContext interface has a method for determining the identity of the user making the secured HTTP invocation. It also has a method that allows you to check whether or not the current user belongs to a certain role:
You can access a SecurityContext instance by injecting it into a field, setter method, or resource method parameter using the @Context annotation.
2.15. RESTEasy Asynchronous Job Service Copy linkLink copied to clipboard!
The RESTEasy Asynchronous Job Service is designed to add asynchronous behavior to the HTTP protocol. While HTTP is a synchronous protocol, it is aware of asynchronous invocations. The HTTP 1.1 response code 202 Accepted means that the server has received and accepted the response for processing, but the processing has not yet been completed. The Asynchronous Job Service builds around this.
2.15.1. Enabling the Asynchronous Job Service Copy linkLink copied to clipboard!
Enable the asynchronous job service in the web.xml file:
<context-param>
<param-name>resteasy.async.job.service.enabled</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>resteasy.async.job.service.enabled</param-name>
<param-value>true</param-value>
</context-param>
2.15.2. Configuring Asynchronous Jobs Copy linkLink copied to clipboard!
This section covers examples of the query parameters for asynchronous jobs with RESTEasy.
Role based security does not work with the Asynchronous Job Service as it cannot be implemented portably. If the Asynchronous Job Service is used, application security must be done through XML declarations in the web.xml file instead.
While GET, DELETE, and PUT methods can be invoked asynchronously, this breaks the HTTP 1.1 contract of these methods. While these invocations might not change the state of the resource if invoked more than once, they do change the state of the server as new job entries with each invocation.
The asynch query parameter is used to run invocations in the background. A 202 Accepted response is returned, as well as a location header with a URL pointing to where the response of the background method is located.
POST http://example.com/myservice?asynch=true
POST http://example.com/myservice?asynch=true
The example above returns a 202 Accepted response. It also returns a location header with a URL pointing to where the response of the background method is located. An example of the location header is shown below:
HTTP/1.1 202 Accepted Location: http://example.com/asynch/jobs/3332334
HTTP/1.1 202 Accepted
Location: http://example.com/asynch/jobs/3332334
The URI will take the form of:
/asynch/jobs/{job-id}?wait={milliseconds}|nowait=true
/asynch/jobs/{job-id}?wait={milliseconds}|nowait=true
GET, POST and DELETE operations can be performed on this URL.
-
GET returns the JAX-RS resource method invoked as a response if the job was completed. If the job has not been completed, the GET returns a
202 Acceptedresponse code. Invoking GET does not remove the job, so it can be called multiple times. - POST does a read of the job response and removes the job if it has been completed.
- DELETE is called to manually clean up the job queue.
When the job queue is full, it evicts the earliest job from memory automatically without needing to call DELETE.
The GET and POST operations allow for the maximum wait time to be defined, using the wait and nowait query parameters. If the wait parameter is not specified, the operation will default to nowait=true, and will not wait at all if the job is not complete. The wait parameter is defined in milliseconds.
POST http://example.com/asynch/jobs/122?wait=3000
POST http://example.com/asynch/jobs/122?wait=3000
RESTEasy supports fire and forget jobs, using the oneway query parameter.
POST http://example.com/myservice?oneway=true
POST http://example.com/myservice?oneway=true
The example above returns a 202 Accepted response, but no job is created.
The configuration parameters for the Asynchronous Job Service can be found in the RESTEasy Asynchronous Job Service Configuration Parameters section in the appendix.
2.16. RESTEasy JavaScript API Copy linkLink copied to clipboard!
2.16.1. About the RESTEasy JavaScript API Copy linkLink copied to clipboard!
RESTEasy can generate a JavaScript API that uses AJAX calls to invoke JAX-RS operations. Each JAX-RS resource class will generate a JavaScript object of the same name as the declaring class or interface. The JavaScript object contains each JAX-RS method as properties.
The following JavaScript code uses the JAX-RS API that was generated in the previous example.
var text = Foo.get({order: 'desc', 'X-Foo': 'hello', colour: 'blue', 'Foo-Cookie': 123987235444});
Foo.post({$entity: text});
var text = Foo.get({order: 'desc', 'X-Foo': 'hello', colour: 'blue', 'Foo-Cookie': 123987235444});
Foo.post({$entity: text});
Each JavaScript API method takes an optional object as single parameter where each property is a cookie, header, path, query or form parameter as identified by its name, or the API parameter properties. For details about the API parameter properties see RESTEasy Javascript API Parameters appendix.
2.16.1.1. Enable the RESTEasy JavaScript API Servlet Copy linkLink copied to clipboard!
The RESTEasy JavaScript API is disabled by default. Follow these steps to enable it by updating the web.xml file.
-
Open the
web.xmlfile of the application in a text editor. Add the following configuration to the file, inside the
web-apptags:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.16.1.2. Build AJAX Queries Copy linkLink copied to clipboard!
The RESTEasy JavaScript API can be used to manually construct requests. The following are some examples of this behavior.
Example: REST Object Used to Override RESTEasy JavaScript API Client Behavior
The REST object contains the following read-write properties:
-
apiURL: Set by default to the JAX-RS root URL. Used by every JavaScript client API functions when constructing the requests. -
log: Set tofunction(string)in order to receive RESTEasy client API logs. This is useful if you want to debug your client API and place the logs where you can see them.
Example: Class Using REST.Request() Method to Build Custom Requests
Chapter 3. Developing JAX-WS Web Services Copy linkLink copied to clipboard!
The Java API for XML-Based Web Services (JAX-WS) defines the mapping between WSDL and Java, as well as the classes to be used for accessing web services and publishing them. JBossWS implements the latest JAX-WS specification, which users can reference for any vendor-agnostic web service usage need.
3.1. Using JAX-WS Tools Copy linkLink copied to clipboard!
The following JAX-WS command-line tools are included with the JBoss EAP distribution. These tools can be used in a variety of ways for server and client-side development.
| Command | Description |
|---|---|
| Generates JAX-WS portable artifacts, and provides the abstract contract. Used for bottom-up development. | |
| Consumes the abstract contract (WSDL and Schema files), and produces artifacts for both a server and client. Used for top-down and client development. |
See JAX-WS Tools for more details on the usage of these tools.
3.1.1. Server-side Development Strategies Copy linkLink copied to clipboard!
When developing a web service endpoint on the server side, you have the option of starting from Java code, known as bottom-up development, or from the WSDL that defines your service, known as top-down development. If this is a new service, meaning that there is no existing contract, then the bottom-up approach is the fastest route; you only need to add a few annotations to your classes to get a service up and running. However, if you are developing a service with a contract already defined, it is far simpler to use the top-down approach, since the tool can generate the annotated code for you.
Bottom-up use cases:
- Exposing an already existing EJB3 bean as a web service.
- Providing a new service, and you want the contract to be generated for you.
Top-down use cases:
- Replacing the implementation of an existing web service, and you can not break compatibility with older clients.
- Exposing a service that conforms to a contract specified by a third party, for example, a vendor that calls you back using an already defined protocol.
- Creating a service that adheres to the XML Schema and WSDL you developed by hand up front.
Bottom-Up Strategy Using wsprovide
The bottom-up strategy involves developing the Java code for your service, and then annotating it using JAX-WS annotations. These annotations can be used to customize the contract that is generated for your service. For example, you can change the operation name to map to anything you like. However, all of the annotations have sensible defaults, so only the @WebService annotation is required.
This can be as simple as creating a single class:
A deployment can be built using this class, and it is the only Java code needed to deploy on JBossWS. The WSDL, and all other Java artifacts called wrapper classes will be generated for you at deploy time.
The primary purpose of the wsprovide tool is to generate portable JAX-WS artifacts. Additionally, it can be used to provide the WSDL file for your service. This can be obtained by invoking wsprovide using the -w option:
javac -d . Echo.java EAP_HOME/bin/wsprovide.sh --classpath=. -w echo.Echo
$ javac -d . Echo.java
$ EAP_HOME/bin/wsprovide.sh --classpath=. -w echo.Echo
Inspecting the WSDL reveals a service named EchoService:
<wsdl:service name="EchoService">
<wsdl:port name="EchoPort" binding="tns:EchoServiceSoapBinding">
<soap:address location="http://localhost:9090/EchoPort"/>
</wsdl:port>
</wsdl:service>
<wsdl:service name="EchoService">
<wsdl:port name="EchoPort" binding="tns:EchoServiceSoapBinding">
<soap:address location="http://localhost:9090/EchoPort"/>
</wsdl:port>
</wsdl:service>
As expected, this service defines an operation, echo:
When deploying you do not need to run this tool. You only need it for generating portable artifacts or the abstract contract for your service.
A POJO endpoint for the deployment can be created in a simple web.xml file:
The web.xml and the single Java class can now be used to create a WAR:
The WAR can then be deployed to JBoss EAP. This will internally invoke wsprovide, which will generate the WSDL. If the deployment was successful, and you are using the default settings, it should be available in the management console.
For a portable JAX-WS deployment, the wrapper classes generated earlier could be added to the deployment.
Top-Down Strategy Using wsconsume
The top-down development strategy begins with the abstract contract for the service, which includes the WSDL file and zero or more schema files. The wsconsume tool is then used to consume this contract, and produce annotated Java classes, and optionally sources, that define it.
wsconsume might have problems with symlinks on Unix systems.
Using the WSDL file from the bottom-up example, a new Java implementation that adheres to this service can be generated. The -k option is passed to wsconsume to preserve the Java source files that are generated, instead of providing just Java classes:
EAP_HOME/bin/wsconsume.sh -k EchoService.wsdl
$ EAP_HOME/bin/wsconsume.sh -k EchoService.wsdl
The following table shows the purpose of each generated file:
| File | Purpose |
|---|---|
| Echo.java | Service Endpoint Interface |
| EchoResponse.java | Wrapper bean for response message |
| EchoService.java | Used only by JAX-WS clients |
| Echo_Type.java | Wrapper bean for request message |
| ObjectFactory.java | JAXB XML Registry |
| package-info.java | Holder for JAXB package annotations |
Examining the service endpoint interface reveals annotations that are more explicit than in the class written by hand in the bottom-up example, however, these evaluate to the same contract.
The only missing piece, other than for packaging, is the implementation class, which can now be written using the above interface.
3.1.2. Client-side Development Strategies Copy linkLink copied to clipboard!
Before going in to detail on the client side, it is important to understand the decoupling concept that is central to web services. Web services are not the best fit for internal RPC, even though they can be used in this way. There are much better technologies for this, such as CORBA and RMI. Web services were designed specifically for interoperable coarse-grained correspondence. There is no expectation or guarantee that any party participating in a web service interaction will be at any particular location, running on any particular operating system, or written in any particular programming language. So because of this, it is important to clearly separate client and server implementations. The only thing they should have in common is the abstract contract definition. If, for whatever reason, your software does not adhere to this principal, then you should not be using web services. For the above reasons, the recommended methodology for developing a client is to follow the top-down approach, even if the client is running on the same server.
Top-Down Strategy Using wsconsume
This section repeats the process of the server-side top-down section, however, it uses a deployed WSDL. This is to retrieve the correct value for soap:address, shown below, which is computed at deploy time. This value can be edited manually in the WSDL if necessary, but you must take care to provide the correct path.
Example: soap:address in a Deployed WSDL
<wsdl:service name="EchoService">
<wsdl:port name="EchoPort" binding="tns:EchoServiceSoapBinding">
<soap:address location="http://localhost.localdomain:8080/echo/Echo"/>
</wsdl:port>
</wsdl:service>
<wsdl:service name="EchoService">
<wsdl:port name="EchoPort" binding="tns:EchoServiceSoapBinding">
<soap:address location="http://localhost.localdomain:8080/echo/Echo"/>
</wsdl:port>
</wsdl:service>
Use wsconsume to generate Java classes for the deployed WSDL.
EAP_HOME/bin/wsconsume.sh -k http://localhost:8080/echo/Echo?wsdl
$ EAP_HOME/bin/wsconsume.sh -k http://localhost:8080/echo/Echo?wsdl
Notice how the EchoService.java class stores the location from which the WSDL was obtained.
As you can see, this generated class extends the main client entry point in JAX-WS, javax.xml.ws.Service. While you can use Service directly, this is far simpler since it provides the configuration information for you. Note the getEchoPort() method, which returns an instance of our service endpoint interface. Any web service operation can then be called by just invoking a method on the returned interface.
Do not refer to a remote WSDL URL in a production application. This causes network I/O every time you instantiate the Service object. Instead, use the tool on a saved local copy, or use the URL version of the constructor to provide a new WSDL location.
Write and compile the client:
You can change the endpoint address of your operation at runtime, by setting the ENDPOINT_ADDRESS_PROPERTY as shown below:
3.2. JAX-WS Web Service Endpoints Copy linkLink copied to clipboard!
3.2.1. About JAX-WS Web Service Endpoints Copy linkLink copied to clipboard!
A JAX-WS web service endpoint is the server component of a web service. Clients and other web services communicate with it over the HTTP protocol using an XML language called Simple Object Access Protocol (SOAP). The endpoint itself is deployed into the JBoss EAP container.
WSDL descriptors can be created in one of the following two ways:
- Writing WSDL descriptors manually.
- Using JAX-WS annotations that create the WSDL descriptors automatically. This is the most common method for creating WSDL descriptors.
An endpoint implementation bean is annotated with JAX-WS annotations and deployed to the server. The server automatically generates and publishes the abstract contract in WSDL format for client consumption. All marshalling and unmarshalling is delegated to the Java Architecture for XML Binding (JAXB) service.
The endpoint itself might be a Plain Old Java Object (POJO) or a Java EE web application. You can also expose endpoints using an EJB3 stateless session bean. It is packaged into a web archive (WAR) file. The specification for packaging the endpoint, called a Java Service Endpoint (JSE) is defined in JSR-181.
Example: POJO Endpoint
Example: Web Services Endpoint
The following EJB3 stateless session bean exposes the same method on the remote interface as well as an endpoint operation.
Service Endpoint Interface
JAX-WS services typically implement a Java service endpoint interface (SEI), which might be mapped from a WSDL port type, either directly or using annotations. This SEI provides a high-level abstraction that hides the details between Java objects and their XML representations.
Endpoint Provider Interface
In some cases, JAX-WS services need the ability to operate at the XML message level. The endpoint Provider interface provides this functionality to the web services that implement it.
Consuming and Accessing the Endpoint
After you deploy your web service, you can consume the WSDL to create the component stubs which will be the basis for your application. Your application can then access the endpoint to do its work.
3.2.2. Developing and Deploying JAX-WS Web Service Endpoint Copy linkLink copied to clipboard!
A JAX-WS service endpoint is a server-side component that responds to requests from JAX-WS clients and publishes the WSDL definition for itself.
See the following quickstarts that ship with JBoss EAP for working examples of how to develop JAX-WS endpoint applications.
- jaxws-addressing
- jaxws-ejb
- jaxws-pojo
- jaxws-retail
- wsat-simple
- wsba-coordinator-completion-simple
- wsba-participant-completion-simple
Development Requirements
A web service must fulfill the requirements of the JAX-WS API and the JSR 181: Web Services Metadata for the Java Platform specification. A valid implementation meets the following requirements:
-
It contains a
javax.jws.WebServiceannotation. - All method parameters and return types are compatible with the JSR 222: JavaTM Architecture for XML Binding (JAXB) 2.0 specification.
The following is an example of a web service implementation that meets these requirements.
Example: Web Service Implementation
The following is an example of the DiscountRequest class that is used by the ProfileMgmtBean bean in the previous example. The annotations are included for verbosity. Typically, the JAXB defaults are reasonable and do not need to be specified.
Example: DiscountRequest Class
Packaging Your Deployment
The implementation class is wrapped in a JAR deployment. Any metadata required for deployment is taken from the annotations on the implementation class and the service endpoint interface. You can deploy the JAR using the management CLI or the management console, and the HTTP endpoint is created automatically.
The following listing shows an example of the structure for a JAR deployment of an EJB web service.
3.3. JAX-WS Web Service Clients Copy linkLink copied to clipboard!
3.3.1. Consume and Access a JAX-WS Web Service Copy linkLink copied to clipboard!
After creating a web service endpoint, either manually or using JAX-WS annotations, you can access its WSDL. This WSDL can be used to create the basic client application that will communicate with the web service. The process of generating Java code from the published WSDL is called consuming the web service. This happens in the following phases:
Create the Client Artifacts
Before you can create client artifacts, you need to create your WSDL contract. The following WSDL contract is used for the examples presented in the rest of this section.
The examples below rely on having this WSDL contract in the ProfileMgmtService.wsdl file.
If you use JAX-WS annotations to create your web service endpoint, the WSDL contract is generated automatically, and you only need its URL. You can find this URL in the Runtime tab of the management console after the endpoint is deployed by selecting the applicable server, then selecting Subsystems → Web Services → View.
The wsconsume.sh or wsconsume.bat tool is used to consume the abstract contract (WSDL) and produce annotated Java classes and optional sources that define it. The tool is located in the EAP_HOME/bin/ directory.
The following command generates the source .java files listed in the output, from the ProfileMgmtService.wsdl file. The sources use the directory structure of the package, which is specified with the -p switch.
Both .java source files and compiled .class files are generated into the output/ directory within the directory where you run the command.
| File | Description |
|---|---|
|
| Service endpoint interface. |
|
| Custom data type. |
|
| Custom data types. |
|
| JAXB XML registry. |
|
| JAXB package annotations. |
|
| Service factory. |
The wsconsume command generates all custom data types (JAXB annotated classes), the service endpoint interface, and a service factory class. These artifacts are used to build web service client implementations.
Construct a Service Stub
Web service clients use service stubs to abstract the details of a remote web service invocation. To a client application, a web service invocation looks like an invocation of any other business component. In this case the service endpoint interface acts as the business interface, and a service factory class is not used to construct it as a service stub.
The following example first creates a service factory using the WSDL location and the service name. Next, it uses the service endpoint interface created by wsconsume to build the service stub. Finally, the stub can be used just as any other business interface would be.
You can find the WSDL URL for your endpoint in the JBoss EAP management console. Select the Runtime tab, select your server, then under Subsystems, select Web Services and click View. Go to the Attributes tab to review the deployment details.
3.3.2. Develop a JAX-WS Client Application Copy linkLink copied to clipboard!
The client communicates with, and requests work from, the JAX-WS endpoint, which is deployed in the Java Enterprise Edition 7 container. For detailed information about the classes, methods, and other implementation details mentioned below, see the relevant sections of the Javadocs bundle included with JBoss EAP.
Overview
A Service is an abstraction which represents a WSDL service. A WSDL service is a collection of related ports, each of which includes a port type bound to a particular protocol and a particular endpoint address.
Usually, the Service is generated when the rest of the component stubs are generated from an existing WSDL contract. The WSDL contract is available via the WSDL URL of the deployed endpoint, or can be created from the endpoint source using the wsprovide tool in the EAP_HOME/bin/ directory.
This type of usage is referred to as the static use case. In this case, you create instances of the Service class which is created as one of the component stubs.
You can also create the service manually, using the Service.create method. This is referred to as the dynamic use case.
Usage
Static Use Case
The static use case for a JAX-WS client assumes that you already have a WSDL contract. This might be generated by an external tool or generated by using the correct JAX-WS annotations when you create your JAX-WS endpoint.
To generate your component stubs, you use the wsconsume tool included in EAP_HOME/bin. The tool takes the WSDL URL or file as a parameter, and generates multiple files, structured in a directory tree. The source and class files representing your Service are named _Service.java and _Service.class, respectively.
The generated implementation class has two public constructors, one with no arguments and one with two arguments. The two arguments represent the WSDL location (a java.net.URL) and the service name (a javax.xml.namespace.QName) respectively.
The no-argument constructor is the one used most often. In this case the WSDL location and service name are those found in the WSDL. These are set implicitly from the @WebServiceClient annotation that decorates the generated class.
For details about how to obtain a port from the service and how to invoke an operation on the port, see Dynamic Proxy. For details about how to work with the XML payload directly or with the XML representation of the entire SOAP message, see Dispatch.
Dynamic Use Case
In the dynamic case, no stubs are generated automatically. Instead, a web service client uses the Service.create method to create Service instances. The following code fragment illustrates this process.
URL wsdlLocation = new URL("http://example.org/my.wsdl");
QName serviceName = new QName("http://example.org/sample", "MyService");
Service service = Service.create(wsdlLocation, serviceName);
URL wsdlLocation = new URL("http://example.org/my.wsdl");
QName serviceName = new QName("http://example.org/sample", "MyService");
Service service = Service.create(wsdlLocation, serviceName);
Handler Resolver
JAX-WS provides a flexible plug-in framework for message processing modules, known as handlers. These handlers extend the capabilities of a JAX-WS runtime system. A Service instance provides access to a HandlerResolver via a pair of getHandlerResolver and setHandlerResolver methods that can configure a set of handlers on a per-service, per-port or per-protocol binding basis.
When a Service instance creates a proxy or a Dispatch instance, the handler resolver currently registered with the service creates the required handler chain. Subsequent changes to the handler resolver configured for a Service instance do not affect the handlers on previously created proxies or Dispatch instances.
Executor
Service instances can be configured with a java.util.concurrent.Executor. The Executor invokes any asynchronous callbacks requested by the application. The setExecutor and getExecutor methods of Service can modify and retrieve the Executor configured for a service.
Dynamic Proxy
A dynamic proxy is an instance of a client proxy using one of the getPort methods provided in the Service. The portName specifies the name of the WSDL port the service uses. The serviceEndpointInterface specifies the service endpoint interface supported by the created dynamic proxy instance.
public <T> T getPort(QName portName, Class<T> serviceEndpointInterface) public <T> T getPort(Class<T> serviceEndpointInterface)
public <T> T getPort(QName portName, Class<T> serviceEndpointInterface)
public <T> T getPort(Class<T> serviceEndpointInterface)
The Service Endpoint Interface is usually generated using the wsconsume tool, which parses the WSDL and creates Java classes from it.
A typed method, which returns a port, is also provided. These methods also return dynamic proxies that implement the SEI. See the following example.
@WebServiceRef
The @WebServiceRef annotation declares a reference to a web service. It follows the resource pattern shown by the javax.annotation.Resource annotation defined in JSR 250.
-
You can use it to define a reference whose type is a generated
Serviceclass. In this case, the type and value element each refer to the generatedServiceclass type. Moreover, if the reference type can be inferred by the field or method declaration the annotation is applied to, the type and value elements might, but are not required to, have the default value ofObject.class. If the type cannot be inferred, then at least the type element must be present with a non-default value. You can use it to define a reference whose type is an SEI. In this case, the type element might (but is not required to) be present with its default value if the type of the reference can be inferred from the annotated field or method declaration. However, the value element must always be present and refer to a generated service class type, which is a subtype of
javax.xml.ws.Service. ThewsdlLocationelement, if present, overrides the WSDL location information specified in the@WebServiceannotation of the referenced generated service class.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Dispatch
XML web services use XML messages for communication between the endpoint, which is deployed in the Java EE container, and any clients. The XML messages use an XML language called Simple Object Access Protocol (SOAP). The JAX-WS API provides the mechanisms for the endpoint and clients to each be able to send and receive SOAP messages. Marshalling is the process of converting a Java Object into a SOAP XML message. Unmarshalling is the process of converting the SOAP XML message back into a Java Object.
In some cases, you need access to the raw SOAP messages themselves, rather than the result of the conversion. The Dispatch class provides this functionality. Dispatch operates in one of two usage modes, which are identified by one of the following constants.
-
javax.xml.ws.Service.Mode.MESSAGE- This mode directs client applications to work directly with protocol-specific message structures. When used with a SOAP protocol binding, a client application works directly with a SOAP message. -
javax.xml.ws.Service.Mode.PAYLOAD- This mode causes the client to work with the payload itself. For instance, if it is used with a SOAP protocol binding, a client application would work with the contents of the SOAP body rather than the entire SOAP message.
Dispatch is a low-level API which requires clients to structure messages or payloads as XML, with strict adherence to the standards of the individual protocol and a detailed knowledge of message or payload structure. Dispatch is a generic class which supports input and output of messages or message payloads of any type.
Asynchronous Invocations
The BindingProvider interface represents a component that provides a protocol binding which clients can use. It is implemented by proxies and is extended by the Dispatch interface.
BindingProvider instances might provide asynchronous operation capabilities. Asynchronous operation invocations are decoupled from the BindingProvider instance at invocation time. The response context is not updated when the operation completes. Instead, a separate response context is made available using the Response interface.
@Oneway Invocations
The @Oneway annotation indicates that the given web method takes an input message but returns no output message. Usually, a @Oneway method returns the thread of control to the calling application before the business method is executed.
Timeout Configuration
Two different properties control the timeout behavior of the HTTP connection and the timeout of a client which is waiting to receive a message. The first is javax.xml.ws.client.connectionTimeout and the second is javax.xml.ws.client.receiveTimeout. Each is expressed in milliseconds, and the correct syntax is shown below.
3.4. Configuring the Web Services Subsystem Copy linkLink copied to clipboard!
JBossWS components handle the processing of web service endpoints and are provided to JBoss EAP through the webservices subsystem. The subsystem supports the configuration of published endpoint addresses and endpoint handler chains.
A default webservices subsystem is provided in the server’s domain and standalone configuration files. It contains several predefined endpoint and client configurations.
3.4.1. Endpoint Configurations Copy linkLink copied to clipboard!
JBossWS enables extra setup configuration data to be predefined and associated with an endpoint implementation. Predefined endpoint configurations can be used for JAX-WS client and JAX-WS endpoint setup. Endpoint configurations can include JAX-WS handlers and key/value properties declarations. This feature provides a convenient way to add handlers to web service endpoints and to set key/value properties that control JBossWS and Apache CXF internals.
The webservices subsystem allows you to define named sets of endpoint configuration data. Each endpoint configuration must have a unique name within the subsystem. The org.jboss.ws.api.annotation.EndpointConfig annotation can then be used to assign an endpoint configuration to a JAX-WS implementation in a deployed application. See Assigning a Configuration for more information on assigning endpoint configurations.
There are two predefined endpoint configurations in the default JBoss EAP configuration:
-
Standard-Endpoint-Configis the endpoint configuration used for any endpoint that does not have an explicitly-assigned endpoint configuration. -
Recording-Endpoint-Configis an example of custom endpoint configuration that includes a recording handler.
Add an Endpoint Configuration
You can add a new endpoint configuration using the management CLI.
/subsystem=webservices/endpoint-config=My-Endpoint-Config:add
/subsystem=webservices/endpoint-config=My-Endpoint-Config:add
Configure an Endpoint Configuration
You can add key/value property declarations for the endpoint configuration using the management CLI.
/subsystem=webservices/endpoint-config=Standard-Endpoint-Config/property=PROPERTY_NAME:add(value=PROPERTY_VALUE)
/subsystem=webservices/endpoint-config=Standard-Endpoint-Config/property=PROPERTY_NAME:add(value=PROPERTY_VALUE)
You can also configure handler chains and handlers for these endpoint configurations.
Remove an Endpoint Configuration
You can remove a endpoint configuration using the management CLI.
/subsystem=webservices/endpoint-config=My-Endpoint-Config:remove
/subsystem=webservices/endpoint-config=My-Endpoint-Config:remove
3.4.2. Handler Chains Copy linkLink copied to clipboard!
Each endpoint configuration can be associated with PRE or POST handler chains. Each handler chain may include JAX-WS-compliant handlers to perform additional processing on messages. For outbound messages, PRE handler chain handlers are executed before any handler attached to the endpoints using standard JAX-WS means, such as the @HandlerChain annotation. POST handler chain handlers are executed after usual endpoint handlers. For inbound messages, the opposite applies.
Server Outbound Messages
Endpoint --> PRE Handlers --> Endpoint Handlers --> POST Handlers --> ... --> Client
Endpoint --> PRE Handlers --> Endpoint Handlers --> POST Handlers --> ... --> Client
Server Inbound Messages
Client --> ... --> POST Handlers --> Endpoint Handlers --> PRE Handlers --> Endpoint
Client --> ... --> POST Handlers --> Endpoint Handlers --> PRE Handlers --> Endpoint
Add a Handler Chain
You can add a POST handler chain to an endpoint configuration using the following management CLI command.
/subsystem=webservices/endpoint-config=My-Endpoint-Config/post-handler-chain=my-post-handler-chain:add
/subsystem=webservices/endpoint-config=My-Endpoint-Config/post-handler-chain=my-post-handler-chain:add
You can add a PRE handler chain to an endpoint configuration using the following management CLI command.
/subsystem=webservices/endpoint-config=My-Endpoint-Config/pre-handler-chain=my-pre-handler-chain:add
/subsystem=webservices/endpoint-config=My-Endpoint-Config/pre-handler-chain=my-pre-handler-chain:add
Configure a Handler Chain
Use the protocol-bindings attribute to set which protocols trigger the handler chain to start.
/subsystem=webservices/endpoint-config=My-Endpoint-Config/post-handler-chain=my-post-handler-chain:write-attribute(name=protocol-bindings,value=##SOAP11_HTTP)
/subsystem=webservices/endpoint-config=My-Endpoint-Config/post-handler-chain=my-post-handler-chain:write-attribute(name=protocol-bindings,value=##SOAP11_HTTP)
See the handlers section for information on configuring handlers for a handler chain.
Remove a Handler Chain
You can remove a handler chain using the management CLI.
/subsystem=webservices/endpoint-config=My-Endpoint-Config/post-handler-chain=my-post-handler-chain:remove
/subsystem=webservices/endpoint-config=My-Endpoint-Config/post-handler-chain=my-post-handler-chain:remove
3.4.3. Handlers Copy linkLink copied to clipboard!
A JAX-WS handler is added to a handler chain and specifies the fully-qualified name of the handler class. When the endpoint is deployed, an instance of that class is created for each referencing deployment. Either the deployment class loader or the class loader for the org.jboss.as.webservices.server.integration module must be able to load the handler class.
See the Handler Javadocs for a listing of the available handlers.
Add a Handler
You can add a handler to a handler chain using the following management CLI command. You must provide the class name of the handler.
/subsystem=webservices/endpoint-config=My-Endpoint-Config/post-handler-chain=my-post-handler-chain/handler=my-handler:add(class="com.arjuna.webservices11.wsarj.handler.InstanceIdentifierInHandler")
/subsystem=webservices/endpoint-config=My-Endpoint-Config/post-handler-chain=my-post-handler-chain/handler=my-handler:add(class="com.arjuna.webservices11.wsarj.handler.InstanceIdentifierInHandler")
Configure a Handler
You can update the class for a handler using the management CLI.
/subsystem=webservices/endpoint-config=My-Endpoint-Config/post-handler-chain=my-post-handler-chain/handler=my-handler:add(class="org.jboss.ws.common.invocation.RecordingServerHandler")
/subsystem=webservices/endpoint-config=My-Endpoint-Config/post-handler-chain=my-post-handler-chain/handler=my-handler:add(class="org.jboss.ws.common.invocation.RecordingServerHandler")
Remove a Handler
You can remove a handler using the management CLI.
/subsystem=webservices/endpoint-config=My-Endpoint-Config/post-handler-chain=my-post-handler-chain/handler=my-handler:
/subsystem=webservices/endpoint-config=My-Endpoint-Config/post-handler-chain=my-post-handler-chain/handler=my-handler:
3.4.4. Published Endpoint Addresses Copy linkLink copied to clipboard!
The rewriting of the <soap:address> element of endpoints published in WSDL contracts is supported. This feature is useful for controlling the server address that is advertised to clients for each endpoint.
The following table lists the attributes that can be configured for this feature.
| Name | Description |
|---|---|
| modify-wsdl-address | This boolean enables and disables the address rewrite functionality.
When
When
When the content of
When |
| wsdl-host |
The host name or IP address to be used for rewriting |
| wsdl-path-rewrite-rule |
This string defines a SED substitution command, for example |
| wsdl-port | Set this property to explicitly define the HTTP port that will be used for rewriting the SOAP address. Otherwise the HTTP port will be identified by querying the list of installed HTTP connectors. |
| wsdl-secure-port | Set this property to explicitly define the HTTPS port that will be used for rewriting the SOAP address. Otherwise the HTTPS port will be identified by querying the list of installed HTTPS connectors. |
| wsdl-uri-scheme |
This property explicitly sets the URI scheme to use for rewriting |
You can use the management CLI to update these attributes. For example:
/subsystem=webservices:write-attribute(name=wsdl-uri-scheme, value=https)
/subsystem=webservices:write-attribute(name=wsdl-uri-scheme, value=https)
3.4.5. Viewing Runtime Information Copy linkLink copied to clipboard!
Each web service endpoint is exposed through the deployment that provides the endpoint implementation. Each endpoint can be queried as a deployment resource. Each web service endpoint specifies a web context and a WSDL URL. You can access this runtime information using the management CLI or the management console.
The following management CLI command shows the details of the TestService endpoint from the jaxws-samples-handlerchain.war deployment.
Using the include-runtime=true flag on the read-resource operation returns runtime statistics in the result. However, the collection of statistics for web service endpoints is disabled by default. You can enable statistics for web service endpoints using the following management CLI command.
/subsystem=webservices:write-attribute(name=statistics-enabled,value=true)
/subsystem=webservices:write-attribute(name=statistics-enabled,value=true)
You can also view runtime information for web services endpoints from the Runtime tab of the management console. Select the server, then select Subsystems → Web Services → View. The runtime statistics are shown on the Statistics tab, and the endpoint details are shown on the Attributes tab.
3.5. Assigning Client and Endpoint Configurations Copy linkLink copied to clipboard!
Client and endpoint configurations can be assigned in the following ways:
- Explicit assignment through annotations, for endpoints, or API programmatic usage, for clients.
- Automatic assignment of configurations from default descriptors.
- Automatic assignment of configurations from the container.
3.5.1. Explicit Configuration Assignment Copy linkLink copied to clipboard!
The explicit configuration assignment is meant for developers that know in advance their endpoint or client has to be set up according to a specified configuration. The configuration is coming from either a descriptor that is included in the application deployment, or is included in the webservices subsystem.
3.5.1.1. Configuration Deployment Descriptor Copy linkLink copied to clipboard!
Java EE archives that can contain JAX-WS client and endpoint implementations may also contain predefined client and endpoint configuration declarations. All endpoint or client configuration definitions for a given archive must be provided in a single deployment descriptor file, which must be an implementation of the schema that can be found at EAP_HOME/docs/schema/jbossws-jaxws-config_4_0.xsd. Many endpoint or client configurations can be defined in the deployment descriptor file. Each configuration must have a name that is unique within the server on which the application is deployed. The configuration name cannot be referred to by endpoint or client implementations outside the application.
Example: Descriptor with Two Endpoint Configurations
Similarly, a client configuration can be specified in descriptors, which is still implementing the schema mentioned above:
3.5.1.2. Application Server Configuration Copy linkLink copied to clipboard!
JBoss EAP allows declaring JBossWS client and server predefined configurations in the webservices subsystem. As a result it is possible to declare server-wide handlers to be added to the chain of each endpoint or client assigned to a given configuration.
Standard Configuration
Clients running in the same JBoss EAP instance, as well as endpoints, are assigned standard configurations by default. The defaults are used unless different a configuration is set. This enables administrators to tune the default handler chains for client and endpoint configurations. The names of the default client and endpoint configurations used in the webservices subsystem are Standard-Client-Config and Standard-Endpoint-Config.
Handlers Classloading
When setting a server-wide handler, the handler class needs to be available through each ws deployment classloader. As a result proper module dependencies may need to be specified in the deployments that are going to use a given predefined configuration. One way to ensure the proper module dependencies are specified in the deployment is to add a dependency to the module containing the handler class in one of the modules which are already automatically set as dependencies to any deployment, for instance org.jboss.ws.spi.
Example Configuration
Example: Default Subsystem Configuration
A configuration file for a deployment specific ws-security endpoint setup:
JBoss EAP default configuration modified to default to SOAP messages schema-validation on:
3.5.1.3. EndpointConfig Annotation Copy linkLink copied to clipboard!
Once a configuration is available to a given application, the org.jboss.ws.api.annotation.EndpointConfig annotation is used to assign an endpoint configuration to a JAX-WS endpoint implementation. When you assign a configuration that is defined in the webservices subsystem, you only need to specify the configuration name. When you assign a configuration that is defined in the application, you need to specify the relative path to the deployment descriptor and the configuration name.
Example: EndpointConfig Annotation
3.5.1.4. JAX-WS Feature Copy linkLink copied to clipboard!
You can also use org.jboss.ws.api.configuration.ClientConfigFeature to set a configuration that is a JAX-WS Feature extension provided by JBossWS.
You can also set properties from the specified configuration by passing in true to the ClientConfigFeature constructor.
Endpoint port = service.getPort(Endpoint.class, new ClientConfigFeature("META-INF/my-client-config.xml", "Custom Client Config"), true);
Endpoint port = service.getPort(Endpoint.class, new ClientConfigFeature("META-INF/my-client-config.xml", "Custom Client Config"), true);
JBossWS parses the specified configuration file, after having resolved it as a resource using the current thread context class loader. The EAP_HOME/docs/schema/jbossws-jaxws-config_4_0.xsd schema defines the descriptor contents and is included in the jbossws-spi artifact.
If you pass in null for the configuration file, the configuration will be read from the current container configurations, if available.
Endpoint port = service.getPort(Endpoint.class, new ClientConfigFeature(null, "Container Custom Client Config"));
Endpoint port = service.getPort(Endpoint.class, new ClientConfigFeature(null, "Container Custom Client Config"));
3.5.1.5. Explicit Setup Through API Copy linkLink copied to clipboard!
Alternatively, the JBossWS API comes with facility classes that can be used for assigning configurations when building a client.
Handlers
JAX-WS handlers are read from client configurations as follows.
You can also use the ClientConfigUtil utility class to set up the handlers.
ClientConfigUtil.setConfigHandlers(bp, "META-INF/my-client-config.xml", "Custom Client Config");
ClientConfigUtil.setConfigHandlers(bp, "META-INF/my-client-config.xml", "Custom Client Config");
The default ClientConfigurer implementation parses the specified configuration file, after having resolved it as a resource using the current thread context class loader. The EAP_HOME/docs/schema/jbossws-jaxws-config_4_0.xsd schema defines the descriptor contents and is included in the jbossws-spi artifact.
If you pass in null for the configuration file, the configuration will be read from the current container configurations, if available.
ClientConfigurer configurer = ClientConfigUtil.resolveClientConfigurer(); configurer.setConfigHandlers(bp, null, "Container Custom Client Config");
ClientConfigurer configurer = ClientConfigUtil.resolveClientConfigurer();
configurer.setConfigHandlers(bp, null, "Container Custom Client Config");
Properties
Similarly, properties are read from client configurations as follows.
You can also use the ClientConfigUtil utility class to set up the properties.
ClientConfigurer configurer = ClientConfigUtil.resolveClientConfigurer(); configurer.setConfigProperties(port, "META-INF/my-client-config.xml", "Custom Client Config");
ClientConfigurer configurer = ClientConfigUtil.resolveClientConfigurer();
configurer.setConfigProperties(port, "META-INF/my-client-config.xml", "Custom Client Config");
The default ClientConfigurer implementation parses the specified configuration file, after having resolved it as a resource using the current thread context class loader. The EAP_HOME/docs/schema/jbossws-jaxws-config_4_0.xsd schema defines the descriptor contents and is included in the jbossws-spi artifact.
If you pass in null for the configuration file, the configuration will be read from the current container configurations, if available.
ClientConfigurer configurer = ClientConfigUtil.resolveClientConfigurer(); configurer.setConfigProperties(port, null, "Container Custom Client Config");
ClientConfigurer configurer = ClientConfigUtil.resolveClientConfigurer();
configurer.setConfigProperties(port, null, "Container Custom Client Config");
3.5.2. Automatic Configuration from Default Descriptors Copy linkLink copied to clipboard!
In some cases, the application developer might not be aware of the configuration that will need to be used for its client and endpoint implementation. In other cases, explicit usage of the JBossWS API might not be accepted because it is a compile-time dependency. To cope with such scenarios, JBossWS allows including default client, jaxws-client-config.xml, and endpoint, jaxws-endpoint-config.xml, descriptors within the application in its root directory. These are parsed for getting configurations whenever a configuration file name is not specified.
<config-file>WEB-INF/jaxws-endpoint-config.xml</config-file>
<config-file>WEB-INF/jaxws-endpoint-config.xml</config-file>
If the configuration name is not specified, JBossWS automatically looks for a configuration named as:
- The fully qualified name (FQN) of the endpoint implementation class, in case of JAX-WS endpoints.
- The FQN of the service endpoint interface, in case of JAX-WS clients.
No automatic configuration name is selected for Dispatch clients.
For example, an endpoint implementation class org.foo.bar.EndpointImpl, for which no predefined configuration is explicitly set, will cause JBossWS to look for a org.foo.bar.EndpointImpl named configuration within a jaxws-endpoint-config.xml descriptor in the root of the application deployment. Similarly, on the client side, a client proxy implementing org.foo.bar.Endpoint interface will have the setup read from a org.foo.bar.Endpoint named configuration in the jaxws-client-config.xml descriptor.
3.5.3. Automatic Configuration Assignment from Container Copy linkLink copied to clipboard!
JBossWS falls back to getting predefined configurations from the container whenever no explicit configuration has been provided and the default descriptors are either not available or do not contain relevant configurations. This behavior gives additional control on the JAX-WS client and endpoint setup to administrators since the container can be managed independently from the deployed applications.
JBossWS accesses the webservices subsystem for an explicitly named configuration. The default configuration names used are:
- The fully qualified name of the endpoint implementation class, in case of JAX-WS endpoints.
- The fully qualified name of the service endpoint interface, in case of JAX-WS clients.
Dispatch clients are not automatically configured. If no configuration is found using names computed as above, the Standard-Client-Config and Standard-Endpoint-Config configurations are used for clients and endpoints respectively.
3.6. Setting Module Dependencies for Web Service Applications Copy linkLink copied to clipboard!
JBoss EAP web services are delivered as a set of modules and libraries, including the org.jboss.as.webservices.* and org.jboss.ws.* modules. You should not need to change these modules.
With JBoss EAP you cannot directly use JBossWS implementation classes unless you explicitly set a dependency to the corresponding module. You declare the module dependencies that you want to be added to the deployment.
The JBossWS APIs are available by default whenever the webservices subsystem is available. You can use them without creating an explicit dependencies declaration for those modules.
3.6.1. Using MANIFEST.MF Copy linkLink copied to clipboard!
To configure deployment dependencies, add them to the MANIFEST.MF file. For example:
Manifest-Version: 1.0 Dependencies: org.jboss.ws.cxf.jbossws-cxf-client services export,foo.bar
Manifest-Version: 1.0
Dependencies: org.jboss.ws.cxf.jbossws-cxf-client services export,foo.bar
This MANIFEST.MF file declares dependencies on the org.jboss.ws.cxf.jbossws-cxf-client and foo.bar modules. For more information on declaring dependencies in a MANIFEST.MF file, including the export and services options, see Add a Dependency Configuration to MANIFEST.MF in the JBoss EAP Development Guide.
When using annotations on the endpoints and handlers, for example, Apache CXF endpoints and handlers, add the proper module dependency in your manifest file. If you skip this step, your annotations are not picked up and are completely, silently ignored.
3.6.1.1. Using JAXB Copy linkLink copied to clipboard!
To successfully and directly use JAXB contexts in your client or endpoint running in-container, set up a JAXB implementation. For example, set the following dependency:
Dependencies: com.sun.xml.bind services export
Dependencies: com.sun.xml.bind services export
3.6.1.2. Using Apache CXF Copy linkLink copied to clipboard!
To use Apache CXF APIs and implementation classes, add a dependency to the org.apache.cxf (API) module or org.apache.cxf.impl (implementation) module. For example:
Dependencies: org.apache.cxf services
Dependencies: org.apache.cxf services
The dependency is purely Apache CXF without any JBossWS customizations or additional extensions. For this reason, a client-side aggregation module is available with all the web service dependencies that you might need.
3.6.1.3. Client-side Web Services Aggregation Module Copy linkLink copied to clipboard!
When you want to use all of the web services features and functionality, you can set a dependency to the convenient client module. For example:
Dependencies: org.jboss.ws.cxf.jbossws-cxf-client services
Dependencies: org.jboss.ws.cxf.jbossws-cxf-client services
The services option is required to enable all JBossWS features by loading JBossWS specific classes. The services option is almost always needed when declaring dependencies on the org.jboss.ws.cxf.jbossws-cxf-client and org.apache.cxf modules. The option affects the loading of classes through the Service API, which is what is used to wire most of the JBossWS components and the Apache CXF Bus extensions.
3.6.1.4. Annotation Scanning Copy linkLink copied to clipboard!
The application server uses an annotation index for detecting JAX-WS endpoints in user deployments. When declaring web service endpoints for a class that belongs to a different module, for instance referring to it in the web.xml descriptor, use an annotations type dependency. Without that dependency your endpoints are ignored as they do not appear as annotated classes to the webservices subsystem.
Dependencies: my.org annotations
Dependencies: my.org annotations
3.6.2. Using jboss-deployment-structure.xml Copy linkLink copied to clipboard!
In some circumstances, the convenient approach of setting module dependencies in the MANIFEST.MF file might not work. For example, setting dependencies in the MANIFEST.MF file does not work when importing and exporting specific resources from a given module dependency. In these scenarios, add a jboss-deployment-structure.xml descriptor file to your deployment and set module dependencies in it.
For more information on using jboss-deployment-structure.xml, see Add a Dependency Configuration to the jboss-deployment-structure.xml in the JBoss EAP Development Guide.
3.7. Configuring HTTP Timeout Copy linkLink copied to clipboard!
The HTTP session timeout defines the period after which an HTTP session is considered to have become invalid because there was no activity within the specified period.
The HTTP session timeout can be configured, in order of precedence, in the following places:
Application
You can define the HTTP session timeout in the application’s
web.xmlconfiguration file by adding the following configuration to the file. This value is in minutes.<session-config> <session-timeout>30</session-timeout> </session-config>
<session-config> <session-timeout>30</session-timeout> </session-config>Copy to Clipboard Copied! Toggle word wrap Toggle overflow If you modified the WAR file, redeploy the application. If you exploded the WAR file, no further action is required because JBoss EAP automatically undeploys and redeploys the application.
Server
You can use the following management CLI command to set the default HTTP session timeout in the
undertowsubsystem. This value is in minutes./subsystem=undertow/servlet-container=default:write-attribute(name=default-session-timeout,value=30)
/subsystem=undertow/servlet-container=default:write-attribute(name=default-session-timeout,value=30)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Default
The default HTTP session timeout is 30 minutes.
3.8. Securing JAX-WS Web Services Copy linkLink copied to clipboard!
WS-Security provides the means to secure your services beyond transport level protocols such as HTTPS. Through a number of standards, such as headers defined in the WS-Security standard, you can:
- Pass authentication tokens between services.
- Encrypt messages or parts of messages.
- Sign messages.
- Timestamp messages.
WS-Security makes use of public and private key cryptography. With public key cryptography, a user has a pair of public and private keys. These are generated using a large prime number and a key function.
The keys are related mathematically, but cannot be derived from one another. With these keys we can encrypt messages. For example, if Scott wants to send a message to Adam, he can encrypt a message using his public key. Adam can then decrypt this message using his private key. Only Adam can decrypt this message as he is the only one with the private key.
Messages can also be signed. This allows you to ensure the authenticity of the message. If Adam wants to send a message to Scott, and Scott wants to be sure that it is from Adam, Adam can sign the message using his private key. Scott can then verify that the message is from Adam by using his public key.
3.8.1. Applying Web Services Security (WS-Security) Copy linkLink copied to clipboard!
Web services support many real-world scenarios requiring WS-Security functionality. These scenarios include signature and encryption support through X509 certificates, authentication and authorization through username tokens, and all WS-Security configurations covered by the WS-SecurityPolicy specification.
For other WS-* features, the core of WS-Security functionality is provided through the Apache CXF engine. In addition, the JBossWS integration adds a few configuration enhancements to simplify the setup of WS-Security enabled endpoints.
3.8.1.1. Apache CXF WS-Security Implementation Copy linkLink copied to clipboard!
Apache CXF features a WS-Security module that supports multiple configurations and is easily extendible.
The system is based on interceptors that delegate to Apache WSS4J for the low-level security operations. Interceptors can be configured in different ways, either through Spring configuration files or directly using the Apache CXF client API.
Recent versions of Apache CXF introduced support for WS-SecurityPolicy, which aims at moving most of the security configuration into the service contract, through policies, so that clients can be easily configured almost completely automatically from that. This way users do not need to manually deal with configuring and installing the required interceptors; the Apache CXF WS-Policy engine internally takes care of that instead.
3.8.1.2. WS-Security Policy Support Copy linkLink copied to clipboard!
WS-SecurityPolicy describes the actions that are required to securely communicate with a service advertised in a given WSDL contract. The WSDL bindings and operations reference WS-Policy fragments with the security requirements to interact with the service. The WS-SecurityPolicy specification allows for specifying things such as asymmetric and symmetric keys, using transports (HTTPS) for encryption, which parts or headers to encrypt or sign, whether to sign then encrypt or encrypt then sign, whether to include timestamps, whether to use derived keys, or something else.
However some mandatory configuration elements are not covered by WS-SecurityPolicy because they are not meant to be public or part of the published endpoint contract. These include things such as keystore locations, and usernames and passwords. Apache CXF allows configuring these elements either through Spring XML descriptors or using the client API or annotations.
| Configuration property | Description |
|---|---|
| ws-security.username |
The username used for |
| ws-security.password |
The password used for |
| ws-security.callback-handler |
The WSS4J security |
| ws-security.signature.properties | The properties file/object that contains the WSS4J properties for configuring the signature keystore and crypto objects. |
| ws-security.encryption.properties | The properties file/object that contains the WSS4J properties for configuring the encryption keystore and crypto objects. |
| ws-security.signature.username | The username or alias for the key in the signature keystore that will be used. If not specified, it uses the default alias set in the properties file. If that is also not set, and the keystore only contains a single key, that key will be used. |
| ws-security.encryption.username |
The username or alias for the key in the encryption keystore that will be used. If not specified, it uses the default alias set in the properties file. If that is also not set, and the keystore only contains a single key, that key will be used. For the web service provider, the |
| ws-security.signature.crypto |
Instead of specifying the signature properties, this can point to the full WSS4J |
| ws-security.encryption.crypto |
Instead of specifying the encryption properties, this can point to the full WSS4J |
| ws-security.enable.streaming | Enable streaming (StAX based) processing of WS-Security messages. |
3.8.2. WS-Trust Copy linkLink copied to clipboard!
WS-Trust is a web service specification that defines extensions to WS-Security. It is a general framework for implementing security in a distributed system. The standard is based on a centralized Security Token Service (STS), which is capable of authenticating clients and issuing tokens containing various types of authentication and authorization data. The specification describes a protocol used for issuance, exchange, and validation of security tokens. The following specifications play an important role in the WS-Trust architecture:
- WS-SecurityPolicy 1.2
- SAML 2.0
- Username Token Profile
- X.509 Token Profile
- SAML Token Profile
- Kerberos Token Profile
The WS-Trust extensions address the needs of applications that span multiple domains and requires the sharing of security keys. This occurs by providing a standards-based trusted third party web service (STS) to broker trust relationships between a web service requester and a web service provider. This architecture also alleviates the pain of service updates that require credential changes by providing a common location for this information. The STS is the common access point from which both the requester and provider retrieves and verifies security tokens.
There are three main components of the WS-Trust specification:
- The Security Token Service (STS) for issuing, renewing, and validating security tokens.
- The message formats for security token requests and responses.
- The mechanisms for key exchange.
The following section explains a basic WS-Trust scenario. For advanced scenarios, see Advanced WS-Trust Scenarios.
3.8.2.1. Scenario: Basic WS-Trust Copy linkLink copied to clipboard!
In this section we provide an example of a basic WS-Trust scenario. It comprises a web service requester (ws-requester), a web service provider (ws-provider), and a Security Token Service (STS).
The ws-provider requires SAML 2.0 token issued from a designated STS to be presented by the ws-requester using asymmetric binding. These communication requirements are declared in the WSDL of the ws-provider. STS requires ws-requester credentials to be provided in a WSS UsernameToken format request using symmetric binding. The response from STS is provided containing SAML 2.0 token. These communication requirements are declared in the WSDL of the STS.
-
The
ws-requestercontacts thews-providerand consumes its WSDL. On finding the security token issuer requirement, thews-requestercreates and configures theSTSClientwith the information required to generate a valid request. -
The
STSClientcontacts the STS and consumes its WSDL. The security policies are discovered. TheSTSClientcreates and sends an authentication request with appropriate credentials. - The STS verifies the credentials.
-
In response, the STS issues a security token that provides proof that the
ws-requesterhas authenticated with the STS. -
The
STSClientpresents a message with the security token to thews-provider. -
The
ws-providerverifies that the token was issued by the STS, and hence proves that thews-requesterhas successfully authenticated with the STS. -
The
ws-providerexecutes the requested service and returns the results to thews-requester.
3.8.2.2. Apache CXF Support Copy linkLink copied to clipboard!
Apache CXF is an open-source, fully-featured web services framework. The JBossWS open source project integrates the JBoss Web Services (JBossWS) stack with the Apache CXF project modules to provide WS-Trust and other JAX-WS functionality. This integration helps in easy deployment of Apache CXF STS implementations. The Apache CXF API also provides a STSClient utility to facilitate web service requester communication with its STS.
3.8.3. Security Token Service (STS) Copy linkLink copied to clipboard!
The Security Token Service (STS) is the core of the WS-Trust specification. It is a standards-based mechanism for authentication and authorization. The STS is an implementation of the WS-Trust specification’s protocol for issuing, exchanging, and validating security tokens, based on token format, namespace, or trust boundaries. The STS is a web service that acts as a trusted third party to broker trust relationships between a web service requester and a web service provider. It is a common access point trusted by both requester and provider to provide interoperable security tokens. It removes the need for a direct relationship between the requestor and provider. The STS helps ensure interoperability across realms and between different platforms because it is a standards-based mechanism for authentication.
The STS’s WSDL contract defines how other applications and processes interact with it. In particular, the WSDL defines the WS-Trust and WS-Security policies that a requester must fulfill to successfully communicate with the STS’s endpoints. A web service requester consumes the STS’s WSDL and, with the aid of an STSClient utility, generates a message request compliant with the stated security policies and submits it to the STS endpoint. The STS validates the request and returns an appropriate response.
3.8.3.1. Configuring a PicketLink WS-Trust Security Token Service (STS) Copy linkLink copied to clipboard!
PicketLink STS provides options for building an alternative to the Apache CXF Security Token Service implementation. You can also use PicketLink to configure SAML SSO for web applications. For more details on configuring SAML SSO using PicketLink, see How To Set Up SSO with SAML v2.
To set up an application to serve as a PicketLink WS-Trust STS, the following steps must be performed:
- Create a security domain for the WS-Trust STS application.
-
Configure the
web.xmlfile for the WS-Trust STS application. - Configure the authenticator for the WS-Trust STS application.
- Declare the necessary dependencies for the WS-Trust STS application.
- Configure the web-service portion of the WS-Trust STS application.
-
Create and configure a
picketlink.xmlfile for the WS-Trust STS application.
The security domain should be created and configured before creating and deploying the application.
3.8.3.1.1. Create a Security Domain for the STS Copy linkLink copied to clipboard!
The STS handles authentication of a principal based on the credentials provided and issues the proper security token based on that result. This requires that an identity store be configured via a security domain. The only requirement around creating this security domain and identity store is that it has authentication and authorization mechanisms properly defined. This means that many different identity stores, for example properties files, database, and LDAP, and their associated login modules could be used to support an STS application. For more information on security domains, see the Security Domains section of the JBoss EAP Security Architecture documentation.
In the below example, a simple UsersRoles login module using properties files for an identity store is used.
CLI Commands for Creating a Security Domain
/subsystem=security/security-domain=sts:add(cache-type=default)
/subsystem=security/security-domain=sts:add(cache-type=default)
/subsystem=security/security-domain=sts/authentication=classic:add
/subsystem=security/security-domain=sts/authentication=classic:add
/subsystem=security/security-domain=sts/authentication=classic/login-module=UsersRoles:add(code=UsersRoles,flag=required,module-options=[usersProperties=${jboss.server.config.dir}/sts-users.properties,rolesProperties=${jboss.server.config.dir}/sts-roles.properties])
/subsystem=security/security-domain=sts/authentication=classic/login-module=UsersRoles:add(code=UsersRoles,flag=required,module-options=[usersProperties=${jboss.server.config.dir}/sts-users.properties,rolesProperties=${jboss.server.config.dir}/sts-roles.properties])
reload
reload
Resulting XML
The management CLI commands shown assume that you are running a JBoss EAP standalone server. For more details on using the management CLI for a JBoss EAP managed domain, see the JBoss EAP Management CLI Guide.
Property Files
The UsersRoles login module utilizes properties files to store the user/password and user/role information. For more specifics of the UsersRoles module, please see the JBoss EAP Login Module Reference. In this example, the properties files contain the following:
Example: sts-users.properties File
Eric=samplePass Alan=samplePass
Eric=samplePass
Alan=samplePass
Example: sts-roles.properties File
Eric=All Alan=
Eric=All
Alan=
You also need to create a keystore for signing and encrypting the security tokens. This keystore will be used when configuring the picketlink.xml file.
3.8.3.1.2. Configure the web.xml File for the STS Copy linkLink copied to clipboard!
The web.xml file for an STS should contain the following:
-
A
<servlet>to enable the STS functionality and a<servlet-mapping>to map its URL. -
A
<security-constraint>with a<web-resource-collection>containing a<url-pattern>that maps to the URL pattern of the secured area. Optionally,<security-constraint>may also contain an<auth-constraint>stipulating the allowed roles. -
A
<login-config>configured for BASIC authentication. -
If any roles were specified in the
<auth-constraint>, those roles should be defined in a<security-role>.
Example web.xml file:
3.8.3.1.3. Configure the Authenticator for the STS Copy linkLink copied to clipboard!
The authenticator is responsible for the authentication of users for issuing and validating security tokens. The authenticator is configured by defining the security domain to be used in authenticating and authorizing principals.
The jboss-web.xml file should have the following:
-
A
<security-domain>to specify which security domain to use for authentication and authorization.
Example: jboss-web.xml File
<jboss-web> <security-domain>sts</security-domain> <context-root>SecureTokenService</context-root> </jboss-web>
<jboss-web>
<security-domain>sts</security-domain>
<context-root>SecureTokenService</context-root>
</jboss-web>
3.8.3.1.4. Declare the Necessary Dependencies for the STS Copy linkLink copied to clipboard!
The web application serving as the STS requires a dependency to be defined in the jboss-deployment-structure.xml file so that the org.picketlink classes can be located. As JBoss EAP provides all necessary org.picketlink and related classes, the application just needs to declare them as dependencies to use them.
Example: Using jboss-deployment-structure.xml to Declare Dependencies
3.8.3.1.5. Configure the Web-Service Portion of the STS Copy linkLink copied to clipboard!
The web application serving as the STS requires that you define a web-service for clients to call to obtain their security tokens. This requires that you define in your WSDL a service name called PicketLinkSTS, and a port called PicketLinkSTSPort. You can, however, change the SOAP address to better reflect your target deployment environment.
Example: PicketLinkSTS.wsdl File
In addition, you need a class for your web-service to use your WSDL:
Example: PicketLinkSTS Class
3.8.3.1.6. Create and Configure a picketlink.xml File for the STS Copy linkLink copied to clipboard!
The picketlink.xml file is responsible for the behavior of the authenticator and is loaded at the application’s startup.
The JBoss EAP Security Token Service defines several interfaces that provide extension points. Implementations can be plugged in and the default values can be specified for some properties using configuration. Similar to the IDP and SP configuration in How To Set Up SSO with SAML v2, all STS configurations are specified in the picketlink.xml file of the deployed application. The following are the elements that can be configured in the picketlink.xml file.
In the following text, a service provider refers to the web service that requires a security token to be presented by its clients.
<PicketLinkSTS>: This is the root element. It defines some properties that allow the STS administrator to set the following properties:-
STSName: A string representing the name of the security token service. If not specified, the defaultPicketLinkSTSvalue is used. -
TokenTimeout: The token lifetime value in seconds. If not specified, the default value of3600(one hour) is used. -
EncryptToken: A boolean specifying whether issued tokens are to be encrypted or not. The default value isfalse.
-
-
<KeyProvider>: This element and all its subelements are used to configure the keystore that are used by PicketLink STS to sign and encrypt tokens. Properties like the keystore location, its password, and the signing (private key) alias and password are all configured in this section. -
<TokenProviders>: This section specifies theTokenProviderimplementations that must be used to handle each type of security token. In the example we have two providers - one that handles tokens of typeSAMLV1.1and one that handles tokens of typeSAMLV2.0. TheWSTrustRequestHandlercalls thegetProviderForTokenType(String type)method ofSTSConfigurationto obtain a reference to the appropriateTokenProvider. -
<ServiceProviders>: This section specifies the token types that must be used for each service provider, the web service that requires a security token. When a WS-Trust request does not contain the token type, theWSTrustRequestHandlermust use the service provider endpoint to find out the type of the token that must be issued.
Example: picketlink.xml Configuration File
By default, the picketlink.xml file is located in the WEB-INF/classes directory of the STS web application. The PicketLink configuration file can also be loaded from the file system. To load the PicketLink configuration file from the file system, it must be named picketlink-sts.xml and be located in the ${user.home}/picketlink-store/sts/ directory.
Another working example of an STS can be found in the picketlink-sts quickstart that ships with JBoss EAP 7. For information about how to download and run the quickstarts, see Using the Quickstart Examples in the JBoss EAP Getting Started Guide.
3.8.3.2. Using a WS-Trust Security Token Service (STS) with a Client Copy linkLink copied to clipboard!
To configure a client to obtain a security token from the STS, you need to make use of the org.picketlink.identity.federation.api.wstrust.WSTrustClient class to connect to the STS and ask for a token to be issued.
First you need to instantiate the client:
Example: Creating a WSTrustClient
WSTrustClient client = new WSTrustClient("PicketLinkSTS", "PicketLinkSTSPort",
"http://localhost:8080/SecureTokenService/PicketLinkSTS",
new SecurityInfo(username, password));
WSTrustClient client = new WSTrustClient("PicketLinkSTS", "PicketLinkSTSPort",
"http://localhost:8080/SecureTokenService/PicketLinkSTS",
new SecurityInfo(username, password));
Next you need to use the WSTrustClient to ask for a token, for example a SAML assertion, to be issued:
Example: Obtaining an Assertion
Once you have the assertion, there are two ways by which it can be included in and sent via the SOAP message:
The client can push the SAML2
Assertioninto the SOAPMessageContextunder the keyorg.picketlink.trust.saml.assertion. For example:bindingProvider.getRequestContext().put(SAML2Constants.SAML2_ASSERTION_PROPERTY, assertion);
bindingProvider.getRequestContext().put(SAML2Constants.SAML2_ASSERTION_PROPERTY, assertion);Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
The SAML2
Assertionis available as part of the JAAS subject on the security context. This can happen if there has been a JAAS interaction with the usage of PicketLink STS login modules.
3.8.3.3. STS Client Pooling Copy linkLink copied to clipboard!
The STS client pooling feature is NOT supported in JBoss EAP.
STS client pooling is a feature that allows you to configure a pool of STS clients on the server, thereby eliminating a possible bottleneck of STS client creation. Client pooling can be used for login modules that need an STS client to obtain SAML tickets. These include:
-
org.picketlink.identity.federation.core.wstrust.auth.STSIssuingLoginModule -
org.picketlink.identity.federation.core.wstrust.auth.STSValidatingLoginModule -
org.picketlink.trust.jbossws.jaas.JBWSTokenIssuingLoginModule
The default number of clients in the pool for each login module is configured using the initialNumberOfClients login module option.
The org.picketlink.identity.federation.bindings.stspool.STSClientPoolFactory class provides client pool functionality to applications.
Using STSClientPoolFactory
STS clients are inserted into subpools using their STSClientConfig configuration as a key. To insert an STS client into a subpool, you need to obtain the STSClientPool instance and then initialize a subpool based on the configuration. Optionally, you can specify the initial number of STS clients when initializing the pool, or you can rely on the default number.
Example: Inserting an STS Client into a Subpool
final STSClientPool pool = STSClientPoolFactory.getPoolInstance(); pool.createPool(20, stsClientConfig); final STSClient client = pool.getClient(stsClientConfig);
final STSClientPool pool = STSClientPoolFactory.getPoolInstance();
pool.createPool(20, stsClientConfig);
final STSClient client = pool.getClient(stsClientConfig);
When you are done with a client, you can return it to the pool by calling the returnClient() method.
Example: Returning an STS Client to the Subpool
pool.returnClient();
pool.returnClient();
Example: Checking If a Subpool Exists with a Given Configuration
if (! pool.configExists(stsClientConfig) {
pool.createPool(stsClientConfig);
}
if (! pool.configExists(stsClientConfig) {
pool.createPool(stsClientConfig);
}
If the picketlink-federation subsystem is enabled, all client pools created for a deployment are destroyed automatically during the undeploy process. To manually destroy a pool:
Example: Manually Destroying a Subpool
pool.destroyPool(stsClientConfig);
pool.destroyPool(stsClientConfig);
3.9. JAX-WS Logging Copy linkLink copied to clipboard!
You can handle logging for inbound and outbound messages using JAX-WS handlers or Apache CXF logging interceptors.
3.9.1. Using JAX-WS Handlers Copy linkLink copied to clipboard!
You can configure a JAX-WS handler to log messages that are passed to it. This approach is portable as the handler can be added to the desired client and endpoints programatically by using the @HandlerChain JAX-WS annotation.
The predefined client and endpoint configuration mechanism allows you to add the logging handler to any client and endpoint combination, or to only some of the clients and endpoints. To add the logging handler to only some of the clients or endpoints, use the @EndpointConfig annotation and the JBossWS API.
The org.jboss.ws.api.annotation.EndpointConfig annotation is used to assign an endpoint configuration to a JAX-WS endpoint implementation. When assigning a configuration that is defined in the webservices subsystem, only the configuration name is specified. When assigning a configuration that is defined in the application, the relative path to the deployment descriptor and the configuration name must be specified.
3.9.2. Using Apache CXF Logging Interceptors Copy linkLink copied to clipboard!
Apache CXF also comes with logging interceptors that can be used to log messages to the console, client log files, or server log files. Those interceptors can be added to client, endpoint, and buses in multiple ways, including:
System property
Setting the
org.apache.cxf.logging.enabledsystem property totruecauses the logging interceptors to be added to any bus instance being created on the JVM. You can also set the system property toprettyto output nicely-formatted XML output. You can use the following management CLI command to set this system property./system-property=org.apache.cxf.logging.enabled:add(value=true)
/system-property=org.apache.cxf.logging.enabled:add(value=true)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Manual interceptor addition
Logging interceptors can be selectively added to endpoints using the Apache CXF annotations
@org.apache.cxf.interceptor.InInterceptorsand@org.apache.cxf.interceptor.OutInterceptors. The same outcome is achieved on the client side by programmatically adding new instances of the logging interceptors to the client or the bus.
3.10. Enabling Web Services Addressing (WS-Addressing) Copy linkLink copied to clipboard!
Web Services Addressing, or WS-Addressing, provides a transport-neutral mechanism to address web services and their associated messages. To enable WS-Addressing, you must add the @Addressing annotation to the web service endpoint and then configure the client to access it.
The following examples assume your application has an existing JAX-WS service and client configuration. See the jaxws-addressing quickstart that ships with JBoss EAP for a complete working example.
Add the
@Addressingannotation to the application’s JAX-WS endpoint code.Example: JAX-WS Endpoint with @Addressing Annotation
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Update the JAX-WS client code to configure WS-Addressing.
Example: JAX-WS Client Configured for WS-Addressing
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
The client and endpoint now communicate using WS-Addressing.
3.11. Enabling Web Services Reliable Messaging Copy linkLink copied to clipboard!
Web Services Reliable Messaging (WS-Reliable Messaging) is implemented internally in Apache CXF. A set of interceptors interacts with the low-level requirements of the reliable messaging protocol.
To enable WS-Reliable Messaging, complete one of the following steps:
- Consume a WSDL contract that specifies proper WS-Reliable Messaging policies, assertions, or both.
- Manually add and configure the reliable messaging interceptors.
- Specify the reliable messaging policies in an optional CXF Spring XML descriptor.
- Specify the Apache CXF reliable messaging feature in an optional CXF Spring XML descriptor.
The first approach, which is the only portable approach, relies on the Apache CXF WS-Policy engine. The other approaches, which are proprietary, allow for fine-grained configuration of the protocol aspects that are not covered by the WS-Reliable Messaging Policy.
3.12. Specifying Web Services Policies Copy linkLink copied to clipboard!
Web Services Policies (WS-Policy) rely on the Apache CXF WS-Policy framework. This framework is compliant with the following specifications:
You can work with the policies in different ways, including:
- Add policy assertions to WSDL contracts and let the runtime consume the assertions and behave accordingly.
- Specify endpoint policy attachments using either CXF annotations or features.
- Use the Apache CXF policy framework to define custom assertions and complete other tasks.
3.13. Apache CXF Integration Copy linkLink copied to clipboard!
All JAX-WS functionality provided by JBossWS on top of JBoss EAP is currently served through a proper integration of the JBossWS stack with most of the Apache CXF project modules.
Apache CXF is an open source services framework. It allows building and developing services using front-end programming APIs, including JAX-WS, with services speaking a variety of protocols such as SOAP and XML/HTTP over a variety of transports such as HTTP and JMS.
The integration layer between JBossWS and Apache CXF is mainly meant for:
- Allowing use of standard web services APIs, including JAX-WS, on JBoss EAP; this is performed internally leveraging Apache CXF without requiring the user to deal with it;
- Allowing use of Apache CXF advanced features, including WS-*, on top of JBoss EAP without requiring the user to deal with, set up, or care about the required integration steps for running in such a container.
In support of those goals, the JBossWS integration with Apache CXF supports the JBossWS endpoint deployment mechanism and comes with many internal customizations on top of Apache CXF.
For more in-depth details on the Apache CXF architecture, refer to the Apache CXF official documentation.
3.13.1. Server-side Integration Customization Copy linkLink copied to clipboard!
The JBossWS server-side integration with Apache CXF takes care of internally creating proper Apache CXF structures for the provided web service deployment. If the deployment includes multiple endpoints, they will all exist within the same Apache CXF Bus, which is separate from other deployments' bus instances.
While JBossWS sets sensible defaults for most of the Apache CXF configuration options on the server side, users might want to fine-tune the Bus instance that is created for their deployment; a jboss-webservices.xml descriptor can be used for deployment-level customizations.
3.13.1.1. Deployment Descriptor Properties Copy linkLink copied to clipboard!
The jboss-webservices.xml descriptor can be used to provide property values.
JBossWS integration with Apache CXF comes with a set of allowed property names to control Apache CXF internals.
3.13.1.2. WorkQueue Configuration Copy linkLink copied to clipboard!
Apache CXF uses WorkQueue instances for dealing with some operations, for example @Oneway request processing. A WorkQueueManager is installed in the Bus as an extension and allows for adding or removing queues as well as controlling the existing ones.
On the server side, queues can be provided by using the cxf.queue.<queue-name>.* properties in jboss-webservices.xml. For example, you can use the cxf.queue.default.maxQueueSize property to configure the maximum queue size of the default WorkQueue. At the deployment time, the JBossWS integration can add new instances of AutomaticWorkQueueImpl to the currently configured WorkQueueManager. The properties below are used to fill in the AutomaticWorkQueueImpl constructor parameters:
| Property | Default Value |
|---|---|
| cxf.queue.<queue-name>.maxQueueSize | 256 |
| cxf.queue.<queue-name>.initialThreads | 0 |
| cxf.queue.<queue-name>.highWaterMark | 25 |
| cxf.queue.<queue-name>.lowWaterMark | 5 |
| cxf.queue.<queue-name>.dequeueTimeout | 120000 |
3.13.1.3. Policy Alternative Selector Copy linkLink copied to clipboard!
The Apache CXF policy engine supports different strategies to deal with policy alternatives. JBossWS integration currently defaults to the MaximalAlternativeSelector, but still allows for setting different selector implementation using the cxf.policy.alternativeSelector property in the jboss-webservices.xml file.
3.13.1.4. MBean Management Copy linkLink copied to clipboard!
Apache CXF allows you to manage its MBean objects that are installed into the JBoss EAP MBean server. You can enable this feature on a deployment basis through the cxf.management.enabled property in the jboss-webservices.xml file. You can also use the cxf.management.installResponseTimeInterceptors property to control installation of the CXF response time interceptors. These interceptors are added by default when enabling the MBean management, but it might not be required in some cases.
Example: MBean Management in the jboss-webservices.xml File
3.13.1.5. Schema Validation Copy linkLink copied to clipboard!
Apache CXF includes a feature for validating incoming and outgoing SOAP messages on both the client and the server side. The validation is performed against the relevant schema in the endpoint WSDL contract (server side) or the WSDL contract used for building up the service proxy (client side).
You can enable schema validation in any of the following ways:
In the JBoss EAP server configuration.
For example, the management CLI command below enables schema validation for the default
Standard-Endpoint-Configendpoint configuration./subsystem=webservices/endpoint-config=Standard-Endpoint-Config/property=schema-validation-enabled:add(value=true)
/subsystem=webservices/endpoint-config=Standard-Endpoint-Config/property=schema-validation-enabled:add(value=true)Copy to Clipboard Copied! Toggle word wrap Toggle overflow In a predefined client or endpoint configuration file.
You can associate any endpoint or client running in-container to a JBossWS predefined configuration by setting the
schema-validation-enabledproperty totruein the referenced configuration file.Programmatically on the client side.
On the client side, you can enable schema validation programmatically. For example:
((BindingProvider)proxy).getRequestContext().put("schema-validation-enabled", true);((BindingProvider)proxy).getRequestContext().put("schema-validation-enabled", true);Copy to Clipboard Copied! Toggle word wrap Toggle overflow Using the
@org.apache.cxf.annotations.SchemaValidationannotation on the server side.On the server side, you can use the
@org.apache.cxf.annotations.SchemaValidationannotation. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.13.1.6. Apache CXF Interceptors Copy linkLink copied to clipboard!
The jboss-webservices.xml descriptor enables specifying the cxf.interceptors.in and cxf.interceptors.out properties. These properties allow you to attach the declaring interceptors to the Bus instance that is created for serving the deployment.
Example: jboss-webservices.xml File
You can declare interceptors using one of the following approaches:
-
Annotation usage on endpoint classes, for example
@org.apache.cxf.interceptor.InInterceptoror@org.apache.cxf.interceptor.OutInterceptor. -
Direct API usage on the client side through the
org.apache.cxf.interceptor.InterceptorProviderinterface. - JBossWS descriptor usage.
Because Spring integration is no longer supported in JBoss EAP, the JBossWS integration uses the jaxws-endpoint-config.xml descriptor file to avoid requiring modifications to the actual client or endpoint code. You can declare interceptors within predefined client and endpoint configurations by specifying a list of interceptor class names for the cxf.interceptors.in and cxf.interceptors.out properties.
Example: jaxws-endpoint-config.xml File
A new instance of each specified interceptor class will be added to the client or endpoint to which the configuration is assigned. The interceptor classes must have a no-argument constructor.
3.13.1.7. Apache CXF Features Copy linkLink copied to clipboard!
The jboss-webservices.xml descriptor enables specifying the cxf.features property. This property allows you to declare features to be attached to any endpoint belonging to the Bus instance that is created for serving the deployment.
Example: jboss-webservices.xml File
You can declare features using one of the following approaches:
-
Annotation usage on endpoint classes, for example
@org.apache.cxf.feature.Features. -
Direct API usage on client side through extensions of the
org.apache.cxf.feature.AbstractFeatureclass. - JBossWS descriptor usage.
Since Spring integration is no longer supported in JBoss EAP, the JBossWS integration adds an additional descriptor, a jaxws-endpoint-config.xml file-based approach to avoid requiring modifications to the actual client or endpoint code. You can declare features within predefined client and endpoint configurations by specifying a list of feature class names for the cxf.features property.
Example: jaxws-endpoint-config.xml File
A new instance of each specified feature class will be added to the client or endpoint the configuration is assigned to. The feature classes must have a no-argument constructor.
3.13.1.8. Properties-Driven Bean Creation Copy linkLink copied to clipboard!
The Apache CXF Interceptors and Apache CXF Features sections explain how to declare CXF interceptors and features through properties either in a client or endpoint predefined configuration or in a jboss-webservices.xml descriptor. By only getting the feature or interceptor class name specified, the container tries to create a bean instance using the class default constructor. This sets a limitation on the feature or interceptor configuration, unless custom extensions of vanilla CXF classes are provided, with the default constructor setting properties before eventually using the super constructor.
To address this issue, JBossWS integration comes with a mechanism for configuring simple bean hierarchies when building them up from properties. Properties can have bean reference values, which are strings starting with ##. Property reference keys are used to specify the bean class name and the value for each attribute.
So for instance, the following properties result in the stack installing two feature instances:
| Key | Value |
|---|---|
| cxf.features | ##foo, ##bar |
| ##foo | org.jboss.Foo |
| ##foo.par | 34 |
| ##bar | org.jboss.Bar |
| ##bar.color | blue |
The same result can be created by the following code:
This mechanism assumes that the classes are valid beans with proper getter() and setter() methods. Value objects are cast to the correct primitive type by inspecting the class definition. Nested beans can also be configured.
Appendix A. Reference Material Copy linkLink copied to clipboard!
A.1. JAX-RS/RESTEasy Annotations Copy linkLink copied to clipboard!
| Annotation | Usage |
|---|---|
| Cache |
Set response |
| ClientInterceptor | Identifies an interceptor as a client-side interceptor. |
| ContentEncoding |
Meta annotation that specifies a |
| Context |
Allows you to specify instances of |
| CookieParam | Allows you to specify the value of a cookie or object representation of an HTTP request cookie into the method invocation. |
| DecorateTypes |
Must be placed on a |
| Decorator | Meta-annotation to be placed on another annotation that triggers decoration. |
| DefaultValue |
Can be combined with the other |
| DELETE |
An annotation that signifies that the method responds to HTTP |
| DoNotUseJAXBProvider |
Put this on a class or parameter when you do not want the JAXB |
| Encoded |
Can be used on a class, method, or param. By default, inject |
| Form | This can be used as a value object for incoming/outgoing request/responses. |
| Formatted | Format XML output with indentations and newlines. This is a JAXB Decorator. |
| GET |
An annotation that signifies that the method responds to HTTP |
| IgnoreMediaTypes | Placed on a type, method, parameter, or field to tell JAXRS not to use JAXB provider for a certain media type |
| ImageWriterParams |
An annotation that a resource class can use to pass parameters to the |
| Mapped |
A |
| MultipartForm | This can be used as a value object for incoming/outgoing request/responses of the multipart/form-data MIME type. |
| NoCache |
Set |
| NoJackson | Placed on class, parameter, field or method when you do not want the Jackson provider to be triggered. |
| PartType |
Must be used in conjunction with Multipart providers when writing out a List or Map as a |
| Path | This must exist either in the class or resource method. If it exists in both, the relative path to the resource method is a concatenation of the class and method. |
| PathParam | Allows you to map variable URI path fragments into a method call. |
| POST |
An annotation that signifies that the method responds to HTTP |
| Priority | An annotation to indicate what order a class should be used. Uses an integer parameter with a lower value signifying a higher priority. |
| Provider | Marks a class to be discoverable as a provider by JAX-RS runtime during a provider scanning phase. |
| PUT |
An annotation that signifies that the method responds to HTTP |
| QueryParam | Allows you to map URI query string parameter or URL form encoded parameter to the method invocation. |
| ServerInterceptor | Identifies an interceptor as a server-side interceptor. |
| StringParameterUnmarshallerBinder |
Meta-annotation to be placed on another annotation that triggers a |
| Stylesheet | Specifies an XML stylesheet header. |
| Wrapped | Put this on a method or parameter when you want to marshal or unmarshal a collection or array of JAXB objects. |
| WrappedMap | Put this on a method or parameter when you want to marshal or unmarshal a map of JAXB objects. |
| XmlHeader | Sets an XML header for the returned document. |
| XmlNsMap |
A |
| XopWithMultipartRelated | This annotation can be used to process/produce incoming/outgoing XOP messages (packaged as multipart/related) to/from JAXB annotated objects. |
A.2. RESTEasy Configuration Parameters Copy linkLink copied to clipboard!
| Option Name | Default Value | Description |
|---|---|---|
| resteasy.servlet.mapping.prefix | No default |
If the URL-pattern for the Resteasy servlet-mapping is not |
| resteasy.scan | false |
Automatically scan |
| resteasy.scan.providers | false |
Scan for |
| resteasy.scan.resources | false | Scan for JAX-RS resource classes. |
| resteasy.providers | no default |
A comma delimited list of fully qualified |
| resteasy.use.builtin.providers | true |
Whether or not to register default, built-in |
| resteasy.resources | No default | A comma delimited list of fully qualified JAX-RS resource class names you want to register. |
| resteasy.jndi.resources | No default | A comma delimited list of JNDI names which reference objects you want to register as JAX-RS resources. |
| javax.ws.rs.Application | No default |
Fully qualified name of |
| resteasy.media.type.mappings | No default |
Replaces the need for an |
| resteasy.language.mappings | No default |
Replaces the need for an |
| resteasy.document.expand.entity.references | false |
Whether to expand external entities or replace them with an empty string. In JBoss EAP, this parameter defaults to |
| resteasy.document.secure.processing.feature | true |
Impose security constraints in processing |
| resteasy.document.secure.disableDTDs | true |
Prohibit DTDs in |
| resteasy.wider.request.matching | true | Turn off class-level expression filtering as defined in the JAX-RS specification and instead match based on the full expression of each JAX-RS method. |
| resteasy.use.container.form.params | true |
Use the |
| resteasy.add.charset | true |
If a resource method returns a |
These parameters are configured in the WEB-INF/web.xml file.
In a Servlet 3.0 container, the resteasy.scan.* configurations in the web.xml file are ignored, and all JAX-RS annotated components will be automatically scanned.
For example, javax.ws.rs.Application parameter is configured within init-param of the servlet configuration:
For example, resteasy.document.expand.entity.references is configured within context-param:
<context-param>
<param-name>resteasy.document.expand.entity.references</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>resteasy.document.expand.entity.references</param-name>
<param-value>true</param-value>
</context-param>
Changing the default values of the following RESTEasy parameters may cause RESTEasy applications to be potentially vulnerable against XXE attacks:
- resteasy.document.expand.entity.references
- resteasy.document.secure.processing.feature
- resteasy.document.secure.disableDTDs
A.3. RESTEasy JavaScript API Parameters Copy linkLink copied to clipboard!
| Property | Default Value | Description |
|---|---|---|
| $entity |
The entity to send as a | |
| $contentType |
The MIME type of the body entity sent as the | |
| $accepts | */* |
The accepted MIME types sent as the |
| $callback |
Set to a function ( | |
| $apiURL | Set to the base URI of the JAX-RS endpoint, not including the last slash. | |
| $username | If username and password are set, they will be used for credentials for the request. | |
| $password | If username and password are set, they will be used for credentials for the request. |
A.4. REST.Request Class Members Copy linkLink copied to clipboard!
| Member | Description |
|---|---|
| execute(callback) | Executes the request with all the information set in the current object. The value is passed to the optional argument callback, not returned. |
| setAccepts(acceptHeader) |
Sets the |
| setCredentials(username, password) | Sets the request credentials. |
| setEntity(entity) | Sets the request entity. |
| setContentType(contentTypeHeader) |
Sets the |
| setURI(uri) | Sets the request URI. This should be an absolute URI. |
| setMethod(method) |
Sets the request method. Defaults to |
| setAsync(async) |
Controls whether the request should be asynchronous. Defaults to |
| addCookie(name, value) | Sets the given cookie in the current document when executing the request. This will be persistent in the browser. |
| addQueryParameter(name, value) | Adds a query parameter to the URI query part. |
| addMatrixParameter(name, value) | Adds a matrix parameter (path parameter) to the last path segment of the request URI. |
| addHeader(name, value) | Adds a request header. |
| addForm(name, value) | Adds a form. |
| addFormParameter(name, value) | Adds a form parameter. |
A.5. RESTEasy Asynchronous Job Service Configuration Parameters Copy linkLink copied to clipboard!
The table below details the configurable context-params for the Asynchronous Job Service. These parameters can be configured in the web.xml file.
| Parameter | Description |
|---|---|
| resteasy.async.job.service.max.job.results |
Number of job results that can be held in the memory at any one time. Default value is |
| resteasy.async.job.service.max.wait |
Maximum wait time on a job when a client is querying for it. Default value is |
| resteasy.async.job.service.thread.pool.size |
Thread pool size of the background threads that run the job. Default value is |
| resteasy.async.job.service.base.path |
Sets the base path for the job URIs. Default value is |
A.6. JAX-WS Tools Copy linkLink copied to clipboard!
wsconsume
wsconsume is a command-line tool provided with JBoss EAP that consumes a WSDL and produces portable JAX-WS service and client artifacts.
Usage
The wsconsume tool is located in the EAP_HOME/bin directory and uses the following syntax.
EAP_HOME/bin/wsconsume.sh [options] <wsdl-url>
EAP_HOME/bin/wsconsume.sh [options] <wsdl-url>
Use the wsconsume.bat script for Windows.
Example usage:
Generate Java class files from the
Example.wsdlWSDL fileEAP_HOME/bin/wsconsume.sh Example.wsdl
EAP_HOME/bin/wsconsume.sh Example.wsdlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Generate Java source and class files from the
Example.wsdlWSDL fileEAP_HOME/bin/wsconsume.sh -k Example.wsdl
EAP_HOME/bin/wsconsume.sh -k Example.wsdlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Generate Java source and class files in the
my.orgpackage from theExample.wsdlWSDL fileEAP_HOME/bin/wsconsume.sh -k -p my.org Example.wsdl
EAP_HOME/bin/wsconsume.sh -k -p my.org Example.wsdlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Generate Java source and class files using multiple binding files
EAP_HOME/bin/wsconsume.sh -k -b schema-binding1.xsd -b schema-binding2.xsd Example.wsdl
EAP_HOME/bin/wsconsume.sh -k -b schema-binding1.xsd -b schema-binding2.xsd Example.wsdlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Use the --help argument or see the below table for a listing of all available wsconsume options.
| Option | Description |
|---|---|
| -a, --additionalHeaders | Enable processing of implicit SOAP headers. |
| -b, --binding=<file> | One or more JAX-WS or JAXB binding files. |
| -c --catalog=<file> | Oasis XML Catalog file for entity resolution. |
| -d --encoding=<charset> | The charset encoding to use for generated sources. |
| -e, --extension | Enable SOAP 1.2 binding extension. |
| -h, --help | Show this help message. |
| -j --clientjar=<name> | Create a jar file of the generated artifacts for calling the web. service |
| -k, --keep | Keep/Generate Java source. |
| -l, --load-consumer | Load the consumer and exit (debug utility). |
| -n, --nocompile | Do not compile generated sources. |
| -o, --output=<directory> | The directory to put generated artifacts. |
| -p --package=<name> | The target package for generated source. |
| -q, --quiet | Be somewhat more quiet. |
| -s, --source=<directory> | The directory to put Java source. |
| -t, --target=<2.1|2.2> | The JAX-WS specification target. |
| -v, --verbose | Show full exception stack traces. |
| -w --wsdlLocation=<loc> |
Value to use for |
wsprovide
wsprovide is a command-line tool provided with JBoss EAP that generates portable JAX-WS artifacts for a service endpoint implementation. It also has the option to generate a WSDL file.
Usage
The wsprovide tool is located in the EAP_HOME/bin directory and uses the following syntax.
EAP_HOME/bin/wsprovide.sh [options] <endpoint class name>
EAP_HOME/bin/wsprovide.sh [options] <endpoint class name>
Use the wsprovide.bat script for Windows.
Example usage:
Generate wrapper classes for portable artifacts in the
outputdirectory.EAP_HOME/bin/wsprovide.sh -o output my.package.MyEndpoint
EAP_HOME/bin/wsprovide.sh -o output my.package.MyEndpointCopy to Clipboard Copied! Toggle word wrap Toggle overflow Generate wrapper classes and WSDL in the
outputdirectory.EAP_HOME/bin/wsprovide.sh -o output -w my.package.MyEndpoint
EAP_HOME/bin/wsprovide.sh -o output -w my.package.MyEndpointCopy to Clipboard Copied! Toggle word wrap Toggle overflow Generate wrapper classes in the
outputdirectory for an endpoint that references other JARs.EAP_HOME/bin/wsprovide.sh -o output -c myapplication1.jar:myapplication2.jar my.org.MyEndpoint
EAP_HOME/bin/wsprovide.sh -o output -c myapplication1.jar:myapplication2.jar my.org.MyEndpointCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Use the --help argument or see the below table for a listing of all available wsprovide options.
| Option | Description |
|---|---|
| -a, --address=<address> | The generated port soap:address in WSDL. |
| -c, --classpath=<path> | The classpath that contains the endpoint. |
| -e, --extension | Enable SOAP 1.2 binding extension. |
| -h, --help | Show this help message. |
| -k, --keep | Keep/Generate Java source. |
| -l, --load-provider | Load the provider and exit (debug utility). |
| -o, --output=<directory> | The directory to put generated artifacts. |
| -q, --quiet | Be somewhat more quiet. |
| -r, --resource=<directory> | The directory to put resource artifacts. |
| -s, --source=<directory> | The directory to put Java source. |
| -t, --show-traces | Show full exception stack traces. |
| -w, --wsdl | Enable WSDL file generation. |
A.7. JAX-WS Common API Reference Copy linkLink copied to clipboard!
Several JAX-WS development concepts are shared between web service endpoints and clients. These include the handler framework, message context, and fault handling.
Handler Framework
The handler framework is implemented by a JAX-WS protocol binding in the runtime of the client and the endpoint, which is the server component. Proxies and Dispatch instances, known collectively as binding providers, each use protocol bindings to bind their abstract functionality to specific protocols.
Client and server-side handlers are organized into an ordered list known as a handler chain. The handlers within a handler chain are invoked each time a message is sent or received. Inbound messages are processed by handlers before the binding provider processes them. Outbound messages are processed by handlers after the binding provider processes them.
Handlers are invoked with a message context which provides methods to access and modify inbound and outbound messages and to manage a set of properties. Message context properties facilitate communication between individual handlers, as well as between handlers and client and service implementations. Different types of handlers are invoked with different types of message contexts.
- Logical Handler
-
Logical handlers only operate on message context properties and message payloads. Logical handlers are protocol-independent and cannot affect protocol-specific parts of a message. Logical handlers implement interface
javax.xml.ws.handler.LogicalHandler. - Protocol Handler
-
Protocol handlers operate on message context properties and protocol-specific messages. Protocol handlers are specific to a particular protocol and may access and change protocol-specific aspects of a message. Protocol handlers implement any interface derived from
javax.xml.ws.handler.Handler, exceptjavax.xml.ws.handler.LogicalHandler. - Service Endpoint Handler
On a service endpoint, handlers are defined using the
@HandlerChainannotation. The location of the handler chain file can be either an absolutejava.net.URLinexternalFormor a relative path from the source file or class file.@WebService @HandlerChain(file = "jaxws-server-source-handlers.xml") public class SOAPEndpointSourceImpl { ... }@WebService @HandlerChain(file = "jaxws-server-source-handlers.xml") public class SOAPEndpointSourceImpl { ... }Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Service Client Handler
On a JAX-WS client, handlers are defined either by using the
@HandlerChainannotation, as in service endpoints, or dynamically, using the JAX-WS API.Copy to Clipboard Copied! Toggle word wrap Toggle overflow The call to the
setHandlerChainmethod is required.
Message Context
The MessageContext interface is the super interface for all JAX-WS message contexts. It extends Map<String,Object> with additional methods and constants to manage a set of properties that enable handlers in a handler chain to share processing related state. For example, a handler may use the put method to insert a property into the message context. One or more other handlers in the handler chain may subsequently obtain the message using the get method.
Properties are scoped as either APPLICATION or HANDLER. All properties are available to all handlers for an instance of a message exchange pattern (MEP) of a particular endpoint. For instance, if a logical handler puts a property into the message context, that property is also available to any protocol handlers in the chain during the execution of an MEP instance.
An asynchronous Message Exchange Pattern (MEP) allows for sending and receiving messages asynchronously at the HTTP connection level. You can enable it by setting additional properties in the request context.
Properties scoped at the APPLICATION level are also made available to client applications and service endpoint implementations. The defaultscope for a property is HANDLER.
Logical and SOAP messages use different contexts.
- Logical Message Context
-
When logical handlers are invoked, they receive a message context of type
LogicalMessageContext.LogicalMessageContextextendsMessageContextwith methods which obtain and modify the message payload. It does not provide access to the protocol-specific aspects of a message. A protocol binding defines which components of a message are available through a logical message context. A logical handler deployed in a SOAP binding can access the contents of the SOAP body but not the SOAP headers. On the other hand, the XML/HTTP binding defines that a logical handler can access the entire XML payload of a message. - SOAP Message Context
-
When SOAP handlers are invoked, they receive a
SOAPMessageContext.SOAPMessageContextextendsMessageContextwith methods which obtain and modify the SOAP message payload.
Fault Handling
An application may throw a SOAPFaultException or an application-specific user exception. In the case of the latter, the required fault wrapper beans are generated at runtime if they are not already part of the deployment.
public void throwApplicationException() throws UserException {
throw new UserException("validation", 123, "Some validation error");
}
public void throwApplicationException() throws UserException {
throw new UserException("validation", 123, "Some validation error");
}
JAX-WS Annotations
The annotations available by the JAX-WS API are defined in JSR-224. These annotations are in the javax.xml.ws package.
The annotations available by the JWS API are defined in JSR-181. These annotations are in the javax.jws package.
A.8. Advanced WS-Trust Scenarios Copy linkLink copied to clipboard!
A.8.1. Scenario: SAML Holder-Of-Key Assertion Scenario Copy linkLink copied to clipboard!
WS-Trust helps in managing software security tokens. A SAML assertion is a type of security token. In the Holder-Of-Key method, STS creates a SAML token containing the client’s public key and signs the SAML token with its private key. The client includes the SAML token and signs the outgoing soap envelope to the web service with its private key. The web service validates the SOAP message and SAML token.
Implementation of this scenario requires the following:
-
SAML tokens with a Holder-Of-Key subject confirmation method must be protected so the token cannot be snooped. In most cases, a Holder-Of-Key token combined with HTTPS is sufficient to prevent getting possession of the token. This means the security policy uses a
sp:TransportBindingandsp:HttpsToken. -
A Holder-Of-Key token has no encryption or signing keys associated with it, therefore a
sp:IssuedTokenofSymmetricKeyorPublicKeykeyType should be used with asp:SignedEndorsingSupportingTokens.
A.8.1.1. Web Service Provider Copy linkLink copied to clipboard!
This section lists the web service elements for the SAML Holder-Of-Key scenario. The components include:
A.8.1.1.1. Web Service Provider WSDL Copy linkLink copied to clipboard!
The Web Service Provider is a contract-first endpoint. All WS-trust and security policies for it are declared in the HolderOfKeyService.wsdl WSDL. For this scenario, a ws-requester is required to provide a SAML 2.0 token of SymmetricKey keyType, issued from a designated STS. The STS address is provided in the WSDL. A transport binding policy is used. The token is declared to be signed and endorsed, sp:SignedEndorsingSupportingTokens.
A detailed explanation of the security settings are provided in the comments in the following listing:
A.8.1.1.2. SSL Configuration Copy linkLink copied to clipboard!
This web service uses HTTPS, therefore the JBoss EAP server must be configured to provide SSL/TLS support in the undertow subsystem. There are two components for SSL/TLS configuration:
- Create a certificate keystore.
-
Declare an SSL connector in the
undertowsubsystem of the JBoss EAP server configuration file.
The following is an example of an SSL/TLS connector declaration:
Red Hat recommends that SSLv2, SSLv3, and TLSv1.0 be explicitly disabled in favor of TLSv1.1 or TLSv1.2 in all affected packages.
A.8.1.1.3. Web Service Provider Interface Copy linkLink copied to clipboard!
The web service provider interface HolderOfKeyIface class is a simple web service definition.
A.8.1.1.4. Web Service Provider Implementation Copy linkLink copied to clipboard!
The web service provider implementation HolderOfKeyImpl class is a simple POJO. It uses the standard WebService annotation to define the service endpoint. In addition there are two Apache CXF annotations, EndpointProperties and EndpointProperty used for configuring the endpoint for the Apache CXF runtime. These annotations come from the Apache WSS4J project, which provides a Java implementation of the primary WS-Security standards for web services. These annotations programmatically add properties to the endpoint. With plain Apache CXF, these properties are often set using the <jaxws:properties> element on the <jaxws:endpoint> element in the Spring configuration. These annotations allow the properties to be configured in the code.
WSS4J uses the Crypto interface to get keys and certificates for signature creation/verification, as asserted by the WSDL for this service. The WSS4J configuration information provided by HolderOfKeyImpl is for Crypto’s Merlin implementation.
The first EndpointProperty statement in the listing disables ensurance of compliance with the Basic Security Profile 1.1. The next EndpointProperty statements declares the Java properties file that contains the (Merlin) Crypto configuration information. The last EndpointProperty statement declares the STSHolderOfKeyCallbackHandler implementation class. It is used to obtain the user’s password for the certificates in the keystore file.
A.8.1.1.5. Crypto Properties and Keystore Files Copy linkLink copied to clipboard!
WSS4J’s Crypto implementation is loaded and configured using a Java properties file that contains Crypto configuration data. The file contains implementation-specific properties such as a keystore location, password, default alias and so on. This application uses the Merlin implementation. The serviceKeystore.properties file contains this information.
The servicestore.jks file is a Java KeyStore (JKS) repository. It contains self-signed certificates for myservicekey and mystskey.
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin org.apache.ws.security.crypto.merlin.keystore.type=jks org.apache.ws.security.crypto.merlin.keystore.password=sspass org.apache.ws.security.crypto.merlin.keystore.alias=myservicekey org.apache.ws.security.crypto.merlin.keystore.file=servicestore.jks
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=sspass
org.apache.ws.security.crypto.merlin.keystore.alias=myservicekey
org.apache.ws.security.crypto.merlin.keystore.file=servicestore.jks
A.8.1.1.6. Default MANIFEST.MF Copy linkLink copied to clipboard!
This application requires access to JBossWS and Apache CXF APIs provided in the org.jboss.ws.cxf.jbossws-cxf-client module. The dependency statement directs the server to provide them at deployment.
Manifest-Version: 1.0 Dependencies: org.jboss.ws.cxf.jbossws-cxf-client
Manifest-Version: 1.0
Dependencies: org.jboss.ws.cxf.jbossws-cxf-client
A.8.2. Scenario: SAML Bearer Assertion Copy linkLink copied to clipboard!
WS-Trust manages software security tokens. A SAML assertion is a type of security token. In the SAML Bearer scenario, the service provider automatically trusts that the incoming SOAP request came from the subject defined in the SAML token after the service verifies the token’s signature.
Implementation of this scenario has the following requirements.
-
SAML tokens with a
Bearersubject confirmation method must be protected so the token can not be snooped. In most cases, a bearer token combined with HTTPS is sufficient to prevent "a man in the middle" getting possession of the token. This means a security policy that uses asp:TransportBindingandsp:HttpsToken. -
A bearer token has no encryption or signing keys associated with it, therefore a
sp:IssuedTokenofbearerkeyType should be used with asp:SupportingTokenor asp:SignedSupportingTokens.
A.8.2.1. Web Service Provider Copy linkLink copied to clipboard!
This section examines the web service elements for the SAML Bearer scenario. The components include:
A.8.2.1.1. Bearer Web Service Provider WSDL Copy linkLink copied to clipboard!
The web service provider is a contract-first endpoint. All the WS-trust and security policies for it are declared in the BearerService.wsdl WSDL. For this scenario, a ws-requester is required to provide a SAML 2.0 Bearer token issued from a designated STS. The address of the STS is provided in the WSDL. HTTPS, a TransportBinding and HttpsToken policy are used to protect the SOAP body of messages that are sent between ws-requester and ws-provider. The security settings details are provided as comments in the following listing.
A.8.2.1.2. SSL Configuration Copy linkLink copied to clipboard!
This web service is using HTTPS, therefore the JBoss EAP server must be configured to provide SSL support in the undertow subsystem. There are two components to SSL configuration:
- Create a certificate keystore.
-
Declare an SSL connector in the
undertowsubsystem of the JBoss EAP server configuration file.
Here is an example of an SSL connector declaration:
Red Hat recommends that SSLv2, SSLv3, and TLSv1.0 be explicitly disabled in favor of TLSv1.1 or TLSv1.2 in all affected packages.
A.8.2.1.3. Bearer Web Service Providers Interface Copy linkLink copied to clipboard!
The BearerIface Bearer Web Service Provider Interface class is a simple web service definition.
A.8.2.1.4. Bearer Web Service Providers Implementation Copy linkLink copied to clipboard!
The BearerImpl Web Service Provider Implementation class is a simple POJO. It uses the standard WebService annotation to define the service endpoint. In addition there are two Apache CXF annotations, EndpointProperties and EndpointProperty used for configuring the endpoint for the Apache CXF runtime. These annotations come from the Apache WSS4J project, which provides a Java implementation of the primary WS-Security standards for web services. These annotations are programmatically adding properties to the endpoint. With plain Apache CXF, these properties are often set using the <jaxws:properties> element on the <jaxws:endpoint> element in the Spring configuration. These annotations allow the properties to be configured in the code.
WSS4J uses the Crypto interface to get keys and certificates for signature creation/verification, as asserted by the WSDL for this service. The WSS4J configuration information being provided by BearerImpl is for Crypto’s Merlin implementation.
Because the web service provider automatically trusts that the incoming SOAP request that came from the subject defined in the SAML token, it is not required for a Crypto CallbackHandler class or a signature username, unlike in prior examples. However, in order to verify the message signature, the Java properties file that contains the (Merlin) Crypto configuration information is still required.
A.8.2.1.5. Crypto Properties and Keystore Files Copy linkLink copied to clipboard!
WSS4J’s Crypto implementation is loaded and configured using a Java properties file that contains Crypto configuration data. The file contains implementation-specific properties such as a keystore location, password, default alias and so on. This application is using the Merlin implementation. The serviceKeystore.properties file contains this information.
The servicestore.jks file is a Java KeyStore (JKS) repository. It contains self-signed certificates for myservicekey and mystskey.
Self-signed certificates are not appropriate for production use.
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin org.apache.ws.security.crypto.merlin.keystore.type=jks org.apache.ws.security.crypto.merlin.keystore.password=sspass org.apache.ws.security.crypto.merlin.keystore.alias=myservicekey org.apache.ws.security.crypto.merlin.keystore.file=servicestore.jks
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=sspass
org.apache.ws.security.crypto.merlin.keystore.alias=myservicekey
org.apache.ws.security.crypto.merlin.keystore.file=servicestore.jks
A.8.2.1.6. Default MANIFEST.MF Copy linkLink copied to clipboard!
When deployed, this application requires access to the JBossWS and Apache CXF APIs provided in module org.jboss.ws.cxf.jbossws-cxf-client. The dependency statement directs the server to provide them at deployment.
Manifest-Version: 1.0 Dependencies: org.jboss.ws.cxf.jbossws-cxf-client
Manifest-Version: 1.0
Dependencies: org.jboss.ws.cxf.jbossws-cxf-client
A.8.2.2. Bearer Security Token Service Copy linkLink copied to clipboard!
This section lists the crucial elements in providing the Security Token Service functionality for providing a SAML Bearer token. The components include:
A.8.2.2.1. Security Domain Copy linkLink copied to clipboard!
STS requires a JBoss security domain be configured. The jboss-web.xml descriptor declares a named security domain,JBossWS-trust-sts to be used by this service for authentication. This security domain requires two properties files and the addition of a security domain declaration in the JBoss EAP server configuration file.
For this scenario the domain needs to contain user alice, password clarinet, and role friend. Refer to the following listings for jbossws-users.properties and jbossws-roles.properties. In addition, the following XML must be added to the JBoss security subsystem in the server configuration file.
Replace "SOME_PATH" with appropriate information.
Example: .jboss-web.xml File
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 2.4//EN" "> <jboss-web> <security-domain>java:/jaas/JBossWS-trust-sts</security-domain> </jboss-web>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 2.4//EN" ">
<jboss-web>
<security-domain>java:/jaas/JBossWS-trust-sts</security-domain>
</jboss-web>
Example: .jbossws-users.properties File
A sample users.properties file for use with the UsersRolesLoginModule
# A sample users.properties file for use with the UsersRolesLoginModule
alice=clarinet
Example: jbossws-roles.properties File
A sample roles.properties file for use with the UsersRolesLoginModule
# A sample roles.properties file for use with the UsersRolesLoginModule
alice=friend
A.8.2.2.2. STS WSDL Copy linkLink copied to clipboard!
A.8.2.2.3. STS Implementation Class Copy linkLink copied to clipboard!
The Apache CXF’s STS, SecurityTokenServiceProvider, is a web service provider that is compliant with the protocols and functionality defined by the WS-Trust specification. It has a modular architecture and its components are configurable or replaceable. There are optional features that are enabled by implementing and configuring plugins. You can customize your own STS by extending from SecurityTokenServiceProvider and overriding the default settings.
The SampleSTSBearer STS implementation class is a POJO that extends from SecurityTokenServiceProvider.
The SampleSTSBearer class is defined with a WebServiceProvider annotation and not a WebService annotation. This annotation defines the service as a Provider-based endpoint, it supports a messaging-oriented approach to web services. In particular, it signals that the exchanged messages will be XML documents. SecurityTokenServiceProvider is an implementation of the javax.xml.ws.Provider interface. In comparison the WebService annotation defines a service endpoint interface-based endpoint, which supports message exchange using SOAP envelopes.
As done in the BearerImpl class, the WSS4J annotations EndpointProperties and EndpointProperty provide endpoint configuration for the Apache CXF runtime. The first EndpointProperty statement in the listing is declaring the user’s name to use for the message signature. It is used as the alias name in the keystore to get the user’s certificate and private key for signature. The next two EndpointProperty statements declare the Java properties file that contains the (Merlin) Crypto configuration information. In this case both for signing and encrypting the messages. WSS4J reads this file and required information for message handling. The last EndpointProperty statement declares the STSBearerCallbackHandler implementation class. It is used to obtain the user’s password for the certificates in the keystore file.
In this implementation we are customizing the operations of token issuance, token validation, and their static properties.
StaticSTSProperties is used to set select properties for configuring resources in STS. This may seem like duplication of the settings made with the WSS4J annotations. The values are the same but the underlaying structures being set are different, thus this information must be declared in both places.
The setIssuer setting is important because it uniquely identifies the issuing STS. The issuer string is embedded in issued tokens and, when validating tokens, the STS checks the issuer string value. Consequently, it is important to use the issuer string in a consistent way, so that the STS can recognize the tokens that are issued.
The setEndpoints call allows the declaration of a set of allowed token recipients by address. The addresses are specified as reg-ex patterns.
TokenIssueOperation has a modular structure. This allows custom behaviors to be injected into the processing of messages. In this case we are overriding the SecurityTokenServiceProvider default behavior and performing SAML token processing. Apache CXF provides an implementation of a SAMLTokenProvider, which can be used rather than creating one.
A.8.2.2.4. STSBearerCallbackHandler Class Copy linkLink copied to clipboard!
STSBearerCallbackHandler is a callback handler for the WSS4J Crypto API. It is used to obtain the password for the private key in the keystore. This class enables Apache CXF to retrieve the password of the user name to use for the message signature.
A.8.2.2.5. Crypto Properties and Keystore Files Copy linkLink copied to clipboard!
WSS4J’s Crypto implementation is loaded and configured using a Java properties file that contains Crypto configuration data. The file contains implementation-specific properties such as a keystore location, password, default alias and so on. This application is using the Merlin implementation. The stsKeystore.properties file contains this information.
The servicestore.jks file is a Java KeyStore (JKS) repository. It contains self-signed certificates for myservicekey and mystskey.
Self-signed certificates are not appropriate for production use.
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin org.apache.ws.security.crypto.merlin.keystore.type=jks org.apache.ws.security.crypto.merlin.keystore.password=stsspass org.apache.ws.security.crypto.merlin.keystore.file=stsstore.jks
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=stsspass
org.apache.ws.security.crypto.merlin.keystore.file=stsstore.jks
A.8.2.2.6. Default MANIFEST.MF Copy linkLink copied to clipboard!
This application requires access to the JBossWS and Apache CXF APIs provided in the org.jboss.ws.cxf.jbossws-cxf-client module. The org.jboss.ws.cxf.sts module is also needed to build the STS configuration in the SampleSTS constructor. The dependency statement directs the server to provide them at deployment.
Manifest-Version: 1.0 Dependencies: org.jboss.ws.cxf.jbossws-cxf-client,org.jboss.ws.cxf.sts
Manifest-Version: 1.0
Dependencies: org.jboss.ws.cxf.jbossws-cxf-client,org.jboss.ws.cxf.sts
A.8.2.3. Web Service Requester Copy linkLink copied to clipboard!
This section provides the details of crucial elements in calling a web service that implements endpoint security as described in the SAML Bearer scenario. The components that will be discussed include:
A.8.2.3.1. Web Service Requester Implementation Copy linkLink copied to clipboard!
The ws-requester, the client, uses standard procedures for creating a reference to the web service. To address the endpoint security requirements, the web service’s "Request Context" is configured with the information required for message generation. In addition, the STSClient that communicates with the STS is configured with similar values.
The key strings ending with a .it suffix flags these settings as belonging to the STSClient. The internal Apache CXF code assigns this information to the STSClient that is auto-generated for this service call.
There is an alternate method of setting up the STSCLient. The user may provide their own instance of the STSClient. The Apache CXF code uses this object and does not auto-generate one. When providing the STSClient in this way, the user must provide a org.apache.cxf.Bus for it and the configuration keys must not have the .it suffix. This is used in the ActAs and OnBehalfOf examples.
A.8.2.3.2. ClientCallbackHandler Copy linkLink copied to clipboard!
ClientCallbackHandler is a callback handler for the WSS4J Crypto API. It is used to obtain the password for the private key in the keystore. This class enables Apache CXF to retrieve the password of the user name to use for the message signature.
The user alice and password have been provided here. This information is not in the (JKS) keystore but provided in the security domain. It is declared in jbossws-users.properties file.
A.8.2.3.3. Crypto Properties and Keystore Files Copy linkLink copied to clipboard!
WSS4J’s Crypto implementation is loaded and configured using a Java properties file that contains Crypto configuration data. The file contains implementation-specific properties such as a keystore location, password, default alias and so on. This application is using the Merlin implementation. The clientKeystore.properties file contains this information.
The clientstore.jks file is a Java KeyStore (JKS) repository. It contains self-signed certificates for myservicekey and mystskey.
Self-signed certificates are not appropriate for production use.
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin org.apache.ws.security.crypto.merlin.keystore.type=jks org.apache.ws.security.crypto.merlin.keystore.password=cspass org.apache.ws.security.crypto.merlin.keystore.alias=myclientkey org.apache.ws.security.crypto.merlin.keystore.file=META-INF/clientstore.jks
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=cspass
org.apache.ws.security.crypto.merlin.keystore.alias=myclientkey
org.apache.ws.security.crypto.merlin.keystore.file=META-INF/clientstore.jks
A.8.3. Scenario: OnBehalfOf WS-Trust Copy linkLink copied to clipboard!
The OnBehalfOf feature is used in scenarios that use the proxy pattern. In such scenarios, the client cannot access the STS directly, instead it communicates through a proxy gateway. The proxy gateway authenticates the caller and puts information about the caller into the OnBehalfOf element of the RequestSecurityToken (RST) sent to the real STS for processing. The resulting token contains only claims related to the client of the proxy, making the proxy completely transparent to the receiver of the issued token.
OnBehalfOf is nothing more than a new sub-element in the RST. It provides additional information about the original caller when a token is negotiated with the STS. The OnBehalfOf element usually takes the form of a token with identity claims such as name, role, and authorization code, for the client to access the service.
The OnBehalfOf scenario is an extension of the basic WS-Trust scenario. In this example the OnBehalfOf service calls the ws-service on behalf of a user. There are only a couple of additions to the basic scenario’s code. An OnBehalfOf web service provider and callback handler have been added. The OnBehalfOf web services' WSDL imposes the same security policies as the ws-provider. UsernameTokenCallbackHandler is a utility shared with ActAs. It generates the content for the OnBehalfOf element. Lastly, there are code additions in the STS that both OnBehalfOf and ActAs share in common.
A.8.3.1. Web Service Provider Copy linkLink copied to clipboard!
This section provides the web service elements from the basic WS-Trust scenario that have been updated to address the requirements of the OnBehalfOf example. The components include:
A.8.3.1.1. Web Service Provider WSDL Copy linkLink copied to clipboard!
The OnBehalfOf web service provider’s WSDL is a clone of the ws-provider’s WSDL. The wsp:Policy section is the same. There are updates to the service endpoint, targetNamespace, portType, binding name, and service.
A.8.3.1.2. Web Service Provider Interface Copy linkLink copied to clipboard!
The OnBehalfOfServiceIface web service provider interface class is a simple web service definition.
A.8.3.1.3. Web Service Provider Implementation Copy linkLink copied to clipboard!
The OnBehalfOfServiceImpl web service provider implementation class is a simple POJO. It uses the standard WebService annotation to define the service endpoint and two Apache WSS4J annotations, EndpointProperties and EndpointProperty used for configuring the endpoint for the Apache CXF runtime. The WSS4J configuration information provided is for WSS4J’s Crypto Merlin implementation.
OnBehalfOfServiceImpl calls the ServiceImpl acting on behalf of the user. The setupService method performs the required configuration setup.
A.8.3.1.4. OnBehalfOfCallbackHandler Class Copy linkLink copied to clipboard!
The OnBehalfOfCallbackHandler is a callback handler for the WSS4J Crypto API. It is used to obtain the password for the private key in the keystore. This class enables Apache CXF to retrieve the password of the user name to use for the message signature. This class has been updated to return the passwords for this service, myactaskey and the OnBehalfOf user, alice.
A.8.3.2. Web Service Requester Copy linkLink copied to clipboard!
This section provides details of the ws-requester elements from the basic WS-Trust scenario that have been updated to address the requirements of the OnBehalfOf example. The component is:
A.8.3.2.1. OnBehalfOf Web Service Requester Implementation Class Copy linkLink copied to clipboard!
The OnBehalfOf ws-requester, the client, uses standard procedures for creating a reference to the web service in the first four lines. To address the endpoint security requirements, the web service’s request context is configured using the BindingProvider. Information needed in the message generation is provided through it. The OnBehalfOf user, alice, is declared in this section and the callbackHandler, UsernameTokenCallbackHandler is provided to the STSClient for generation of the contents for the OnBehalfOf message element. In this example an STSClient object is created and provided to the proxy’s request context. The alternative is to provide keys tagged with the .it suffix as done in the Basic Scenario client. The use of OnBehalfOf is configured by the stsClient.setOnBehalfOf call method. The alternative is to use the key SecurityConstants.STS_TOKEN_ON_BEHALF_OF and a value in the properties map.
A.8.4. Scenario: ActAs WS-Trust Copy linkLink copied to clipboard!
The ActAs feature is used in scenarios that require composite delegation. It is commonly used in multi-tiered systems where an application calls a service on behalf of a logged in user, or a service calls another service on behalf of the original caller.
ActAs is nothing more than a new sub-element in the RequestSecurityToken (RST). It provides additional information about the original caller when a token is negotiated with the STS. The ActAs element usually takes the form of a token with identity claims such as name, role, and authorization code, for the client to access the service.
The ActAs scenario is an extension of the basic WS-Trust scenario. In this example the ActAs service calls the ws-service on behalf of a user. There are only a couple of additions to the basic scenario’s code. An ActAs web service provider and callback handler have been added. The ActAs web services' WSDL imposes the same security policies as the ws-provider. UsernameTokenCallbackHandler is a new utility that generates the content for the ActAs element. Lastly, there are a couple of code additions in the STS to support the ActAs request.
A.8.4.1. Web Service Provider Copy linkLink copied to clipboard!
This section provides details about the web service elements from the basic WS-Trust scenario that have been changed to address the needs of the ActAs example. The components include:
A.8.4.1.1. Web Service Provider WSDL Copy linkLink copied to clipboard!
The ActAs web service provider’s WSDL is a clone of the ws-provider’s WSDL. The wsp:Policy section is the same. There are changes to the service endpoint, targetNamespace, portType, binding name, and service.
A.8.4.1.2. Web Service Provider Interface Copy linkLink copied to clipboard!
The ActAsServiceIface web service provider interface class is a simple web service definition.
A.8.4.1.3. Web Service Provider Implementation Copy linkLink copied to clipboard!
The ActAsServiceImpl web service provider implementation class is a simple POJO. It uses the standard WebService annotation to define the service endpoint and two Apache WSS4J annotations, EndpointProperties, and EndpointProperty, used for configuring the endpoint for the Apache CXF runtime. The WSS4J configuration information provided is for WSS4J’s Crypto Merlin implementation.
ActAsServiceImpl is calling ServiceImpl acting on behalf of the user. The setupService method performs the required configuration setup.
A.8.4.1.4. ActAsCallbackHandler Class Copy linkLink copied to clipboard!
ActAsCallbackHandler is a callback handler for the WSS4J Crypto API. It is used to obtain the password for the private key in the keystore. This class enables Apache CXF to retrieve the password of the user name to use for the message signature. This class has been updated to return the passwords for this service, myactaskey and the ActAs user, alice.
A.8.4.1.5. UsernameTokenCallbackHandler Copy linkLink copied to clipboard!
The ActAs and OnBeholdOf sub-elements of the RequestSecurityToken have to be defined as WSSE UsernameTokens. This utility generates the properly formatted element.
A.8.4.1.6. Crypto properties and keystore files Copy linkLink copied to clipboard!
The ActAs service must provide its own credentials. The requisite actasKeystore.properties properties file and actasstore.jks keystore are created.
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin org.apache.ws.security.crypto.merlin.keystore.type=jks org.apache.ws.security.crypto.merlin.keystore.password=aapass org.apache.ws.security.crypto.merlin.keystore.alias=myactaskey org.apache.ws.security.crypto.merlin.keystore.file=actasstore.jks
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=aapass
org.apache.ws.security.crypto.merlin.keystore.alias=myactaskey
org.apache.ws.security.crypto.merlin.keystore.file=actasstore.jks
A.8.4.1.7. Default MANIFEST.MF Copy linkLink copied to clipboard!
This application requires access to the JBossWS and Apache CXF APIs provided in the org.jboss.ws.cxf.jbossws-cxf-client module. The org.jboss.ws.cxf.sts module is also needed in handling the ActAs and OnBehalfOf extensions. The dependency statement directs the server to provide them at deployment.
Manifest-Version: 1.0 Dependencies: org.jboss.ws.cxf.jbossws-cxf-client, org.jboss.ws.cxf.sts
Manifest-Version: 1.0
Dependencies: org.jboss.ws.cxf.jbossws-cxf-client, org.jboss.ws.cxf.sts
A.8.4.2. Security Token Service Copy linkLink copied to clipboard!
This section provides the details of the STS elements from the basic WS-Trust scenario that have been changed to address the needs of the ActAs example. The components include:
A.8.4.2.1. STS Implementation Class Copy linkLink copied to clipboard!
The declaration of the set of allowed token recipients by address has been extended to accept ActAs addresses and OnBehalfOf addresses. The addresses are specified as reg-ex patterns.
The TokenIssueOperation requires the UsernameTokenValidator class to be provided to validate the contents of the OnBehalfOf, and the UsernameTokenDelegationHandler class to be provided to process the token delegation request of the ActAs on OnBehalfOf user.
A.8.4.2.2. STSCallbackHandler Class Copy linkLink copied to clipboard!
The user, alice, and corresponding password was required to be added for the ActAs example.
A.8.4.2.3. Web Service Requester Copy linkLink copied to clipboard!
This section provides the details of the ws-requester elements from the basic WS-Trust scenario that have been changed to address the requirements of the ActAs example. The component is:
A.8.4.2.4. Web Service Requester Implementation Class Copy linkLink copied to clipboard!
The ActAs ws-requester, the client, uses standard procedures for creating a reference to the web service in the first four lines. To address the endpoint security requirements, the web service’s request context is configured using BindingProvider to provide information required for message generation. The ActAs user, myactaskey, is declared in this section and UsernameTokenCallbackHandler is used to provide the contents of the ActAs element to the STSClient. In this example an STSClient object is created and provided to the proxy’s request context. The alternative is to provide keys tagged with the .it suffix as was done in the Basic Scenario client. The use of ActAs is configured through the properties map using the SecurityConstants.STS_TOKEN_ACT_AS key. The alternative is to use the STSClient.setActAs method.
Revised on 2018-10-11 12:32:52 UTC