comparison docs/setup.rst @ 4501:a68fc4abeda3

issue #7 remove obsolete configuration
author domruf <dominikruf@gmail.com>
date Wed, 27 Aug 2014 21:50:25 +0200
parents 8e26c46e9abe
children a9a1560dad79
comparison
equal deleted inserted replaced
4500:e69d34136be5 4501:a68fc4abeda3
366 366
367 367
368 Authentication by container or reverse-proxy 368 Authentication by container or reverse-proxy
369 -------------------------------------------- 369 --------------------------------------------
370 370
371 Starting with version 1.3, Kallithea supports delegating the authentication 371 Kallithea supports delegating the authentication
372 of users to its WSGI container, or to a reverse-proxy server through which all 372 of users to its WSGI container, or to a reverse-proxy server through which all
373 clients access the application. 373 clients access the application.
374 374
375 When these authentication methods are enabled in Kallithea, it uses the 375 When these authentication methods are enabled in Kallithea, it uses the
376 username that the container/proxy (Apache/Nginx/etc) authenticated and doesn't 376 username that the container/proxy (Apache/Nginx/etc) authenticated and doesn't
381 a matching user account is created in Kallithea with default permissions. An 381 a matching user account is created in Kallithea with default permissions. An
382 administrator can then modify it using Kallithea's admin interface. 382 administrator can then modify it using Kallithea's admin interface.
383 It's also possible for an administrator to create accounts and configure their 383 It's also possible for an administrator to create accounts and configure their
384 permissions before the user logs in for the first time. 384 permissions before the user logs in for the first time.
385 385
386
386 Container-based authentication 387 Container-based authentication
387 '''''''''''''''''''''''''''''' 388 ''''''''''''''''''''''''''''''
388 389
389 In a container-based authentication setup, Kallithea reads the user name from 390 In a container-based authentication setup, Kallithea reads the user name from
390 the ``REMOTE_USER`` server variable provided by the WSGI container. 391 the ``REMOTE_USER`` server variable provided by the WSGI container.
391 392
392 After setting up your container (see `Apache's WSGI config`_), you'd need 393 After setting up your container (see `Apache's WSGI config`_), you'd need
393 to configure it to require authentication on the location configured for 394 to configure it to require authentication on the location configured for
394 Kallithea. 395 Kallithea.
395
396 In order for Kallithea to start using the provided username, you should set the
397 following in the [app:main] section of your .ini file::
398
399 container_auth_enabled = true
400 396
401 397
402 Proxy pass-through authentication 398 Proxy pass-through authentication
403 ''''''''''''''''''''''''''''''''' 399 '''''''''''''''''''''''''''''''''
404 400
430 RewriteCond %{LA-U:REMOTE_USER} (.+) 426 RewriteCond %{LA-U:REMOTE_USER} (.+)
431 RewriteRule .* - [E=RU:%1] 427 RewriteRule .* - [E=RU:%1]
432 RequestHeader set X-Forwarded-User %{RU}e 428 RequestHeader set X-Forwarded-User %{RU}e
433 </Location> 429 </Location>
434 430
435 In order for Kallithea to start using the forwarded username, you should set
436 the following in the [app:main] section of your .ini file::
437
438 proxypass_auth_enabled = true
439 431
440 .. note:: 432 .. note::
441 If you enable proxy pass-through authentication, make sure your server is 433 If you enable proxy pass-through authentication, make sure your server is
442 only accessible through the proxy. Otherwise, any client would be able to 434 only accessible through the proxy. Otherwise, any client would be able to
443 forge the authentication header and could effectively become authenticated 435 forge the authentication header and could effectively become authenticated