Este contenido no está disponible en el idioma seleccionado.
Appendix A. Reference Material
A.1. JAX-RS/RESTEasy Annotations Copiar enlaceEnlace copiado en el portapapeles!
| 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 Copiar enlaceEnlace copiado en el portapapeles!
| 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 Copiar enlaceEnlace copiado en el portapapeles!
| 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 Copiar enlaceEnlace copiado en el portapapeles!
| 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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
A.8.1. Scenario: SAML Holder-Of-Key Assertion Scenario Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
The web service provider interface HolderOfKeyIface class is a simple web service definition.
A.8.1.1.4. Web Service Provider Implementation Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
The BearerIface Bearer Web Service Provider Interface class is a simple web service definition.
A.8.2.1.4. Bearer Web Service Providers Implementation Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 alice=clarinet
# 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 alice=friend
# A sample roles.properties file for use with the UsersRolesLoginModule
alice=friend
A.8.2.2.2. STS WSDL Copiar enlaceEnlace copiado en el portapapeles!
A.8.2.2.3. STS Implementation Class Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
The OnBehalfOfServiceIface web service provider interface class is a simple web service definition.
A.8.3.1.3. Web Service Provider Implementation Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
The ActAsServiceIface web service provider interface class is a simple web service definition.
A.8.4.1.3. Web Service Provider Implementation Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
The user, alice, and corresponding password was required to be added for the ActAs example.
A.8.4.2.3. Web Service Requester Copiar enlaceEnlace copiado en el portapapeles!
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 Copiar enlaceEnlace copiado en el portapapeles!
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