Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 2CC2A200B95 for ; Tue, 27 Sep 2016 11:51:54 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 2B4D4160AD3; Tue, 27 Sep 2016 09:51:54 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 1F3DD160AD2 for ; Tue, 27 Sep 2016 11:51:52 +0200 (CEST) Received: (qmail 37636 invoked by uid 500); 27 Sep 2016 09:51:52 -0000 Mailing-List: contact commits-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list commits@cxf.apache.org Received: (qmail 37627 invoked by uid 99); 27 Sep 2016 09:51:52 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Sep 2016 09:51:52 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id AF71CC0C0D for ; Tue, 27 Sep 2016 09:51:51 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.374 X-Spam-Level: * X-Spam-Status: No, score=1.374 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, KAM_LAZY_DOMAIN_SECURITY=1, KAM_LIVE=1, RP_MATCHES_RCVD=-1.426] autolearn=disabled Received: from mx2-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id btMVcAUANtYY for ; Tue, 27 Sep 2016 09:51:48 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx2-lw-eu.apache.org (ASF Mail Server at mx2-lw-eu.apache.org) with ESMTP id 541BE5FBDE for ; Tue, 27 Sep 2016 09:51:47 +0000 (UTC) Received: from svn01-us-west.apache.org (svn.apache.org [10.41.0.6]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 85201E0147 for ; Tue, 27 Sep 2016 09:51:46 +0000 (UTC) Received: from svn01-us-west.apache.org (localhost [127.0.0.1]) by svn01-us-west.apache.org (ASF Mail Server at svn01-us-west.apache.org) with ESMTP id 82C923A0478 for ; Tue, 27 Sep 2016 09:51:46 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r998367 - in /websites/production/cxf/content: cache/docs.pageCache docs/ws-trust.html Date: Tue, 27 Sep 2016 09:51:46 -0000 To: commits@cxf.apache.org From: buildbot@apache.org X-Mailer: svnmailer-1.0.9 Message-Id: <20160927095146.82C923A0478@svn01-us-west.apache.org> archived-at: Tue, 27 Sep 2016 09:51:54 -0000 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> -

OnBehalfOf

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:

  1. By specifying a value for the JAX-WS property SecurityConstants.STS_TOKEN_ON_BEHALF_OF ("ws-security.sts.token.on-behalf-of")
  2. By specifying a value for the STSClient.onBehalfOf property.

For either case, the value can be one of the following:

  • A String
  • A DOM Element
  • A CallbackHandler object to use to obtain the token

WS-Trust using SPNego

As of CXF 2.4.7 and 2.5.3, CXF contains (client) support for WS-Trust using SPNego. See the following blog for an explanati on of what this entails, and how to run some system tests in CXF for this feature.

WS-Trust using XKMS

Since CXF 2.7.7 Security Token Service (STS) can be configured to use XKMS 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 blog for the details and sample.

This feature can be especially useful for STS scenario with SymmetricKey. With this scenario, the STS and the WS consumer negotiate a symmetric key:

  1. The WS-Client authenticates himself to STS and contributes material to the creation of symmetric key.
  2. The STS verifies WS-Clien t authentication and generates symmetric key using material received from WS-Client
  3. The STS encrypts symmetric key using WS-Service public key and inserts the encrypted key together with security token into SAML assertion
  4. The STS signs SAML assertion and sends it together with key material for generation symmetric key to the WS-Client.
  5. The WS-Client generates short-lived symmetric key from own material and the key material from the STS.
  6. 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.
  7. 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.
  8. 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.
  9. The WS-Service uses the symmetric key to decrypt the message text.

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.

XKMS Crypto provider provides elegant solution of this using following configuration:

  • encryptionUsername (in StaticSTSProperties or jaxws:endpoint properties) should be set into special value: useEndpointAsCertAlias (STSConstants.USE_ENDPOINT_AS_CERT_ALIAS)
  • encryptionCrypto should be set to XKMS Crypto implementation
  • Service certificates should be saved into XKMS under service endpoint (use Application "urn:apache:cxf:service:endpoint " and service endpoint as identifier)

In this case STS recognizes encryptionName constant and will ask XKMS Crypto for the service certificate using AppliesTo endpoint address. XKMS will locate service certificate using this endpoint address.

STS can server multiple WS-Services and doesn't care about services certificates locally - they are stored and managed in central XKMS repository.

The following blog explains the details and contains the sample code.

Blogs on WS-Trust in CXF

Some blogs for up-to-date information about WS-Trust and other security topics in CXF:
http://coheigea.blogspot.com/
http://owulff.blogspot.com/

+

OnBehalfOf

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:

  1. By specifying a value for the JAX-WS property SecurityConstants.STS_TOKEN_ON_BEHALF_OF ("ws-security.sts.token.on-behalf-of")
  2. By specifying a value for the STSClient.onBehalfOf property.

For either case, the value can be one of the following:

  • A String
  • A DOM Element
  • A CallbackHandler object to use to obtain the token

WS-Trust using SPNego

As of CXF 2.4.7 and 2.5.3, CXF contains (client) support for WS-Trust using SPNego. See the following blog for an explanati on of what this entails, and how to run some system tests in CXF for this feature.

WS-Trust using XKMS

Since CXF 2.7.7 Security Token Service (STS) can be configured to use XKMS 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 blog for the details and sample.

This feature can be especially useful for STS scenario with SymmetricKey. With this scenario, the STS and the WS consumer negotiate a symmetric key:

  1. The WS-Client authenticates himself to STS and contributes material to the creation of symmetric key.
  2. The STS verifies WS-Clien t authentication and generates symmetric key using material received from WS-Client
  3. The STS encrypts symmetric key using WS-Service public key and inserts the encrypted key together with security token into SAML assertion
  4. The STS signs SAML assertion and sends it together with key material for generation symmetric key to the WS-Client.
  5. The WS-Client generates short-lived symmetric key from own material and the key material from the STS.
  6. 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.
  7. 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.
  8. 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.
  9. The WS-Service uses the symmetric key to decrypt the message text.

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.

XKMS Crypto provider provides elegant solution of this using following configuration:

  • encryptionUsername (in StaticSTSProperties or jaxws:endpoint properties) should be set into special value: useEndpointAsCertAlias (STSConstants.USE_ENDPOINT_AS_CERT_ALIAS)
  • encryptionCrypto should be set to XKMS Crypto implementation
  • Service certificates should be saved into XKMS under service endpoint (use Application "urn:apache:cxf:service:endpoint< /a>" and service endpoint as identifier)

In this case STS recognizes encryptionName constant and will ask XKMS Crypto for the service certificate using AppliesTo endpoint address. XKMS will locate service certificate using this endpoint address.

STS can server multiple WS-Services and doesn't care about services certificates locally - they are stored and managed in central XKMS repository.

The following blog explains the details and contains the sample code.

Blogs on WS-Trust in CXF

Some blogs for up-to-date information about WS-Trust and other security topics in CXF:
http://coheigea.blogspot.com/
http://owulff.blogspot.com/
http://janbernhardt.blogspot.com/