Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 8. Secure Your Connections and Resources
8.1. Simple Authentication and Security Layer - SASL Link kopierenLink in die Zwischenablage kopiert!
Link kopierenLink in die Zwischenablage kopiert!
8.1.1. SASL - Simple Authentication and Security Layer Link kopierenLink in die Zwischenablage kopiert!
Link kopierenLink in die Zwischenablage kopiert!
MRG Messaging uses Simple Authentication and Security Layer (SASL) for identifying and authorizing incoming connections to the broker, as mandated in the AMQP specification. SASL provides a variety of authentication methods. The Messaging Broker can be configured to allow any combination of the available SASL mechanisms. Clients can negotiate with the Messaging Broker to find a SASL mechanism that both can use.
MRG Messaging clients (with the exception of the JMS client) and the broker use the Cyrus SASL library to allow for a full SASL implementation.
8.1.2. SASL Support in Windows Clients Link kopierenLink in die Zwischenablage kopiert!
Link kopierenLink in die Zwischenablage kopiert!
The Windows Qpid C++ and C# clients support only
ANONYMOUS
and PLAIN
and EXTERNAL
authentication mechanisms.
No other SASL mechanisms are supported by Windows at this time.
If no sasl-mechanism is specified, the default chosen mechanism will usually differ between Windows and Linux.
8.1.3. SASL Mechanisms Link kopierenLink in die Zwischenablage kopiert!
Link kopierenLink in die Zwischenablage kopiert!
- Changes
- Updated April 2013.
The SASL authentication mechanisms allowed by the broker are controlled by the file
/etc/sasl2/qpidd.conf
on the broker. To narrow the allowed mechanisms to a smaller subset, edit this file and remove mechanisms.
Important
The PLAIN authentication mechanism sends passwords in cleartext. If using this mechanism, for complete security using Security Services Library (SSL) is recommended.
SASL Mechanisms
- ANONYMOUS
- Clients are able to connect anonymously.Note that when the broker is started with
auth=no
, authentication is disabled.PLAIN
andANONYMOUS
authentication mechanisms are available as identification mechanisms, but they have no authentication value. - PLAIN
- Passwords are passed in plain text between the client and the broker. This is not a secure mechanism, and should be used in development environments only. If PLAIN is used in production, it should only be used over SSL connections, where the SSL encryption of the transport protects the password.Note that when the broker is started with
auth=no
, authentication is disabled. ThePLAIN
andANONYMOUS
authentication mechanisms are available as identification mechanisms, but they have no authentication value. - DIGEST-MD5
- MD5 hashed password exchange using HTTP headers. This is a medium strength security protocol.
- CRAM-MD5
- A challenge-response protocol using MD5 encryption.
- KERBEROS/GSSAPI
- The Generic Security Service Application Program Interface (GSSAPI) is a framework that allows for the connection of different security providers. By far the most frequently used is Kerberos. GSSAPI security provides centralized management of security, including single sign-on, opaque token exchange, and transport security.
- EXTERNAL
- EXTERNAL SASL authentication uses an SSL-encrypted connection between the client and the server. The client presents a certificate to encrypt the connection, and this certificate contains both the cryptographic key for the connection and the identity of the client.
8.1.4. SASL Mechanisms and Packages Link kopierenLink in die Zwischenablage kopiert!
Link kopierenLink in die Zwischenablage kopiert!
The following table lists the
cyrus-sasl-*
package(s) that need to be installed on the server for each authentication mechanism.
Method | Package | /etc/sasl2/qpidd.conf entry |
---|---|---|
ANONYMOUS
|
-
|
-
|
PLAIN
| cyrus-sasl-plain
| mech_list: PLAIN
|
DIGEST-MD5
| cyrus-sasl-md5
| mech_list: DIGEST-MD5
|
CRAM-MD5
| cyrus-sasl-md5
| mech_list: CRAM-MD5
|
KERBEROS/GSSAPI
| cyrus-sasl-gssapi
| mech_list: GSSAPI
|
EXTERNAL
|
-
| mech_list: EXTERNAL
|
8.1.5. Configure SASL using a Local Password File Link kopierenLink in die Zwischenablage kopiert!
Link kopierenLink in die Zwischenablage kopiert!
The local SASL database is used by the PLAIN, DIGEST-MD5, or CRAM-MD5 SASL authentication mechanisms. The GSSAPI/KERBEROS mechanism authenticates clients against the Kerberos user database, and the EXTERNAL mechanism uses the client identity in the SSL certificate used by the client to encrypt the connection.
Procedure 8.1. Configure SASL using a Local Password File
- Add new users to the database by using the
saslpasswd2
command. The User ID for authentication and ACL authorization uses the formuser-id@domain
.Ensure that the correct realm has been set for the broker. This can be done by editing the configuration file or using the-u
option. The default realm for the broker isQPID
.saslpasswd2 -f /var/lib/qpidd/qpidd.sasldb -u QPID new_user_name
# saslpasswd2 -f /var/lib/qpidd/qpidd.sasldb -u QPID new_user_name
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Existing user accounts can be listed by using the
-f
option:sasldblistusers2 -f /var/lib/qpidd/qpidd.sasldb
# sasldblistusers2 -f /var/lib/qpidd/qpidd.sasldb
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Note
The user database at/var/lib/qpidd/qpidd.sasldb
is readable only by theqpidd
user. If you start the broker from a user other than theqpidd
user, you will need to either modify the configuration file, or turn authentication off.Note also that this file must be readable by theqpidd
user. If you delete and recreate this file, make sure the qpidd user has read permissions, or authentication attempts will fail. - To switch authentication on or off, use the
auth yes|no
option when you start the broker:/usr/sbin/qpidd --auth yes /usr/sbin/qpidd --auth no
# /usr/sbin/qpidd --auth yes # /usr/sbin/qpidd --auth no
Copy to Clipboard Copied! Toggle word wrap Toggle overflow You can also set authentication to be on or off by adding the appropriate line to to the/etc/qpid/qpidd.conf
configuration file:auth=no auth=yes
auth=no auth=yes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow The SASL configuration file is in/etc/sasl2/qpidd.conf
for Red Hat Enterprise Linux.
8.1.6. Configure SASL with ACL Link kopierenLink in die Zwischenablage kopiert!
Link kopierenLink in die Zwischenablage kopiert!
- To start using the ACL, specify the path and filename using the
--acl-file
command. The filename should have a.acl
extension:qpidd --acl-file ./aclfilename.acl
$ qpidd --acl-file ./aclfilename.acl
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Optionally, you can limit the number of active connections per user with the
--connection-limit-per-user
and--connection-limit-per-ip
commands. These limits can only be enforced if the--acl-file
command is specified. - You can now view the file with the
cat
command and edit it in your preferred text editor. If the path and filename is not found,qpidd
will fail to start.
8.1.7. Configure Kerberos 5 Link kopierenLink in die Zwischenablage kopiert!
Link kopierenLink in die Zwischenablage kopiert!
Kerberos uses the GSSAPI (Generic Security Services Application Program Interface) authentication mechanism on the broker to authenticate with a Kerberos server.
Both the MRG Messaging broker and users are principals of the Kerberos server, which means that they are both clients of the Kerberos authentication services.
Note
The following instructions make use of example domain names and Kerberos realms. To follow these instructions you must have a Kerberos server configured and use the appropriate domain names and Kerberos realm for your network environment.
To use Kerberos, both the broker and each user must be authenticated on the Kerberos server:
- Install the Kerberos workstation software and Cyrus SASL GSSAPI on each machine that runs a qpidd broker or a qpidd messaging client:
sudo yum install cyrus-sasl-gssapi krb5-workstation
$ sudo yum install cyrus-sasl-gssapi krb5-workstation
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Change the mech_list line in
/etc/sasl2/qpidd.conf
to:mech_list: GSSAPI
mech_list: GSSAPI
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Add the following lines to
/etc/qpid/qpidd.conf
:auth=yes realm=QPID
auth=yes realm=QPID
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Register the Qpid broker in the Kerberos database.Traditionally, a Kerberos principal is divided into three parts: the primary, the instance, and the realm. A typical Kerberos V5 has the format
primary/instance@REALM
. For a broker, the primary isqpidd
, the instance is the fully qualified domain name, and the REALM is the Kerberos domain realm. By default, this realm isQPID
, but a different realm can be specified in qpid.conf per the following example.realm=EXAMPLE.COM
realm=EXAMPLE.COM
Copy to Clipboard Copied! Toggle word wrap Toggle overflow For instance, if the fully qualified domain name isdublduck.example.com
and the Kerberos domain realm isEXAMPLE.COM
, then the principal name isqpidd/dublduck.example.com@EXAMPLE.COM
.FDQN=`hostname --fqdn` REALM="EXAMPLE.COM" kadmin -r $REALM -q "addprinc -randkey -clearpolicy qpidd/$FQDN"
FDQN=`hostname --fqdn` REALM="EXAMPLE.COM" kadmin -r $REALM -q "addprinc -randkey -clearpolicy qpidd/$FQDN"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Now create a Kerberos keytab file for the broker. The broker must have read access to the keytab file. The following script creates a keytab file and allows the broker read access:QPIDD_GROUP="qpidd" kadmin -r $REALM -q "ktadd -k /etc/qpidd.keytab qpidd/$FQDN@$REALM" chmod g+r /etc/qpidd.keytab chgrp $QPIDD_GROUP /etc/qpidd.keytab
QPIDD_GROUP="qpidd" kadmin -r $REALM -q "ktadd -k /etc/qpidd.keytab qpidd/$FQDN@$REALM" chmod g+r /etc/qpidd.keytab chgrp $QPIDD_GROUP /etc/qpidd.keytab
Copy to Clipboard Copied! Toggle word wrap Toggle overflow The default location for the keytab file is/etc/krb5.keytab
. If a different keytab file is used, the KRB5_KTNAME environment variable must contain the name of the file as the following example shows.export KRB5_KTNAME=/etc/qpidd.keytab
export KRB5_KTNAME=/etc/qpidd.keytab
Copy to Clipboard Copied! Toggle word wrap Toggle overflow If this is correctly configured, you can now enable Kerberos support on the broker by setting theauth
andrealm
options in/etc/qpid/qpidd.conf
:CDATA[# /etc/qpid/qpidd.conf auth=yes realm=EXAMPLE.COM
CDATA[# /etc/qpid/qpidd.conf auth=yes realm=EXAMPLE.COM
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Restart the broker to activate these settings. - Make sure that each Qpid user is registered in the Kerberos database, and that Kerberos is correctly configured on the client machine. The Qpid user is the account from which a Qpid messaging client is run. If it is correctly configured, the following command should succeed:
kinit user@REALM.COM
$ kinit user@REALM.COM
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Additional configuration for Java JMS clients
Java JMS clients require a few additional steps.- The Java JVM must be run with the following arguments:
- -Djavax.security.auth.useSubjectCredsOnly=false
- Forces the SASL GSSAPI client to obtain the Kerberos credentials explicitly instead of obtaining from the "subject" that owns the current thread.
- -Djava.security.auth.login.config=myjas.conf
- Specifies the jass configuration file. Here is a sample JASS configuration file:
com.sun.security.jgss.initiate { com.sun.security.auth.module.Krb5LoginModule required useTicketCache=true; };
com.sun.security.jgss.initiate { com.sun.security.auth.module.Krb5LoginModule required useTicketCache=true; };
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - -Dsun.security.krb5.debug=true
- Enables detailed debug info for troubleshooting
- The client Connection URL must specify the following Kerberos-specific broker properties:
sasl_mechs
must be set toGSSAPI
.sasl_protocol
must be set to the principal for the qpidd broker, e.g.qpidd
/sasl_server
must be set to the host for the SASL server, e.g.sasl.com
.
Here is a sample connection URL for a Kerberos connection:amqp://guest@clientid/testpath?brokerlist='tcp://localhost:5672?sasl_mechs='GSSAPI'&sasl_protocol='qpidd'&sasl_server='<server-host-name>''
amqp://guest@clientid/testpath?brokerlist='tcp://localhost:5672?sasl_mechs='GSSAPI'&sasl_protocol='qpidd'&sasl_server='<server-host-name>''
Copy to Clipboard Copied! Toggle word wrap Toggle overflow