cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r868893 - in /websites/production/cxf/content: cache/docs.pageCache docs/xml-key-management-service-xkms.html
Date Tue, 09 Jul 2013 10:48:32 GMT
Author: buildbot
Date: Tue Jul  9 10:48:32 2013
New Revision: 868893

Log:
Production update by buildbot for cxf

Modified:
    websites/production/cxf/content/cache/docs.pageCache
    websites/production/cxf/content/docs/xml-key-management-service-xkms.html

Modified: websites/production/cxf/content/cache/docs.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/cxf/content/docs/xml-key-management-service-xkms.html
==============================================================================
--- websites/production/cxf/content/docs/xml-key-management-service-xkms.html (original)
+++ websites/production/cxf/content/docs/xml-key-management-service-xkms.html Tue Jul  9 10:48:32
2013
@@ -133,46 +133,46 @@ Apache CXF -- XML Key Management Service
 
 <h2><a shape="rect" name="XMLKeyManagementService%28XKMS%29-Usecase"></a>Use
case</h2>
 
-<p>CXF uses asymmetric algorithms for different purposes: encryption of symmetric keys
and payloads, signing security tokens and messages, proof of possession.<br clear="none">
-Normally the public keys (in form of X509 certificates) are stored in java keystores.</p>
+<p>CXF uses asymmetric algorithms for different purposes: encryption of symmetric keys
and payloads, signing security tokens and messages, proof of possession, etc.<br clear="none">
+Normally the public keys (in the form of X509 certificates) are stored in java keystores.</p>
 
-<p>For example, if sender encrypts the message payload sending to the receiver, he
should have access to receiver certificate saved in local keystore. <br clear="none">
-The sender uses this certificate for message encryption and receiver decrypts request with
corresponded own private key:</p>
+<p>For example, if the sender encrypts the message payload sending to the receiver,
he should have access to the receiver certificate saved in the local keystore. <br clear="none">
+The sender uses this certificate for message encryption and receiver decrypts the request
with the corresponding private key:</p>
 
 
 <p><span class="image-wrap" style=""><img src="xml-key-management-service-xkms.data/classic-message-encryption.jpg"
style="border: 0px solid black"></span></p>
 
 
-<p>Seems to be OK? Imagine now that you have production environment with 100 different
clients of this service and service certificate is expired. You should reissue and replace
certificate in ALL client keystores! Even more, if keystores are packaged into war files or
OSGi bundles &#8211; they should be unpackaged and updated. Not really acceptable for
enterprise environments.</p>
+<p>Seems to be OK? Imagine now that you have a production environment with 100 different
clients of this service and the service certificate is expired. You should reissue and replace
the certificate in ALL client keystores! Even more, if keystores are packaged into war files
or OSGi bundles &#8211; they should be unpackaged and updated. Not really acceptable for
enterprise environments.</p>
 
 <p>Therefore large service landscapes support central certificates management. It means
that X509 certificates are not stored locally in keystores, but are provided and administrated
centrally.</p>
 
-<p>Normally it is a responsibility of <a shape="rect" class="external-link" href="http://en.wikipedia.org/wiki/Public-key_infrastructure"
rel="nofollow">Public Key Infrastructure</a> (PKI) established in organization. PKI
is responsible to create, manage, store, distribute, synchronize and revoke public certificates
and certification authorities (CAs).</p>
+<p>Normally it is a responsibility of <a shape="rect" class="external-link" href="http://en.wikipedia.org/wiki/Public-key_infrastructure"
rel="nofollow">Public Key Infrastructure</a> (PKI) established in the organization.
PKI is responsible to create, manage, store, distribute, synchronize and revoke public certificates
and certification authorities (CAs).</p>
 
 <h2><a shape="rect" name="XMLKeyManagementService%28XKMS%29-XKMSSpecification"></a>XKMS
Specification</h2>
 
-<p>W3C specifies protocol to distribute and register public keys, certificates and
CAs that can be used for XML-based cryptography, including signature and encryption: <a
shape="rect" class="external-link" href="http://www.w3.org/TR/xkms2/" rel="nofollow">XML
Key Management Specification</a> (XKMS 2.0). <br clear="none">
-The XKMS Specification comprises two parts &#8211; the XML Key Information Service Specification
(XKISS) describing the runtime aspects of key lookup and certificate validation and the XML
Key Registration Service Specification (XKRSS) describing the administrative aspects of registering,
renewing, revoking and recovering certificates. <br clear="none">
-XKMS Service implements both parts of specification.</p>
+<p>W3C specifies a protocol to distribute and register public keys, certificates and
CAs that can be used for XML-based cryptography, including signature and encryption: <a
shape="rect" class="external-link" href="http://www.w3.org/TR/xkms2/" rel="nofollow">XML
Key Management Specification</a> (XKMS 2.0). <br clear="none">
+The XKMS Specification comprises two parts &#8211; the XML Key Information Service Specification
(XKISS) describing the runtime aspects of key lookup and certificate validation, and the XML
Key Registration Service Specification (XKRSS) describing the administrative aspects of registering,
renewing, revoking and recovering certificates. <br clear="none">
+The XKMS Service implements both parts of specification.</p>
 
-<p>XKMS SOAP interface can be used as standard frontend to access Public Key Infrastructure
(PKI). Using XKMS message encryption scenario  message encryption picture will change in following
way:</p>
+<p>The XKMS SOAP interface can be used as a standard frontend to access the Public
Key Infrastructure (PKI). Using XKMS message encryption scenario, the message encryption picture
will change in the following way:</p>
 
 <p><span class="image-wrap" style=""><img src="xml-key-management-service-xkms.data/classic-message-encryption-PKI-XKMS.jpg"
style="border: 0px solid black"></span></p>
 
 <h3><a shape="rect" name="XMLKeyManagementService%28XKMS%29-XKMSDesign"></a>XKMS
Design</h3>
 
-<p>Internal structure of XKMS service is represented on the following figure:</p>
+<p>Internal structure of XKMS service is represented in the following figure:</p>
 
 <p><span class="image-wrap" style=""><img src="xml-key-management-service-xkms.data/XKMS-cxf.jpg"
style="border: 0px solid black"></span></p>
 
-<p>XKMS Service exposes SOAP interface specified in <a shape="rect" class="external-link"
href="http://www.w3.org/TR/xkms2/" rel="nofollow">XKMS 2.0</a>. <br clear="none">
-XKMS implementation realizes chain of <a shape="rect" class="external-link" href="http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern"
rel="nofollow">responsibility design pattern </a>.<br clear="none">
-Each XKMS operation defines handler interface and provides one or more implementations of
this interface. Handler implementations are connected into chain. <br clear="none">
-Operation implementation invokes handlers one after another from pre-configured chain until
either all handlers will be processed or critical error will occur. <br clear="none">
-This design makes XKMS internal implementation quite flexible: it is easy to add/remove handlers,
change their order, introduce handlers supporting new backends, etc. <br clear="none">
-For example certificate can be searched firstly in the LDAP repository by LDAP lookup handler
and, if it is not found there, additionally looked in remote PKI using appropriate lookup
handler. Validation operation logic is organized in chain is well: first validation handler
checks format and expire date of X509 certificate, next one checks certificate trust chain.</p>
+<p>The XKMS Service exposes a SOAP interface specified in <a shape="rect" class="external-link"
href="http://www.w3.org/TR/xkms2/" rel="nofollow">XKMS 2.0</a>. <br clear="none">
+The XKMS implementation realizes <a shape="rect" class="external-link" href="http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern"
rel="nofollow">chain of responsibility design pattern </a>.<br clear="none">
+Each XKMS operation defines a handler interface and provides one or more implementations
of this interface. Handler implementations are connected into a chain. <br clear="none">
+Operation implementation invokes handlers one after another from the pre-configured chain
until either all handlers will be processed or a critical error will occur. <br clear="none">
+This design makes the XKMS internal implementation quite flexible: it is easy to add/remove
handlers, change their order, introduce handlers supporting new backends, etc. <br clear="none">
+For example, a certificate can be searched firstly in the LDAP repository by LDAP lookup
handler and, if it is not found there, additionally looked for in a remote PKI using an appropriate
lookup handler. Validation operation logic is organized in a chain is well: first validation
handler checks format and expiry date of the X509 certificate, next one checks the certificate
trust chain.</p>
 
-<p>Currently XKMS Service supports simple file based and LDAP backends.<br clear="none">
+<p>Currently the XKMS Service supports simple file based and LDAP backends.<br clear="none">
 Sample spring configuration of XKMS handlers looks like:</p>
 <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
 <script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[
@@ -250,10 +250,9 @@ Sample spring configuration of XKMS hand
 ]]></script>
 </div></div>
 
-
-<p>dateValidator and trustedAuthorityValidator beans are implementations of Validator
interface for validity date and trusted chain validation. <br clear="none">
+<p>The dateValidator and trustedAuthorityValidator beans are implementations of the
Validator interface for date and trusted chain validation. <br clear="none">
 x509Locator and x509Register are implementations of Locator and Register interfaces for X509
certificates.<br clear="none">
-certificateRepo is repository implementation for LDAP backend. LdapSearch and LdapSchemaConfig
contain LDAP configuration described in the following table:</p>
+certificateRepo is the repository implementation for LDAP backend. LdapSearch and LdapSchemaConfig
contain LDAP configuration described in the following table:</p>
 
 <div class="table-wrap">
 <table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1"
class="confluenceTh"> Property </th><th colspan="1" rowspan="1" class="confluenceTh">
Sample Value </th><th colspan="1" rowspan="1" class="confluenceTh"> Description
</th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"> ldapServerConfig
arguments </td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td
colspan="1" rowspan="1" class="confluenceTd"> URL, baseDN and credentials of LDAP Server
</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"> certObjectClass
</td><td colspan="1" rowspan="1" class="confluenceTd"> inetOrgPerson </td><td
colspan="1" rowspan="1" class="confluenceTd"> LDAP object class used to store certificates
</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"> attrUID
</td><td colspan="1" rowspan="1" class="confluenceTd"> uid </td><td colspan="1"
rowspan="1" class="confluenceTd"> Attribute containing X509 subject DN </td></tr><tr><td
colspan="1" rowspan="1
 " class="confluenceTd"> attrIssuerID </td><td colspan="1" rowspan="1" class="confluenceTd">
manager </td><td colspan="1" rowspan="1" class="confluenceTd"> LDAP attribute
containing X509 issuer DN </td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">
attrSerialNumber </td><td colspan="1" rowspan="1" class="confluenceTd"> employeeNumber
</td><td colspan="1" rowspan="1" class="confluenceTd"> LDAP attribute containing
X509 serial number </td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">
attrCrtBinary </td><td colspan="1" rowspan="1" class="confluenceTd"> userCertificate
</td><td colspan="1" rowspan="1" class="confluenceTd"> LDAP attribute containing
X509 certificate content </td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">
constAttrNamesCSV </td><td colspan="1" rowspan="1" class="confluenceTd"> sn </td><td
colspan="1" rowspan="1" class="confluenceTd"> Comma separated list of mandatory LDAP attributes
</td></tr><tr><td colspan="1" rowspan="1" class="c
 onfluenceTd"> constAttrValuesCSV </td><td colspan="1" rowspan="1" class="confluenceTd">
X509 certificate </td><td colspan="1" rowspan="1" class="confluenceTd"> Comma
separated list of mandatory LDAP attributes values </td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"> serviceCertRDNTemplate </td><td
colspan="1" rowspan="1" class="confluenceTd"> cn=%s,ou=services </td><td colspan="1"
rowspan="1" class="confluenceTd"> Relative distinguished name for service certificates
</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"> serviceCertUIDTemplate
</td><td colspan="1" rowspan="1" class="confluenceTd"> cn=%s </td><td
colspan="1" rowspan="1" class="confluenceTd"> Template to transform service QName to DN
for storing into attrUID </td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">
trustedAuthorityFilter </td><td colspan="1" rowspan="1" class="confluenceTd">
(&amp;(objectClass=inetOrgPerson)(ou:dn:=CAs)) </td><td colspan="1" rowspan="1"
class="confluenceTd"
 > Filter to determine trusted CAs for trusted chain validation </td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"> intermediateFilter </td><td colspan="1"
rowspan="1" class="confluenceTd"> (objectClass=inetOrgPerson) </td><td colspan="1"
rowspan="1" class="confluenceTd"> Filter to determine intermediate certificates for trusted
chain validation </td></tr></tbody></table>
@@ -261,13 +260,13 @@ certificateRepo is repository implementa
 
 
 <h4><a shape="rect" name="XMLKeyManagementService%28XKMS%29-Supportedcertificatestypes."></a>Supported
certificates types.</h4>
-<p>XKMS distinguishes following types of X509 certificates:</p>
+<p>XKMS distinguishes between the following types of X509 certificates:</p>
 <div class="table-wrap">
 <table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1"
class="confluenceTh">Type</th><th colspan="1" rowspan="1" class="confluenceTh">Description</th></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"> User </td><td colspan="1" rowspan="1"
class="confluenceTd"> Normal user X509 certificate</td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"> Service </td><td colspan="1" rowspan="1"
class="confluenceTd"> Certificate identifies service. Required application "urn:apache:cxf:service:soap"
by lookup and registration. Identified as {SERVICE_ NAMESPACE}SERVICE_NAME </td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"> Trusted CA </td><td colspan="1"
rowspan="1" class="confluenceTd"> CAs used as trusted anchor by certificates validations.
Trusted CAs can be retrieved using trustedAuthorityFilter property </td></tr></tbody></table>
 </div>
 
 
-<p>XKMS service endpoint is configured in following way:</p>
+<p>XKMS service endpoint is configured in the following way:</p>
 
 <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
 <script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[
@@ -298,14 +297,14 @@ certificateRepo is repository implementa
 ]]></script>
 </div></div>
 
-<h4><a shape="rect" name="XMLKeyManagementService%28XKMS%29-IntegrationXKMSclientintoCXFruntime."></a>Integration
XKMS client into CXF runtime.</h4>
+<h4><a shape="rect" name="XMLKeyManagementService%28XKMS%29-IntegratingtheXKMSclientintotheCXFruntime."></a>Integrating
the XKMS client into the CXF runtime.</h4>
 
-<p>XKMS client can be integrated into CXF and WSS4J using custom Crypto provider implementation.
In this case XKMS service will be automatically invoked when WSS4J requires or validates certificate.
Details are described in this <a shape="rect" class="external-link" href="http://ashakirin.blogspot.de/2013/04/cxf-security-getting-certificates-from.html"
rel="nofollow">blog</a>. Sample XKMS based implementation of WSS4J Crypto interface
is contributed into XKMS Client component. </p>
+<p>The XKMS client can be integrated into CXF and WSS4J using a custom Crypto provider
implementation. In this case, the XKMS service will be automatically invoked when WSS4J requires
or validates a certificate. Details are described in this <a shape="rect" class="external-link"
href="http://ashakirin.blogspot.de/2013/04/cxf-security-getting-certificates-from.html" rel="nofollow">blog</a>.
A sample XKMS based implementation of WSS4J Crypto interface is contributed into the XKMS
Client component. </p>
 
 <h4><a shape="rect" name="XMLKeyManagementService%28XKMS%29-DataFormats"></a>Data
Formats</h4>
 
-<p>Input and output data formats are specified in XML Key Management Service Specification
Version 2.0 (see <span class="error">[XKMS 2.0]</span>). Anyway XKMS service supports
only subset of specified requests and responses.<br clear="none">
-Restrictions of formats for request and responses are described in following table:</p>
+<p>Input and output data formats are specified in XML Key Management Service Specification
Version 2.0 (see <a shape="rect" class="external-link" href="http://www.w3.org/TR/xkms2/"
rel="nofollow">XKMS 2.0</a>). The XKMS service supports only a subset of the specified
requests and responses.<br clear="none">
+Restrictions of formats for request and responses are described in the following table:</p>
 
 <div class="table-wrap">
 <table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1"
class="confluenceTh">Element XPath</th><th colspan="1" rowspan="1" class="confluenceTh">Supporting
values</th><th colspan="1" rowspan="1" class="confluenceTh">Description</th></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd">RootElement/QueryKeyBinding/UseKeyWith@Application
</td><td colspan="1" rowspan="1" class="confluenceTd"> urn:ietf:rfc:2459 </td><td
colspan="1" rowspan="1" class="confluenceTd"> Application specifies X509 SubjectDN in Identifier
attribute. Used for normal users certificates</td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd">RootElement/QueryKeyBinding/UseKeyWith@Application </td><td
colspan="1" rowspan="1" class="confluenceTd"> urn:apache:cxf:service:soap </td><td
colspan="1" rowspan="1" class="confluenceTd"> Application specifies Service Id in Identifier
attribute as {SERVICE_ NAMESPACE}SERVICE_NAME. Used for service certificates</td></tr><tr><td
colspan="1" rowspan="1" cl
 ass="confluenceTd">RootElement/QueryKeyBinding/UseKeyWith@Identifier </td><td
colspan="1" rowspan="1" class="confluenceTd"> X509 Subject DN or Service name as {SERVICE_
NAMESPACE}SERVICE_NAME </td><td colspan="1" rowspan="1" class="confluenceTd">
Depending on Application attribute public key is identified as X509 Subject DN or Service
nameservice certificates</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">RootElement/UnverifiedKeyBinding/KeyInfo
</td><td colspan="1" rowspan="1" class="confluenceTd"> X509Data/X509Certificate
</td><td colspan="1" rowspan="1" class="confluenceTd"> Only X509Data with X509Certificate
is supported</td></tr></tbody></table>
@@ -314,8 +313,8 @@ Restrictions of formats for request and 
 
 <h4><a shape="rect" name="XMLKeyManagementService%28XKMS%29-ErrorHandling"></a>Error
Handling</h4>
 
-<p>Success and Fault Response formats are specified in <span class="error">[XKMS
2.0]</span>. Error conditions in XKMS service are reported using ResultMajor and ResultMinor
attributes in root response element.<br clear="none">
-XKMS Service uses following values for response codes:</p>
+<p>Success and Fault Response formats are specified in <a shape="rect" class="external-link"
href="http://www.w3.org/TR/xkms2/" rel="nofollow">XKMS 2.0</a>. Error conditions
in XKMS service are reported using ResultMajor and ResultMinor attributes in the root response
element.<br clear="none">
+The XKMS Service uses the following values for response codes:</p>
 
 <p>ResultMajor</p>
 <div class="table-wrap">
@@ -332,7 +331,7 @@ XKMS Service uses following values for r
 
 <h4><a shape="rect" name="XMLKeyManagementService%28XKMS%29-Deployment"></a>Deployment</h4>
 
-<p>XKMS Service can be deployed into web and OSGi containers. Service implementation
was tested with Tomcat and Karaf.</p>
+<p>The XKMS Service can be deployed into web and OSGi containers. The Service implementation
was tested with Tomcat and Karaf.</p>
 
 <h4><a shape="rect" name="XMLKeyManagementService%28XKMS%29-SampleRequestsandResponses"></a>Sample
Requests and Responses</h4>
 <p>Sample request for Locate operation:</p>
@@ -369,7 +368,7 @@ XKMS Service uses following values for r
             &lt;ns2:UnverifiedKeyBinding&gt;
                 &lt;ns4:KeyInfo&gt;
                     &lt;ns4:X509Data&gt;
-                        &lt;ns4:X509Certificate&gt;É &lt;/ns4:X509Certificate&gt;
+                        &lt;ns4:X509Certificate&gt;… &lt;/ns4:X509Certificate&gt;
                     &lt;/ns4:X509Data&gt;
                 &lt;/ns4:KeyInfo&gt;
             &lt;/ns2:UnverifiedKeyBinding&gt;



Mime
View raw message