Appendix A. Reference Material
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.wsdl
WSDL fileEAP_HOME/bin/wsconsume.sh Example.wsdl
EAP_HOME/bin/wsconsume.sh Example.wsdl
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Generate Java source and class files from the
Example.wsdl
WSDL fileEAP_HOME/bin/wsconsume.sh -k Example.wsdl
EAP_HOME/bin/wsconsume.sh -k Example.wsdl
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Generate Java source and class files in the
my.org
package from theExample.wsdl
WSDL fileEAP_HOME/bin/wsconsume.sh -k -p my.org Example.wsdl
EAP_HOME/bin/wsconsume.sh -k -p my.org Example.wsdl
Copy 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.wsdl
Copy 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
output
directory.EAP_HOME/bin/wsprovide.sh -o output my.package.MyEndpoint
EAP_HOME/bin/wsprovide.sh -o output my.package.MyEndpoint
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Generate wrapper classes and WSDL in the
output
directory.EAP_HOME/bin/wsprovide.sh -o output -w my.package.MyEndpoint
EAP_HOME/bin/wsprovide.sh -o output -w my.package.MyEndpoint
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Generate wrapper classes in the
output
directory 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.MyEndpoint
Copy 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
@HandlerChain
annotation. The location of the handler chain file can be either an absolutejava.net.URL
inexternalForm
or 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
@HandlerChain
annotation, as in service endpoints, or dynamically, using the JAX-WS API.Copy to Clipboard Copied! Toggle word wrap Toggle overflow The call to the
setHandlerChain
method 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
.LogicalMessageContext
extendsMessageContext
with 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
.SOAPMessageContext
extendsMessageContext
with 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:TransportBinding
andsp:HttpsToken
. -
A Holder-Of-Key token has no encryption or signing keys associated with it, therefore a
sp:IssuedToken
ofSymmetricKey
orPublicKey
keyType 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.
For information on how to configure HTTPS for web applications, see Configure One-way and Two-way SSL/TLS for Applications in How to Configure Server Security.
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
Bearer
subject 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:TransportBinding
andsp:HttpsToken
. -
A bearer token has no encryption or signing keys associated with it, therefore a
sp:IssuedToken
ofbearer
keyType should be used with asp:SupportingToken
or 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.
For information on how to configure HTTPS for web applications, see Configure One-way and Two-way SSL/TLS for Applications in How to Configure Server Security.
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 2019-12-05 13:41:47 UTC