cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r998367 - in /websites/production/cxf/content: cache/docs.pageCache docs/ws-trust.html
Date Tue, 27 Sep 2016 09:51:46 GMT
Author: buildbot
Date: Tue Sep 27 09:51:46 2016
New Revision: 998367

Log:
Production update by buildbot for cxf

Modified:
    websites/production/cxf/content/cache/docs.pageCache
    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-trust.html
==============================================================================
--- websites/production/cxf/content/docs/ws-trust.html (original)
+++ websites/production/cxf/content/docs/ws-trust.html Tue Sep 27 09:51:46 2016
@@ -211,7 +211,7 @@ org.apache.ws.security.crypto.merlin.key
     </property>
 </bean>
 </pre>
-</div></div><h3 id="WS-Trust-OnBehalfOf">OnBehalfOf</h3><p>The
OnBehalfOf capability allows an initiator to request a security token on behalf of somebody
else. The content of the OnBehalfOf element to be sent in the STS RequestSecurityToken call
can be set in one of two ways:</p><ol><li>By specifying a value for the
JAX-WS property SecurityConstants.STS_TOKEN_ON_BEHALF_OF ("ws-security.sts.token.on-behalf-of")</li><li>By
specifying a value for the STSClient.onBehalfOf property.</li></ol><p>For
either case, the value can be one of the following:</p><ul><li>A String</li><li>A
DOM Element</li><li>A CallbackHandler object to use to obtain the token</li></ul><h2
id="WS-Trust-WS-TrustusingSPNego">WS-Trust using SPNego</h2><p>As of CXF 2.4.7
and 2.5.3, CXF contains (client) support for WS-Trust using SPNego. See the following <a
shape="rect" class="external-link" href="http://coheigea.blogspot.com/2012/02/ws-trust-spnego-support-in-apache-cxf.html"
rel="nofollow">blog</a> for an explanati
 on of what this entails, and how to run some system tests in CXF for this feature.</p><h2
id="WS-Trust-WS-TrustusingXKMS">WS-Trust using XKMS</h2><p>Since CXF 2.7.7
Security Token Service (STS) can be configured to use <a shape="rect" href="xml-key-management-service-xkms.html">XKMS
</a>Crypto provider. In this case X509 certificates can be located centrally and managed
using standard XKMS interface. STS will automatically invoke XKMS client for locate or validate
corresponded X509 certificate. See the following <a shape="rect" class="external-link"
href="http://ashakirin.blogspot.de/2013/07/cxf-security-integrate-pki-to-security.html" rel="nofollow">blog</a>
for the details and sample.</p><p>This feature can be especially useful for STS
scenario with SymmetricKey. With this scenario, the STS and the WS consumer negotiate a symmetric
key:</p><ol><li>The WS-Client authenticates himself to STS and contributes
material to the creation of symmetric key.</li><li>The STS verifies WS-Clien
 t authentication and generates symmetric key using material received from WS-Client</li><li>The
STS encrypts symmetric key using WS-Service public key and inserts the encrypted key together
with security token into SAML assertion</li><li>The STS signs SAML assertion and
sends it together with key material for generation symmetric key to the WS-Client.</li><li>The
WS-Client generates short-lived symmetric key from own material and the key material from
the STS.</li><li>The WS-Client inserts the SAML token, into the message header.
It encrypts the message texts or/and signs the message with the generated symmetric key. It
then sends the user's message to the WS-Service.</li><li>The WS-Service checks
the signature in the SAML token and uses its private key to decrypt the symmetric key contained
in the SAML token.</li><li>The WS-Service verifies the signature of the WS-Client
(Holder-of-Key) with the decrypted symmetric key. In this way, the STS confirms that the Holder-of-Key
is the su
 bject (the user) in the assertion.</li><li>The WS-Service uses the symmetric
key to decrypt the message text.</li></ol><p>On the step (3) STS needs the
public key (certificate) of target WS-Service. Normally STS servers not only one, but multiple
services (restricted by url patterns in TokenServiceProvider). This can be a serious drawback
to manage public certificates of all services into STS local keystore.</p><p>XKMS
Crypto provider provides elegant solution of this using following configuration:</p><ul><li>encryptionUsername
(in StaticSTSProperties or jaxws:endpoint properties) should be set into special value: <em>useEndpointAsCertAlias</em>
(STSConstants.USE_ENDPOINT_AS_CERT_ALIAS)</li><li>encryptionCrypto should be set
to XKMS Crypto implementation</li><li>Service certificates should be saved into
XKMS under service endpoint (use Application <a shape="rect" class="external-link" href="http://urnapachecxfservice:endpoint"
rel="nofollow">"<em>urn:apache:cxf:service:endpoint</em>
 </a>" and service endpoint as identifier)</li></ul><p>In this case
STS recognizes encryptionName constant and will ask XKMS Crypto for the service certificate
using AppliesTo endpoint address.&#160;XKMS will locate service certificate using this
endpoint address.</p><p>STS can server multiple WS-Services and doesn't care about
services certificates locally - they are stored and managed in central XKMS repository.</p><p>The
following <a shape="rect" class="external-link" href="http://ashakirin.blogspot.de/2013/07/cxf-security-integrate-pki-to-security.html"
rel="nofollow">blog</a> explains the details and contains the sample code.</p><h2
id="WS-Trust-BlogsonWS-TrustinCXF">Blogs on WS-Trust in CXF</h2><p>Some blogs
for up-to-date information about WS-Trust and other security topics in CXF:<br clear="none">
<a shape="rect" class="external-link" href="http://coheigea.blogspot.com/" rel="nofollow">http://coheigea.blogspot.com/</a><br
clear="none"> <a shape="rect" class="external-link" hr
 ef="http://owulff.blogspot.com/" rel="nofollow">http://owulff.blogspot.com/</a></p></div>
+</div></div><h3 id="WS-Trust-OnBehalfOf">OnBehalfOf</h3><p>The
OnBehalfOf capability allows an initiator to request a security token on behalf of somebody
else. The content of the OnBehalfOf element to be sent in the STS RequestSecurityToken call
can be set in one of two ways:</p><ol><li>By specifying a value for the
JAX-WS property SecurityConstants.STS_TOKEN_ON_BEHALF_OF ("ws-security.sts.token.on-behalf-of")</li><li>By
specifying a value for the STSClient.onBehalfOf property.</li></ol><p>For
either case, the value can be one of the following:</p><ul><li>A String</li><li>A
DOM Element</li><li>A CallbackHandler object to use to obtain the token</li></ul><h2
id="WS-Trust-WS-TrustusingSPNego">WS-Trust using SPNego</h2><p>As of CXF 2.4.7
and 2.5.3, CXF contains (client) support for WS-Trust using SPNego. See the following <a
shape="rect" class="external-link" href="http://coheigea.blogspot.com/2012/02/ws-trust-spnego-support-in-apache-cxf.html"
rel="nofollow">blog</a> for an explanati
 on of what this entails, and how to run some system tests in CXF for this feature.</p><h2
id="WS-Trust-WS-TrustusingXKMS">WS-Trust using XKMS</h2><p>Since CXF 2.7.7
Security Token Service (STS) can be configured to use <a shape="rect" href="xml-key-management-service-xkms.html">XKMS
</a>Crypto provider. In this case X509 certificates can be located centrally and managed
using standard XKMS interface. STS will automatically invoke XKMS client for locate or validate
corresponded X509 certificate. See the following <a shape="rect" class="external-link"
href="http://ashakirin.blogspot.de/2013/07/cxf-security-integrate-pki-to-security.html" rel="nofollow">blog</a>
for the details and sample.</p><p>This feature can be especially useful for STS
scenario with SymmetricKey. With this scenario, the STS and the WS consumer negotiate a symmetric
key:</p><ol><li>The WS-Client authenticates himself to STS and contributes
material to the creation of symmetric key.</li><li>The STS verifies WS-Clien
 t authentication and generates symmetric key using material received from WS-Client</li><li>The
STS encrypts symmetric key using WS-Service public key and inserts the encrypted key together
with security token into SAML assertion</li><li>The STS signs SAML assertion and
sends it together with key material for generation symmetric key to the WS-Client.</li><li>The
WS-Client generates short-lived symmetric key from own material and the key material from
the STS.</li><li>The WS-Client inserts the SAML token, into the message header.
It encrypts the message texts or/and signs the message with the generated symmetric key. It
then sends the user's message to the WS-Service.</li><li>The WS-Service checks
the signature in the SAML token and uses its private key to decrypt the symmetric key contained
in the SAML token.</li><li>The WS-Service verifies the signature of the WS-Client
(Holder-of-Key) with the decrypted symmetric key. In this way, the STS confirms that the Holder-of-Key
is the su
 bject (the user) in the assertion.</li><li>The WS-Service uses the symmetric
key to decrypt the message text.</li></ol><p>On the step (3) STS needs the
public key (certificate) of target WS-Service. Normally STS servers not only one, but multiple
services (restricted by url patterns in TokenServiceProvider). This can be a serious drawback
to manage public certificates of all services into STS local keystore.</p><p>XKMS
Crypto provider provides elegant solution of this using following configuration:</p><ul><li>encryptionUsername
(in StaticSTSProperties or jaxws:endpoint properties) should be set into special value: <em>useEndpointAsCertAlias</em>
(STSConstants.USE_ENDPOINT_AS_CERT_ALIAS)</li><li>encryptionCrypto should be set
to XKMS Crypto implementation</li><li>Service certificates should be saved into
XKMS under service endpoint (use Application <a shape="rect" class="external-link" href="http://urnapachecxfserviceendpoint"
rel="nofollow">"<em>urn:apache:cxf:service:endpoint</em><
 /a>" and service endpoint as identifier)</li></ul><p>In this case STS
recognizes encryptionName constant and will ask XKMS Crypto for the service certificate using
AppliesTo endpoint address.&#160;XKMS will locate service certificate using this endpoint
address.</p><p>STS can server multiple WS-Services and doesn't care about services
certificates locally - they are stored and managed in central XKMS repository.</p><p>The
following <a shape="rect" class="external-link" href="http://ashakirin.blogspot.de/2013/07/cxf-security-integrate-pki-to-security.html"
rel="nofollow">blog</a> explains the details and contains the sample code.</p><h2
id="WS-Trust-BlogsonWS-TrustinCXF">Blogs on WS-Trust in CXF</h2><p>Some blogs
for up-to-date information about WS-Trust and other security topics in CXF:<br clear="none">
<a shape="rect" class="external-link" href="http://coheigea.blogspot.com/" rel="nofollow">http://coheigea.blogspot.com/</a><br
clear="none"> <a shape="rect" class="external-link" hre
 f="http://owulff.blogspot.com/" rel="nofollow">http://owulff.blogspot.com/</a><br
clear="none"><a shape="rect" class="external-link" href="http://janbernhardt.blogspot.com/"
rel="nofollow">http://janbernhardt.blogspot.com/</a></p></div>
            </div>
            <!-- Content -->
          </td>



Mime
View raw message