Mercurial > kallithea
comparison docs/setup.rst @ 1657:d2a108366f8f beta
Added documentation for container-based and proxy pass-through authentication
author | Liad Shani <liadff@gmail.com> |
---|---|
date | Mon, 07 Nov 2011 15:16:32 +0200 |
parents | a9fef2e6c1ff |
children | 456e1e3ce4eb |
comparison
equal
deleted
inserted
replaced
1656:833f9dec0a06 | 1657:d2a108366f8f |
---|---|
342 Last Name Attribute = sn | 342 Last Name Attribute = sn |
343 E-mail Attribute = mail | 343 E-mail Attribute = mail |
344 | 344 |
345 All other LDAP settings will likely be site-specific and should be | 345 All other LDAP settings will likely be site-specific and should be |
346 appropriately configured. | 346 appropriately configured. |
347 | |
348 | |
349 | |
350 Authentication by container or reverse-proxy | |
351 -------------------------------------------- | |
352 | |
353 Starting with version 1.3, RhodeCode supports delegating the authentication | |
354 of users to its WSGI container, or to a reverse-proxy server through which all | |
355 clients access the application. | |
356 | |
357 When these authentication methods are enabled in RhodeCode, it uses the | |
358 username that the container/proxy (Apache/Nginx/etc) authenticated and doesn't | |
359 perform the authentication itself. The authorization, however, is still done by | |
360 RhodeCode according to its settings. | |
361 | |
362 When a user logs in for the first time using these authentication methods, | |
363 a matching user account is created in RhodeCode with default permissions. An | |
364 administrator can then modify it using RhodeCode's admin interface. | |
365 It's also possible for an administrator to create accounts and configure their | |
366 permissions before the user logs in for the first time. | |
367 | |
368 Container-based authentication | |
369 '''''''''''''''''''''''''''''' | |
370 | |
371 In a container-based authentication setup, RhodeCode reads the user name from | |
372 the ``REMOTE_USER`` server variable provided by the WSGI container. | |
373 | |
374 After setting up your container (see `Apache's WSGI config`_), you'd need | |
375 to configure it to require authentication on the location configured for | |
376 RhodeCode. | |
377 | |
378 In order for RhodeCode to start using the provided username, you should set the | |
379 following in the [app:main] section of your .ini file:: | |
380 | |
381 container_auth_enabled = true | |
382 | |
383 | |
384 Proxy pass-through authentication | |
385 ''''''''''''''''''''''''''''''''' | |
386 | |
387 In a proxy pass-through authentication setup, RhodeCode reads the user name | |
388 from the ``X-Forwarded-User`` request header, which should be configured to be | |
389 sent by the reverse-proxy server. | |
390 | |
391 After setting up your proxy solution (see `Apache virtual host reverse proxy example`_, | |
392 `Apache as subdirectory`_ or `Nginx virtual host example`_), you'd need to | |
393 configure the authentication and add the username in a request header named | |
394 ``X-Forwarded-User``. | |
395 | |
396 For example, the following config section for Apache sets a subdirectory in a | |
397 reverse-proxy setup with basic auth:: | |
398 | |
399 <Location /<someprefix> > | |
400 ProxyPass http://127.0.0.1:5000/<someprefix> | |
401 ProxyPassReverse http://127.0.0.1:5000/<someprefix> | |
402 SetEnvIf X-Url-Scheme https HTTPS=1 | |
403 | |
404 AuthType Basic | |
405 AuthName "RhodeCode authentication" | |
406 AuthUserFile /home/web/rhodecode/.htpasswd | |
407 require valid-user | |
408 | |
409 RequestHeader unset X-Forwarded-User | |
410 | |
411 RewriteEngine On | |
412 RewriteCond %{LA-U:REMOTE_USER} (.+) | |
413 RewriteRule .* - [E=RU:%1] | |
414 RequestHeader set X-Forwarded-User %{RU}e | |
415 </Location> | |
416 | |
417 In order for RhodeCode to start using the forwarded username, you should set | |
418 the following in the [app:main] section of your .ini file:: | |
419 | |
420 proxypass_auth_enabled = true | |
421 | |
422 .. note:: | |
423 If you enable proxy pass-through authentication, make sure your server is | |
424 only accessible through the proxy. Otherwise, any client would be able to | |
425 forge the authentication header and could effectively become authenticated | |
426 using any account of their liking. | |
347 | 427 |
348 | 428 |
349 | 429 |
350 Hook management | 430 Hook management |
351 --------------- | 431 --------------- |