File: README-authorisation

package info (click to toggle)
rabbitmq-server 2.8.4-1
  • links: PTS
  • area: main
  • in suites: wheezy
  • size: 8,928 kB
  • sloc: erlang: 52,968; python: 2,846; xml: 1,987; sh: 816; makefile: 683; perl: 86; ruby: 63
file content (156 lines) | stat: -rw-r--r-- 4,516 bytes parent folder | download
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
Overview
========

Authorisation is effected by three configuration options:

* vhost_access_query
* resource_access_query
* tag_queries

Each defines a query that will determine whether a user has access to
a vhost, a resource (e.g. exchange, queue, binding) or is considered
an administrator.

The default values are {constant, true}, {constant, true} and
[{administrator, {constant, false}}] respectively, granting all users
access to all objects in all vhosts, but not making them
administrators.

A query can be of one of several types:

Constant Query
--------------

{constant, Bool}

This will always return either true or false, unconditionally granting
or denying access.

Exists Query
------------

{exists, Pattern}

This will substitute variables into the pattern, and return true if
there exists an object with the resulting DN. Substitution occurs with
${} syntax. The vhost_access_query in the example configuration below
therefore allows you to control access to vhosts by controlling the
existence of OUs in a vhosts OU.

Each of the three queries allow different substitutions:

vhost_access_query:
  ${username}
  ${user_dn}
  ${vhost}

resource_access_query:
  ${username}
  ${user_dn}
  ${vhost}
  ${resource} (one of exchange or queue)
  ${name}
  ${permission} (one of configure, write or read)

The terms configure, write and read for resource access have the same
meanings that they do for the built-in RabbitMQ permissions system,
see http://www.rabbitmq.com/access-control.html

tag_queries:
  ${username}
  ${user_dn}

Note that tag_queries consists of a proplist, mapping the name of a
tag to a query to perform to determine whether or not the user has
that tag. You must list queries for all tags that you want your users
to have.

In Group Query
--------------

{in_group, Pattern}

Like the Exists Query, substitutes arguments into a pattern to look
for an object. However, this query returns true if the logged in user
is a member.

Match Query
-----------

{match, StringSubQuery, RESubQuery}

Takes a string and a regular expression, and checks that the one
matches the other. Note that the string and the regular expression are
both queries in turn.

String Query
------------

{string, Pattern}

Just substitutes arguments into a string. As this returns a string
rather than a boolean it should be used within a match query.

Attribute Query
---------------

{attribute, DNPattern, AttributeName}

Returns the value of an attribute of an object retrieved from LDAP. As
this returns a string rather than a boolean it should be used within a
match query.

For Query
---------

{for, [{Name, Value, SubQuery}, ...]}

This allows you to split up a query and handle different cases with
different subqueries.

Options should be a list of three-tuples, with each tuple containing a
name, value and subquery. The name is the name of a variable
(i.e. something that would go into a ${} substitution). The value is a
possible value for that variable.

So the example:

     {resource_access_query,
      {for, [{resource, exchange,
              {for, [{permission, configure,
                      { in_group, "cn=wheel,ou=groups,dc=example,dc=com" }
                     },
                     {permission, write, {constant, true}},
                     {permission, read,  {constant, true}}
                    ]}},
             {resource, queue, {constant, true}} ]}}

would allow members of the "wheel" group to declare and delete
exchanges, and allow all users to do everything else.

Example Configuration
=====================

TODO improve and explain this

[
  {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"},
     {vhost_access_query,    {exists,
                              "ou=${vhost},ou=vhosts,dc=example,dc=com"}},
     {resource_access_query,
      {for, [{resource, exchange,
              {for, [{permission, configure,
                      { in_group, "cn=wheel,ou=groups,dc=example,dc=com" }
                     },
                     {permission, write, {constant, true}},
                     {permission, read,  {constant, true}}
                    ]}},
             {resource, queue, {constant, true}} ]}},
     {tag_queries,           [{administrator, {constant, false}}]},
     {use_ssl,               false},
     {port,                  389},
     {log,                   false} ] }
].