You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@ws.apache.org by co...@apache.org on 2021/11/12 10:03:54 UTC
svn commit: r1894972 [5/8] - in /webservices/website/wss4j: advisories/
apidocs/org/apache/wss4j/common/util/
apidocs/org/apache/wss4j/common/util/class-use/
testapidocs/org/apache/wss4j/common/token/
testapidocs/org/apache/wss4j/common/util/ testapido...
Added: webservices/website/wss4j/advisories/user_guide.html
URL: http://svn.apache.org/viewvc/webservices/website/wss4j/advisories/user_guide.html?rev=1894972&view=auto
==============================================================================
--- webservices/website/wss4j/advisories/user_guide.html (added)
+++ webservices/website/wss4j/advisories/user_guide.html Fri Nov 12 10:03:53 2021
@@ -0,0 +1,2658 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<!-- Generated by Apache Maven Doxia Site Renderer 1.7.4 at 2021-11-12 -->
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
+ <title>Apache WSS4J – </title>
+ <style type="text/css" media="all">
+ @import url("./css/maven-base.css");
+ @import url("./css/maven-theme.css");
+ @import url("./css/site.css");
+ </style>
+ <link rel="stylesheet" href="./css/print.css" type="text/css" media="print" />
+ <meta http-equiv="Content-Language" content="en" />
+
+ </head>
+ <body class="composite">
+ <div id="banner">
+ <a href="http://ws.apache.org/wss4j" id="bannerLeft">
+ Apache WSS4Jâ¢
+ </a>
+ <a href="http://www.apache.org" id="bannerRight">
+ <img src="http://activemq.apache.org/images/asf-logo.png" alt="$alt" />
+ </a>
+ <div class="clear">
+ <hr/>
+ </div>
+ </div>
+ <div id="breadcrumbs">
+
+ <div class="xleft">
+ <span id="publishDate">Last Published: 2021-11-12</span>
+ | <span id="projectVersion">Version: 2.5.0-SNAPSHOT</span>
+ </div>
+ <div class="xright">
+ </div>
+ <div class="clear">
+ <hr/>
+ </div>
+ </div>
+ <div id="leftColumn">
+ <div id="navcolumn">
+
+ <h5>Apache WSS4J</h5>
+ <ul>
+ <li class="none">
+ <a href="index.html" title="Home">Home</a>
+ </li>
+ <li class="none">
+ <a href="download.html" title="Download">Download</a>
+ </li>
+ <li class="none">
+ <strong>User Guide</strong>
+ </li>
+ <li class="none">
+ <a href="security_advisories.html" title="Security Advisories">Security Advisories</a>
+ </li>
+ </ul>
+ <h5>Project Documentation</h5>
+ <ul>
+ <li class="collapsed">
+ <a href="project-info.html" title="Project Information">Project Information</a>
+ </li>
+ <li class="collapsed">
+ <a href="project-reports.html" title="Project Reports">Project Reports</a>
+ </li>
+ </ul>
+ <a href="http://maven.apache.org/" title="Built by Maven" class="poweredBy">
+ <img class="poweredBy" alt="Built by Maven" src="./images/logos/maven-feather.png" />
+ </a>
+
+ </div>
+ </div>
+ <div id="bodyColumn">
+ <div id="contentBox">
+ <h1>Apache WSS4J™ User Guide</h1>
+<div id="toc" class="toc">
+<div id="toctitle">Table of Contents</div>
+<ul class="sectlevel1">
+<li><a href="#what_is_apache_wss4j">What is Apache WSS4J™?</a>
+<ul class="sectlevel2">
+<li><a href="#the_technical_answer">The technical answer</a></li>
+<li><a href="#the_less_technical_answer">The less technical answer</a></li>
+</ul>
+</li>
+<li><a href="#using_apache_wss4j">Using Apache WSS4J™</a>
+<ul class="sectlevel2">
+<li><a href="#action_based_approach">Action based approach</a></li>
+<li><a href="#ws_securitypolicy_based_approach">WS-SecurityPolicy based approach</a></li>
+<li><a href="#standalone_approach">Standalone approach</a></li>
+<li><a href="#soap_stacks">SOAP Stacks</a></li>
+</ul>
+</li>
+<li><a href="#apache_wss4j_migration_guides">Apache WSS4J Migration Guides</a>
+<ul class="sectlevel2">
+<li><a href="#apache_wss4j_2_2_0_migration_guide">Apache WSS4J 2.2.0 Migration Guide</a></li>
+<li><a href="#apache_wss4j_2_1_0_migration_guide">Apache WSS4J 2.1.0 Migration Guide</a></li>
+<li><a href="#apache_wss4j_2_0_0_migration_guide">Apache WSS4J 2.0.0 Migration Guide</a></li>
+<li><a href="#new_features_available_in_apache_wss4j_2_0_0">New features available in Apache WSS4J 2.0.0</a></li>
+<li><a href="#apache_wss4j_1_6_0_migration_guide">Apache WSS4J 1.6.0 Migration Guide</a></li>
+</ul>
+</li>
+<li><a href="#wss4j_configuration">WSS4J configuration</a>
+<ul class="sectlevel2">
+<li><a href="#crypto_properties">Crypto properties</a></li>
+<li><a href="#saml_properties">SAML properties</a></li>
+<li><a href="#configuration_tags">Configuration tags</a></li>
+</ul>
+</li>
+<li><a href="#streaming_stax_ws_security_support_in_apache_wss4j_2_0_0">Streaming (StAX) WS-Security support in Apache WSS4J™ 2.0.0</a>
+<ul class="sectlevel2">
+<li><a href="#overview_of_new_features_2">Overview of new features</a></li>
+<li><a href="#limitations_of_the_streaming_ws_security_implementation">Limitations of the streaming WS-Security implementation</a></li>
+</ul>
+</li>
+<li><a href="#securing_message_attachments">Securing message attachments</a>
+<ul class="sectlevel2">
+<li><a href="#securing_message_attachments_via_the_action_approach">Securing message attachments via the action approach</a></li>
+<li><a href="#securing_message_attachments_via_ws_securitypolicy">Securing message attachments via WS-SecurityPolicy</a></li>
+</ul>
+</li>
+<li><a href="#wss4j_special_topics">WSS4J Special Topics</a>
+<ul class="sectlevel2">
+<li><a href="#crypto_interface">Crypto Interface</a></li>
+<li><a href="#verifying_public_keys">Verifying Public Keys</a></li>
+<li><a href="#introducing_validators">Introducing Validators</a></li>
+<li><a href="#specifying_elements_to_sign_or_encrypt">Specifying elements to sign or encrypt</a></li>
+<li><a href="#wspasswordcallback_identifiers">WSPasswordCallback identifiers</a></li>
+<li><a href="#usernametoken_handling_in_wss4j_1_6">UsernameToken handling in WSS4J 1.6</a></li>
+<li><a href="#support_for_saml2_assertions_in_wss4j_1_6">Support for SAML2 assertions in WSS4J 1.6</a></li>
+<li><a href="#jsr_105_support">JSR-105 support</a></li>
+<li><a href="#basic_security_profile_1_1_compliance">Basic Security Profile 1.1 compliance</a></li>
+</ul>
+</li>
+<li><a href="#security_best_practices">Security Best Practices</a>
+<ul class="sectlevel2">
+<li><a href="#upgrade_to_wss4j_2_3_x_or_2_2_x">Upgrade to WSS4J 2.3.x or 2.2.x</a></li>
+<li><a href="#upgrade_to_the_latest_minor_release_as_soon_as_possible">Upgrade to the latest minor release as soon as possible</a></li>
+<li><a href="#use_ws_securitypolicy_to_enforce_security_requirements">Use WS-SecurityPolicy to enforce security requirements</a></li>
+<li><a href="#use_rsa_oaep_for_the_key_transport_algorithm">Use RSA-OAEP for the Key Transport Algorithm</a></li>
+<li><a href="#avoid_using_a_cbc_symmetric_encryption_algorithm">Avoid using a cbc Symmetric Encryption Algorithm</a></li>
+<li><a href="#use_subject_dn_regular_expressions_with_chain_trust">Use Subject DN regular expressions with chain trust</a></li>
+<li><a href="#specify_signature_algorithm_on_receiving_side">Specify signature algorithm on receiving side</a></li>
+</ul>
+</li>
+<li><a href="#further_resources">Further Resources</a>
+<ul class="sectlevel2">
+<li><a href="#wss4j_2_0_0_articles">WSS4J 2.0.0 articles</a></li>
+<li><a href="#wss4j_1_6_x_articles">WSS4J 1.6.x articles</a></li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="sect1">
+<h2 id="what_is_apache_wss4j">What is Apache WSS4J™?</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>In this section we describe what Apache WSS4J is and what functionality it supports.
+For more information about how to use WSS4J, see the <a href="using.html">Using Apache WSS4J</a> page.</p>
+</div>
+<div class="sect2">
+<h3 id="the_technical_answer">The technical answer</h3>
+<div class="paragraph">
+<p>The technical answer is that Apache WSS4J provides a Java implementation of
+the primary security standards for Web Services, namely the OASIS Web Services
+Security (WS-Security) specifications from the
+<a href="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss">OASIS Web Services Security TC</a>. WSS4J provides an implementation of the following
+WS-Security standards:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SOAPMessageSecurity.pdf">SOAP Message Security 1.1</a></p>
+</li>
+<li>
+<p><a href="http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-UsernameTokenProfile.pdf">UsernameToken Profile 1.1</a></p>
+</li>
+<li>
+<p><a href="http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-x509TokenProfile.pdf">X.509Certificate Token Profile 1.1</a></p>
+</li>
+<li>
+<p><a href="http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SAMLTokenProfile.pdf">SAML Token Profile 1.1</a></p>
+</li>
+<li>
+<p><a href="http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-KerberosTokenProfile.pdf">Kerberos Token Profile 1.1</a></p>
+</li>
+<li>
+<p><a href="http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SwAProfile.pdf">SOAP Messages with Attachments Profile 1.1</a></p>
+</li>
+<li>
+<p><a href="http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1.html">Basic Security Profile 1.1</a></p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="the_less_technical_answer">The less technical answer</h3>
+<div class="paragraph">
+<p>Apache WSS4J is designed to be used with a Web Services stack such as Apache
+CXF or Apache Axis to secure SOAP messages. It offers the following high
+level functionality:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Message Confidentiality</p>
+</li>
+<li>
+<p>Message Integrity</p>
+</li>
+<li>
+<p>Message Authentication</p>
+</li>
+<li>
+<p>Message Authorization</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>WSS4J uses the functionality of Apache Santuario to encrypt SOAP Messages.
+Typically, the SOAP Body as well as a UsernameToken in the security header are
+encrypted. WSS4J supports both Symmetric and Asymmetric encryption. Typically,
+a Symmetric Key is generated and used to encrypt the SOAP Body/UsernameToken,
+and then the Symmetric Key is in turn encrypted by the public key of the
+recipient and included in the security header of the request.</p>
+</div>
+<div class="paragraph">
+<p>WSS4J also provides the ability to ensure message integrity by applying XML
+Signature to a SOAP request. Typically, the SOAP Body, Timestamp,
+WS-Addressing headers, as well as any other token in the security header are
+signed. Both Symmetric and Asymmetric Signature are supported. WSS4J supports
+using a secret key associated with a token, such as a Kerberos Token or a key
+derived from a UsernameToken, to sign (as well as to encrypt) a request.</p>
+</div>
+<div class="paragraph">
+<p>As well as providing message confidentiality and integrity, WSS4J allows for
+client authentication in a number of different ways. The most common way is
+to include a username and password in a UsernameToken included in the security
+header. The message recipient can plug in a WSS4J Validator to validate the
+received credentials. Authentication is also supported via Kerberos Tokens,
+SAML Assertions (when used with "HolderOfKey"), and Asymmetric Signature.</p>
+</div>
+<div class="paragraph">
+<p>Finally, WSS4J supports message authorization using an RBAC approach. This can
+be supported via the use-case of UsernameTokens validated using the JAAS
+Validator that ships with WSS4J. This stores the JAAS Subject in the WSS4J
+results list, and can be used by the web services stack to populate a security
+context. Similarly, authorization can be supported using Claims extracted
+from a SAML (Attribute) Assertion.</p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="using_apache_wss4j">Using Apache WSS4J™</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>This page describes how to use Apache WSS4J. For information about how to
+configure WSS4J, see the <a href="config.html">configuration page</a>. WSS4J
+can essentially be used in three different ways. For information about using
+WSS4J with a SOAP stack, see the sections on Apache CXF and Apache Rampart/Axis.</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Action based approach: WSS4J offers an "Action" based approach to
+applying WS-Security to a SOAP request or response, in conjunction with a SOAP
+stack.</p>
+</li>
+<li>
+<p>WS-SecurityPolicy based approach: WSS4J can be configured for a SOAP
+request/response via WS-SecurityPolicy, in conjunction with a SOAP Stack.
+This is the recommended approach.</p>
+</li>
+<li>
+<p>Standalone approach: WSS4J offers a low-level (DOM) API to
+construct/sign/encrypt/etc. tokens directly.</p>
+</li>
+</ul>
+</div>
+<div class="sect2">
+<h3 id="action_based_approach">Action based approach</h3>
+<div class="paragraph">
+<p>The WSHandler class in WSS4J is designed to configure WSS4J to secure an
+outbound SOAP request, by parsing configuration that is supplied to it via
+a subclass. Typically a web services stack that uses WSS4J for WS-Security
+will subclass WSHandler. An example of a subclass is the
+<a href="http://cxf.apache.org/docs/ws-security.html">WSS4JOutInterceptor</a>
+in Apache CXF. The configuration tags are defined in the <a href="https://github.com/apache/ws-wss4j/tree/master/ws-security-common/src/main/java/org/apache/wss4j/common/ConfigurationConstants.java?view=markup">ConfigurationConstants</a> class (WSHandlerConstants in WSS4J 1.6.x). For a more detailed explanation
+of the configuration tags, please refer to the <a href="config.html">configuration</a> page. The next few paragraphs will
+describe the most fundamental configuration tags that are used in most
+cases.</p>
+</div>
+<div class="sect3">
+<h4 id="common_configuration_tags">Common configuration tags</h4>
+<div class="paragraph">
+<p>The "Action" based approach to using Apache WSS4J involves explicitly telling
+WSS4J what WS-Security functionality to perform on a request, by configuring
+the stack specific WSHandler implementation with the required properties. On
+the receiving side, the "actions" that are configured are matched against what
+was processed in the security header, and an error is thrown if they do not
+match (in some order). Typical actions include "UsernameToken, "Signature",
+"Encrypt", "Timestamp, "SAMLTokenSigned", etc.</p>
+</div>
+<div class="paragraph">
+<p>After specifying the action to perform on a request, the next task is typically
+to specify the "user". The "user" can be either the username to insert into a
+UsernameToken, or the keystore alias to use for either signature or encryption.
+If you are configuring more than one of these actions, the "signatureUser" and
+"encryptionUser" configuration tags override the more general "user" tag. The
+next task is often to specify a CallbackHandler implementation to use to
+retrieve passwords. On the sending side, this is used to retrieve a password
+to insert into a UsernameToken and to decrypt a private key from a keystore
+for Signature. On the receiving side, it is used to retrieve a password to
+validate a received UsernameToken, and to decrypt a private key from a
+keystore to use for decryption.</p>
+</div>
+<div class="paragraph">
+<p>The next task is to specify a Crypto implementation if you are using Signature
+or Encryption. See the <a href="configuration.html">configuration</a> page for
+more information on the Crypto interface. Typically, it is configured in a
+Crypto properties file, which specifies the Crypto implementation to use, as
+well as the keystore location, default alias/password, etc. For signature, the
+path of this properties file can be referred to by the tag "signaturePropFile"
+and "encryptionPropFile" for outbound request, and
+"signatureVerificationPropFile" and "decryptionPropFile" for inbound requests".
+How signing keys/certificates are referenced from a Signature can be
+controlled via the "signatureKeyIdentifier" configuration tag. This defaults
+to "IssuerSerial", but could be "DirectReference", "Thumbprint", etc. The
+"encryptionKeyIdentifier" tag performs the same function for encryption.</p>
+</div>
+<div class="paragraph">
+<p>Finally, the Elements to sign or encrypt can be specified by the
+"signatureParts" and "encryptionParts" configuration tags. Both default to the
+SOAP Body. The value of signatureParts/encryptionParts is a list of semi-colon
+separated values that identify the elements to sign/encrypt. The value is of
+the format of an encryption mode specifier, and a namespace URI, each inside a
+pair of curly brackets, and then the local name of the Element. For example,
+"{Content}{http://example.org/paymentv2}CreditCard;". The encryption modifier
+can be either "Content" or "Element" and only applies to encryption.</p>
+</div>
+<div class="paragraph">
+<p>Here are some sample configuration values for various actions, as taken from
+some CXF system tests. The constructor of the
+WSS4JOutInterceptor/WSS4JInIntereptor interceptors in CXF takes a map of
+String/Object pairs which correspond to the key/value pairs given in the tables
+below. See the CXF configuration <a href="https://github.com/apache/cxf/blob/master/systests/ws-security/src/test/resources/org/apache/cxf/systest/ws/action/client.xml">file</a> for more information.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="sample_outbound_usernametoken_configuration">Sample Outbound UsernameToken configuration</h4>
+<div class="ulist">
+<ul>
+<li>
+<p><strong>Key</strong> - <strong>Value</strong></p>
+</li>
+<li>
+<p>action - UsernameToken</p>
+</li>
+<li>
+<p>user - Alice</p>
+</li>
+<li>
+<p>passwordCallbackClass - <a href="https://github.com/apache/cxf/blob/master/systests/ws-security/src/test/java/org/apache/cxf/systest/ws/common/UTPasswordCallback.java">org.apache.cxf.systest.ws.common.UTPasswordCallback</a></p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="sample_outbound_signaturetimestamp_configuration">Sample Outbound Signature/Timestamp configuration</h4>
+<div class="ulist">
+<ul>
+<li>
+<p><strong>Key</strong> - <strong>Value</strong></p>
+</li>
+<li>
+<p>action - Signature Timestamp</p>
+</li>
+<li>
+<p>signatureUser - alice</p>
+</li>
+<li>
+<p>passwordCallbackClass - <a href="https://github.com/apache/cxf/blob/master/systests/ws-security/src/test/java/org/apache/cxf/systest/ws/common/KeystorePasswordCallback.java">org.apache.cxf.systest.ws.common.KeystorePasswordCallback</a></p>
+</li>
+<li>
+<p>signaturePropFile - <a href="https://github.com/apache/cxf/blob/master/systests/ws-security/src/test/resources/alice.properties">alice.properties</a></p>
+</li>
+<li>
+<p>signatureKeyIdentifier - DirectReference</p>
+</li>
+<li>
+<p>signatureParts - {}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp;{}{http://schemas.xmlsoap.org/soap/envelope/}Body;</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="ws_securitypolicy_based_approach">WS-SecurityPolicy based approach</h3>
+<div class="paragraph">
+<p>The recommended way of applying WS-Security to your web services is to use
+WS-SecurityPolicy. The WS-SecurityPolicy specification defines a set of
+WS-Policy expressions that can be used to define the security requirements of
+a web service. Typically one or more policies are attached to the WSDL of a
+service, which conveys the security requirements of the service to the client.
+A WS-SecurityPolicy aware stack such as Apache CXF or Apache Axis/Rampart can
+parse the policies and configure WSS4J appropriately. This greatly simplifies
+things for the user, who then only has to supply some basic information about
+which users, CallbackHandlers, Crypto property files, etc. to use.</p>
+</div>
+<div class="paragraph">
+<p>For more information on using WS-SecurityPolicy with WSS4J, please see CXF’s
+WS-SecurityPolicy page, or go to the SOAP stack sections below:
+<a href="http://cxf.apache.org/docs/ws-securitypolicy.html">CXF WS-SecurityPolicy configuration</a></p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="standalone_approach">Standalone approach</h3>
+<div class="paragraph">
+<p>Apache WSS4J provides a set of APIs to implement WS-Security functionality on
+a SOAP message. It is possible to use these APIs directly in a standalone
+manner, although it is far more common to use either the "Action" or
+WS-SecurityPolicy based approaches. This functionality is only available for
+the DOM code. The best way of finding out how to do this is to take a look at
+the test sources. For example:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://github.com/apache/ws-wss4j/tree/master/ws-security-dom/src/test/java/org/apache/wss4j/dom/message/UsernameTokenTest.java?view=markup">Username Token Test</a></p>
+</li>
+<li>
+<p><a href="https://github.com/apache/ws-wss4j/tree/master/ws-security-dom/src/test/java/org/apache/wss4j/dom/message/EncryptionTest.java?view=markup">Encryption Test</a></p>
+</li>
+<li>
+<p><a href="https://github.com/apache/ws-wss4j/tree/master/ws-security-dom/src/test/java/org/apache/wss4j/dom/message/SignatureTest.java?view=markup">Signature Test</a></p>
+</li>
+<li>
+<p><a href="https://github.com/apache/ws-wss4j/tree/master/ws-security-dom/src/test/java/org/apache/wss4j/dom/message/TimestampTest.java?view=markup">Timestamp Test</a></p>
+</li>
+<li>
+<p><a href="https://github.com/apache/ws-wss4j/tree/master/ws-security-dom/src/test/java/org/apache/wss4j/dom/saml/SamlTokenTest.java?view=markup">SAML Token Test</a></p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="soap_stacks">SOAP Stacks</h3>
+<div class="sect3">
+<h4 id="apache_cxf">Apache CXF</h4>
+<div class="paragraph">
+<p><a href="http://cxf.apache.org">Apache CXF</a> is an open-source web services
+stack. CXF uses WSS4J to perform the core WS-Security functionality, and
+provides extended security functionality based around the WS-SecurityPolicy,
+WS-SecureConversation and WS-Trust specifications. More information:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="http://cxf.apache.org/docs/ws-security.html">CXF WS-Security configuration</a></p>
+</li>
+<li>
+<p><a href="http://cxf.apache.org/docs/ws-secureconversation.html">CXF WS-SecureConversation configuration</a></p>
+</li>
+<li>
+<p><a href="http://cxf.apache.org/docs/ws-securitypolicy.html">CXF WS-SecurityPolicy configuration</a></p>
+</li>
+<li>
+<p><a href="http://cxf.apache.org/docs/ws-trust.html">CXF WS-Trust configuration</a></p>
+</li>
+<li>
+<p><a href="http://cxf.apache.org/resources-and-articles.html">CXF Security articles</a></p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="apache_rampartaxis">Apache Rampart/Axis</h4>
+<div class="paragraph">
+<p><a href="http://axis.apache.org/axis2/java/rampart/">Apache Rampart</a> is the
+security module for the Axis2 web services stack. Rampart uses WSS4J to
+perform the core WS-Security functionality, and provides extended security
+functionality based around the WS-SecurityPolicy, WS-SecureConversation and
+WS-Trust specifications. Note that support for Apache Axis1 via the WSS4J
+1.5.x series of releases is no longer supported. More information:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="http://axis.apache.org/axis2/java/rampart/developer-guide.html">Rampart developer guide</a></p>
+</li>
+<li>
+<p><a href="http://axis.apache.org/axis2/java/rampart/samples.html">Rampart samples</a></p>
+</li>
+<li>
+<p><a href="http://axis.apache.org/axis2/java/rampart/rampartconfig-guide.html">Rampart configuration guide</a></p>
+</li>
+<li>
+<p><a href="http://axis.apache.org/axis2/java/rampart/articles.html">Rampart articles</a></p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="apache_wss4j_migration_guides">Apache WSS4J Migration Guides</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Information about migrating to various new versions of WSS4J is provided in this section.</p>
+</div>
+<div class="sect2">
+<h3 id="apache_wss4j_2_2_0_migration_guide">Apache WSS4J 2.2.0 Migration Guide</h3>
+<div class="paragraph">
+<p>This section is a migration guide for helping Apache WSS4J 2.1.x users to migrate
+to the 2.2.x releases.</p>
+</div>
+<div class="sect3">
+<h4 id="jdk8_minimum_requirement">JDK8 minimum requirement</h4>
+<div class="paragraph">
+<p>WSS4J 2.1.x required JDK7 as a minimum requirement. WSS4J 2.2.x requires at
+least JDK8.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="base64_changes">Base64 changes</h4>
+<div class="paragraph">
+<p>In WSS4J 2.1.x, the Base64 implementation that ships with the JDK
+(java.util.Base64) is used, instead of the Base64 implementation that ships
+with Apache Santuario. It is unlikely, but this may have an impact on users
+who are parsing messages with Base64 implementations that depend on specific
+CR or LF characters, as the Santuario and Java Base64 implementations differ
+slightly. Both the Apache Santuario and Java Base64 implementations can
+correctly decode the messages created with Apache WSS4J 2.2.x.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="kerberos_changes">Kerberos changes</h4>
+<div class="paragraph">
+<p>There are some changes with regards to Kerberos in WSS4J 2.1.x. The
+KerberosClientAction and KerberosServiceAction classes are removed. Instead
+use KerberosClientExceptionAction and KerberosServiceExceptionAction in the
+same package. The KerberosTokenDecoderImpl is removed as we can now get access
+to the secret key via the JDK APIs. As a consequence, the ws-security-common
+module no longer has a dependency on Apache Directory.</p>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="apache_wss4j_2_1_0_migration_guide">Apache WSS4J 2.1.0 Migration Guide</h3>
+<div class="paragraph">
+<p>This section is a migration guide for helping Apache WSS4J 2.0.x users to migrate
+to the 2.1.x releases.</p>
+</div>
+<div class="sect3">
+<h4 id="jdk7_minimum_requirement">JDK7 minimum requirement</h4>
+<div class="paragraph">
+<p>WSS4J 2.0.x required JDK6 as a minimum requirement. WSS4J 2.1.x requires at
+least JDK7. The Xerces and xml-api dependencies have been removed from the DOM
+code, as they are no longer required due to the JDK7 minimum requirement.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="opensaml_3_x_migration">OpenSAML 3.x migration</h4>
+<div class="paragraph">
+<p>A key dependency change in WSS4J 2.1.0 is the upgrade from OpenSAML 2.x to
+3.x (currently 3.1.0). OpenSAML 3.x contains a large number of package
+changes. Therefore if you have any OpenSAML dependencies in a CallbackHandler
+used to create SAML Assertions in WSS4J, code changes will be required.</p>
+</div>
+<div class="paragraph">
+<p>The most common OpenSAML dependency is to include a "SAMLVersion" to tell
+the SAMLCallback whether to create a SAML 2.0 or 1.1 Assertion. WSS4J 2.1
+provides an alternative way of specifying the SAML Version, via a <a href="https://github.com/apache/ws-wss4j/tree/master/ws-security-common/src/main/java/org/apache/wss4j/common/saml/bean/Version.java">Version</a> bean. See
+<a href="https://github.com/apache/ws-wss4j/tree/master/ws-security-dom/src/test/java/org/apache/wss4j/dom/common/SAML2CallbackHandler.java">here</a> for an example.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="custom_processor_changes">Custom processor changes</h4>
+<div class="paragraph">
+<p>If you have a custom Processor instance to process a token in the security
+header in some custom way, you must add the WSSecurityEngineResult that is
+generated by the processing, to the WSDocInfo Object via the "addResult"
+method. Otherwise, it will not be available when security results are
+retrieved and processed.</p>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="apache_wss4j_2_0_0_migration_guide">Apache WSS4J 2.0.0 Migration Guide</h3>
+<div class="paragraph">
+<p>This section is a migration guide for helping Apache WSS4J 1.6.x users to migrate
+to the 2.0.x releases. Also see the <a href="newfeatures20.html">new
+features</a> page for more information about the new functionality available in
+WSS4J 2.0.x.</p>
+</div>
+<div class="sect3">
+<h4 id="migrating_to_using_the_streaming_stax_code">Migrating to using the streaming (StAX) code</h4>
+<div class="paragraph">
+<p>WSS4J 2.0.0 introduces a streaming (StAX-based) WS-Security implementation to
+complement the existing DOM-based implementation. The DOM-based implementation
+is quite performant and flexible, but having to read the entire request into
+memory carries performance penalties. The StAX-based code offers largely the
+same functionality as that available as part of the DOM code, and is
+configured in mostly the same way (via configuration tags that are shared
+between both stacks).</p>
+</div>
+<div class="paragraph">
+<p>As of the time of writing, Apache CXF is the only web services stack to
+integrate the new WS-Security streaming functionality. To switch to use the
+streaming code for the manual "Action" based approach, simply change the
+outbound and inbound interceptors as follows:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>"org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor" to
+"org.apache.cxf.ws.security.wss4j.WSS4JStaxOutInterceptor".</p>
+</li>
+<li>
+<p>"org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor" to
+"org.apache.cxf.ws.security.wss4j.WSS4JStaxInInterceptor".</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For the WS-SecurityPolicy based approach of configuring WS-Security, simply
+set the JAX-WS property SecurityConstants.ENABLE_STREAMING_SECURITY
+("ws-security.enable.streaming") to "true".</p>
+</div>
+<div class="paragraph">
+<p>For more information on the streaming functionality available in WSS4J 2.0.0,
+please see the <a href="streaming.html">streaming documentation</a> page.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="cryptocallbackhandler_changes">Crypto/CallbackHandler changes</h4>
+<div class="paragraph">
+<p>Typically, a user configures Signature and Encryption keys via a Crypto
+properties file. In WSS4J 1.6.x, the property names all start with
+"org.apache.ws.security.crypto.*". In WSS4J 2.0.0, the new prefix is
+"org.apache.wss4j.crypto.\*". However, WSS4J 2.0.0 will accept the older
+prefix value. No other changes are necessary for migrating Crypto properties.</p>
+</div>
+<div class="paragraph">
+<p>In WSS4J 1.6.x, it was only possible to specify a Crypto implementation for
+both Signature Creation + Verification. In WSS4J 2.0.0, there is now a
+separate Signature Verification Crypto instance, that can be configured via
+the following configuration tags:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>signatureVerificationPropFile - The path of the crypto property file to
+use for Signature verification.</p>
+</li>
+<li>
+<p>signatureVerificationPropRefId - The key that holds a reference to the
+object holding complete information about the signature verification Crypto
+implementation.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>In WSS4J, you need to define a CallbackHandler to supply a password to a
+WSPasswordCallback Object when dealing with UsernameTokens, or to unlock
+private keys for Signature creation, etc. In WSS4J 2.0.0, the functionality is
+exactly the same, except that the package of the WSPasswordCallback Object has
+changed from "org.apache.ws.security" to "org.apache.wss4j.common.ext". Any
+CallbackHandler implementation will need to be updated to use the new package.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="saml_assertion_changes">SAML Assertion changes</h4>
+<div class="paragraph">
+<p>A CallbackHandler implementation is required to create a SAML Assertion, by
+populating various beans. Similar to the WSPasswordCallback package change,
+there are also some package changes for SAML. The base package for the
+SAMLCallback class, and of the various "bean" classes, has changed from
+"org.apache.ws.security.saml.ext" to "org.apache.wss4j.common.saml".</p>
+</div>
+<div class="paragraph">
+<p>Apache WSS4J 1.6.x uses the SAMLIssuer interface to configure the creation and
+signing of a SAML Assertion. In Apache WSS4J 2.0.0, the SAMLIssuer
+functionality has been moved to the SAMLCallback, so that the CallbackHandler
+used to create a SAML Assertion is responsible for all of the signing
+configuration as well. Therefore, the properties file that is used in
+WSS4J 1.6.x to sign a SAML Assertion is no longer used in WSS4J 2.0.0, and
+the "samlPropFile" and "samlPropRefId" configuration tags have been removed.</p>
+</div>
+<div class="paragraph">
+<p>The SAMLCallback Object contains the additional properties in WSS4J 2.0.0 that
+can be set to sign the Assertion:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>boolean signAssertion - Whether to sign the assertion or not (default "false").</p>
+</li>
+<li>
+<p>String issuerKeyName - The keystore alias for signature</p>
+</li>
+<li>
+<p>String issuerKeyPassword - The keystore password for the alias</p>
+</li>
+<li>
+<p>Crypto issuerCrypto - The Crypto instance used for signature</p>
+</li>
+<li>
+<p>boolean sendKeyValue - Whether to send the keyvalue or the X509Certificate
+(default "false").</p>
+</li>
+<li>
+<p>String canonicalizationAlgorithm - The C14n algorithm to use for signature.</p>
+</li>
+<li>
+<p>String signatureAlgorithm - The Signature algorithm.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="configuration_tag_changes">Configuration tag changes</h4>
+<div class="paragraph">
+<p>In WSS4J 1.6.x, configuration tags were configured in the WSHandlerConstants
+class. In WSS4J 2.0.0, both the DOM and StAX-based code largely share the
+same configuration options, and so the configuration tags are defined in
+<a href="https://github.com/apache/ws-wss4j/tree/master/ws-security-common/src/main/java/org/apache/wss4j/common/ConfigurationConstants.java?view=markup">ConfigurationConstants</a>. Note that the WSS4J 1.6.x configuration class
+(WSHandlerConstants) extends this class in WSS4J 2.0.0, so there is no need to
+change any configuration code when upgrading.</p>
+</div>
+<div class="paragraph">
+<p>The configuration tags that have been removed and added are detailed below.
+The non-standard key derivation and UsernameToken Signature functionality that
+was optional in WSS4J 1.6.x has been removed. Some new actions are added for
+the streaming code, as well as some options surrounding caching. An important
+migration point is that there is now a separate configuration tag used for
+verifying signatures. In WSS4J 1.6.x, there was only one tag used for both
+signature creation and verification.</p>
+</div>
+<div class="sect4">
+<h5 id="removed_configuration_tags_in_wss4j_2_0_0">Removed Configuration tags in WSS4J 2.0.0</h5>
+<div class="paragraph">
+<p>This section details the Configuration tags that are no longer present in
+WSS4J 2.0.0.</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>SIGN_WITH_UT_KEY (UsernameTokenSignature) - Perform a .NET specific signature using a Username Token action. Removed
+as it was not standard compliant.</p>
+</li>
+<li>
+<p>PASSWORD_TYPE_STRICT (passwordTypeStrict) - Whether to enable strict Username Token password type handling. In WSS4J
+2.0.0 this functionality can be enabled by just setting the required
+PASSWORD_TYPE.</p>
+</li>
+<li>
+<p>USE_DERIVED_KEY (useDerivedKey) - Whether to use the standard UsernameToken Key Derivation algorithm. Removed
+as only the standard algorithm is used in WSS4J 2.0.0.</p>
+</li>
+<li>
+<p>ENC_KEY_NAME (embeddedKeyName) - The text of the key name to be sent in the KeyInfo for encryption. Embedded
+KeyNames are not supported in WSS4J 2.0.0.</p>
+</li>
+<li>
+<p>ADD_UT_ELEMENTS (addUTElements) - Additional elements to add to a Username Token, i.e. "nonce" and "created".
+See the ADD_USERNAMETOKEN_NONCE and ADD_USERNAMETOKEN_CREATED properties below.</p>
+</li>
+<li>
+<p>WSE_SECRET_KEY_LENGTH (wseSecretKeyLength) - The length of the secret (derived) key to use for the WSE UT_SIGN
+functionality. Removed as it is not standard compliant.</p>
+</li>
+<li>
+<p>ENC_CALLBACK_CLASS (embeddedKeyCallbackClass) - The CallbackHandler implementation class used to get the key associated
+with a key name. KeyName is not supported in WSS4J 2.0.0.</p>
+</li>
+<li>
+<p>ENC_CALLBACK_REF (embeddedKeyCallbackRef) -The CallbackHandler implementation object used to get the key associated
+with a key name. KeyName is not supported in WSS4J 2.0.0.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect4">
+<h5 id="new_configuration_tags_in_wss4j_2_0_0">New Configuration tags in WSS4J 2.0.0</h5>
+<div class="paragraph">
+<p>This section details the new Configuration tags in WSS4J 2.0.0.</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>USERNAME_TOKEN_SIGNATURE (UsernameTokenSignature) - Perform a UsernameTokenSignature action.</p>
+</li>
+<li>
+<p>SIGNATURE_DERIVED (SignatureDerived) - Perform a Signature action with derived keys.</p>
+</li>
+<li>
+<p>ENCRYPT_DERIVED (EncryptDerived) - Perform a Encryption action with derived keys.</p>
+</li>
+<li>
+<p>SIGNATURE_WITH_KERBEROS_TOKEN (SignatureWithKerberosToken) - Perform a Signature action with a kerberos token. Only for StAX code.</p>
+</li>
+<li>
+<p>ENCRYPT_WITH_KERBEROS_TOKEN (EncryptWithKerberosToken) - Perform a Encryption action with a kerberos token. Only for StAX code.</p>
+</li>
+<li>
+<p>KERBEROS_TOKEN (KerberosToken) - Add a kerberos token.</p>
+</li>
+<li>
+<p>CUSTOM_TOKEN (CustomToken) - Add a "Custom" token from a CallbackHandler</p>
+</li>
+<li>
+<p>SIG_VER_PROP_FILE (signatureVerificationPropFile) - The path of the crypto property file to use for Signature verification.</p>
+</li>
+<li>
+<p>SIG_VER_PROP_REF_ID (signatureVerificationPropRefId) - The String ID that is used to store a reference to the Crypto object or
+the Crypto Properties object for Signature verification.</p>
+</li>
+<li>
+<p>ALLOW_RSA15_KEY_TRANSPORT_ALGORITHM (allowRSA15KeyTransportAlgorithm) - Whether to allow the RSA v1.5 Key Transport Algorithm or not. Default is
+"false".</p>
+</li>
+<li>
+<p>ADD_INCLUSIVE_PREFIXES (addInclusivePrefixes) - Whether to add an InclusiveNamespaces PrefixList as a
+CanonicalizationMethod child when generating Signatures using
+WSConstants.C14N_EXCL_OMIT_COMMENTS. Default is "true".</p>
+</li>
+<li>
+<p>ADD_USERNAMETOKEN_NONCE (addUsernameTokenNonce) - Whether to add a Nonce Element to a UsernameToken (for plaintext). Default
+is "false"</p>
+</li>
+<li>
+<p>ADD_USERNAMETOKEN_CREATED (addUsernameTokenCreated) - Whether to add a Created Element to a UsernameToken (for plaintext).
+Default is "false"</p>
+</li>
+<li>
+<p>ALLOW_USERNAMETOKEN_NOPASSWORD (allowUsernameTokenNoPassword) - Whether a UsernameToken with no password element is allowed. Default is
+"false".</p>
+</li>
+<li>
+<p>VALIDATE_SAML_SUBJECT_CONFIRMATION (validateSamlSubjectConfirmation) - Whether to validate the SubjectConfirmation requirements of a received
+SAML Token (sender-vouches or holder-of-key). Default is "true".</p>
+</li>
+<li>
+<p>INCLUDE_SIGNATURE_TOKEN (includeSignatureToken) - Whether to include the Signature Token in the security header as well or
+not (for IssuerSerial + Thumbprint cases). Default is "false"</p>
+</li>
+<li>
+<p>INCLUDE_ENCRYPTION_TOKEN (includeEncryptionToken) - Whether to include the Encryption Token in the security header as well or
+not (for IssuerSerial, Thumbprint, SKI cases). Default is "false"</p>
+</li>
+<li>
+<p>ENABLE_NONCE_CACHE (enableNonceCache) - Whether to cache UsernameToken nonces. Default is "true"</p>
+</li>
+<li>
+<p>ENABLE_TIMESTAMP_CACHE (enableTimestampCache) - Whether to cache Timestamp Created Strings (these are only cached in
+conjunction with a message Signature). Default is "true"</p>
+</li>
+<li>
+<p>ENABLE_SAML_ONE_TIME_USE_CACHE (enableSamlOneTimeUseCache) - Whether to cache SAML2 Token Identifiers, if the token contains a
+"OneTimeUse" Condition. Default is "true".</p>
+</li>
+<li>
+<p>USE_2005_12_NAMESPACE (use200512Namespace) - Whether to use the 2005/12 namespace for SecureConveration + DerivedKeys,
+or the older namespace. The default is "true"</p>
+</li>
+<li>
+<p>OPTIONAL_SIGNATURE_PARTS (optionalSignatureParts) - Parameter to define which parts of the request shall be signed, if they
+exist in the request.</p>
+</li>
+<li>
+<p>OPTIONAL_ENCRYPTION_PARTS (optionalEncryptionParts) - Parameter to define which parts of the request shall be encrypted, if they
+exist in the request.</p>
+</li>
+<li>
+<p>ENC_MGF_ALGO (encryptionMGFAlgorithm) - Defines which encryption mgf algorithm to use with the RSA OAEP Key
+Transport algorithm for encryption. The default is mgfsha1.</p>
+</li>
+<li>
+<p>VALIDATOR_MAP (validatorMap) - A map of QName, Object (Validator) instances to be used to validate
+tokens identified by their QName.</p>
+</li>
+<li>
+<p>NONCE_CACHE_INSTANCE (nonceCacheInstance) - A ReplayCache instance used to cache UsernameToken nonces. The default
+instance that is used is the EHCacheReplayCache.</p>
+</li>
+<li>
+<p>TIMESTAMP_CACHE_INSTANCE (timestampCacheInstance) - A ReplayCache instance used to cache Timestamp Created Strings. The default
+instance that is used is the EHCacheReplayCache.</p>
+</li>
+<li>
+<p>SAML_ONE_TIME_USE_CACHE_INSTANCE (samlOneTimeUseCacheInstance) - A ReplayCache instance used to cache SAML2 Token Identifier Strings (if
+the token contains a OneTimeUse Condition). The default instance that is used
+is the EHCacheReplayCache.</p>
+</li>
+<li>
+<p>PASSWORD_ENCRYPTOR_INSTANCE (passwordEncryptorInstance) - A PasswordEncryptor instance used to decrypt encrypted passwords in Crypto
+properties files. The default is the JasyptPasswordEncryptor.</p>
+</li>
+<li>
+<p>DERIVED_TOKEN_REFERENCE (derivedTokenReference) - This controls how deriving tokens are referenced.</p>
+</li>
+<li>
+<p>DERIVED_TOKEN_KEY_ID (derivedTokenKeyIdentifier) - This controls the key identifier of Derived Tokens.</p>
+</li>
+<li>
+<p>DERIVED_SIGNATURE_KEY_LENGTH (derivedSignatureKeyLength) - The length to use (in bytes) when deriving a key for Signature.</p>
+</li>
+<li>
+<p>DERIVED_ENCRYPTION_KEY_LENGTH (derivedEncryptionKeyLength) - The length to use (in bytes) when deriving a key for Encryption.</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect3">
+<h4 id="derived_key_and_secure_conversation_namespace_change">Derived Key and Secure Conversation namespace change</h4>
+<div class="paragraph">
+<p>In WSS4J 1.6.x, the default namespace used for Derived Key and Secure
+Conversation was the older "http://schemas.xmlsoap.org/ws/2005/02/sc"
+namespace. In WSS4J 2.0.0, the default namespace is now
+"http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512". To switch
+back to use the older namespace, you can set the new configuration property
+"USE_2005_12_NAMESPACE" to "false".</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="caching_changes">Caching changes</h4>
+<div class="paragraph">
+<p>WSS4J 2.0.0 uses three EhCache-based caches by default for the following
+scenarios, to prevent replay attacks:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>UsernameToken nonces</p>
+</li>
+<li>
+<p>Signed Timestamps</p>
+</li>
+<li>
+<p>SAML 2.0 OneTimeUse Assertions</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>If you are seeing a error about "replay attacks" after upgrade, then you may
+need to disable a particular cache.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="rsa_v1_5_key_transport_algorithm_not_allowed_by_default">RSA v1.5 Key Transport algorithm not allowed by default</h4>
+<div class="paragraph">
+<p>WSS4J supports two key transport algorithms, RSA v1.5 and RSA-OAEP. A number
+of attacks exist on RSA v1.5. Therefore, you should always use RSA-OAEP as the
+key transport algorithm. In WSS4J 2.0.0, the RSA v1.5 Key Transport algorithm
+is not allowed by default (as opposed to previous versions of WSS4J, where it
+is allowed). If you wish to allow it, then you must set the
+WSHandlerConstants.ALLOW_RSA15_KEY_TRANSPORT_ALGORITHM property to "true".</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="inclusivenamespaces_prefixlist_change">InclusiveNamespaces PrefixList change</h4>
+<div class="paragraph">
+<p>In WSS4J 1.6.x, when BSP Compliance was switched off on the outbound side, it
+had the effect that an InclusiveNamespaces PrefixList was not generated as a
+CanonicalizationMethod child of a Signature Element (as required by the BSP
+specification). In WSS4J 2.0.0, this is now controlled by a separate
+configuration tag "addInclusivePrefixes", which defaults to true.</p>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="new_features_available_in_apache_wss4j_2_0_0">New features available in Apache WSS4J 2.0.0</h3>
+<div class="sect3">
+<h4 id="overview_of_new_features">Overview of new features</h4>
+<div class="paragraph">
+<p>Apache WSS4J 2.0.0 delivers the following major new features:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Support for a streaming (StAX) based WS-Security implementation that
+covers all of the main specifications.</p>
+</li>
+<li>
+<p>A WS-SecurityPolicy model that can be shared between both DOM + StAX
+implementations.</p>
+</li>
+<li>
+<p>Support for "real-time" WS-SecurityPolicy validation for the StAX
+implementation.</p>
+</li>
+<li>
+<p>Support for the SOAP with Attachments (SWA) Profile 1.1 specification.</p>
+</li>
+<li>
+<p>Support for caching based on EhCache.</p>
+</li>
+<li>
+<p>Support for encrypting passwords in Crypto properties files using Jasypt.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="streaming_stax_based_ws_security_implementation">Streaming (StAX) based WS-Security implementation</h4>
+<div class="paragraph">
+<p>WSS4J 2.0.0 introduces a new streaming (StAX) based WS-Security implementation.
+Please see the dedicated <a href="streaming.html">page</a> for more information.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="ws_securitypolicy_support">WS-SecurityPolicy support</h4>
+<div class="paragraph">
+<p>WSS4J 2.0.0 introduces a new WS-SecurityPolicy model as part of the
+"wss4j-policy" module. This model can be shared between both the DOM and StAX
+WS-Security implementations. Web service stacks such as Apache CXF and
+Apache Axis/Rampart that use WSS4J for WS-Security no longer need to maintain
+their own model. In this way any bug fixes to the model will get picked up
+by all web service stacks that rely on WSS4J.</p>
+</div>
+<div class="paragraph">
+<p>In addition to the new WS-SecurityPolicy model, a significant new feature of
+WSS4J 2.0.0 is that the new streaming WS-Security implementation has the
+ability to perform "real-time" validation of a request against the set of
+applicable WS-SecurityPolicy policies. The DOM-based code in WSS4J does not
+have any concept of WS-SecurityPolicy, but instead processes an inbound
+request, and relies on the web service stack to compare the results against
+the applicable policies. The advantage of the streaming approach in WSS4J
+2.0.0 is that bogus requests can be rejected quicker, which may help to avoid
+DoS based scenarios.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="support_for_signing_and_encrypting_message_attachments">Support for signing and encrypting message attachments</h4>
+<div class="paragraph">
+<p>WSS4J 2.0.0 introduces support for signing and encrypting SOAP message
+attachments, via the the SOAP with Attachments (SWA) Profile 1.1 specification.
+Please see the dedicated <a href="attachments.html">page</a> for more
+information.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="replay_attack_detection_using_ehcache">Replay Attack detection using EhCache</h4>
+<div class="paragraph">
+<p>In WSS4J 1.6.x, a "ReplayCache" interface was introduced to cache tokens to
+guard against replay attacks for the following scenarios:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Signed Timestamps</p>
+</li>
+<li>
+<p>UsernameToken nonces</p>
+</li>
+<li>
+<p>SAML OneTimeUse Assertions</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>However, replay attack detection was not "switched on" by default in WSS4J
+1.6.x. In WSS4J 2.0.x, replay attack detection is enabled by default using
+an implementation of the "ReplayCache" interface based on EhCache. The
+following configuration tags can be used to configure caching:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>ConfigurationConstants.TIMESTAMP_CACHE_INSTANCE ("timestampCacheInstance"):
+This holds a reference to a ReplayCache instance used to cache Timestamp
+Created Strings. The default instance that is used is the EHCacheReplayCache.</p>
+</li>
+<li>
+<p>ConfigurationConstants.ENABLE_TIMESTAMP_CACHE ("enableTimestampCache"):
+Whether to cache Timestamp Created Strings (these are only cached in
+conjunction with a message Signature). The default value is "true".</p>
+</li>
+<li>
+<p>ConfigurationConstants.NONCE_CACHE_INSTANCE ("nonceCacheInstance"): This
+holds a reference to a ReplayCache instance used to cache UsernameToken
+nonces. The default instance that is used is the EHCacheReplayCache.</p>
+</li>
+<li>
+<p>ConfigurationConstants.ENABLE_NONCE_CACHE ("enableNonceCache"): Whether to
+cache UsernameToken nonces. The default value is "true".</p>
+</li>
+<li>
+<p>ConfigurationConstants. SAML_ONE_TIME_USE_CACHE_INSTANCE
+("samlOneTimeUseCacheInstance"): This holds a reference to a ReplayCache
+instance used to cache SAML2 Token Identifier Strings (if the token contains a
+OneTimeUse Condition). The default instance that is used is the
+EHCacheReplayCache.</p>
+</li>
+<li>
+<p>ConfigurationConstants.ENABLE_SAML_ONE_TIME_USE_CACHE
+("enableSamlOneTimeUseCache"): Whether to cache SAML2 Token Identifiers, if
+the token contains a "OneTimeUse" Condition. The default value is "true".</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="encrypting_passwords_in_crypto_property_files">Encrypting passwords in Crypto property files</h4>
+<div class="paragraph">
+<p>A typical example of the contents of a Crypto properties file (for Signature
+creation) is as follows:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>org.apache.wss4j.crypto.provider=org.apache.wss4j.common.crypto.Merlin</p>
+</li>
+<li>
+<p>org.apache.wss4j.crypto.merlin.keystore.type=jks</p>
+</li>
+<li>
+<p>org.apache.wss4j.crypto.merlin.keystore.password=security</p>
+</li>
+<li>
+<p>org.apache.wss4j.crypto.merlin.keystore.alias=wss40</p>
+</li>
+<li>
+<p>org.apache.wss4j.crypto.merlin.keystore.file=keys/wss40.jks</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Note that the password used to load the keystore is in cleartext. One of the
+new features of Apache WSS4J 2.0.0 is the ability to instead store a (BASE-64
+encoded) encrypted version of the keystore password in the Crypto properties
+file. A new PasswordEncryptor interface is defined to allow for the
+encryption/decryption of passwords. A default implementation is now provided
+based on Jasypt called JasyptPasswordEncryptor, which uses
+"PBEWithMD5AndTripleDES".</p>
+</div>
+<div class="paragraph">
+<p>The WSPasswordCallback class has an additional "usage" called
+WSPasswordCallback.PASSWORD_ENCRYPTOR_PASSWORD, which is used to return the
+master password for use with the PasswordEncryptor implementation. When WSS4J
+is loading a Crypto implementation via a properties file, and it encounters a
+password encrypted in the format "ENC(encoded encrypted password)", it queries
+a CallbackHandler for a password via this WSPasswordCallback usage tag. It is
+possible to pass a custom PasswordEncryptor implementation to WSS4J via the
+new configuration tag ConfigurationConstants.PASSWORD_ENCRYPTOR_INSTANCE
+("passwordEncryptorInstance").</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="miscellaneous_new_features">Miscellaneous new features</h4>
+<div class="paragraph">
+<p>Support was added in WSS4J 1.6.x to obtain a Kerberos ticket from a KDC (Key
+Distribution Center) and include it in the security header of a request, as
+well as to process the received token. However, there was no built-in way to
+extract the secret key from the ticket to secure the request. Instead it was
+up to the user to plug in a custom "KerberosTokenDecoder" implementation to
+support this behaviour. In WSS4J 2.0.0, a default KerberosTokenDecoder
+implementation is provided, and so WSS4J now supports signing/encrypting using
+Kerberos tokens by default.</p>
+</div>
+<div class="paragraph">
+<p>A new "CustomToken" Action is defined in WSS4J 2.0.0. If this action is
+defined, a token (DOM Element) will be retrieved from a CallbackHandler via
+WSPasswordCallback.Usage.CUSTOM_TOKEN and written out as is in the security
+header. This provides for an easy way to write out tokens that have been
+retrieved out of band. Another related new feature is the ability to associate
+an action with a particular set of keys/algorithms. This means that it is now
+possible to configure two different Signature actions, that use different
+keys/algorithms.</p>
+</div>
+<div class="paragraph">
+<p>Support for enforcing the Basic Security Profile (BSP) 1.1 specification was
+added in WSS4J 1.6.x. In WSS4J 2.0.0, it is possible to disable individual
+BSP Rules for a non-compliant request, instead of having to disable BSP
+enforcement altogether as for WSS4J 1.6.x. The RequestData class has a
+setIgnoredBSPRules method, that takes a list of BSPRule Objects as an argument.
+The BSPRule class contains a complete list of Basic Security Profile rules
+that are enforced in WSS4J.</p>
+</div>
+<div class="paragraph">
+<p>WSS4J 2.0.0 now enforces the SubjectConfirmation requirements of an inbound
+SAML Token, instead of leaving it to the web services stack. For
+sender-vouches, a Signature must be present that covers both the SOAP Body and
+the SAML Assertion. For holder-of-key, a Signature must be present that signs
+some part of the SOAP request using the key information contained in the SAML
+Subject. Note that a Signature can be either a message or transport level
+Signature (i.e. using TLS is acceptable). A new configuration tag is defined
+that allows the user to switch off this validation if required
+(ConfigurationConstants.VALIDATE_SAML_SUBJECT_CONFIRMATION -
+"validateSamlSubjectConfirmation").</p>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="apache_wss4j_1_6_0_migration_guide">Apache WSS4J 1.6.0 Migration Guide</h3>
+<div class="paragraph">
+<p>This page describes the new features of WSS4J 1.6.0, and the things to be
+aware of when upgrading from WSS4J 1.5.x. Note that WSS4J 1.6.x has now been
+replaced by WSS4J 2.0.x, please see the WSS4J 2.0.0 <a href="wss4j20.html">migration guide</a> for more information.</p>
+</div>
+<div class="sect3">
+<h4 id="new_features">New features</h4>
+<div class="paragraph">
+<p>This section describes the main new features that have been implemented in
+WSS4J 1.6. For more information on the changes, please click on the links. You
+can also review the
+<a href="https://issues.apache.org/jira/browse/WSS/fixforversion/12313718">list of JIRAs</a>
+that have been fixed in WSS4J 1.6.</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="http://coheigea.blogspot.com/2011/03/wss4j-16-jsr-105-support.html">JSR-105 support</a>:
+WSS4J 1.6 has been ported to use the JSR 105 API for XML Digital Signature.</p>
+</li>
+<li>
+<p><a href="http://coheigea.blogspot.com/2011/02/support-for-saml2-assertions-in-wss4j.html">SAML2 support</a>: WSS4J 1.6 includes full support for creating, manipulating and parsing SAML2
+assertions, via the Opensaml2 library.</p>
+</li>
+<li>
+<p>Performance work: A general code-rewrite has been done with a focus on improving performance,
+e.g. the <a href="http://coheigea.blogspot.com/2011/01/wss4j-16-actionprocessor-loading-change.html">changes</a> that have been made to processor loading.</p>
+</li>
+<li>
+<p><a href="http://coheigea.blogspot.com/2011/03/wss4j-16-basic-security-profile-11.html">Basic Security Profile 1.1 compliance</a>: WSS4J 1.6 provides support for the BSP 1.1 specification.</p>
+</li>
+<li>
+<p>JDK 1.5 port: The JDK 1.4 requirement of WSS4J 1.5.x has been dropped as part of this work.</p>
+</li>
+<li>
+<p><a href="http://coheigea.blogspot.com/2011/01/wss4j-16-crypto-property-change.html">Support for Crypto trust-stores</a>: WSS4J 1.6 separates the concept of keystore and truststores for
+Crypto implementations.</p>
+</li>
+<li>
+<p><a href="http://coheigea.blogspot.com/2011/04/wss4j-16-introducing-validators.html">New Validator interface</a>: WSS4J 1.6 moves all validation of security tokens into a new Validator
+interface, which allows for custom validation of specific tokens.</p>
+</li>
+<li>
+<p>Support for the Kerberos Token Profile (in WSS4J 1.6.2 and 1.6.3).</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="upgrade_notes">Upgrade notes</h4>
+<div class="paragraph">
+<p>This section describes the changes that have been made in WSS4J 1.6 that will impact on an existing
+user of WSS4J 1.5.x. Although WSS4J 1.6 is not 100% backwards compatible with 1.5.x, a general goal for
+the release was to restrict the API changes to those that were strictly necessary.</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>All Axis1 dependencies have been removed. Any user wishing to use WSS4J with Axis1 must use the
+WSS4J 1.5.x library. As Axis1 has been replaced by Axis2, this is unlikely to be an issue.</p>
+</li>
+<li>
+<p>A number of changes have been made to the Crypto interface. See
+<a href="http://coheigea.blogspot.com/2011/01/wss4j-16-crypto-property-change.html">here</a>,
+<a href="http://coheigea.blogspot.com/2011/02/wss4j-16-changes-to-crypto-interface.html">here</a>
+and <a href="http://coheigea.blogspot.com/2011/02/wss4j-16-change-to-publickey-validation.html">here</a>
+for an indepth explanation. In a nutshell, these changes are:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The BouncyCastle crypto implementation has been removed (replaced by Merlin)</p>
+</li>
+<li>
+<p>A new set of Merlin "truststore" configuration tags have been added. The behaviour of the old Merlin
+configuration tags will work exactly the same way in WSS4J 1.6.</p>
+</li>
+<li>
+<p>The CA certs are now <b>not</b> loaded by default.</p>
+</li>
+<li>
+<p>PublicKeys (from KeyValues) are now not handled by a PublicKeyCallback, but by the Crypto implementation
+directly.</p>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>If the WSEncryptionPart used to point to an element for signature or encryption does not either store
+the element directly, or store the wsu:Id, <strong>all</strong> DOM Elements that match the stored
+localname/namespace will be processed. See the
+<a href="http://ws.apache.org/wss4j/topics.html#Specifying_elements_to_sign_or_encrypt">Special Topics page</a>
+for more information.</p>
+</li>
+<li>
+<p>WSS4J 1.5.x used Opensaml1 to provide extremely limited support for SAML 1 assertions. WSS4J 1.6 has
+been upgraded to Opensaml2, and provides far more comprehensive support for SAML. See
+<a href="http://coheigea.blogspot.com/2011/02/support-for-saml2-assertions-in-wss4j.html">here</a> for
+more information on this. Some changes to be aware of are:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The way of creating SAML assertions via a properties file has completely changed. For example, see
+<a href="xref-test/org/apache/ws/security/saml/SamlTokenTest.html">SAML Token Test</a>.</p>
+</li>
+<li>
+<p>WSS4J 1.5.x ignored (enveloped) signatures on SAML (1.1) assertions - this is no longer the case, so
+deployments which do not set the correct keystore/truststore config for dealing with signature
+verification will fail.</p>
+</li>
+<li>
+<p>The SAMLTokenProcessor no longer saves all tokens as an "WSConstants.ST_UNSIGNED" action. It saves
+tokens that do not have an enveloped signature as this action, and token which <strong>do</strong> have an enveloped
+signature are saved as a "WSConstants.ST_SIGNED" action.</p>
+</li>
+<li>
+<p>The object that is saved as part of the action above has changed, from an Opensaml1 specific Assertion
+object, to an AssertionWrapper instance, which is a WSS4J specific object which encapsulates an
+Assertion, as well as some information corresponding to signature verification, etc.</p>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>The way that UsernameTokens are processed has been changed. See
+<a href="http://coheigea.blogspot.com/2011/02/usernametoken-processing-changes-in.html">here</a> for
+more information. Some important changes are:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The plaintext password case has exactly the same behaviour as the digest case. The identifier is now
+WSPasswordCallback.USERNAME_TOKEN and not WSPasswordCallback.USERNAME_TOKEN_UNKNOWN, and the
+CallbackHandler does not do any authentication, but must set the password on the callback.</p>
+</li>
+<li>
+<p>The custom password type case defaults to the same behaviour as the plaintext case, assuming
+wssConfig.getHandleCustomPasswordTypes() returns true.</p>
+</li>
+<li>
+<p>For the case of a username token with no password element, the default behaviour is simply to ignore it,
+and to store it as a new result of type WSConstants.UT_NOPASSWORD.</p>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Some changes have been made to the WSPasswordCallback identifiers, used to obtain passwords for various
+actions. For more information see
+<a href="http://coheigea.blogspot.com/2011/02/wspasswordcallback-changes-in-wss4j-16.html">here</a>. In
+a nutshell, these changes consist of:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The WSPasswordCallback KEY_NAME, USERNAME_TOKEN_UNKNOWN and WSPasswordCallback.ENCRYPTED_KEY_TOKEN
+identifiers have been removed.</p>
+</li>
+<li>
+<p>CUSTOM_TOKEN is not longer used in the processors to get a secret key.</p>
+</li>
+<li>
+<p>SECRET_KEY is a new identifier for finding secret keys. It replaces the occasionally incorrect use of
+CUSTOM_TOKEN, as well as KEY_NAME and ENCRYPTED_KEY_TOKEN.</p>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Timestamp validation and signature trust verification is not done by the WSHandler implementation
+any more, but is performed when the security header is processed.</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="wss4j_configuration">WSS4J configuration</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>This section describes how to use configure Apache WSS4J. This page only applies
+to WSS4J 2.x, and 1.6.x, a lot of the properties have changed since WSS4J 1.5.x.</p>
+</div>
+<div class="sect2">
+<h3 id="crypto_properties">Crypto properties</h3>
+<div class="paragraph">
+<p>Apache WSS4J uses the Crypto interface to get keys and certificates for
+encryption/decryption and for signature creation/verification. WSS4J ships
+with three implementations:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://github.com/apache/ws-wss4j/tree/master/ws-security-common/src/main/java/org/apache/wss4j/common/crypto/Merlin.java?view=markup">
+Merlin</a>: The standard implementation, based around two JDK keystores for
+key/cert retrieval, and trust verification.</p>
+</li>
+<li>
+<p><a href="https://github.com/apache/ws-wss4j/tree/master/ws-security-common/src/main/java/org/apache/wss4j/common/crypto/CertificateStore.java?view=markup">
+CertificateStore</a>: Holds an array of X509 Certificates. Can only be used
+for encryption and signature verification.</p>
+</li>
+<li>
+<p><a href="https://github.com/apache/ws-wss4j/tree/master/ws-security-common/src/main/java/org/apache/wss4j/common/crypto/MerlinDevice.java?view=markup">
+MerlinDevice</a>: Based on Merlin, allows loading of keystores using a null
+InputStream - for example on a smart-card device.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For more information on the Crypto implementations see the
+<a href="http://ws.apache.org/wss4j/topics.html#Crypto_Interface">Special
+Topics page</a>. It is possible to instantiate a Crypto implementation
+directly, but it can also be loaded via a properties file. For Apache WSS4J
+2.0.0 onwards, the property names ${PREFIX} below is "org.apache.wss4j.crypto".
+For Apache WSS4J 1.6.x, the property names ${PREFIX} below is
+"org.apache.ws.security.crypto". WSS4J 2.0.0 onwards will also accept the older
+${PREFIX} value. The property values for the standard Merlin implementation
+are as follows:</p>
+</div>
+<div class="sect3">
+<h4 id="general_properties">General properties</h4>
+<div class="ulist">
+<ul>
+<li>
+<p>${PREFIX}.provider - WSS4J specific provider used to create Crypto instances. Defaults to
+"org.apache.wss4j.common.crypto.Merlin".</p>
+</li>
+<li>
+<p>${PREFIX}.merlin.x509crl.file - The location of an (X509) CRL file to use.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="merlin_keystore_properties">Merlin Keystore Properties</h4>
+<div class="ulist">
+<ul>
+<li>
+<p>${PREFIX}.merlin.keystore.provider - The provider used to load keystores. Defaults to installed provider.</p>
+</li>
+<li>
+<p>${PREFIX}.merlin.cert.provider - The provider used to load certificates. Defaults to keystore provider.</p>
+</li>
+<li>
+<p>${PREFIX}.merlin.keystore.file - The location of the keystore</p>
+</li>
+<li>
+<p>${PREFIX}.merlin.keystore.password - The password used to load the keystore. Default value is "security".</p>
+</li>
+<li>
+<p>${PREFIX}.merlin.keystore.type - Type of keystore. Defaults to: java.security.KeyStore.getDefaultType())</p>
+</li>
+<li>
+<p>${PREFIX}.merlin.keystore.alias - The default keystore alias to use, if none is specified.</p>
+</li>
+<li>
+<p>${PREFIX}.merlin.keystore.private.password - The default password used to load the private key.</p>
+</li>
+<li>
+<p><strong>WSS4J 2.3.0/2.2.6</strong> ${PREFIX}.merlin.keystore.private.caching - Whether to enable caching when loading private keys or not. The default is true for WSS4J 2.3.0 and false for WSS4J 2.2.6. There is a significant performance gain for PKCS12 keys when caching is enabled.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="merlin_truststore_properties">Merlin TrustStore properties</h4>
+<div class="ulist">
+<ul>
+<li>
+<p>${PREFIX}.merlin.load.cacerts - Whether or not to load the CA certs in ${java.home}/lib/security/cacerts (default is false)</p>
+</li>
+<li>
+<p>${PREFIX}.merlin.truststore.file - The location of the truststore</p>
+</li>
+<li>
+<p>${PREFIX}.merlin.truststore.password - The truststore password. Defaults to "changeit".</p>
+</li>
+<li>
+<p>${PREFIX}.merlin.truststore.type - The truststore type. Defaults to: java.security.KeyStore.getDefaultType().</p>
+</li>
+<li>
+<p>${PREFIX}.merlin.truststore.provider - <strong>WSS4J 2.1.5</strong> The provider used to load truststores. By default it’s the same as the keystore provider. Set to an empty value to force use of the JRE’s default provider.</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="saml_properties">SAML properties</h3>
+<div class="paragraph">
+<p><strong>WSS4J 1.6.x only</strong> Apache WSS4J 1.6.x uses the SAMLIssuer interface to
+configure the creation and signing of a SAML Assertion. In Apache WSS4J 2.0.0,
+the SAMLIssuer functionality has been moved to the SAMLCallback, so that the
+CallbackHandler used to create a SAML Assertion is responsible for all of the
+signing configuration as well.</p>
+</div>
+<div class="paragraph">
+<p>WSS4J 1.6.x ships with a default "SAMLIssuerImpl" implementation. It is
+possible to instantiate a SAMLIssuer implementation directly, but it can also
+be loaded via a properties file. The property values are as follows:</p>
+</div>
+<div class="sect3">
+<h4 id="samlissuer_properties">SAMLIssuer properties</h4>
+<div class="ulist">
+<ul>
+<li>
+<p>org.apache.ws.security.saml.issuerClass - The SAML Issuer implementation (defaults to "org.apache.ws.security.saml.SAMLIssuerImpl").</p>
+</li>
+<li>
+<p>org.apache.ws.security.saml.issuer.cryptoProp.file - The crypto properties file corresponding to the issuer crypto instance, if the assertion is to
+be signed.</p>
+</li>
+<li>
+<p>org.apache.ws.security.saml.issuer.key.name - The KeyStore alias for the issuer key.</p>
+</li>
+<li>
+<p>org.apache.ws.security.saml.issuer.key.password - The KeyStore password for the issuer key.</p>
+</li>
+<li>
+<p>org.apache.ws.security.saml.issuer - The issuer name</p>
+</li>
+<li>
+<p>org.apache.ws.security.saml.issuer.sendKeyValue - Whether to send the key value or the X509Certificate. Default is "false".</p>
+</li>
+<li>
+<p>org.apache.ws.security.saml.issuer.signAssertion - Whether the SAMLIssuer implementation will sign the assertion or not. Default is
+"false".</p>
+</li>
+<li>
+<p>org.apache.ws.security.saml.callback - The name of the SAML CallbackHandler implementation used to populate the SAML Assertion.</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="configuration_tags">Configuration tags</h3>
+<div class="paragraph">
+<p>Apache WSS4J provides a set of configuration tags that can be used to configure
+both the DOM-based and StAX-based (WSS4J 2.0.0 onwards) outbound and inbound
+processing. As both DOM and StAX code are very similar, both approaches share
+a set of common configuration tags given in <a href="https://github.com/apache/ws-wss4j/tree/master/ws-security-common/src/main/java/org/apache/wss4j/common/ConfigurationConstants.java?view=markup">ConfigurationConstants</a>. Note
+that the WSS4J 1.6.x configuration class (WSHandlerConstants) extends this
+class in WSS4J 2.0.0, so there is no need to change any configuration code
+when upgrading.</p>
+</div>
+<div class="paragraph">
+<p>The configuration tags for Actions are as follows:</p>
+</div>
+<div class="sect3">
+<h4 id="action_configuration_tags">Action configuration tags</h4>
+<div class="ulist">
+<ul>
+<li>
+<p>ACTION (action) - The action to perform, e.g. ConfigurationConstants.TIMESTAMP</p>
+</li>
+<li>
+<p>NO_SECURITY (NoSecurity) - Do not perform any action, do nothing. Only applies to DOM code.</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> USERNAME_TOKEN_SIGNATURE (UsernameTokenSignature) - Perform a UsernameTokenSignature action.</p>
+</li>
+<li>
+<p>USERNAME_TOKEN (UsernameToken) - Perform a UsernameToken action.</p>
+</li>
+<li>
+<p>USERNAME_TOKEN_NO_PASSWORD (UsernameTokenNoPassword) - Used on the receiving side to specify a UsernameToken with no password</p>
+</li>
+<li>
+<p>SAML_TOKEN_UNSIGNED (SAMLTokenUnsigned) - Perform an unsigned SAML Token action.</p>
+</li>
+<li>
+<p>SAML_TOKEN_SIGNED (SAMLTokenSigned) - Perform a signed SAML Token action.</p>
+</li>
+<li>
+<p>SIGNATURE (Signature) - Perform a signature action.</p>
+</li>
+<li>
+<p><strong>WSS4J 2.3.0</strong> ENCRYPTION (Encryption) - Perform an encryption action.
+Note that for previous releases, this configuration tag was called ENCRYPT (Encrypt).</p>
+</li>
+<li>
+<p>TIMESTAMP (Timestamp) - Perform a Timestamp action.</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> SIGNATURE_DERIVED (SignatureDerived) - Perform a Signature action with derived keys.</p>
+</li>
+<li>
+<p><strong>WSS4J 2.3.0</strong> ENCRYPTION_DERIVED (EncryptionDerived) - Perform a Encryption action with derived keys.
+Note that for releases from 2.0.0 â 2.2.x, this configuration tag was called ENCRYPT_DERIVED (EncryptDerived).</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> SIGNATURE_WITH_KERBEROS_TOKEN (SignatureWithKerberosToken) - Perform a Signature action with a kerberos token. Only for StAX code.</p>
+</li>
+<li>
+<p><strong>WSS4J 2.3.0</strong> ENCRYPTION_WITH_KERBEROS_TOKEN (EncryptionWithKerberosToken) - Perform a Encryption action with a kerberos token. Only for StAX code.
+Note that for releases from 2.0.0 → 2.2.x, this configuration tag was called ENCRYPT_WITH_KERBEROS_TOKEN (EncryptWithKerberosToken).</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> KERBEROS_TOKEN (KerberosToken) - Add a kerberos token. Only for StAX code.</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> CUSTOM_TOKEN (CustomToken) - Add a "Custom" token from a CallbackHandler</p>
+</li>
+<li>
+<p><strong>WSS4J 1.6.x only</strong> SIGN_WITH_UT_KEY (UsernameTokenSignature) - Perform a .NET specific signature using a Username Token action.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="wshandler_user_configuration_tags">WSHandler User configuration tags</h4>
+<div class="paragraph">
+<p>The configuration tags for WSHandler user properties are as follows:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>ACTOR ("actor") - The actor or role name of the wsse:Security header.</p>
+</li>
+<li>
+<p>USER ("user") - The user’s name. Consult the Javadoc for an explanation of this property.</p>
+</li>
+<li>
+<p>ENCRYPTION_USER ("encryptionUser") - The user’s name for encryption. Consult the Javadoc for an explanation of
+this property.</p>
+</li>
+<li>
+<p>SIGNATURE_USER ("signatureUser") - The user’s name for signature. Consult the Javadoc for an explanation of
+this property.</p>
+</li>
+<li>
+<p>USE_REQ_SIG_CERT ("useReqSigCert") - A special value for ENCRYPTION_USER. Consult the Javadoc for an
+explanation of this property.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="callback_class_and_property_file_configuration_tags">Callback class and Property File configuration tags</h4>
+<div class="paragraph">
+<p>The configuration tags for callback class and property file configuration are
+summarised here:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>PW_CALLBACK_CLASS (passwordCallbackClass) - The CallbackHandler implementation class used to obtain passwords.</p>
+</li>
+<li>
+<p>PW_CALLBACK_REF (passwordCallbackRef) - The CallbackHandler implementation object used to obtain passwords.</p>
+</li>
+<li>
+<p>SAML_CALLBACK_CLASS (samlCallbackClass) - The CallbackHandler implementation class used to construct SAML Assertions.</p>
+</li>
+<li>
+<p>SAML_CALLBACK_REF (samlCallbackRef) - The CallbackHandler implementation object used to construct SAML Assertions.</p>
+</li>
+<li>
+<p><strong>WSS4J 1.6.x only</strong> ENC_CALLBACK_CLASS (embeddedKeyCallbackClass) - The CallbackHandler implementation class used to get the key associated
+with a key name.</p>
+</li>
+<li>
+<p><strong>WSS4J 1.6.x only</strong> ENC_CALLBACK_REF (embeddedKeyCallbackRef) - The CallbackHandler implementation object used to get the key associated
+with a key name.</p>
+</li>
+<li>
+<p>SIG_PROP_FILE (signaturePropFile) - The path of the crypto property file to use for Signature.</p>
+</li>
+<li>
+<p>SIG_PROP_REF_ID (signaturePropRefId) - The String ID that is used to store a reference to the Crypto object or
+the Crypto Properties object for Signature.</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> SIG_VER_PROP_FILE (signatureVerificationPropFile) - The path of the crypto property file to use for Signature verification.</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> SIG_VER_PROP_REF_ID (signatureVerificationPropRefId) - The String ID that is used to store a reference to the Crypto object or
+the Crypto Properties object for Signature verification.</p>
+</li>
+<li>
+<p>DEC_PROP_FILE (decryptionPropFile) - The path of the crypto property file to use for Decryption.</p>
+</li>
+<li>
+<p>DEC_PROP_REF_ID (decryptionPropRefId) - The String ID that is used to store a reference to the Crypto object or
+the Crypto Properties object for decryption.</p>
+</li>
+<li>
+<p>ENC_PROP_FILE (encryptionPropFile) - The path of the crypto property file to use for encryption.</p>
+</li>
+<li>
+<p>ENC_PROP_REF_ID (encryptionPropRefId) - The String ID that is used to store a reference to the Crypto object or
+the Crypto Properties object for encryption.</p>
+</li>
+<li>
+<p>SAML_PROP_FILE (samlPropFile) - The path of the property file to use for creating SAML Assertions.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="boolean_configuration_tags">Boolean configuration tags</h4>
+<div class="paragraph">
+<p>The configuration tags for properties that are configured via a boolean
+parameter (i.e. "true" or "false") are as follows:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>ENABLE_SIGNATURE_CONFIRMATION (enableSignatureConfirmation) - Whether to enable signature confirmation or not. Default is "false".</p>
+</li>
+<li>
+<p>MUST_UNDERSTAND (mustUnderstand) - Set the outbound MustUnderstand flag or not. Default is "true".</p>
+</li>
+<li>
+<p>IS_BSP_COMPLIANT (isBSPCompliant) - Whether or not to ensure compliance with the BSP 1.1 spec. Default is
+"true".</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> ADD_INCLUSIVE_PREFIXES (addInclusivePrefixes) - Whether to add an InclusiveNamespaces PrefixList as a
+CanonicalizationMethod child when generating Signatures using
+WSConstants.C14N_EXCL_OMIT_COMMENTS. Default is "true".</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> ADD_USERNAMETOKEN_NONCE (addUsernameTokenNonce) - Whether to add a Nonce Element to a UsernameToken (for plaintext). Default
+is "false"</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> ADD_USERNAMETOKEN_CREATED (addUsernameTokenCreated) - Whether to add a Created Element to a UsernameToken (for plaintext).
+Default is "false"</p>
+</li>
+<li>
+<p>HANDLE_CUSTOM_PASSWORD_TYPES (handleCustomPasswordTypes) - Whether to allow non-standard password types in a UsernameToken. Default
+is "false".</p>
+</li>
+<li>
+<p><strong>WSS4J 1.6.x only</strong> PASSWORD_TYPE_STRICT (passwordTypeStrict) - Whether to enable strict Username Token password type handling. Default is
+"false".</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> ALLOW_USERNAMETOKEN_NOPASSWORD (allowUsernameTokenNoPassword) - Whether a UsernameToken with no password element is allowed. Default is
+"false".</p>
+</li>
+<li>
+<p>REQUIRE_SIGNED_ENCRYPTED_DATA_ELEMENTS (requireSignedEncryptedDataElements) - Whether the engine needs to enforce EncryptedData elements are in a signed
+subtree of the document. Default is "false".</p>
+</li>
+<li>
+<p><strong>WSS4J 1.6.x only</strong> USE_DERIVED_KEY (useDerivedKey) - Whether to use the standard UsernameToken Key Derivation algorithm.
+Default is "true".</p>
+</li>
+<li>
+<p>ALLOW_NAMESPACE_QUALIFIED_PASSWORD_TYPES (allowNamespaceQualifiedPasswordTypes) - Whether (wsse) namespace qualified password types are accepted when
+processing UsernameTokens. Default is "false".</p>
+</li>
+<li>
+<p>ENABLE_REVOCATION (enableRevocation) - Whether to enable Certificate Revocation List (CRL) checking when
+verifying trust in a certificate. Default is "false".</p>
+</li>
+<li>
+<p>USE_ENCODED_PASSWORDS (useEncodedPasswords) - Set whether to treat passwords as binary values for Username Tokens.
+Default is "false". DOM code only.</p>
+</li>
+<li>
+<p>USE_SINGLE_CERTIFICATE (useSingleCertificate) - Whether to use a single certificate or a whole certificate chain to
+construct a BinarySecurityToken. Default is "true".</p>
+</li>
+<li>
+<p>USE_DERIVED_KEY_FOR_MAC (useDerivedKeyForMAC) - Whether to use the Username Token derived key for a MAC. Default is
+"true".</p>
+</li>
+<li>
+<p>TIMESTAMP_PRECISION (precisionInMilliseconds) - Set whether outbound timestamps have precision in milliseconds. Default is
+"true".</p>
+</li>
+<li>
+<p>TIMESTAMP_STRICT (timestampStrict) - Set whether to enable strict Timestamp handling, i.e. throw an exception if
+the current receiver time is past the Expires time of the Timestamp. Default
+is "true".</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.4/2.1.0</strong> REQUIRE_TIMESTAMP_EXPIRES (requireTimestampExpires) - Set the value of this parameter to true to require that a Timestamp must
+have an "Expires" Element. The default is "false".</p>
+</li>
+<li>
+<p>ENC_SYM_ENC_KEY (encryptSymmetricEncryptionKey) - Set whether to encrypt the symmetric encryption key or not. Default is
+"true".</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> ALLOW_RSA15_KEY_TRANSPORT_ALGORITHM (allowRSA15KeyTransportAlgorithm) - Whether to allow the RSA v1.5 Key Transport Algorithm or not. Default is
+"false".</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> VALIDATE_SAML_SUBJECT_CONFIRMATION (validateSamlSubjectConfirmation) - Whether to validate the SubjectConfirmation requirements of a received
+SAML Token (sender-vouches or holder-of-key). Default is "true".</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> INCLUDE_SIGNATURE_TOKEN (includeSignatureToken) - Whether to include the Signature Token in the security header as well or
+not (for IssuerSerial, Thumbprint, SKI cases). Default is "false"</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> INCLUDE_ENCRYPTION_TOKEN (includeEncryptionToken) - Whether to include the Encryption Token in the security header as well or
+not (for IssuerSerial, Thumbprint, SKI cases). Default is "false"</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> USE_2005_12_NAMESPACE (use200512Namespace) - Whether to use the 2005/12 namespace for SecureConveration + DerivedKeys,
+or the older namespace. The default is "true"</p>
+</li>
+<li>
+<p><strong>WSS4J 2.1.2/2.0.5</strong> GET_SECRET_KEY_FROM_CALLBACK_HANDLER (getSecretKeyFromCallbackHandler) - Whether to get a secret key from a CallbackHandler or not for encryption
+only. The default is false. If set to true WSS4J attempts to get the secret
+key from the CallbackHandler instead of generating a random key internally.</p>
+</li>
+<li>
+<p><strong>WSS4J 2.1.2/2.0.5</strong> STORE_BYTES_IN_ATTACHMENT (storeBytesInAttachment) - Whether to store bytes (CipherData or BinarySecurityToken) in an
+attachment. The default is false, meaning that bytes are BASE-64 encoded and
+"inlined" in the message. Setting this to true is more efficient, as it means
+that the BASE-64 encoding step can be skipped. For this to work, a
+CallbackHandler must be set on RequestData that can handle attachments.</p>
+</li>
+<li>
+<p><strong>WSS4J 2.1.2/2.0.5</strong> EXPAND_XOP_INCLUDE_FOR_SIGNATURE (expandXOPIncludeForSignature) - (Deprecated in 2.2.0). Whether to expand xop:Include Elements encountered when verifying a
+Signature. The default is true, meaning that the relevant attachment bytes are
+BASE-64 encoded and inserted into the Element. This ensures that the actual
+bytes are signed, and not just the reference.</p>
+</li>
+<li>
+<p><strong>WSS4J 2.2.0</strong> EXPAND_XOP_INCLUDE (expandXOPInclude) - Whether to search for and expand xop:Include Elements for encryption and
+signature (on the outbound side) or for signature verification (on the inbound
+side). The default is false on the outbound side and true on the inbound side.
+What this means on the inbound side, is that the relevant attachment bytes are
+BASE-64 encoded and inserted into the Element. This ensures that the actual
+bytes are signed, and not just the reference.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="non_boolean_configuration_tags">Non-boolean configuration tags</h4>
+<div class="paragraph">
+<p>The configuration tags for properties that are configured via a non-boolean
+parameter are as follows:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>PASSWORD_TYPE (passwordType) - The encoding of the password for a Username Token. The default is
+WSConstants.PW_DIGEST.</p>
+</li>
+<li>
+<p><strong>WSS4J 1.6.x only</strong> ENC_KEY_NAME (embeddedKeyName) - The text of the key name to be sent in the KeyInfo for encryption</p>
+</li>
+<li>
+<p><strong>WSS4J 1.6.x only</strong> ADD_UT_ELEMENTS (addUTElements) - Additional elements to add to a Username Token, i.e. "nonce" and "created".</p>
+</li>
+<li>
+<p>SIG_KEY_ID (signatureKeyIdentifier) - The key identifier type to use for signature. The default is "IssuerSerial".</p>
+</li>
+<li>
+<p>SIG_ALGO (signatureAlgorithm) - The signature algorithm to use. The default is set by the data in the
+certificate.</p>
+</li>
+<li>
+<p>SIG_DIGEST_ALGO (signatureDigestAlgorithm) - The signature digest algorithm to use. The default is SHA-1.</p>
+</li>
+<li>
+<p>SIG_C14N_ALGO (signatureC14nAlgorithm) - Defines which signature c14n (canonicalization) algorithm to use. The
+default is: "http://www.w3.org/2001/10/xml-exc-c14n#".</p>
+</li>
+<li>
+<p><strong>WSS4J 1.6.x only</strong> WSE_SECRET_KEY_LENGTH (wseSecretKeyLength) - The length of the secret (derived) key to use for the WSE UT_SIGN
+functionality.</p>
+</li>
+<li>
+<p>SIGNATURE_PARTS (signatureParts) - Parameter to define which parts of the request shall be signed. The SOAP
+body is signed by default.</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> OPTIONAL_SIGNATURE_PARTS (optionalSignatureParts) - Parameter to define which parts of the request shall be signed, if they
+exist in the request.</p>
+</li>
+<li>
+<p>DERIVED_KEY_ITERATIONS (derivedKeyIterations) - The number of iterations to use when deriving a key from a Username Token.
+The default is 1000.</p>
+</li>
+<li>
+<p>ENC_KEY_ID (encryptionKeyIdentifier) - The key identifier type to use for encryption. The default is
+"IssuerSerial".</p>
+</li>
+<li>
+<p>ENC_SYM_ALGO (encryptionSymAlgorithm) - The symmetric encryption algorithm to use. The default is AES-128.</p>
+</li>
+<li>
+<p>ENC_KEY_TRANSPORT (encryptionKeyTransportAlgorithm) - The algorithm to use to encrypt the generated symmetric key. The default is RSA-OAEP.</p>
+</li>
+<li>
+<p>ENC_DIGEST_ALGO (encryptionDigestAlgorithm) - The encryption digest algorithm to use with the RSA-OAEP key transport
+algorithm. The default is SHA-1.</p>
+</li>
+<li>
+<p>ENCRYPTION_PARTS (encryptionParts) - Parameter to define which parts of the request shall be encrypted. The
+SOAP body is encrypted in "Content" mode by default.</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> OPTIONAL_ENCRYPTION_PARTS (optionalEncryptionParts) - Parameter to define which parts of the request shall be encrypted, if they
+exist in the request.</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> ENC_MGF_ALGO (encryptionMGFAlgorithm) - Defines which encryption mgf algorithm to use with the RSA OAEP Key
+Transport algorithm for encryption. The default is mgfsha1.</p>
+</li>
+<li>
+<p>TTL_TIMESTAMP (timeToLive) - The time difference between creation and expiry time in seconds in the WSS
+Timestamp. The default is "300".</p>
+</li>
+<li>
+<p>TTL_FUTURE_TIMESTAMP (futureTimeToLive) - The time in seconds in the future within which the Created time of an
+incoming Timestamp is valid. The default is "60".</p>
+</li>
+<li>
+<p>TTL_USERNAMETOKEN (utTimeToLive) - The time difference between creation and expiry time in seconds in the WSS
+UsernameToken created element. The default is "300".</p>
+</li>
+<li>
+<p>TTL_FUTURE_USERNAMETOKEN (utFutureTimeToLive) - The time in seconds in the future within which the Created time of an
+incoming UsernameToken is valid. The default is "60".</p>
+</li>
+<li>
+<p>SIG_SUBJECT_CERT_CONSTRAINTS (sigSubjectCertConstraints) - A String (separated by the value specified for SIG_CERT_CONSTRAINTS_SEPARATOR)
+of regular expressions which will be applied to
+the subject DN of the certificate used for signature validation, after trust
+verification of the certificate chain associated with the certificate.</p>
+</li>
+<li>
+<p>SIG_ISSUER_CERT_CONSTRAINTS (sigIssuerCertConstraints) - A String (separated by the value specified for SIG_CERT_CONSTRAINTS_SEPARATOR)
+of regular expressions which will be applied to
+the issuer DN of the certificate used for signature validation, after trust
+verification of the certificate chain associated with the certificate.</p>
+</li>
+<li>
+<p><strong>WSS4J 2.2.3</strong> SIG_CERT_CONSTRAINTS_SEPARATOR (sigCertConstraintsSeparator) - The separator that is used to parse certificate constraints configured in the
+SIG_SUBJECT_CERT_CONSTRAINTS and SIG_ISSUER_CERT_CONSTRAINTS configuration tags. The default is ",".</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> VALIDATOR_MAP (validatorMap) - A map of QName, Object (Validator) instances to be used to validate
+tokens identified by their QName.</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> NONCE_CACHE_INSTANCE (nonceCacheInstance) - A ReplayCache instance used to cache UsernameToken nonces. The default
+instance that is used is the EHCacheReplayCache.</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> TIMESTAMP_CACHE_INSTANCE (timestampCacheInstance) - A ReplayCache instance used to cache Timestamp Created Strings. The default
+instance that is used is the EHCacheReplayCache.</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> SAML_ONE_TIME_USE_CACHE_INSTANCE (samlOneTimeUseCacheInstance) - A ReplayCache instance used to cache SAML2 Token Identifier Strings (if
+the token contains a OneTimeUse Condition). The default instance that is used
+is the EHCacheReplayCache.</p>
+</li>
+<li>
+<p><strong>WSS4J 2.0.0</strong> PASSWORD_ENCRYPTOR_INSTANCE (passwordEncryptorInstance) - A PasswordEncryptor instance used to decrypt encrypted passwords in Crypto
+properties files. The default is the JasyptPasswordEncryptor.</p>
+</li>
+<li>
[... 696 lines stripped ...]