Author: buildbot
Date: Tue Feb 26 21:48:07 2013
New Revision: 852118
Log:
Production update by buildbot for cxf
Modified:
websites/production/cxf/content/cache/docs.pageCache
websites/production/cxf/content/docs/ws-secureconversation.html
websites/production/cxf/content/docs/ws-security.html
websites/production/cxf/content/docs/ws-trust.html
Modified: websites/production/cxf/content/cache/docs.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/cxf/content/docs/ws-secureconversation.html
==============================================================================
--- websites/production/cxf/content/docs/ws-secureconversation.html (original)
+++ websites/production/cxf/content/docs/ws-secureconversation.html Tue Feb 26
21:48:07 2013
@@ -123,15 +123,15 @@ Apache CXF -- WS-SecureConversation
<div class="wiki-content">
<div id="ConfluenceContent"><h1><a shape="rect"
name="WS-SecureConversation-WSSecureConversation"></a>WS-SecureConversation</h1>
-<p>WS-SecureConversation support in CXF builds upon the <a shape="rect"
href="ws-securitypolicy.html" title="WS-SecurityPolicy">WS-SecurityPolicy</a>
implementation to handle the SecureConverstationToken policy assertions that
could be found in the WS-SecurityPolicy fragment. </p>
+<p>WS-SecureConversation support in CXF builds upon the <a shape="rect"
href="ws-securitypolicy.html" title="WS-SecurityPolicy">WS-SecurityPolicy</a>
implementation to handle the SecureConversationToken policy assertions that
could be found in the WS-SecurityPolicy fragment. </p>
<p><b>Note:</b> Because the WS-SecureConversation support builds on the
WS-SecurityPolicy support, this is currently only available to "wsdl first"
projects.</p>
-<p>One of the "problems" of WS-Security is that the use of strong encryption
keys for all communication extracts a hefty performance penalty on the
communication. WS-SecureConversation helps to aleviate that somewhat by
allowing the client and service to use the strong encryption at the start to
negotiatate a set of new security keys that will be used for furthur
communication. This can be a huge benefit if the client needs to send many
requests to the service. However, if the client only needs to send a single
request and then is discarded, WS-SecureConversation is actually slower as the
key negotiation requires and extra request/response to the server.</p>
+<p>One of the "problems" of WS-Security is that the use of strong encryption
keys for all communication extracts a hefty performance penalty on the
communication. WS-SecureConversation helps to alleviate that somewhat by
allowing the client and service to use the strong encryption at the start to
negotiatate a set of new security keys that will be used for furthur
communication. This can be a huge benefit if the client needs to send many
requests to the service. However, if the client only needs to send a single
request and then is discarded, WS-SecureConversation is actually slower as the
key negotiation requires an extra request/response to the server.</p>
-<p>With WS-SecureConversation, there are two Security policies that come into
affect:</p>
-<ol><li>The "outer" policy that describes the security requirements for
interacting with the actual endpoint. This will contain a
SecureConversationToken in it someplace.</li><li>The "bootstrap" policy that is
contained in the SecureConverstationToken. This policy is the policy in
affect when the client is negotiating the SecureConversation keys.</li></ol>
+<p>With WS-SecureConversation, there are two Security policies that come into
effect:</p>
+<ol><li>The "outer" policy that describes the security requirements for
interacting with the actual endpoint. This will contain a
SecureConversationToken in it someplace.</li><li>The "bootstrap" policy that is
contained in the SecureConversationToken. This policy is the policy in affect
when the client is negotiating the SecureConversation keys.</li></ol>
Modified: websites/production/cxf/content/docs/ws-security.html
==============================================================================
--- websites/production/cxf/content/docs/ws-security.html (original)
+++ websites/production/cxf/content/docs/ws-security.html Tue Feb 26 21:48:07
2013
@@ -335,7 +335,7 @@ CryptoCoverageChecker checker = <span cl
<h3><a shape="rect" name="WS-Security-CustomProcessors"></a>Custom
Processors</h3>
-<p>As of CXF 2.0.10 and 2.1.4, you can specify custom WSS4J Processor
configurations on the WSS4JInInterceptor. To activate this configuration
option, one provides a non-WSS4J defined property, wss4j.processor.map, to the
WSS4JInInterceptor as shown in the following Spring example. The same
configuratoin can be acheieved through the API as well. The key value is an
XML qualified name of the WS-S header element to process with the given
processor implementation. The entry values can be a String representing a
class name of the processor to instantiate, an Object implementing Processor,
or null to disable processing of the given WS-S header element.</p>
+<p>As of CXF 2.0.10 and 2.1.4, you can specify custom WSS4J Processor
configurations on the WSS4JInInterceptor. To activate this configuration
option, one provides a non-WSS4J defined property, wss4j.processor.map, to the
WSS4JInInterceptor as shown in the following Spring example. The same
configuration can be achieved through the API as well. The key value is an XML
qualified name of the WS-Security header element to process with the given
processor implementation. The entry values can be a String representing a
class name of the processor to instantiate, an Object implementing Processor,
or null to disable processing of the given WS-Security header element.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent
panelContent">
<pre class="code-xml">
@@ -344,7 +344,7 @@ CryptoCoverageChecker checker = <span cl
<span class="code-tag"><map></span>
...
<!-- This reconfigures the processor implementation that WSS4j uses
to
- process a WS-S Signature element. -->
+ process a WS-Security Signature element. -->
<span class="code-tag"><entry key=<span
class="code-quote">"wss4j.processor.map"</span>></span>
<span class="code-tag"><map key-type=<span
class="code-quote">"javax.xml.namespace.QName"</span>></span>
<span class="code-tag"><entry value=<span
class="code-quote">"my.class"</span>></span>
@@ -366,7 +366,7 @@ CryptoCoverageChecker checker = <span cl
<h3><a shape="rect" name="WS-Security-CustomActions"></a>Custom Actions</h3>
-<p>As of CXF 2.2.6, you can specify custom WSS4J Action configurations on the
WSS4JOutInterceptor. To activate this configuration option, one provides a
non-WSS4J defined property, wss4j.action.map, to the WSS4JOutInterceptor as
shown in the following Spring example. The same configuratoin can be acheieved
through the API as well. The key value is an integer representing the WSS4J
action identifier. The entry values can be a String representing a class name
of the action to instantiate or an Object implementing Action. This
configuration option allows you to override built-in action implementations or
add your own.</p>
+<p>As of CXF 2.2.6, you can specify custom WSS4J Action configurations on the
WSS4JOutInterceptor. To activate this configuration option, one provides a
non-WSS4J defined property, wss4j.action.map, to the WSS4JOutInterceptor as
shown in the following Spring example. The same configuration can be achieved
through the API as well. The key value is an integer representing the WSS4J
action identifier. The entry values can be a String representing a class name
of the action to instantiate or an Object implementing Action. This
configuration option allows you to override built-in action implementations or
add your own.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent
panelContent">
<pre class="code-xml">
@@ -553,7 +553,7 @@ keytool -<span class="code-keyword">impo
<h3><a shape="rect" name="WS-Security-Signing"></a>Signing</h3>
-<p>Signing a message is used to validate to the recipient that the message
could only have come from a certain sender, and that the message was not
altered in transit. It involves the sender encrypting a digest (hash) of the
message with its private key, and the recipient unencrypting the hash with the
sender's public key, and recalculating the digest of the message to make sure
the message was not altered in transit (i.e., that the digest values calculated
by both the sender and recipient are the same). For this process to occur you
must ensure that the Client's public key has been imported into the server's
keystore using keytool.</p>
+<p>Signing a message is used to validate to the recipient that the message
could only have come from a certain sender, and that the message was not
altered in transit. It involves the sender encrypting a digest (hash) of the
message with its private key, and the recipient decrypting the hash with the
sender's public key, and recalculating the digest of the message to make sure
the message was not altered in transit (i.e., that the digest values calculated
by both the sender and recipient are the same). For this process to occur you
must ensure that the Client's public key has been imported into the server's
keystore using keytool.</p>
<p>On the client side, our outgoing WS-Security properties will look like so
(see <a shape="rect" href="#WS-Security-addinterceptors">above</a> for code
sample):</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent
panelContent">
@@ -586,7 +586,7 @@ org.apache.ws.security.crypto.provider=o
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=keyStorePassword
org.apache.ws.security.crypto.merlin.keystore.alias=myAlias
-org.apache.ws.security.crypto.merlin.file=client_keystore.jks
+org.apache.ws.security.crypto.merlin.keystore.file=client_keystore.jks
</pre>
</div></div>
<p>On the server side, we need to configure our incoming WSS4J interceptor to
verify the signature using the Client's public key.</p>
@@ -602,7 +602,7 @@ inProps.put(WSHandlerConstants.SIG_PROP_
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=amex123
-org.apache.ws.security.crypto.merlin.file=server_keystore.jks
+org.apache.ws.security.crypto.merlin.keystore.file=server_keystore.jks
</pre>
</div></div>
Modified: websites/production/cxf/content/docs/ws-trust.html
==============================================================================
--- websites/production/cxf/content/docs/ws-trust.html (original)
+++ websites/production/cxf/content/docs/ws-trust.html Tue Feb 26 21:48:07 2013
@@ -135,13 +135,13 @@ Apache CXF -- WS-Trust
<p>WS-Trust solves this by using security tokens that are obtained from a
trusted Security Token Service. A client authenticates itself with the STS
based on policies and requirements defined by the STS. The STS then provides
a security token (example: a SAML token) that the client then uses to talk to
the target service. The service can validate that token to make sure it really
came from the trusted STS. </p>
-<p>When the WS-SecurityPolicy runtime in CXF encounters an IssuedToken
assertion in the policy, the runtime requries an instance of
org.apache.cxf.ws.security.trust.STSClient to talk to the STS to obtain the
required token. Since the STSClient is a WS-SecurityPolicy client, it will
need configuration items to be able to create it's secure SOAP messages to talk
to the STS. </p>
+<p>When the WS-SecurityPolicy runtime in CXF encounters an IssuedToken
assertion in the policy, the runtime requires an instance of
org.apache.cxf.ws.security.trust.STSClient to talk to the STS to obtain the
required token. Since the STSClient is a WS-SecurityPolicy client, it will
need configuration items to be able to create its secure SOAP messages to talk
to the STS. </p>
<h2><a shape="rect" name="WS-Trust-GeneralConfiguration"></a>General
Configuration</h2>
<p>There are several ways to configure the STSClient:</p>
-<p><b>Direct configuration of an STS bean in the properties:</b><br
clear="none">
+<p><b>Direct configuration of an STSClient bean in the properties:</b><br
clear="none">
In this scenario, a STSClient object is created directly as a property of the
client object. The wsdlLocation, service/endpoint names, etc... are all
configured in line for that client. </p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent
panelContent">
@@ -200,7 +200,7 @@ org.apache.ws.security.crypto.provider=o
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=KeystorePasswordHere
org.apache.ws.security.crypto.merlin.keystore.alias=ClientKeyAlias
-org.apache.ws.security.crypto.merlin.file=NameOfKeystore.jks
+org.apache.ws.security.crypto.merlin.keystore.file=NameOfKeystore.jks
</pre>
</div></div>
@@ -236,7 +236,7 @@ If an STSClient is not found from the ab
<h2><a shape="rect" name="WS-Trust-WSTrust1.4Support"></a>WS-Trust 1.4
Support</h2>
-<p>CXF provides limited support of WS-Trust 1.4. The currently supported
features are listed below.</p>
+<p>CXF supports some of the new functionality defined in the WS-Trust 1.4
specification. The currently supported features are listed below.</p>
<h3><a shape="rect" name="WS-Trust-ActAs%282.2.10%29"></a>ActAs (2.2.10)</h3>
<p>The ActAs capability allows an initiator to request a security token that
allows it to act as if it were somebody else. This capability becomes
important in composite services where intermediate services make additional
requests on-behalf of the true initiator. In this scenario, the relying party
(the final destination of an indirect service request) may require information
about the true origin of the request. The ActAs capability allows an
intermediary to request a token that can convey this information.</p>
