Index Changes

Message Security / Content Security


- Encryption: There are various phases a message goes through after receiving over transport. It could be in midst of an execution process within or outside of the organization, queued or persisted to a data store such as DB. The message or its specific content may contain privacy information of individuals or organizations. At no point should this data be compromised to un-authorized entities.

- Authorized Sender & Non-Repudiation: When exchanging messages across two systems, the two should be able to vouch that the message is from a valid entity. At any time in the future, neither party should repudiate sending the particular message. To achieve this goal, Signature is used where both the parties sign and verify the messages they exchange.

- Data Integrity: When exchanging messages, to ensure the data is not tampered on its way, Signature is used to enforce this.


All the below requirements are captured based on the feedback received from the field, the details of which are published on Security Questionnaire page.
  1. Sign and Verify a message.
  2. Encrypt and Decrypt a message.
  3. Compress and De-compress a message.
  4. Configure Keys / Certs as alias along with the Keystore information. More details on KeyStore are available at Keystore Management
  5. Support for various Crypto standards: PKCS#7 (or CMS), SMIME, XML Security, WS-Security, PGP (Please refer to Questionnaire section, Message Security (3.2)).
  6. The message may be a binary, ASCII or of any other character encoding.
  7. Ability to explicitly specify a Crypto Provider or use a default provider.
  8. All the above functionality should be available as an API.

Integration into OpenESB:

  1. Configure and Run service: Usage should be as simple as to configure and be able to use the functionality. No importing of jar files and other technical work. (Ref: Q 3.6 in the Questionnaire)
  2. Configure Security Properties: Properties such as
    1. Crypto Standard: PKCS#7 (or CMS), SMIME, XML Security, WS-Security, PGP etc..
    2. Based on the above selected standard, the property sheet differs. Eg: for XML Security, Transformations are required to be configured while for PKCS#7 it is not required. Also to note is that there are a few common properties across all standards.
    3. KeyStore Configuration: The alias of the key or cert required along with details such as KeyStore location, password, type etc.. are required to be configured. The list of certs / keys available in the KeyStore should be displayed to the user.The interface used for looking up additional information of keystore or modifying the keystore should be the same as the one described in KeyStore page .
  3. The configuration of security i.e sign / encrypt or other operations should be localized to the corresponding service User should have the ability to localize the configuration of Key / Cert alias and corresponding password to a particular service.
  4. Ability to dynamically configure / reset the Key / Cert alias without having to make changes to execution components. The change should occur without having to re-build or re-deploy the Service Assembly.
  5. Available as a Systemic service that is pluggable and not have to embed along with core business process.

Scenarios for Integrating into OpenESB:

More scenarios will be added as we go.
  1. Service requests for Crypto, expects the signed message back. This is largely addressed by a direct API invoke by the BizService.
  1. Between two Services crypto needs to be injected. Eg: Between a Service Unit and Binding component, message should be signed i.e the output of Service Unit before it reaches the BC, needs to be signed.

ESB Integration Options:

  1. As a QoS: As a standard Quality Of Service, Security could be exposed in the CASA editor where in for the corresponding Service Unit Security is configured.
    1. Pros:
      1. Since Security is a systemic quality, this approach would be consistent with general QoS configuration.
      2. Single point of configuration abstracted away from business logic.
    2. Cons:
      1. A QoS can only be invoked if the corresponding Service invokes it explicitly i.e every component for which a QoS is configured MUST invoke the QoS API. This would require changes to all the components.
      2. User does not have an option to map a message structure to crypto service input. In a multi-partner environment, the crypto input could vary depending on the Partner. Eg: the crypto algorithm could be RSAWithSHA1 for Partner 'A' while it could be DSAWithSHA1 for Partner 'B'.
      3. Sequence of crypto activities may have to be executed i.e sign after which encrypt. How do we define this flow?
      4. In case of Inbound i.e receiving message from external entities, the key or certificate information MAY not be available within the message - especially in case of asynchronous crypto such as PKCS. Only XML supports adding Key or Cert identity information within the message, even in which case it is optional. Once the message is received an unknown service needs to identify the key or cert based on certain meta data information available in the message. By using the QoS option, plugging in this additional service could be a challenge. The challenge includes support for various formats - XML, non-XML, B2B protocols etc..
  2. Service Engine / Unit: The high level operations - Sign. Verify, Encrypt, Decrypt, Compress, Decompress can be exposed explicitly for user to include as part of the flow. For eg: In a BPEL this would be an 'activity' in the flow.
    1. Pros:
      1. User has the ability to map runtime data to Crypto service input. Formats such as SMIME do not support encapsulation of complete data required for crypto service such as algorithms, key alias etc while formats such as XML Security support encapsulation but at the same time some of the properties are optional. Eg: For SMIME, the algorithm used for signing the content MUST be pre-negotiated. A preceding service to Sign service MUST lookup the configuration and map the output to corresponding properties for Sign. This is especially useful when algorithm or other details vary depending on who the consumer of the signed message is.
      2. Ability to localize the crypto configuration to a particular binding based on certain runtime message characteristics.
      3. A sequence of crypto activities can be easily configured by linking the sequence of activities.
    2. Cons:
      1. QoS exposed as a business node as part of the flow.
      2. If a sequence of crypto activities need to be executed, all the corresponding nodes are included in the flow which could add to the clutter in visual display. Added to this when the sequence decision is made at runtime based on the message (eg in AS2 protocol), the if conditions add more clutter.
  3. Aspect or Interceptor: Crypto Service can be wired in at deployment time instead of user having to explicitly do so. The user configures the required security properties at the Service Unit or if possible ideally at the link or binding between 2 service Units.
    1. Pros:
      1. Acts as a wire property and not embedded into the flow. Thereby avoids the clutter in the flow.
      2. A much more lean method where users with little knowledge on Security terminology can get started by setting the values in the config sheet rather than understanding the mapping of properties.
    2. Cons:
      1. Mapping / accessing runtime properties. This could probably be overcome by a robust implementation of Subject object which is required for other security services such as Authentication, Security Propagation etc.. The user credentials (or user pertaining data) could be obtained from Subject object that is propagated across. While non-user data such as Algorithm, KeyStore Config etc. may not be available and could require a config lookup. This could be overcome by configuring these details at the Service Unit that requests crypto service or even better the binding between two service units. If there is a way to access runtime content using variables i.e $var pattern, that option could pretty much remove this limitation.

Development Status:

Basic API has been checked into the SVN repository under Fuji project The check out command to use is:
svn checkout fuji --username username

The supported functionality thus far is:

  1. Sign / Verification: Supported formats thus far are PKCS#1, CMS (PKCS#7), SMIME. PKCS#1 uses the JDK provided API's while CMS and SMIME require third party implementations, for which the default is BouncyCastle.

Please note that this is a work-in-progress and the underlying implementation may be changed or cleaned up as required. But the API will not change.

All your feedback would be very much appreciated.

JSPWiki v2.4.100
« Home Index Changes Prefs
This page (revision-18) was last changed on 31-Jan-09 21:26 PM, -0800 by Sambas