LibraryPrintFeedback

Security Guide

Version 7.1

December 2012
Trademark Disclaimer
Third Party Acknowledgements

Updated: 08 Jan 2014

Table of Contents

1. Security Architecture
OSGi Container Security
Apache ActiveMQ Security
Apache Camel Security
2. Securing the Fuse ESB Enterprise Container
JAAS Authentication
Default JAAS Realm
Defining JAAS Realms
JAAS Properties Login Module
JAAS OSGi Config Login Module
JAAS Public Key Login Module
JAAS JDBC Login Module
JAAS LDAP Login Module
Encrypting Stored Passwords
Enabling LDAP Authentication
Configuring Roles for the Administrative Protocols
Using Encrypted Property Placeholders
3. Securing the Web Console
4. Securing an Apache ActiveMQ Broker
Tutorial I: SSL/TLS Security
Broker JAAS Authentication
Tutorial II: JAAS Authentication
5. Securing the Camel ActiveMQ Component
Secure ActiveMQ Connection Factory
Tutorial III: Camel ActiveMQ Component
6. Securing the Camel Jetty Component
Enabling SSL/TLS Security
BASIC Authentication with JAAS
7. Securing the Camel CXF Component
The Camel CXF Proxy Demonstration
Securing the Web Services Proxy
Deploying the Apache Camel Route
Securing the Web Services Client
8. LDAP Authentication Tutorial
Tutorial Overview
Set-up a Directory Server and Browser
Add User Entries to the Directory Server
Enable LDAP Authentication in the OSGi Container
Configuring Access to OSGi Administrative Functions
Enable SSL/TLS on the LDAP Connection
A. Managing Certificates
What is an X.509 Certificate?
Certification Authorities
Commercial Certification Authorities
Private Certification Authorities
Certificate Chaining
Special Requirements on HTTPS Certificates
Creating Your Own Certificates
B. ASN.1 and Distinguished Names
ASN.1
Distinguished Names
Index

List of Figures

1.1. OSGi Container Security Architecture
1.2. Apache ActiveMQ Security Architecture
1.3. Apache Camel Security Architecture
6.1. Untrusted Certificate Warning
6.2. Untrusted Certificate Warning
7.1. Camel CXF Proxy Overview
7.2. WS Endpoint Implicitly Configured by httpj:engine-factory Element
7.3. Client Proxy Implicitly Configured by http:conduit Element
8.1. New LDAP Connection Wizard
8.2. Authentication Step of New LDAP Connection
8.3. New Entry Wizard
8.4. Distinguished Name Step of New Entry Wizard
8.5. Attributes Step of New Entry Wizard
8.6. Obtaining the Certificate
A.1. A Certificate Chain of Depth 2
A.2. A Certificate Chain of Depth 3

List of Tables

2.1. Flags for Defining a JAAS Module
2.2. Properties for the Fuse ESB Enterprise LDAP Login Module
B.1. Commonly Used Attribute Types

List of Examples

2.1. JAAS Blueprint Namespace
2.2. Defining a JAAS Realm in Blueprint XML
2.3. Standard JAAS Properties
2.4. Blueprint JAAS Properties
2.5. Configuring a JAAS Realm
2.6. Fuse ESB Enterprise LDAP JAAS Login Module
2.7. Configuring a JAAS Realm that Uses LDAP Authentication
2.8. Property File with an Encrypted Property
2.9. Encrypted Property Namespaces
2.10. Aries Placeholder Extension
2.11. Jasypt Blueprint Configuration
2.12. Jasypt Blueprint Configuration
2.13. Installing the Jasypt Feature
3.1. Pax Web Property for Disabling the HTTP Port
3.2. Pax Web Property for Enabling the HTTPS Port
3.3. Pax Web Property for Enabling the HTTPS Port
3.4. Configuration for Web Console to use SSL
5.1. Defining a Secure Connection Factory Bean
7.1. The ReportIncidentEndpointService WSDL Service
7.2. httpj:engine-factory Element with SSL/TLS Enabled
7.3. ReportIncidentRoutesTest Java client
7.4. http:conduit Element with SSL/TLS Enabled
8.1. Blueprint JAAS Realm
8.2. Web console configuration for a specific realm
8.3. LDAP Configuration for Using SSL/TLS
A.1. OpenSSL Configuration
A.2. Creating a CA Certificate
A.3. Creating a CSR
A.4. Converting a Signed Certificate to PEM
A.5. Importing a Certificate Chain
A.6. Adding a CA to the Trust Store
A.7. Creating a Certificate and Private Key using Keytool
A.8. Signing a CSR

Figure 1.1 shows an overview of the security infrastructure that is used across the container and is accessible to all bundles deployed in the container. This common security infrastructure currently consists of a mechanism for making JAAS realms (or login modules) available to all application bundles. Other aspects of security are currently implemented separately in each of the Fuse ESB Enterprise component products (Apache ActiveMQ, Apache Camel, and Apache CXF).


A JAAS realm or login module is a plug-in module that provides authentication and authorization data to Java applications, as defined by the Java Authentication and Authorization Service (JAAS) specification.

Fuse ESB Enterprise supports a special mechanism for defining JAAS login modules (in either a Spring or a blueprint file), which makes the login module accessible to all bundles in the container. This makes it easy for multiple applications running in the OSGi container to consolidate their security data into a single JAAS realm.

You can administer the OSGi container remotely either by connecting to the console port with a Karaf client or using the Karaf ssh:ssh command (see Using Remote Connections to Manage a Container in Configuring and Running Fuse ESB Enterprise). The console port is secured by a JAAS login feature that connects to the karaf realm. Users that try to connect to the console port will be prompted to enter a username and password that must match one of the accounts from the karaf realm.

Figure 1.2 shows an overview of the Apache ActiveMQ security architecture. The main security features supported by Apache ActiveMQ are the SSL/TLS security layer and the JAAS security layer. The SSL/TLS security layer provides message encryption and identifies the broker to its clients, while the JAAS security layer identifies clients to the broker.


Figure 1.3 shows an overview of the basic options for securely routing messages between Apache Camel endpoints.


As shown in Figure 1.3, 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.

When defining a JAAS realm in the OSGi container, you cannot put the definitions in a conventional JAAS login configuration file. Instead, the OSGi container uses a special jaas:config element for defining JAAS realms in a blueprint configuration file. The JAAS realms defined in this way are made available to all of the application bundles deployed in the container, making it possible to share the JAAS security infrastructure across the whole container.

The syntax for the jaas:config element is shown in Example 2.2.


The elements are used as follows:

jaas:config

Defines the JAAS realm. It has the following attributes:

  • name—specifies the name of the JAAS realm.

  • rank—specifies an optional rank for resolving naming conflicts between JAAS realms . When two or more JAAS realms are registered under the same name, the OSGi container always picks the realm instance with the highest rank.

jaas:module

Defines a JAAS login module in the current realm. jaas:module has the following attributes:

The contents of a jaas:module element is a space separated list of property settings, which are used to initialize the JAAS login module instance. The specific properties are determined by the JAAS login module and must be put into the proper format.

[Note]Note

You can define multiple login modules in a realm.

Fuse ESB Enterprise uses the same properties as a standard Java login configuration file, however Fuse ESB Enterprise requires that they are specified slightly differently. To see how the Fuse ESB Enterprise approach to defining JAAS realms compares with the standard Java login configuration file approach, consider how to convert the login configuration shown in Example 2.3, which defines the PropertiesLogin realm using the Apache ActiveMQ properties login module class, PropertiesLoginModule:


The equivalent JAAS realm definition, using the jaas:config element in a blueprint file, is shown in Example 2.4.


[Important]Important

You do not use double quotes for JAAS properties in the blueprint configuration.

The following classes implement the JAAS OSGi config login module:

[Note]Note

There is no backing engine factory for the OSGi config login module, which means that this module cannot be managed using the jaas:* console commands.

The following classes implement the JAAS public key login module:

[Note]Note

There is no backing engine factory for the public key login module, which means that this module cannot be managed using the jaas:* console commands.

The JAAS JDBC login module supports the following options:

datasource

The JDBC data source, specified either as an OSGi service or as a JNDI name. You can specify a data source's OSGi service using the following syntax:

osgi:ServiceInterfaceName[/ServicePropertiesFilter]

The ServiceInterfaceName is the interface or class that is exported by the data source's OSGi service (usually javax.sql.DataSource).

Because multiple data sources can be exported as OSGi services in a container, it is usually necessary to specify a filter, ServicePropertiesFilter, to select the particular data source that you want. Filters on OSGi services are applied to the service property settings and follow a syntax that is borrowed from LDAP filter syntax.

query.password

The SQL query that retrieves the user's password. The query can contain a single question mark character, ?, which is substituted by the username at run time.

query.role

The SQL query that retrieves the user's roles. The query can contain a single question mark character, ?, which is substituted by the username at run time.

insert.user

The SQL query that creates a new user entry. The query can contain two question marks, ?, characters: the first question mark is substituted by the username and the second question mark is substituted by the password at run time.

insert.role

The SQL query that adds a role to a user entry. The query can contain two question marks, ?, characters: the first question mark is substituted by the username and the second question mark is substituted by the role at run time.

delete.user

The SQL query that deletes a user entry. The query can contain a single question mark character, ?, which is substituted by the username at run time.

delete.role

The SQL query that deletes a role from a user entry. The query can contain two question marks, ?, characters: the first question mark is substituted by the username and the second question mark is substituted by the role at run time.

delete.roles

The SQL query that deletes multiple roles from a user entry. The query can contain a single question mark character, ?, which is substituted by the username at run time.

After the data source has been instantiated and exported as an OSGi service, you are ready to configure the JDBC login module. In particular, the datasource option of the JDBC login module can reference the data source's OSGi service using the following syntax:

osgi:javax.sql.DataSource/(osgi.jndi.service.name=jdbc/karafdb)

Where javax.sql.DataSource is the interface type of the exported OSGi service and the filter, (osgi.jndi.service.name=jdbc/karafdb), selects the particular javax.sql.DataSource instance whose osgi.jndi.service.name service property has the value, jdbc/karafdb.

For example, you can use the following Blueprint configuration to override the karaf realm with a JDBC login module that references the sample MySQL data source:

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
           xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.0.0"
           xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0"
           xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0">

    <!-- Allow usage of System properties, especially the karaf.base property -->
    <ext:property-placeholder placeholder-prefix="$[" placeholder-suffix="]"/>

    <jaas:config name="karaf" rank="2">
        <jaas:module className="org.apache.karaf.jaas.modules.jdbc.JDBCLoginModule" 
                     flags="required">
            datasource = osgi:javax.sql.DataSource/(osgi.jndi.service.name=jdbc/karafdb)
            query.password = SELECT PASSWORD FROM USERS WHERE USERNAME=?
            query.role = SELECT ROLE FROM ROLES WHERE USERNAME=?
            insert.user = INSERT INTO USERS VALUES(?,?)
            insert.role = INSERT INTO ROLES VALUES(?,?)
            delete.user = DELETE FROM USERS WHERE USERNAME=?
            delete.role = DELETE FROM ROLES WHERE USERNAME=? AND ROLE=?
            delete.roles = DELETE FROM ROLES WHERE USERNAME=?
        </jaas:module>
    </jaas:config>

    <!-- The Backing Engine Factory Service for the JDBCLoginModule -->
    <service interface="org.apache.karaf.jaas.modules.BackingEngineFactory">
        <bean class="org.apache.karaf.jaas.modules.jdbc.JDBCBackingEngineFactory"/>
    </service>

</blueprint>
[Note]Note

The SQL statements shown in the preceding configuration are in fact the default values of these options. Hence, if you create user and role tables consistent with these SQL statements, you could omit the options settings and rely on the defaults.

In addition to creating a JDBCLoginModule, the preceding Blueprint configuration also instantiates and exports a JDBCBackingEngineFactory instance, which enables you to manage the user data using the jaas:* console commands.

The following classes implement the JAAS LDAP Login Module:

[Note]Note

There is no backing engine factory for the LDAP Login Module, which means that this module cannot be managed using the jaas:* console commands.

The JAAS LDAP login module supports the following options:

connection.url

The LDAP connection URL—for example, ldap://hostname.

connection.username

Admin username to connect to the LDAP server. This parameter is optional: if it is not provided, the LDAP connection will be anonymous.

connection.password

Admin password to connect to the LDAP server. Used only if the connection.username is also specified.

user.base.dn

The LDAP base DN used to look up roles—for example, ou=role,dc=apache,dc=org.

user.filter

The LDAP filter used to look up a user's role—for example, (member:=uid=%u).

user.search.subtree

If true, the user lookup is recursive (SUBTREE). If false, the user lookup is performed only at the first level (ONELEVEL).

role.base.dn

The LDAP base DN used to look up roles—for example, ou=role,dc=apache,dc=org.

role.filter

The LDAP filter used to look up a user's role—for example, (member:=uid=%u).

role.name.attribute

The LDAP role attribute containing the role value used by Apache Karaf—for example, cn.

role.search.subtree

If true, the role lookup is recursive (SUBTREE). If false, the role lookup is performed only at the first level (ONELEVEL).

authentication

Define the authentication back-end used on the LDAP server. The default is simple.

initial.context.factory

Define the initial context factory used to connect to the LDAP server. The default is com.sun.jndi.ldap.LdapCtxFactory.

ssl

If true or if the protocol on the connection.url is ldaps, an SSL connection will be used.

ssl.provider

Specifies the SSL provider.

ssl.protocol

The protocol version to use—for example, SSL or TLS.

ssl.algorithm

The algorithm to use for the KeyManagerFactory and the TrustManagerFactory—for example, PKIX.

ssl.keystore

The ID of the keystore that stores the LDAP client's own X.509 certificate (required only if SSL client authentication is enabled on the LDAP server). The keystore must be deployed using a jaas:keystore element (see Sample Blueprint configuration).

ssl.keyalias

The keystore alias of the LDAP client's own X.509 certificate (required only if there is more than one certificate stored in the keystore specified by ssl.keystore).

ssl.truststore

The ID of the keystore that stores trusted CA certificates, which are used to verify the LDAP server's certificate (the LDAP server's certificate chain must be signed by one of the certificates in the truststore). The keystore must be deployed using a jaas:keystore element.

Table 2.2 describes the properties used to configure the Fuse ESB Enterprise JAAS LDAP login module.

Table 2.2. Properties for the Fuse ESB Enterprise LDAP Login Module

PropertyDescription
connection.url Specifies specify the location of the directory server using an ldap URL, ldap://Host:Port. You can optionally qualify this URL, by adding a forward slash, /, followed by the DN of a particular node in the directory tree.
connection.username Specifies the DN of the user that opens the connection to the directory server. For example, uid=admin,ou=system.
connection.password Specifies the password that matches the DN from connection.username. In the directory server, the password is normally stored as a userPassword attribute in the corresponding directory entry.
user.base.dn Specifies the DN of the subtree of the DIT to search for user entries.
user.filter Specifies the LDAP search filter used to locate user credentials. It is applied to the subtree selected by user.base.dn. Before being passed to the LDAP search operation, the value is subjected to string substitution such that all occurrences of %u are replaced by the user name extracted from the incoming credentials.
user.search.subtree Specifies if the user entry search's scope includes the subtrees of the tree selected by user.base.dn.
role.base.dn Specifies the DN of the subtree of the DIT to search for role entries.
role.filter Specifies the LDAP search filter used to locate roles. It is applied to the subtree selected by role.base.dn. Before being passed to the LDAP search operation, the value is subjected to string substitution such that all occurrences of %u are replaced by the user name extracted from the incoming credentials.
role.name.attribute Specifies the attribute type of the role entry that contains the name of the role/group. If you omit this option, the role search feature is effectively disabled.
role.search.subtree Specifies if the role entry search's scope includes the subtrees of the tree selected by role.base.dn.
authentication

Specifies the authentication method used when binding to the LDAP server. Valid values are

  • simple—bind with user name and password authentication

  • none—bind anonymously

initial.context.factory Specifies the class of the context factory used to connect to the LDAP server. This must always be set to com.sun.jndi.ldap.LdapCtxFactory.
ssl Specifies if the connection to the LDAP server is secured via SSL. If connection.url starts with ldaps:// SSL is used regardless of this property.
ssl.provider Specifies the SSL provider to use for the LDAP connection. If not specified, the default SSL provider is used.
ssl.protocol Specifies the protocol to use for the SSL connection.
ssl.algorithm Specifies the algorithm used by the trust store manager.
ssl.keystore Specifies the keystore name.
ssl.keyalias Specifies the name of the private key in the keystore.
ssl.truststore Specifies the trust keystore name.

All of the properties are mandatory except the SSL properties.

The placeholder you use for encrypted properties are the same as you use for regular properties. The use the form ${prop.name}.

Example 2.12 shows an LDAP JAAS realm that uses the properties file in Example 2.8.


The ${ldap.password} placeholder will be replaced with the decrypted value of the ldap.password property from the properties file.

To enable SSL/TLS:

  1. Open etc/org.ops4j.pax.web.cfg in a text editor.

  2. Disable the insecure HTTP port by adding the org.osgi.service.http.enabled and setting it to false as shown in Example 3.1.


  3. Enable the secure HTTPS port by adding the org.osgi.service.http.secure.enabled and setting it to true as shown in Example 3.2.


  4. Specify the port used for connecting over HTTPS by adding the org.osgi.service.http.port.secure and setting it to an available port as shown in Example 3.3.


  5. Configure the keystore used to hold the X.509 certificates.

    1. Specify the location of the keystore by adding the org.ops4j.pax.web.ssl.keystore.

    2. Specify the type of keystore used by adding the org.ops4j.pax.web.ssl.keystore.type and setting it to JKS.

    3. Specify the password for unlocking the Java keystore by adding the org.ops4j.pax.web.ssl.password property.

    4. Specify the password for decrypting the private key by adding the org.ops4j.pax.web.ssl.keypassword property.

      [Tip]Tip

      This is typically the same as the password used to unlock the keystore.

    5. Specify if certificate-based client authentication at the server is wanted by adding the org.ops4j.pax.web.ssl.clientauthwanted property.

      When set to true the server will request that the client send an X.509 certificate during the SSL handshake.

    6. Specify if certificate-based client authentication at the server is required by adding the org.ops4j.pax.web.ssl.clientauthneeded property.

      When set to true an exception is thrown if the client does not present a valid X.509 certificate during the SSL handshake.

After configuring the Web console and installing the webconsole feature, you should be able to open the Web console by browsing to the following URL:

https://localhost:8183/system/console

[Tip]Tip

Remember to type the https: scheme, instead of http:, in this URL.

Initially, the browser will warn you that you are using an untrusted certificate. Skip this warning and you will be prompted to enter a username and a password. Log in with the username smx and the password smx.

The following prerequisites are needed for this tutorial:

You must customize the POM file in order to generate an OSGi bundle, as follows:

  1. Follow the POM customization steps described in Generating a Bundle Project in Deploying into the Container.

  2. In the configuration of the Maven bundle plug-in, modify the bundle instructions to import additional Java packages, as follows:

    <project ... >
      ...
      <build>
        ...
          <plugin>
            <groupId>org.apache.felix</groupId>
            <artifactId>maven-bundle-plugin</artifactId>
            <extensions>true</extensions>
            <configuration>
              <instructions>
                <Bundle-SymbolicName>
                  ${project.artifactId}
                </Bundle-SymbolicName>
                <Import-Package>org.apache.activemq.xbean,
                                org.apache.activemq.spring,
                                org.apache.activemq.broker,
                                org.apache.activemq.security,
                                org.apache.activemq.jaas,
                                org.apache.activemq.pool,
                                org.apache.activemq.camel.component,
                                org.apache.camel.component.jms,
                                *</Import-Package>
              </instructions>
            </configuration>
          </plugin>
        </plugins>
      </build>
      ...
    </project>
[Note]Note

Not all of these packages are required by the current tutorial. It is convenient, however, to add all of the packages required by the subsequent tutorials at this point.

To test the broker configured in the OSGi container, you are going to use the example consumer tool and producer tool supplied with the standalone version of Apache ActiveMQ.

Configure the consumer and the producer clients to pick up the client trust store. Edit the Ant build file, ActiveMQInstallDir/example/build.xml, and add the javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword JSSE system properties to the consumer target and the producer target as shown in the following example:

In the context of the Ant build tool, this is equivalent to adding the system properties to the command line.

Introduction to JAAS in ActiveMQ Security Guide describes how to define JAAS realms using login configuration files. This approach must not be used with the OSGi container, however. It is only suitable for use in a standalone Apache ActiveMQ application.

This tutorial shows you how to enable JAAS authentication on a broker installed in the OSGi container. Instead of creating a local instance of a JAAS realm (as you would for a standalone broker), the broker exploits Fuse ESB Enterprise's support for container-wide JAAS realms, as shown in Figure 1.1.

After the broker is secured by JAAS authentication, you can test it using the sample JMS clients from the standalone Apache ActiveMQ distribution. The JMS clients must first be modified, however, to provide the requisite username/password JMS credentials.

This tutorial part builds on Tutorial I: SSL/TLS Security. All of the prerequisites from Prerequisites apply here and you must complete the previous tutorial part before proceeding.

Apache ActiveMQ enables you to program SSL security settings (and JAAS security settings) by creating and configuring an instance of the ActiveMQSslConnectionFactory JMS connection factory. Programming the JMS connection factory is the correct approach to use in the context of the containers such as OSGi, J2EE, Tomcat, and so on, because these settings are local to the application using the JMS connection factory instance.

[Note]Note

A standalone broker can configure SSL settings using Java system properties. For clients deployed in a container, however, this is not a practical approach, because the configuration must apply only to individual bundles, not the entire OSGi container. A Camel ActiveMQ endpoint is effectively a kind of Apache ActiveMQ Java client, so this restriction applies also to Camel ActiveMQ endpoints.

This tutorial part builds on Tutorial I: SSL/TLS Security and Tutorial II: JAAS Authentication. All of the prerequisites from Prerequisites apply here and you must complete the previous tutorial parts before proceeding.

Edit the broker-spring.xml file in the src/main/resources/META-INF/spring directory of your Maven project and add the following bean definitions, which configure the Camel ActiveMQ component:

This configuration defines the secure activemqs component, which you can now use to define endpoints in your Apache Camel routes. The activemqs bean references jmsConfig, which configures the the component. The jmsConfig bean in turn references a chain of JMS connection factories: the pooled connection factory wrapper, pooledConnectionFactory, which is important for performance; and the secure connection factory, jmsConnectionFactory, which is capable of creating secure connections to the broker.

The certificates used in this demonstration are taken from a sample in the Apache CXF 2.6.0.fuse-71-047 product. If you download and install the standalone version of Apache CXF, you will find the sample certificates in the CXFInstallDir/samples/wsdl_first_https/certs directory.

Copy the certs directory from CXFInstallDir/samples/wsdl_first_https/ to the EsbInstallDir/etc/ directory. After copying, you should have the following directory structure under EsbInstallDir/etc/:

EsbInstallDir/etc/
    |
    \--certs/
        |
        \--cherry.jks
           wibble.jks
           truststore.jks
           ...

Where cherry.jks, wibble.jks, and truststore.jks are the keystores that are used in this demonstration.

[Warning]Warning

The demonstration key store and trust sture are provided for testing purposes only. Do not deploy these certificates in a production system. To set up a genuinely secure SSL/TLS system, you must generate custom certificates, as described in Appendix A.

The Jetty Web server is created by defining a Jetty endpoint at the start of an Apache Camel route. The route is then responsible for processing the incoming HTTP request and generating a reply. The current example simply sends back a small HTML page in the reply. For a more realistic application, you would typically process the incoming message using a bean, which accesses the message through the Java servlet API.

Create the following directory to hold the Spring configuration files:

ProjectDir/jetty-security/src/main/resources/META-INF/spring

In the spring directory that you just created, use your favorite text editor to create the file, jetty-spring.xml, containing the following XML configuration:

The jetty bean defines a new instance of the Apache Camel Jetty component, overriding the default component defined in the camel-jetty JAR file. This Jetty component is configured with SSL/TLS properties as follows:

[Note]Note

The preceding configuration shows how to enable SSL/TLS security for all IP port values. To enable SSL/TLS security for specific IP ports only.

You must also modify the URI at the start of the route (the uri attribute of the from element). Make sure that the scheme of the URI matches the secure Jetty component, jetty, that you have just created. You must also change the protocol scheme from http to https.

[Tip]Tip

Always double-check you have changed the protocol scheme to https! This is such a small change, it is easy to forget.

This example builds on the project created in Enabling SSL/TLS Security. You must complete the steps in the Jetty SSL/TLS example before proceeding with this tutorial.

[Note]Note

In any case, it is highly recommended that you always enable SSL/TLS in combination with BASIC authentication, in order to protect against password snooping.

In the jetty-security project, edit the jetty-spring.xml file from the src/main/resources/META-INF/spring directory. To configure the Jetty security handler with BASIC authentication, add the following bean definitions:

Two aspects of Jetty authentication are configured by the preceding bean definitions:

The Camel CXF proxy demonstration is available only from the standalone distribution of Apache Camel. Download version 2.10.0.fuse-71-047 of Apache Camel from the download page, http://fusesource.com/downloads/, and install it according to the instructions in the Installation Guide.

Assuming that you have installed Apache Camel in CamelInstallDir, you can find the Camel CXF proxy demonstration in the following directory:

CamelInstallDir/examples/camel-example-cxf-proxy

A WS endpoint can be configured by creating the endpoint in Spring and then configuring SSL/TLS properties on its Jetty container. The configuration can be somewhat confusing, however, for the following reason: the Jetty container (which is configured by a httpj:engine-factory element in Spring) does not explicitly reference the WS endpoints it contains and the WS endpoints do not explicitly reference the Jetty container either. The connection between the Jetty container and its contained endpoints is established implicitly, in that they are both configured to use the same IP port, as illustrated by Figure 7.2.


The connection between the Web service endpoint and the httpj:engine-factory element is established as follows:

  1. The Spring container loads and parses the file containing the httpj:engine-factory element.

  2. When the httpj:engine-factory bean is created, a corresponding entry is created in the registry, storing a reference to the bean. The httpj:engine-factory bean is also used to initialize a Jetty container that listens on the specified IP port.

  3. When the WS endpoint is created, it scans the registry to see if it can find a httpj:engine-factory bean with the same IP port as the IP port in the endpoint's address URL.

  4. If one of the beans matches the endpoint's IP port, the WS endpoint installs itself into the corresponding Jetty container. If the Jetty container has SSL/TLS enabled, the WS endpoint shares those security settings.

The certificates used in this demonstration are taken from a sample in the Apache CXF 2.6.0.fuse-71-047 product. If you download and install the standalone version of Apache CXF, you will find the sample certificates in the CXFInstallDir/samples/wsdl_first_https/certs directory.

Copy the cherry.jks, wibble.jks, and truststore.jks keystores from the CXFInstallDir/samples/wsdl_first_https/certs directory to the CamelInstallDir/examples/camel-example-cxf-proxy/src/main/resources/certs directory (you must first create the certs sub-directory).

Deploy the camel-example-cxf-proxy bundle, by entering the following console command:

karaf@root> install -s mvn:org.apache.camel/camel-example-cxf-proxy/2.10.0.fuse-71-047
[Note]Note

In this case, it is preferable to deploy the bundle directly using install, rather than using hot deploy, so that you can see the bundle output on the console screen.

If you have any difficulty using the mvn URL handler, see Mvn URL Handler in Deploying into the Container for details of how to set it up.

In principle, there are several different ways of creating a WSDL proxy: you could use the JAX-WS API to create a proxy based on the contents of a WSDL file; you could use the JAX-WS API to create a proxy without a WSDL file; or you could use the Apache CXF-specific class, JaxWsProxyFactoryBean, to create a proxy.

For this SSL/TLS client, the most convenient approach is to use the JAX-WS API to create a proxy without using a WSDL file, as shown in the following Java sample:

// Java
import javax.xml.ws.Service;
import org.apache.camel.example.reportincident.ReportIncidentEndpoint;
...
// create the webservice client and send the request
Service s = Service.create(SERVICE_NAME);
s.addPort(
    PORT_NAME,
    "http://schemas.xmlsoap.org/soap/",
    ADDRESS_URL
  );
ReportIncidentEndpoint client =
  s.getPort(PORT_NAME, ReportIncidentEndpoint.class);
[Note]Note

In this example, you cannot use the JaxWsProxyFactoryBean approach to create a proxy, because a proxy created in this way fails to find the HTTP conduit settings specified in the Spring configuration file.

The SERVICE_NAME and PORT_NAME constants are the QNames of the WSDL service and the WSDL port respectively, as defined in Example 7.1. The ADDRESS_URL string has the same value as the proxy Web service address and is defined as follows:

private static final String ADDRESS_URL =
  "https://localhost:9080/camel-example-cxf-proxy/webservices/incident";

In particular, note that the address must be defined with the URL scheme, https, which selects HTTP over SSL/TLS.

Example 7.3 shows the complete code for a Java client that is implemented as a JUnit test case. This client replaces the existing test, ReportIncidentRoutesTest.java, in the src/test/java/org/apache/camel/example/reportincident sub-directory of the examples/camel-example-cxf-proxy demonstration.

To add the client to the CamelInstallDir/examples/camel-example-cxf-proxy demonstration, go to the src/test/java/org/apache/camel/example/reportincident sub-directory, move the existing ReportIncidentRoutesTest.java file to a backup location, then create a new ReportIncidentRoutesTest.java file and paste the code from Example 7.3 into this file.

Example 7.3. ReportIncidentRoutesTest Java client

// Java
package org.apache.camel.example.reportincident;

import org.apache.camel.spring.Main;
import org.apache.cxf.jaxws.JaxWsProxyFactoryBean;
import org.junit.Test;

import java.net.URL;
import javax.xml.namespace.QName;
import javax.xml.ws.Service;

import org.apache.cxf.Bus;
import org.apache.cxf.bus.spring.SpringBusFactory;
import org.apache.camel.example.reportincident.ReportIncidentEndpoint;
import org.apache.camel.example.reportincident.ReportIncidentEndpointService;

import static org.junit.Assert.assertEquals;

/**
 * Unit test of our routes
 */
public class ReportIncidentRoutesTest {

    private static final QName SERVICE_NAME
        = new QName("http://reportincident.example.camel.apache.org", "ReportIncidentEndpointService");

    private static final QName PORT_NAME =
        new QName("http://reportincident.example.camel.apache.org", "ReportIncidentEndpoint");

    private static final String WSDL_URL = "file:src/main/resources/etc/report_incident.wsdl";

    // should be the same address as we have in our route
    private static final String ADDRESS_URL = "https://localhost:9080/camel-example-cxf-proxy/webservices/incident";

    protected SpringBusFactory bf;

    protected void startCxfBus() throws Exception {
        bf = new SpringBusFactory();
        Bus bus = bf.createBus("META-INF/spring/cxf-client.xml");
        bf.setDefaultBus(bus);
    }

    @Test
    public void testRendportIncident() throws Exception {
        startCxfBus();
        runTest();
    }
    
    protected void runTest() throws Exception {
       
        // create input parameter
        InputReportIncident input = new InputReportIncident();
        input.setIncidentId("123");
        input.setIncidentDate("2008-08-18");
        input.setGivenName("Claus");
        input.setFamilyName("Ibsen");
        input.setSummary("Bla");
        input.setDetails("Bla bla");
        input.setEmail("davsclaus@apache.org");
        input.setPhone("0045 2962 7576");

        // create the webservice client and send the request
        Service s = Service.create(SERVICE_NAME);
        s.addPort(PORT_NAME, "http://schemas.xmlsoap.org/soap/", ADDRESS_URL);
        ReportIncidentEndpoint client = s.getPort(PORT_NAME, ReportIncidentEndpoint.class);
	
        OutputReportIncident out = client.reportIncident(input);

        // assert we got a OK back
        assertEquals("OK;456", out.getCode());
    }
}

Example 7.4 shows the Spring configuration that defines a http:conduit element for the ReportIncidentEndpoint WSDL port. The http:conduit element is configured to enable SSL/TLS security for any client proxies that use the specified WSDL port.

To add the Spring configuration to the client test case, go to the src/test/resources/META-INF/spring sub-directory, use your favorite text editor to create the file, cxf-client.xml, and paste the contents of Example 7.4 into the file.


Please note the following points about the preceding configuration:

To set-up the directory server and browser:

  1. Download Apache Directory Server from http://directory.apache.org/apacheds/1.5/downloads.html.

  2. Run the downloaded installer.

    [Important]Important

    During the installation process, you will be asked whether or not to install a default instance of the directory server. Choose the default instance.

  3. Start the directory service as described in Starting Apache Directory Server.

  4. Install Apache Directory Studio as described in Install Apache Directory Studio.

  5. Start Apache Directory Studio.

    • If you installed the standalone version of Apache Directory Studio, double-click the relevant icon to launch the application.

    • If you installed Apache Directory Studio into an existing Eclipse IDE:

      1. Start Eclipse.

      2. Select Window|Open Perspective|Other.

      3. In the Open Perspective dialog, select LDAP.

      4. Click OK.

  6. Connect the browser to the server as described in Connecting the browser to the server.

The Apache Directory Studio is an Eclipse-based suite of tools for administering an X.500 directory server. In particular, for this tutorial, you need the LDAP Browser feature, which enables you to create new entries in the Directory Information Tree (DIT).

There are two alternative ways of installing Apache Directory Studio:

Perform the following steps to add user entries to the directory server:

  1. Ensure that the LDAP server and browser are running.

    See Set-up a Directory Server and Browser.

  2. In the LDAP Browser view, drill down to the ou=users node.

    directory information tree in the LDAP browser
  3. Select the ou=users node.

  4. Open the context menu.

  5. Select New|New Entry.

    The New Entry wizard appears.

  6. In the Entry Creation Method pane, check Create entry from scratch.

  7. Click Next.

    The Object Classes pane opens.

  8. In the Object Classes pane, select inetOrgPerson from the list of Available object classes on the left.

  9. Click Add to populate the list of Selected object classes.


  10. Click Next.

    The Distinguished Name pane opens.

  11. In the the RDN field, enter uid in front and jdoe after the equals sign.


  12. Click Next.

    The Attributes pane opens.

  13. Fill in the remaining mandatory attributes in the Attributes pane.

    1. Set the cn (common name) attribute to John Doe

    2. Set the sn (surname) attribute to Doe.


  14. Add a userPassword attribute to the user entry.

    1. Open the context menu in the Attributes pane.

    2. Select New Attribute.

      The New Attribute wizard appears.

    3. From the Attribute type drop-down list, select userPassword.

    4. Click Finish.

      The Password Editor dialog appears.

    5. In the Enter New Password field, enter the password, secret.

    6. Click OK.

      The userPassword attribute will appear in the attributes editor.

  15. Click Finish.

  16. Add a user Jane Doe by following Step 3 to Step 15.

    In Step 11, use janedoe for the new user's uid.

  17. Add a user Camel Rider by following Step 3 to Step 15.

    In Step 11, use crider for the new user's uid.

To add the groups that define the roles:

  1. Create a new organizational unit to contain the role groups.

    1. In the LDAP Browser view, select the ou=system node.

    2. Open the context menu.

    3. Select New|New Entry.

      The New Entry wizard appears.

    4. In the Entry Creation Method pane, check Create entry from scratch.

    5. Click Next.

      The Object Classes pane opens.

    6. Select organizationalUnit from the list of Available object classes on the left.

    7. Click Add to populate the list of Selected object classes.

    8. Click Next>.

      The Distinguished Name pane opens.

    9. In the the RDN field, enter ou in front and roles after the equals sign.

    10. Click Next>.

      The Attributes pane opens.

    11. Click Finish.

    [Note]Note

    This step is required because Apache DS only allows administrators access to entries in ou=system,ou=groups.

  2. In the LDAP Browser view, drill down to the ou=roles node.

  3. Select the ou=roles node.

  4. Open the context menu.

  5. Select New|New Entry.

    The New Entry wizard appears.

  6. In the Entry Creation Method pane, check Create entry from scratch.

  7. Click Next.

    The Object Classes pane opens.

  8. Select groupOfNames from the list of Available object classes on the left.

  9. Click Add to populate the list of Selected object classes.

  10. Click Next.

    The Distinguished Name pane opens.

  11. In the the RDN field, enter cn in front and admin after the equals sign.

  12. Click Next.

    The Attributes pane opens and you are presented with a DN editor.

  13. Enter uid=jdoe.

  14. Click OK.

  15. Click Finish.

  16. Add a sshConsole role by following Step 3 to Step 15.

    In Step 11, use sshConsole for the new group's cn.

    In Step 13, use uid=janedoe.

  17. Add a webconsole role by following Step 3 to Step 15.

    In Step 11, use webconsole for the new group's cn.

    In Step 13, use uid=janedoe.

  18. Add a jmxUser role by following Step 3 to Step 15.

    In Step 11, use jmxUser for the new group's cn.

    In Step 13, use uid=crider.

To enable LDAP authentication:

  1. Ensure that the X.500 directory server is running.

  2. Start Fuse ESB Enterprise by entering the following command in a terminal window:

    > servicemix
  3. Create a Blueprint configuration file called ldap-module.xml.

  4. Copy Example 8.1 into ldap-module.xml.


    This login module creates a JAAS realm called karaf, which is the same name as the default JAAS realm used by Fuse ESB Enterprise. By redefining this realm with a rank attribute value greater than 0, it overrides the standard karaf realm which has the rank 0. For more information on configuring a JAAS realm see Defining JAAS Realms.

    For a detailed description of configuring Fuse ESB Enterprise to use LDAP see Enabling LDAP Authentication.

    [Important]Important

    When setting the JAAS properties above, do not enclose the property values in double quotes.

    [Tip]Tip

    If you use OpenLDAP, the syntax of the role filter is (member:=uid=%u).

  5. To deploy the new LDAP module, copy the ldap-module.xml into the Fuse ESB Enterprise deploy/ directory.

    The LDAP module is automatically activated.

  6. Test the new LDAP realm by connecting to the running container using the Fuse ESB Enterprise client utility.

    1. Open a new command prompt.

    2. change directory to the Fuse ESB Enterprise install directory.

    3. Enter the following command to log on to the running container instance using the identity janedoe:

      client -u janedoe -p secret

      You should receive the following message:

      Authentication failure

      This fails because janedoe does not have the admin role which is required for using the remote console.

    4. Enter the following command to log on to the running container instance using the identity jdoe:

      client -u jdoe -p secret

      You should successfully log into the container's remote console because jdoe does have the admin role.

  7. Log off the remote console by entering the logout command.

This tutorial explains how to configure the OSGi administrative functions to use specific roles for authorization. By configuring each of the administrative functions to use a different role for access, you can provide fine grained control over who can monitor and manipulate running containers.

When LDAP is enabled, the OSGi container expects the user role data to be stored along with the user authentication data in the LDAP directory server. The LDAP search query to extract the role data is specified by the role.* properties in the jaas:module element.

The JAAS LDAP login module used in this tutorial, shown in Example 8.1, is configured to extract the role name from the cn property of all entries selected by the filter member=uid=%u which is run on the tree selected using the base DN uo=roles,ou=system. In Adding groups for the roles, you added three groups to the uo=roles,ou=system tree. The filter will match with any group that has a member specified by uid=%u.

For example, when you attempted to connect to the remote console as user jdoe the filter searched for a group with a member uid=jdoe and matched on the group cn=admin,uo=roles,ou=system. The LDAP module extracted the cn property's value of admin and used it as the role for authorizing user jdoe.

To enable SSL/TLS security on the connection to the Apache Directory Server:

  1. Obtain a copy of the server's self-signed certificate.

    1. Using a Web browser , navigate to the following URL:

      https://localhost:10636
      [Important]Important

      Remember to specify the scheme as https, not just http.

      The Web browser now signals an error, because the certificate it receives from the server is untrusted. In the case of Firefox, you will see the following error in the browser window:


    2. Click I Understand the Risks.

    3. Click Add Exception.

      The Add Security Exception dialog opens.

    4. In the Add Security Exception dialog, click Get Certificate.

    5. Click View.

      The Certificate Viewer dialog opens.

    6. In the Certificate Viewer dialog, select the Details tab.

    7. Click Export.

      The Save Certificate To File dialog opens.

    8. In the Save Certificate To File dialog, use the drop-down list to set the Save as type to X.509 Certificate (DER).

    9. Save the certificate, ApacheDS.der, to a convenient location on the filesystem.

  2. Convert the DER format certificate into a keystore.

    1. From a command prompt, change directory to the directory where you have stored the ApacheDS.der file.

    2. Enter the following keytool command:

      keytool -import -file ApacheDS.der -alias server -keystore truststore.ks -storepass secret
  3. Copy the newly created keystore file, truststore.ks, into the Fuse ESB Enterprise etc/ directory.

  4. Open the ldap-module.xml file you created in Enable LDAP Authentication in the OSGi Container in a text editor.

  5. Edit the connection.url to use ldaps://localhost:10636.

  6. Add the highlighted lines in Example 8.3.


  7. Copy the ldap-module.xml file into the Fuse ESB Enterprise deploy/ directory.

    The LDAP module is automatically activated.

  8. Test the new LDAP realm by connecting to the running container using the Fuse ESB Enterprise client utility.

    1. Open a new command prompt.

    2. change directory to the Fuse ESB Enterprise install directory.

    3. Enter the following command to log on to the running container instance using the identity jdoe:

      client -u jdoe -p secret

      You should successfully log into the container's remote console because jdoe does have the admin role.

A CA consists of a set of tools for generating and managing certificates and a database that contains all of the generated certificates. When setting up a system, it is important to choose a suitable CA that is sufficiently secure for your requirements.

There are two types of CA you can use:

  • commercial CAs are companies that sign certificates for many systems.

  • private CAs are trusted nodes that you set up and use to sign certificates for your system only.

One software package that allows you to set up a private CA is OpenSSL, http://www.openssl.org. OpenSSL is derived from SSLeay, an implementation of SSL developed by Eric Young (). The OpenSSL package includes basic command line utilities for generating and signing certificates. Complete documentation for the OpenSSL command line utilities is available at http://www.openssl.org/docs.

Using the subject DN’s Common Name for the certificate identity has the disadvantage that only one host name can be specified at a time. If you deploy a certificate on a multi-homed host, however, you might find it is practical to allow the certificate to be used with any of the multi-homed host names. In this case, it is necessary to define a certificate with multiple, alternative identities, and this is only possible using the subjectAltName certificate extension.

For example, if you have a multi-homed host that supports connections to either of the following host names:

www.progress.com
fusesource.com

Then you can define a subjectAltName that explicitly lists both of these DNS host names. If you generate your certificates using the openssl utility, edit the relevant line of your openssl.cnf configuration file to specify the value of the subjectAltName extension, as follows:

subjectAltName=DNS:www.progress.com,DNS:fusesource.com

Where the HTTPS protocol matches the server host name against either of the DNS host names listed in the subjectAltName (the subjectAltName takes precedence over the Common Name).

The HTTPS protocol also supports the wildcard character, *, in host names. For example, you can define the subjectAltName as follows:

subjectAltName=DNS:*.fusesource.com

This certificate identity matches any three-component host name in the domain fusesource.com.

[Warning]Warning

You must never use the wildcard character in the domain name (and you must take care never to do this accidentally by forgetting to type the dot, ., delimiter in front of the domain name). For example, if you specified *fusesource.com, your certificate could be used on any domain that ends in the letters fusesource.

You can download the OpenSSL utilities from http://openssl.org/.

This section describes using the OpenSSL command-line utilities to create certificates. Further documentation of the OpenSSL command-line utilities can be obtained at http://www.openssl.org/docs.

To create your own CA and certificates:

  1. Add the OpenSSL bin directory to your path.

  2. Create your own private CA.

    1. Create the directory structure for the CA.

      The directory structure should be:

      • X509CA/ca

      • X509CA/certs

      • X509CA/newcerts

      • X509CA/crl

      Where X509CA is the name of the CA's home directory.

    2. Copy the openssl.cnf file from your OpenSSL installation to your X509CA directory.

    3. Open your copy of openssl.cnf in a text editor.

    4. Edit the [CA_default] section to look like Example A.1.


      [Tip]Tip

      You might decide to edit other details of the OpenSSL configuration at this point. For more details, see the OpenSSL documentation.

    5. Initialize the CA database as described in CA database files.

    6. Create a new self-signed CA certificate and private key with the command:

      openssl req -x509 -new -config X509CA/openssl.cnf -days 365 -out X509CA/ca/new_ca.pem -keyout X509CA/ca/new_ca_pk.pem

      You are prompted for a pass phrase for the CA private key and details of the CA distinguished name as shown in Example A.2.


      [Note]Note

      The security of the CA depends on the security of the private key file and the private key pass phrase used in this step.

      You must ensure that the file names and location of the CA certificate and private key, new_ca.pem and new_ca_pk.pem, are the same as the values specified in openssl.cnf during Step 2.d.

  3. Create signed certificates in a Java keystore.

    1. Generate a certificate and private key pair using the keytool -genkeypair command.

      For details on the options to use when using keytool -genkeypair see Generate a certificate and private key pair.

    2. Create a certificate signing request using the keystore -certreq command.

      Example A.3 creates a new certificate signing request for the fusesample.jks certificate and exports it to the fusesample_csr.pem file.


    3. Sign the CSR using the openssl ca command.

      You will prompted to enter the CA private key pass phrase you used when creating the CA in Step 2.f).

      See Signing a CSR for details on the options to use when signing the CSR.

    4. Convert the signed certificate to PEM only format using the openssl x509 command with the -outform option set to PEM.

      Example A.4 converts the signed certificate fusesigned.pem.


    5. Concatenate the CA certificate file and the converted, signed certificate file to form a certificate chain.

      The CA certificate file is stored in the CA's ca directory. For example, the certificate file for the CA created in Step 2.f would be ca/new_ca.pem.

    6. Import the new certificate's full certificate chain into the Java keystore using the keytool -import command.

      Example A.5 imports the chain fusesample.chain into the fusesample.jks keystore.


  4. Repeat Step 3 to create a full set of certificates for your system.

  5. Add trusted CAs to your Java trust store.

    1. Assemble the collection of trusted CA certificates that you want to deploy.

      The trusted CA certificates can be obtained from public CAs or private CAs. The trusted CA certificates can be in any format that is compatible with the Java keystore utility; for example, PEM format. All you need are the certificates themselves—the private keys and passwords are not required.

    2. Add a CA certificate to the trust store using the keytool -import command.

      Example A.6 adds the CA certificate cacert.pem, in PEM format, to a JKS trust store.


      truststore.ts is a keystore file containing CA certificates. If this file does not already exist, the keytool command creates one. StorePass is the password required to access the keystore file.

    3. Repeat Step 5.b to add all of the CA certificates to the trust store.

To generate a certificate and private key pair you use the keytool -genkeypair command. For example, Example A.7 creates a certificate and key pair that are valid for 365 days and is stored in the keystore file fusesample.jks. The generated key store entry will use the alias fuse and the password fusepass.


Because the specified keystore, fusessample.jks, did not exist prior to issuing the command implicitly creates a new keystore and sets its password to fusestorepass.

The -dname and -validity flags define the contents of the newly created X.509 certificate.

The -dname flag specifies the subject DN. For more details about DN format, see Appendix B. Some parts of the subject DN must match the values in the CA certificate (specified in the CA Policy section of the openssl.cnf file). The default openssl.cnf file requires the following entries to match:

  • Country Name (C)

  • State or Province Name (ST)

  • Organization Name (O)

[Note]Note

If you do not observe the constraints, the OpenSSL CA will refuse to sign the certificate (see Step 2.f ).

The -validity flag specifies the number of days for which the certificate is valid.

B

Basic Encoding Rules (see BER)
BER, BER

C

CA, Integrity of the public key
choosing a host, Choosing a host for a private certification authority
commercial CAs, Commercial Certification Authorities
index file, CA database files
list of trusted, Trusted CAs
multiple CAs, Certificates signed by multiple CAs
private CAs, Private Certification Authorities
private key, creating, Procedure
security precautions, Security precautions
self-signed, Procedure
serial file, CA database files
setting up, Procedure
certificate signing request, Procedure
signing, Procedure
certificates
chaining, Certificate chain
peer, Chain of trust
public key, Contents of an X.509 certificate
self-signed, Self-signed certificate, Procedure
signing, Integrity of the public key, Procedure
signing request, Procedure
X.509, Role of certificates
chaining of certificates, Certificate chain
connection.password, LDAP properties
connection.url, LDAP properties
connection.username, LDAP properties
CSR, Procedure

D

DER, DER
Distinguished Encoding Rules (see DER)
distinguished names
definition, Overview
DN
definition, Overview
string representation, String representation of DN

I

index file, CA database files
initial.context.factory, LDAP properties

J

JAAS
configuration syntax, Configuring a JAAS realm
converting to blueprint, Converting standard JAAS login properties to XML
namespace, Namespace
jaas:config, Configuring a JAAS realm
jaas:module, Configuring a JAAS realm
Jasypt
configuration, Jasypt configuration
libraries, Installing the Jasypt features
namespaces, Namespaces
jasypt-encryption, Installing the Jasypt features
JMX
roles, Changing the JMX role

L

LDAP
authentication, LDAP properties
configuration, LDAP properties
connection.password, LDAP properties
connection.url, LDAP properties
connection.username, LDAP properties
enabling, Enabling LDAP Authentication
initial.context.factory, LDAP properties
properties, LDAP properties
role.base.dn, LDAP properties
role.filter, LDAP properties
role.name.attribute, LDAP properties
role.search.subtree, LDAP properties
ssl, LDAP properties
ssl.algorithm, LDAP properties
ssl.keyalias, LDAP properties
ssl.keystore, LDAP properties
ssl.protocol, LDAP properties
ssl.provider, LDAP properties
ssl.truststore, LDAP properties
user.base.dn, LDAP properties
user.filter, LDAP properties
user.search.subtree, LDAP properties
LDAPLoginModule, Enabling LDAP Authentication

N

namespaces
Aries, Namespaces
Jasypt, Namespaces

O

OpenSSL, OpenSSL software package
OpenSSL command-line utilities, OpenSSL utilities

P

peer certificate, Chain of trust
private key, Procedure
properties
Apache Karaf placeholder extension, Jasypt configuration
Aries placeholder extension, Placeholder extension
encrypted, Encrypted properties
LDAP, LDAP properties
placeholder, Placeholders
property-placeholder, Placeholder extension, Jasypt configuration
public keys, Contents of an X.509 certificate

R

RDN, RDN
relative distinguished name (see RDN)
remote console
roles, Changing the remote console's role
role.base.dn, LDAP properties
role.filter, LDAP properties
role.name.attribute, LDAP properties
role.search.subtree, LDAP properties
roles
default, Default role
JMX, Changing the JMX role
LDAP configuration, LDAP properties
remote console, Changing the remote console's role
root certificate directory, Trusted CAs

S

self-signed CA, Procedure
self-signed certificate, Self-signed certificate
serial file, CA database files
signing certificates, Integrity of the public key
ssl, LDAP properties
ssl.algorithm, LDAP properties
ssl.keyalias, LDAP properties
ssl.keystore, LDAP properties
ssl.protocol, LDAP properties
ssl.provider, LDAP properties
ssl.truststore, LDAP properties
SSLeay, OpenSSL software package

T

trusted CAs, Trusted CAs

U

user.base.dn, LDAP properties
user.filter, LDAP properties
user.search.subtree, LDAP properties

X

X.500, ASN.1 and Distinguished Names
X.509 certificate
definition, Role of certificates