THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
XML
...
Key
...
Management
...
Service
...
(XKMS)
...
Use
...
case
...
CXF
...
security
...
uses
...
asymmetric
...
algorithms
...
for
...
different
...
purposes:
...
encryption
...
of
...
symmetric
...
keys
...
and
...
payloads,
...
signing
...
security
...
tokens
...
and
...
messages,
...
proof
...
of
...
possession.
...
Normally
...
the
...
public
...
keys
...
(in
...
form
...
of
...
X509
...
certificates)
...
are
...
stored
...
in
...
java
...
keystores.
...
For
...
example,
...
if
...
sender
...
encrypts
...
the
...
message
...
payload
...
sending
...
to
...
the
...
receiver,
...
he
...
should
...
have
...
access
...
to
...
receiver
...
certificate
...
saved
...
in
...
local
...
keystore.
...
The
...
sender
...
uses
...
this
...
certificate
...
for
...
message
...
encryption
...
and
...
receiver
...
decrypts
...
request
...
with
...
corresponded
...
own
...
private
...
key:
...
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 – they should be unpackaged and updated. Not really acceptable for enterprise environments.
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.
Normally it is a responsibility of Public Key Infrastructure (PKI) established in organization. PKI is responsible to create, manage, store, distribute, synchronize and revoke public certificates and certification authorities (CAs).
XKMS Specification
W3C specifies standard protocol to distribute and register public keys, certificates and CAs that can be used for XML-based cryptography, including signature and encryption: XML Key Management Specification (XKMS 2.0). XKMS can be used as standardized frontend to Public Key Infrastructure (PKI).
The XKMS Specification comprises two parts – 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. XKMS Service implements both parts of specification.
XKMS Design
Internal structure of XKMS service is represented on the following figure:
XKMS Service exposes standardized XKISS and XKRSS SOAP interfaces.
Input and output parameters as well as samples of SOAP messages are described in the specification XKMS 2.0.
XKMS implementation supports chain of responsibility design pattern chain-of-responsibility .
Each XKMS operation defines handler interface and provides one or more implementations of this interface. Handler implementations are connected into chain.
Operation implementation invokes handlers one after another from pre-configured chain until either all handlers will be processed or critical error will occur.
This design decision makes XKMS internal implementation quite flexible: it is easy to add/remove handlers, change their order, introduce handlers supporting new backends, etc.
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. Logic validation operation is organized in chain is well: first validation handler checks format and expire date of X509 certificate, next one checks certificate trust chain.
Data Formats
Input and output data formats are specified in XML Key Management Service Specification Version 2.0 (see XKMS 2.0). Anyway XKMS service supports only subset of specified requests and responses.
Restrictions of formats for request and responses are described in following table:
Element XPath | Supporting values | Description |
|---|---|---|
RootElement/QueryKeyBinding/UseKeyWith@Application | urn:ietf:rfc:2459 | Application specifies X509 SubjectDN in Identifier attribute. Used for normal users certificates |
RootElement/QueryKeyBinding/UseKeyWith@Application | urn:apache:cxf:service:soap |
...
Application |
...
specifies |
...
Service |
...
Id |
...
in |
...
Identifier |
...
attribute as {SERVICE_ |
...
NAMESPACE}SERVICE_NAME. |
...
Used |
...
for |
...
service |
...
certificates |
...
RootElement/QueryKeyBinding/UseKeyWith@Identifier |
...
X509 |
...
Subject |
...
DN |
...
or |
...
Service |
...
name |
...
as |
...
{SERVICE_ |
...
NAMESPACE |
...
}SERVICE_NAME |
...
Depending |
...
on |
...
Application |
...
attribute |
...
public |
...
key |
...
is |
...
identified |
...
as |
...
X509 |
...
Subject |
...
DN |
...
or |
...
Service |
...
nameservice |
...
certificates |
...
RootElement/UnverifiedKeyBinding/KeyInfo |
...
X509Data/X509Certificate |
...
Only |
...
X509Data |
...
with |
...
X509Certificate |
...
is |
...
supported |
Error Handling
Success and Fault Response formats are specified in XKMS 2.0. Error conditions in XKMS service are reported using ResultMajor and ResultMinor attributes in root response element.
XKMS Service uses following values for response codes:
ResultMajor
Value | Description |
|---|---|
Success | The operation succeeded. |
Receiver | An error occurred at the receiver. |
Sender | An error occurred that was due to the message sent by the sender. |
ResultMinor
Value | Description |
|---|---|
Failure | The service attempted to perform the request but the operation failed. |
NoMatch | No match was found for the search prototype provided. |
TooManyResponses | The request resulted in the number of responses that exceeded limit determined by the service. |
TimeInstantNotSupported | The receiver has refused the operation because it does not support the TimeInstant element. |