Rabbitmq vhost что это

Расширенная настройка подключения к RabbitMQ

Настройка vhost в rabbitmq

Для подключения нескольких экземпляров Loyalty к одному брокеру сообщений RabbitMQ необходимо воспользоваться виртуальными хостами.

Для создания отдельного vhost в RabbitMq вам необходимо:

Будет создан виртуальный хост с именем по которому вам необходимо выполнять подключение

Настройка подключения из Creatio

Для подключения к RabbitMQ необходимо в группе «Импорт и интеграции» перейти на страницу «Настройка программы лояльности»

В настройках подключения необходимо указать имя сервиса на котором развернут RabbitMQ, логин и пароль пользователя RabbitMQ и Name виртуального хоста который вы создали в RabbitMQ

Настройка подключения сервиса к RabbitMQ

Для подключения к виртуальным хостам в настройку переменных добавлен параметр RMQ_VIRTUAL_HOST

В параметре RMQ_VIRTUAL_HOST необходимо указать значение name созданного виртуального хоста на стороне RabbitMQ

Пример compose файла:

После разворачивания сервиса в rabbitMQ видим, что появилась соответствующая очередь с подключением к виртуальному хосту

О НАС

Компания «Программные Технологии» занимается внедрением проектов по автоматизации бизнес-процессов, а также разработкой продуктов на платформе Creatio.

Мы работаем на рынке с 2003 года, а с 2014 года являемся Центром Разработки и Внедрения Террасофт Поволжье.

Источник

RabbitMQ URI Specification

This specification defines an «amqp» URI scheme. Conforming URIs represent the information needed by AMQP 0-9-1 clients as well as some RabbitMQ plugins to connect to RabbitMQ server.

1. Introduction

The scope of this specification is limited to AMQP 0-9-1, the original protocol implemented by RabbitMQ. An AMQP 0-9-1 client connects to a RabbitMQ node in order to publish and consume messages according to the messaging model.

A RabbitMQ client will typically obtain all these parameters from a configuration file or environment variables in order for it to set up the connection. So it is convenient if the connection parameters can be combined into a single character string, rather than as distinct configuration settings. That means that only one configuration setting is needed, and only one value has to be passed to the client library.

But combining the connection parameters into a single string requires a convention, understood by the client library, about exactly how the connection parameters are represented and delimited. It is desirable to standardise that convention, so that it may be implemented consistently by many AMQP 0-9-1 client libraries. An obvious basis for such a standard is the generic syntax for URIs defined in RFC3986.

The purpose of this specification is to define the «amqp» and «amqps» URI schemes which represent the AMQP 0-9-1 connection parameters within the generic URI syntax.

2. The «amqp» URI scheme

The syntax of an AMQP 0-9-1 URI is defined by the following ABNF rules. All names in these rules not defined here are taken from RFC3986.

Once a URI has been successfully parsed according to this syntax, the connection parameters are determined as described in the following sections.

2.1. Host

The host to which the underlying TCP connection is made is determined from the host component according to RFC3986, section 3.2.2. Note that according to the ABNF, the host component may not be absent, but it may be zero-length.

2.2. Port

The port number to which the underlying TCP connection is made is determined from the port component according to RFC3986. The port component may be absent, indicated by the lack of the «:» character separating it from the host. If it is absent, then the IANA-assigned port number for AMQP 0-9-1, 5672, should be substituted instead.

2.3. Username and password

If present, the username and password components should be used in the SASL exchange that occurs via the connection.secure and connection.secure-ok AMQP 0-9-1 methods. Any percent-encoded octets in the username and password should be decoded before they are used in the SASL exchange, and the resulting octet sequences should be regarded as UTF-8 encoded.

Both the username and password may be absent; their absence is indicated by the lack of the «@» character separating the amqp_userinfo from the host. If the username is present, the password may be absent; this is indicated by the lack of the «:» character separating it from the username. Zero-length usernames and passwords are not equivalent to absent usernames and passwords.

RFC3986 states that «A password appearing within the userinfo component is deprecated and should be considered an error» (section 7.5). While this is sound advice in the context of user-facing applications (e.g. web browsers) and for URIs that might be stored and displayed insecurely, it is not necessarily valid for backend applications. Many of those applications are «headless» services, and open RabbitMQ connections on behalf of the application as a whole rather than for specific users. So the username and password identify the application rather than a human user, and are likely to be included with connection parameters appearing in a secure store of configuration settings. User-facing applications, which make RabbitMQ connections on behalf of specific users, are also possible. In such cases the username and password may be provided by the user to identify themselves. But such applications are the exception rather than the rule. Thus authors of applications implementing this specification should not consider themselves bound by section 7.5 of RFC3986. Please also see section 5 («Security Considerations») below.

2.4. Vhost

The vhost component is used as the basis for the virtual-host field of the connection.open AMQP 0-9-1 method. Any percent-encoded octets in the vhost should be decoded before the it is passed to the server.

The vhost component may be absent; this is indicated by the lack of a «/» character following the amqp_authority. An absent vhost component is not equivalent to an empty (i.e. zero-length) vhost name.

3. Handling of absent components

Certain URI components (the port, username, password, vhost and query) may be absent from a URI. The host may not be absent, but may be zero-length; for the purposes of this section, a zero-length host is treated as absent.

Apart from the port (which is covered in the section 2.2 above), this specification does not mandate how implementations should handle absent components. Possible approaches include, but are not limited to, the following:

Furthermore, an application may follow different strategies for different components.

For example, the URI «amqp://», in which all components are absent, might result in an client library using a set of defaults which correspond to a connection to a local RabbitMQ server, authenticating as a guest user. This would be convenient for development purposes.

4. The «amqps» URI scheme

The «amqps» URI scheme is used to instruct a client to make an secured connection to the server.

The AMQP 0-9-1 specification assume that the underlying transport layer provides reliable byte stream-oriented virtual circuits. When it is not necessary to secure the traffic on the network, TCP/IP connections are typically used.

In cases where the traffic must be secured, TLS (see RFC5246) can be used. Current practice is simply to layer AMQP 0-9-1 on top of TLS to form «AMQPS» (analogously to the way HTTPS layers HTTP on top of TLS). AMQP 0-9-1 does not provide a way for a non-secured connection to be upgraded to a secured connection. So a server that supports both secured and non-secured connections must listen on distinct ports for the two types of connections.

Apart from the scheme identifier, the syntax of the «amqps» URI scheme is identical to that of the «amqp» URI scheme:

The interpretation of an amqps URI differs from the corresponding «plain» URI in two ways. In all other respects, the interpretation is the same.

5. Security Considerations

As discussed in the section 2.3 above, URIs will often be supplied to applications as configuration settings. In such contexts, if the password cannot be incorporated into the URI, then it will simply be supplied as a separate configuration setting. This reduces the benefit of the use of a URI without any increase in security. For this reason, this specification overrides RFC3986’s deprecation of passwords within the userinfo component.

Developers should feel free use the password component whenever this does not impact security. Nonetheless, they should be aware that the contents of the password component may be sensitive, and they should avoid leaking it (e.g. the full URI should not appear in exception messages or log records, which might be visible to less privileged personnel).

Appendix A: Examples

Below is a table of examples that show how URIs should be parsed according to this specification. Many of these examples are intended to demonstrate edge cases in order to elucidate the specification and provide test cases for code that parses URIs. Each row shows a URI, and the resulting octet sequences for each component. Those octet sequences are enclosed in double quotes. Empty cells indicate absent components, as described in section 3.

Appendix B: Query parameters

Clients may require further parameterisation to define how they should connect to servers. The standard URI query syntax may be used to provide additional information to the client.

Query parameters may be more implementation-specific than other URI parts; as such this document will not attempt to prescribe how they should be used. However, we have documented how the officially supported clients read URI query parameters here.

Getting Help and Providing Feedback

If you have questions about the contents of this guide or any other topic related to RabbitMQ, don’t hesitate to ask them on the RabbitMQ mailing list.

Help Us Improve the Docs <3

If you’d like to contribute an improvement to the site, its source is available on GitHub. Simply fork the repository and submit a pull request. Thank you!

Источник

FAQ: What is a RabbitMQ vhost?

By now, you’re probably familiar with the concepts of exchanges, bindings, and queues in RabbitMQ. When you actually explore RabbitMQ, however, you will soon realize there is a concept that hasn’t always been covered in detail, namely, vhosts (Virtual Hosts).

What is a vhost?

Think of vhosts as individual, uniquely named containers. Inside each vhost container is a logical group of exchanges, connections, queues, bindings, user permissions, and other system resources. Different users can have different permissions to different vhost and queues and exchanges can be created, so they only exist in one vhost. When a client establishes a connection to the RabbitMQ server, it specifies the vhost within which it will operate, as in the following example: amqp://myuser:mypassword@localhost:5672/myvhost

Resources such as exchanges and queues are named resources inside the vhost container, making each vhost essentially a RabbitMQ mini-server. When configuring RabbitMQ, at least one vhost is needed, which in default is just a slash “/”.

Vhosts are created through the management portal, through the HTTP API or via rabbitmqctl. View vhosts by entering the admin tab and select the Virtual Hosts. Select the Add New Virtual Host options to create a new vhost. The permissions within the vhost and the users assigned to it depend on your system requirements, and it’s up to you to assign users to the vhost. A newly created vhost always has a default set of exchanges, but no other entities and no user permissions.

A vhost is a virtual separation

Vhosts do not share exchanges or queues between them, and users, policies, etc. are unique to each vhost. Essentially, RabbitMQ vhosts are like a virtual machine for a physical server, allowing for multiple secure application operations through virtual rather than physical separation. As the separation is virtual, it is important to remember that the vhosts are not physically separated from each other and therefore they might affect each other’s performance.

If one service is experiencing a traffic spike or a code bug, this may cause problems for other services and affect their performance. A vhost can be created for each service to hold all of the logical infrastructure, which also allows for better individual topology management.

RabbitMQ vhosts make it possible to have many different virtual brokers within one single RabbitMQ instance. The same broker can be used on parts of different applications. You can separate environments, e.g. production to one vhost and staging to another vhost, within the same broker instead of setting up multiple brokers.

Resource permission within a vhost

Resource permissions in RabbitMQ are dependent on each vhost. A user does not have global permissions, just permissions in one or more vhost(s), specified by you. This ensures absolute separation since all users, exchanges, queues, and bindings in each vhost cannot be reached from any other virtual hosts. This makes vhosts extremely useful to avoid naming collisions and to separate multiple customers.

Limits and Security within a vhost

An exchange on one vhost cannot be bound to a queue on another, which is good for security and for portability. For instance, a banking app that has a deposit function using its own vhost. This deposit vhost may initially operate on the same instance that houses other functions of the app, but one day the deposit traffic goes way up and uses excessive server resources, slowing down the other functions. Because deposits happen on a separate vhost, this function can easily and safely be moved to another server.

Connection leaks and users that create way too many queues are two common errors in RabbitMQ. As of RabbitMQ version 3.7.0, it is possible to set a per-vhost limit. This means that you can set a limit on the maximum allowed number of queues or concurrent client connections in a vhost.

Shared servers in CloudAMQP are separated though vhosts

Shared servers on CloudAMQP, like Little Lemur and Tough Tiger are virtual hosts located on a large shared RabbitMQ server. This means that a single instance of RabbitMQ is running to serve multiple tenants.

Explore our blog for great tutorials and information on how to configure RabbitMQ. Remember that you can get started with RabbitMQ at CloudAMQP within two minutes. Please email us if you have suggestions, questions, or other feedback!

Источник

Virtual Hosts

Introduction

RabbitMQ is multi-tenant system: connections, exchanges, queues, bindings, user permissions, policies and some other things belong to virtual hosts, logical groups of entities. If you are familiar with virtual hosts in Apache or server blocks in Nginx, the idea is similar. There is, however, one important difference: virtual hosts in Apache are defined in the configuration file; that’s not the case with RabbitMQ: virtual hosts are created and deleted using rabbitmqctl or HTTP API instead.

Logical and Physical Separation

Virtual hosts provide logical grouping and separation of resources. Separation of physical resources is not a goal of virtual hosts and should be considered an implementation detail.

For example, resource permissions in RabbitMQ are scoped per virtual host. A user doesn’t have global permissions, only permissions in one or more virtual hosts. User tags can be considered global permissions but they are an exception to the rule.

Therefore when talking about user permissions it is very important to clarify what virtual host(s) they apply to.

Virtual Hosts and Client Connections

A virtual host has a name. When an AMQP 0-9-1 client connects to RabbitMQ, it specifies a vhost name to connect to. If authentication succeeds and the username provided was granted permissions to the vhost, connection is established.

Connections to a vhost can only operate on exchanges, queues, bindings, and so on in that vhost. «Interconnection» of e.g. a queue and an exchange in different vhosts is only possible when an application connects to two vhosts at the same time. For example, an application can consume from one vhost then republishes into the other. This scenario can involve vhosts in different clusters or the same cluster (or a single node). RabbitMQ Shovel plugin is one example of such application.

Creating a Virtual Hosts

A virtual host can be created using CLI tools or an HTTP API endpoint.

A newly created vhost will have a default set of exchanges but no other entities and no user permissions. For a user to be able to connect and use the virtual host, permissions to it must be granted to every user that will use the vhost, e.g. using rabbitmqctl set_permissions.

Using CLI Tools

A virtual host can be created using rabbitmqctl’s add_vhost command which accepts virtual host name as the only mandatory argument.

Here’s an example that creates a virtual host named qa1 :

Using HTTP API

A virtual host can be created using the PUT /api/vhosts/ HTTP API endpoint where is the name of the virtual host

Here’s an example that uses curl to create a virtual host vh1 by contacting a node at rabbitmq.local:15672 :

Bulk Creation and Pre-provisioning

Virtual host creation involves a blocking cluster-wide transaction. Each node has to perform a number of setup steps which are moderately expensive. In practice it can take up to a few seconds for a virtual host to be created.

When a number of virtual hosts is created in a loop, CLI and HTTP API clients can outpace the actual rate of virtual host creation and experience timeouts. If that’s the case operation timeout should be increased and delays should be introduced between operations.

Definition export and import is the recommended way of pre-configuring many virtual hosts at deployment time.

Deleting a Virtual Hosts

A virtual host can be created using CLI tools or an HTTP API endpoint.

Deleting a virtual host will permanently delete all entities (queues, exchanges, bindings, policies, permissions, etc) in it.

Using CLI Tools

A virtual host can be deleted using rabbitmqctl’s delete_vhost command which accepts virtual host name as the only mandatory argument.

Here’s an example that deletes a virtual host named qa1 :

Using HTTP API

A virtual host can be deleted using the DELETE /api/vhosts/ HTTP API endpoint where is the name of the virtual host

Here’s an example that uses curl to delete a virtual host vh1 by contacting a node at rabbitmq.local:15672 :

Virtual Hosts and STOMP

Like AMQP 0-9-1, STOMP includes the concept of virtual hosts. See the STOMP guide for details.

Virtual Hosts and MQTT

Unlike AMQP 0-9-1 and STOMP, MQTT doesn’t have the concept of virtual hosts. MQTT connections use a single RabbitMQ host by default. There are MQTT-specific convention and features that make it possible for clients to connect to a specific vhosts without any client library modifications. See the MQTT guide for details.

Limits

In some cases it is desirable to limit the maximum allowed number of queues or concurrent client connections in a vhost. As of RabbitMQ 3.7.0, this is possible via per-vhost limits.

These limits can be configured using rabbitmqctl or HTTP API.

Configuring Limits Using rabbitmqctl

rabbitmqctl set_vhost_limits is the command used to define vhost limits. It requires a vhost parameter and a JSON document of limit definitions.

Configuring Max Connection Limit

To disable client connections to a vhost, set the limit to a zero:

To lift the limit, set it to a negative value:

Configuring Max Number of Queues

To lift the limit, set it to a negative value:

Getting Help and Providing Feedback

If you have questions about the contents of this guide or any other topic related to RabbitMQ, don’t hesitate to ask them on the RabbitMQ mailing list.

Help Us Improve the Docs <3

If you’d like to contribute an improvement to the site, its source is available on GitHub. Simply fork the repository and submit a pull request. Thank you!

Источник

Authentication, Authorisation, Access Control

Overview

This document describes authentication and authorisation features in RabbitMQ. Together they allow the operator to control access to the system.

Different users can be granted access only to specific virtual hosts. Their permissions in each virtual hosts also can be limited.

This guide covers a variety of authentication, authorisation and user management topics such as

Password-based authentication has a companion guide. A closely related topic of TLS support is also covered in a dedicated guide.

Terminology and Definitions

Authentication and authorisation are often confused or used interchangeably. That’s wrong and in RabbitMQ, the two are separated. For the sake of simplicity, we’ll define authentication as «identifying who the user is» and authorisation as «determining what the user is and isn’t allowed to do.»

The Basics

Clients use RabbitMQ features to connect to it. Every connection has an associated user which is authenticated. It also targets a virtual host for which the user must have a certain set of permissions.

User credentials, target virtual host and (optionally) client certificate are specified at connection initiation time.

There is a default pair of credentials called the default user. This user can only be used for host-local connections by default. Remote connections that use it will be refused.

Production environments should not use the default user and create new user accounts with generated credentials instead.

Default Virtual Host and User

When the server first starts running, and detects that its database is uninitialised or has been deleted, it initialises a fresh database with the following resources:

It is advisable to pre-configure a new user with a generated username and password or delete the guest user or at least change its password to reasonably secure generated value that won’t be known to the public.

Authentication: Who Do You Say You Are?

After an application connects to RabbitMQ and before it can perform operations, it must authenticate, that is, present and prove its identity. With that identity, RabbitMQ nodes can look up its permissions and authorize access to resources such as virtual hosts, queues, exchanges, and so on.

Two primary ways of authenticating a client are username/password pairs and X.509 certificates. Username/password pairs can be used with a variety of authentication backends that verify the credentials.

Connections that fail to authenticate will be closed with an error message in the server log.

To authenticate client connections using X.509 certificate a built-in plugin, rabbitmq-auth-mechanism-ssl, must be enabled and clients must be configured to use the EXTERNAL mechanism. With this mechanism, any client-provided password will be ignored.

«guest» user can only connect from localhost

By default, the guest user is prohibited from connecting from remote hosts; it can only connect over a loopback interface (i.e. localhost ). This applies to connections regardless of the protocol. Any other users will not (by default) be restricted in this way.

The recommended way to address this in production systems is to create a new user or set of users with the permissions to access the necessary virtual hosts. This can be done using CLI tools, HTTP API or definitions import.

This is configured via the loopback_users item in the configuration file.

A minimalistic RabbitMQ config file which allows remote connections for guest looks like so:

Managing Users and Permissions

Users and permissions can be managed using CLI tools and definition import (covered below).

Before We Start: Shell Escaping and Generated Passwords

It is a common security practice to generate complex passwords, often involving non-alphanumeric characters. This practice is perfectly applicable to RabbitMQ users.

, and others) as control characters.

When users are created via HTTP API without using a shell (e.g. curl ), the control character limitation does not apply. However, different escaping rules may be necessary depending on the programming language used.

Adding a User

On Windows, rabbitmqctl becomes rabbitmqctl.bat and shell escaping would be different:

Listing Users

To list users in a cluster, use rabbitmqctl list_users :

The output can be changed to be JSON:

Deleting a User

To delete a user, use rabbitmqctl delete_user :

Granting Permissions to a User

To grant permissions to a user in a virtual host, use rabbitmqctl set_permissions :

Revoking Permissions of a User in a Virtual Host

To revoke permissions from a user in a virtual host, use rabbitmqctl clear_permissions :

Operations on Multiple Virtual Hosts

Seeding (Pre-creating) Users and Permissions

Production environments typically need to pre-configure (seed) a number of virtual hosts, users and user permissions.

This can be done in a few ways:

CLI Tools

Definition Import at Node Boot Time

This process involves the following steps:

See importing definitions on node boot in the definitions guide to learn more.

Definition Import After Node Boot

Override Default User Credentials

Two configuration options can be used to override default user credentials. This user will only be created on first node boot so they must exist in the configuration file before first boot.

Authorisation: How Permissions Work

When a RabbitMQ client establishes a connection to a server and authenticates, it specifies a virtual host within which it intends to operate. A first level of access control is enforced at this point, with the server checking whether the user has any permissions to access the virtual hosts, and rejecting the connection attempt otherwise.

Resources, i.e. exchanges and queues, are named entities inside a particular virtual host; the same name denotes a different resource in each virtual host. A second level of access control is enforced when certain operations are performed on resources.

RabbitMQ distinguishes between configure, write and read operations on a resource. The configure operations create or destroy resources, or alter their behaviour. The write operations inject messages into a resource. And the read operations retrieve messages from a resource.

In order to perform an operation on a resource the user must have been granted the appropriate permissions for it. The following table shows what permissions on what type of resource are required for all the AMQP commands which perform permission checks.

Permissions are expressed as a triple of regular expressions — one each for configure, write and read — on per-vhost basis. The user is granted the respective permission for operations on all resources with names matching the regular expressions.

For convenience RabbitMQ maps AMQP 0-9-1’s default exchange’s blank name to ‘amq.default’ when performing permission checks.

For example, ‘^(amq\.gen.*|amq\.default)$’ gives a user access to server-generated names and the default exchange. The empty string, » is a synonym for ‘^$’ and restricts permissions in the exact same way.

RabbitMQ may cache the results of access control checks on a per-connection or per-channel basis. Hence changes to user permissions may only take effect when the user reconnects.

For details of how to set up access control, please see the User management section as well as the rabbitmqctl man page.

User Tags and Management UI Access

In addition to the permissions covered above, users can have tags associated with them. Currently only management UI access is controlled by user tags.

The tags are managed using rabbitmqctl. Newly created users do not have any tags set on them by default.

Please refer to the management plugin guide to learn more about what tags are supported and how they limit management UI access.

Topic Authorisation

As of version 3.7.0, RabbitMQ supports topic authorisation for topic exchanges. The routing key of a message published to a topic exchange is taken into account when publishing authorisation is enforced (e.g. in RabbitMQ default authorisation backend, the routing key is matched against a regular expression to decide whether the message can be routed downstream or not). Topic authorisation targets protocols like STOMP and MQTT, which are structured around topics and use topic exchanges under the hood.

Topic authorisation is an additional layer on top of existing checks for publishers. Publishing a message to a topic-typed exchange will go through both the basic.publish and the routing key checks. The latter is never called if the former refuses access.

Topic authorisation can also be enforced for topic consumers. Note that it works differently for different protocols. The concept of topic authorisation only really makes sense for the topic-oriented protocols such as MQTT and STOMP. In AMQP 0-9-1, for example, consumers consume from queues and thus the standard resource permissions apply. In addition for AMQP 0-9-1, binding routing keys between an AMQP 0-9-1 topic exchange and a queue/exchange are checked against the topic permissions configured, if any. For more information about how RabbitMQ handles authorisation for topics, please see the STOMP and MQTT documentation guides.

When default authorisation backend is used, publishing to a topic exchange or consuming from a topic is always authorised if no topic permissions are defined (which is the case on a fresh RabbitMQ installation). With this authorisation backend, topic authorisation is optional: you don’t need to whitelist any exchanges. To use topic authorisation therefore you need to opt in and define topic permissions for one or more exchanges. For details please see the rabbitmqctl man page.

If a different authorisation backend (e.g. LDAP, HTTP, AMQP) is used, please refer to the documentation of those backends.

If a custom authorisation backend is used, topic authorisation is enforced by implementing the check_topic_access callback of the rabbit_authz_backend behavior.

Alternative Authentication and Authorisation Backends

Authentication and authorisation are pluggable. Plugins can provide implementations of

It is possible for a plugin to provide both. For example the internal, LDAP and HTTP backends do so.

Some plugins, for example, the Source IP range one, only provide an authorisation backend. Authentication is supposed to be handled by the internal database, LDAP, etc.

Combining Backends

It is possible to use multiple backends for authn or authz using the auth_backends configuration key. When several authentication backends are used then the first positive result returned by a backend in the chain is considered to be final. This should not be confused with mixed backends (for example, using LDAP for authentication and internal backend for authorisation).

The following example configures RabbitMQ to use the internal backend only (and is the default):

When using third party plugins, providing a full module name is necessary.

The following example configures RabbitMQ to use the LDAP backend for both authentication and authorisation. Internal database will not be consulted:

This will check LDAP first, and then fall back to the internal database if the user cannot be authenticated through LDAP:

Same as above but will fall back to the HTTP backend instead:

The following example configures RabbitMQ to use the internal database for authentication and the source IP range backend for authorisation:

The following example configures RabbitMQ to use the LDAP backend for authentication and the internal backend for authorisation:

The example below is fairly advanced. It will check LDAP first. If the user is found in LDAP then the password will be checked against LDAP and subsequent authorisation checks will be performed against the internal database (therefore users in LDAP must exist in the internal database as well, but do not need a password there). If the user is not found in LDAP then a second attempt is made using only the internal database:

Authentication Mechanisms

More authentication mechanisms can be provided by plugins. See the plugin development guide for more information on general plugin development.

Built-in Authentication Mechanisms

The built-in mechanisms are:

Mechanism Configuration in the Server

The configuration variable auth_mechanisms in the rabbit application determines which of the installed mechanisms are offered to connecting clients. This variable should be a list of atoms corresponding to mechanism names, for example [‘PLAIN’, ‘AMQPLAIN’] by default. The server-side list is not considered to be in any particular order. See the configuration file documentation.

Mechanism Configuration in the Client

Mechanism Configuration in Java

ConnectionFactory.getSaslConfig() and ConnectionFactory.setSaslConfig(SaslConfig) are the primary methods for interacting with authentication mechanisms.

Mechanism Configuration in Erlang

The Erlang client provides its own SASL mechanism implementations in the amqp_auth_mechanisms module. The #amqp_params<> record can be provided with a list of authentication functions in preference order for network connections.

Troubleshooting Authentication

Server logs will contain entries about failed authentication attempts:

Authentication failures on connections that authenticate using X.509 certificates will be logged differently. See TLS Troubleshooting guide for details.

rabbitmqctl authenticate_user can be used to test authentication for a username and password pair:

If authentication succeeds, it will exit with the code of zero. In case of a failure, a non-zero exit code will be used and a failure error message will be printed.

rabbitmqctl authenticate_user will use a CLI-to-node communication connection to attempt to authenticate the username/password pair against an internal API endpoint. The connection is assumed to be trusted. If that’s not the case, its traffic can be encrypted using TLS.

Per AMQP 0-9-1 spec, authentication failures should result in the server closing TCP connection immediately. However, with RabbitMQ clients can opt in to receive a more specific notification using the authentication failure notification extension to AMQP 0-9-1. Modern client libraries support that extension transparently to the user: no configuration would be necessary and authentication failures will result in a visible returned error, exception or other way of communicating a problem used in a particular programming language or environment.

Troubleshooting Authorisation

rabbitmqctl list_permissions can be used to inspect a user’s permission in a given virtual host:

Server logs will contain entries about operation authorisation failures. For example, if a user does not have any permissions configured for a virtual host:

authorisation failures (permission violations) are also logged:

Getting Help and Providing Feedback

If you have questions about the contents of this guide or any other topic related to RabbitMQ, don’t hesitate to ask them on the RabbitMQ mailing list.

Help Us Improve the Docs <3

If you’d like to contribute an improvement to the site, its source is available on GitHub. Simply fork the repository and submit a pull request. Thank you!

Источник