cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r852118 - in /websites/production/cxf/content: cache/docs.pageCache docs/ws-secureconversation.html docs/ws-security.html docs/ws-trust.html
Date Tue, 26 Feb 2013 21:48:08 GMT
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">&lt;map&gt;</span>
       ...
       &lt;!-- This reconfigures the processor implementation that WSS4j uses to 
-               process a WS-S Signature element. --&gt;
+               process a WS-Security Signature element. --&gt;
       <span class="code-tag">&lt;entry key=<span class="code-quote">"wss4j.processor.map"</span>&gt;</span>
         <span class="code-tag">&lt;map key-type=<span class="code-quote">"javax.xml.namespace.QName"</span>&gt;</span>
           <span class="code-tag">&lt;entry value=<span class="code-quote">"my.class"</span>&gt;</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>



Mime
View raw message