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
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
|
=encoding utf-8
=head1 RT Authentication
RT allows for several different ways to authenticate users including an
internal user management system and a number of ways to integrate with existing
authentication systems.
=head1 Internal Authentication
RT's native internal authentication system provides administration tools to
manage usernames and passwords. If you plan to run your RT as a stand-alone
system and don't need to use accounts associated with any other system, this
may be all you need. The administration pages under Admin → Users
provide new user creation as well as password setting and control of RT's
privileged flag for existing users.
=head1 Token Authentication
Authentication tokens are typically used for accessing RT's REST APIs,
often L<RT::REST2>. To set up token access, first select an RT user
account you will use when accessing APIs and give that user account
appropriate rights to operate on tickets based on what you plan to do
(read ticket information, create tickets, update tickets, etc.).
You can then give that user the right ManageAuthTokens which will
add a new option in the menu Logged in as > Settings > AuthTokens.
When setting up token authentication, add the following directive to
your RT Apache configuration to allow RT to access the Authorization header.
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
Since tokens grant access on behalf of a user, RT prompts for a password
when a user is creating a token. However, if you have a mix of RT and
federated authentication, RT can't authenticate users via the federated
password system. For this case, you can explicitly disable the password
check with the C<$DisablePasswordForAuthToken> configuration option.
=head1 External Authentication
There are two primary types of external authentication: in one you type your
username and password into RT's login form, and in the other your web server
(such as Apache) handles authentication, often seamlessly, and tells RT the
user logged in.
Starting with RT 4.4, both of these options are supported by RT out of the
box, activated using different configuration options. The first is supported
by the L<RT::Authen::ExternalAuth> module. The second is activated using
the configuration option C<$WebRemoteUserAuth> along with some related
options. These two types may be used independently or together, and both
can fallback to RT's internal authentication.
If you are running a version of RT earlier than 4.4, you can install
L<RT::Authen::ExternalAuth|https://metacpan.org/pod/RT::Authen::ExternalAuth>
as an extension.
No matter what type of external authentication you use, RT still maintains user
records in its database that correspond to your external source. This is
necessary so RT can link tickets, groups, rights, dashboards, etc. to users.
All that is necessary for integration with external authentication systems is a
shared username or email address. However, in RT you may want to leverage
additional information from your external source. Synchronization of users,
user data, and groups is provided by an extension named
L<RT::LDAPImport>. It uses an external LDAP source, such an
OpenLDAP or Active Directory server, as the authoritative repository and keeps
RT up to date accordingly. This can be used in tandem with any of the external
authentication options as it does not provide any authentication itself.
Note that if you start with L<Internal Authentication> and then switch to
L<External Authentication>, your original users will still have passwords in
the RT database. RT ignores these passwords when handling logins, but in some
cases RT may show a password box that would normally be hidden for external
authentication because it detects an existing password. To avoid this, you can
clear passwords in the Users table when you switch to external authentication.
=head2 Via your web server, aka C<$WebRemoteUserAuth>, aka C<REMOTE_USER>
This type of external authentication is built-in to RT and bypasses the RT
login form. Instead, RT defers authentication to the web server which is
expected to set a C<REMOTE_USER> environment variable. Upon a request, RT
checks the value of C<REMOTE_USER> against its internal database and logs in
the matched user.
It is often used to provide single sign-on (SSO) support via Apache modules
such as C<mod_auth_kerb> (to talk to Active Directory). C<$WebRemoteUserAuth> is
widely used by organizations with existing authentication standards for web
services that leverge web server modules for central authentication services.
The flexibility of RT's C<$WebRemoteUserAuth> support means that it can be setup
with almost any authentication system.
In order to keep user data in sync, this type of external auth is almost always
used in combination with one or both of L<RT::Authen::ExternalAuth> and
L<RT::LDAPImport>.
=head3 Apache Configuration
When configuring Apache to protect RT, remember that the RT mail gateway
uses the web interface to upload the incoming email messages. You will
thus need to provide an exception for the mail gateway endpoint.
An example of using LDAP authentication and HTTP Basic auth:
<Location />
Require valid-user
AuthType Basic
AuthName "RT access"
AuthBasicProvider ldap
AuthLDAPURL \
"ldap://ldap.example.com/dc=example,dc=com"
</Location>
<Location /REST/1.0/NoAuth/mail-gateway>
Require local
</Location>
=head3 RT Configuration Options
All of the following options control the behavior of RT's built-in external
authentication which relies on the web server. They are documented in detail
under the "Authorization and user configuration" section of L<RT_Config>
and you can read the documentation by running C<perldoc /usr/share/request-tracker5/etc/RT_Config.pm>.
The list below is meant to make you aware of what's available. You should read
the full documentation as described above.
=head4 C<$WebRemoteUserAuth>
Enables or disables RT's expectation that the web server will provide
authentication using the C<REMOTE_USER> environment variable.
=head4 C<$WebRemoteUserContinuous>
Check C<REMOTE_USER> on every request rather than the initial request.
When this is off, users will remain logged into RT even after C<REMOTE_USER> is
no longer provided. This provides a separation of sessions, but it may not be
desirable in all cases. For example, if a user logs out of the external
authentication system their RT session will remain active unless
C<$WebRemoteUserContinuous> is on.
=head4 C<$WebFallbackToRTLogin>
If true, allows internal logins as well as C<REMOTE_USER> by providing a login
form if external authentication fails. This is useful to provide local admin
access (usually as root) or self service access for people without external
user accounts.
=head4 C<$WebRemoteUserAutocreate>
Enables or disables auto-creation of RT users when a new C<REMOTE_USER> is
encountered.
=head4 C<$UserAutocreateDefaultsOnLogin>
Specifies the default properties of auto-created users.
=head4 C<$WebRemoteUserGecos>
Tells RT to compare C<REMOTE_USER> to the C<Gecos> field of RT users instead of
the C<Name> field.
=head2 Via RT's login form, aka RT::Authen::ExternalAuth
L<RT::Authen::ExternalAuth> provides authentication
B<using> RT's login form. It can be configured to talk to an LDAP source (such
as Active Directory), an external database, or an SSO cookie.
The key difference between C<$WebRemoteUserAuth> and
L<RT::Authen::ExternalAuth> is the use of the RT login form and what
part of the system talks to your authentication source (your web
server vs. RT itself).
As noted above, for versions of RT before 4.4, you can install
L<RT::Authen::ExternalAuth|https://metacpan.org/pod/RT::Authen::ExternalAuth>
as an extension.
=head3 Info mode and Authentication mode
There are two modes of operation in L<RT::Authen::ExternalAuth>: info and auth.
Usually you want to configure both so that successfully authenticated users
also get their information pulled and updated from your external source.
Auth-only configurations are rare, and generally not as useful.
Info-only configurations are commonly setup in tandem with C<$WebRemoteUserAuth>.
This lets your web server handle authentication (usually for SSO) and
C<RT::Authen::ExternalAuth> ensures user data is updated every time someone
logs in.
=head2 RT::Extension::LDAPImport
L<RT::LDAPImport> provides no authentication, but
is useful alongside authentication because it provides user data and group
member synchronization from any LDAP source into RT. It provides a similar
but more complete sync solution than L<RT::Authen::ExternalAuth> (which
only updates upon login and doesn't handle groups). It may be used with
either of RT's external authentication sources, or on it's own.
Starting with RT 4.4, L<RT::LDAPImport> is part of RT. For
earlier versions of RT, you can install L<RT::Extension::LDAPImport> as
an extension.
|
