Ce contenu n'est pas disponible dans la langue sélectionnée.

1.2. Apache Camel Security


Overview

Figure 1.2, “Apache Camel Security Architecture” shows an overview of the basic options for securely routing messages between Apache Camel endpoints.

Figure 1.2. Apache Camel Security Architecture

Apache Camel Security Architecture

Alternatives for Apache Camel security

As shown in Figure 1.2, “Apache Camel Security Architecture”, you have the following options for securing messages:
  • Endpoint security—part (a) shows a message sent between two routes with secure endpoints. The producer endpoint on the left opens a secure connection (typically using SSL/TLS) to the consumer endpoint on the right. Both of the endpoints support security in this scenario.
    With endpoint security, it is typically possible to perform some form of peer authentication (and sometimes authorization).
  • Payload security—part (b) shows a message sent between two routes where the endpoints are both insecure. To protect the message from unauthorized snooping in this case, use a payload processor that encrypts the message before sending and decrypts the message after it is received.
    A limitation of payload security is that it does not provide any kind of authentication or authorization mechanisms.

Endpoint security

There are several Camel components that support security features. It is important to note, however, that these security features are implemented by the individual components, not by the Camel core. Hence, the kinds of security feature that are supported, and the details of their implementation, vary from component to component. Some of the Camel components that currently support security are, as follows:
  • JMS and ActiveMQ—SSL/TLS security and JAAS security for client-to-broker and broker-to-broker communication.
  • Jetty—HTTP Basic Authentication and SSL/TLS security.
  • CXF—SSL/TLS security and WS-Security.
  • Crypto—creates and verifies digital signatures in order to guarantee message integrity.
  • Netty—SSL/TLS security.
  • MINA—SSL/TLS security.
  • Cometd—SSL/TLS security.
  • glogin and gauth—authorization in the context of Google applications.

Payload security

Apache Camel provides the following payload security implementations, where the encryption and decryption steps are exposed as data formats on the marshal() and unmarshal() operations

XMLSecurity data format

The XMLSecurity data format is specifically designed to encrypt XML payloads. When using this data format, you can specify which XML element to encrypt. The default behavior is to encrypt all XML elements. This feature uses a symmetric encryption algorithm.

Crypto data format

The crypto data format is a general purpose encryption feature that can encrypt any kind of payload. It is based on the Java Cryptographic Extension and implements only symmetric (shared-key) encryption and decryption.
For more details, see http://camel.apache.org/crypto.html.
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.