1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
|
Overview
========
This plugin provides the ability for your RabbitMQ server to perform
authentication (determining who can log in) and authorisation
(determining what permissions they have) by deferring to an external
LDAP server. To use this plugin, some editing of the RabbitMQ
configuration file is required. You must enable the plugin, and then
configure it. You are advised to read this entire file before
starting.
Requirements
============
You can build and install it like any other plugin (see
http://www.rabbitmq.com/plugin-development.html).
Enabling the plugin
===================
To enable the plugin, set the value of the "auth_backends" configuration item
for the "rabbit" application to include "rabbit_auth_backend_ldap".
"auth_backends" is a list of authentication providers to try in order.
Therefore a complete RabbitMQ configuration that enables this plugin would
look like:
[{rabbit, [{auth_backends, [rabbit_auth_backend_ldap]}]}].
to use only LDAP, or:
[{rabbit,
[{auth_backends, [rabbit_auth_backend_ldap, rabbit_auth_backend_internal]}]
}].
to use LDAP and the internal database.
Configuring the plugin
======================
You must then configure the plugin. This plugin has quite a few configuration
options, but most have sensible defaults.
The most complex part of configuring the plugin pertains to
authorisation (i.e. granting permissions to your users via LDAP). This
is documented separately in README-authorisation.
The default configuration allows all users to access all objects in
all vhosts, but does not make them administrators. If you're happy
with that, there is no need to read README-authorisation.
The options not directly related to authorisation are:
servers
-------
Default: ["ldap"]
List of LDAP servers to attempt to bind to, in order. You almost certainly
want to change this.
user_dn_pattern
---------------
Default: "${username}"
There are two ways to convert a username as provided through AMQP to a
Distinguished Name. The simplest way is via string substitution with
user_dn_pattern. To do this, set user_dn_pattern to a string
containing exactly one instance of "${username}".
For example, setting user_dn_pattern to:
"cn=${username},ou=People,dc=example,dc=com"
would cause the username "simon" to be converted to the DN
"cn=simon,ou=People,dc=example,dc=com"
dn_lookup_attribute and dn_lookup_base
--------------------------------------
Default: 'none' and 'none'
The other way to convert a username to a Distinguished Name is via an
LDAP lookup after binding. In order for this to work your LDAP server
needs to be configured to allow binding with the unadorned username
(Microsoft Active Directory typically does this).
To do this, set dn_lookup_attribute to the name of the attribute the
represents the user name, and dn_lookup_base to the base DN for the
query.
For example, if I set
{dn_lookup_attribute, "userPrincipalName"},
{dn_lookup_base, "DC=vmware,DC=com"}
I can authenticate as "smacmullen@vmware.com" and have my local Active
Directory server return my real DN.
other_bind
----------
Default: as_user
For authentication this plugin binds to the LDAP server as
the user it is trying to authenticate. This option controls how to
bind for authorisation queries, and to retrieve the details of a user
who is logging in without presenting a password (e.g. SASL EXTERNAL).
This option must either be one of the atoms 'as_user' or 'anon', or a
tuple {UserDN, Password}. 'as_user' means to bind as the authenticated
user.
use_ssl
-------
Default: false
Whether to use LDAP over SSL. Uses the same SSL configuration as elsewhere in
RabbitMQ.
port
----
Default: 389
Port on which to connect to the LDAP servers.
log
---
Default: false
Set to true to cause LDAP traffic to be written to the RabbitMQ
log. You probably only want to use this for debugging, since it will
usually cause passwords to be written to the logs, and is rather verbose.
Example configuration file
==========================
A minimal configuration file with some options specified might look
like:
[
{rabbit, [{auth_backends, [rabbit_auth_backend_ldap]}]},
{rabbitmq_auth_backend_ldap,
[ {servers, ["my-ldap-server"]},
{user_dn_pattern, "cn=${username},ou=People,dc=example,dc=com"} ] }
].
Limitations
===========
Currently this plugin is rather chatty with LDAP connections when
doing authorisation over LDAP - every time RabbitMQ needs to do an
authorisation query it starts a new LDAP connection. However, RabbitMQ
does have a per-channel authorisation cache, so this is not too awful.
There might need to be more types of queries.
|
