AS1024/Kanboard-Prod
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update documentation

Browse Source
This commit is contained in:
Frédéric Guillot
2014-10-26 19:58:47 -04:00
parent c5f59f8c8f
commit d97e1bd4cf
23 changed files with 172 additions and 68 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
docs/reverse-proxy-authentication.markdown
View File

@@ -1,28 +1,35 @@
Reverse Proxy Authentication
============================
This authentication method is often used for [SSO](http://en.wikipedia.org/wiki/Single_sign-on) (Single Sign-On) especially for large organizations.
The authentication is done by another system, Kanboard doesn't know your password and suppose you are already authenticated.
Requirements
------------
- A well configured reverse proxy (or Apache auth on the same server), that performs authentication and sends the authenticated username to Kanboard using a HTTP header. It is useful if you have yet some SSO (Single-Sign-On) in your organization, so you should know what your are doing.
- A well configured reverse proxy
or
- Apache auth on the same server
How does this work?
-------------------
- Your reverse proxy authenticates the user and adds a HTTP header containing its login to the request. The default header name or how to specify it should be in the reverse proxy documentation, however:
- If it is the same web server that runs Kanboard, the CGI spec specifies this header to be REMOTE_USER (see [RFC 3875](http://www.ietf.org/rfc/rfc3875) §4.1.11). For example, Apache adds REMOTE_USER by default if `Require valid-user` is set. Note this header is only set for CGI (like PHP), and not if Apache is a reverse proxy to another Apache running Kanboard. It works the same with IIS and nginx according to their documentation.
- If it is a real reverse proxy, the HTTP ICAP extension draft spec proposes the header to be X-Authenticated-User (see [IETF draft spec §3.4](http://tools.ietf.org/html/draft-stecher-icap-subid-00#section-3.4)). This de-facto standart has been adopted by a number of tools.
- Kanboard retrieves the value of the specified HTTP header, and:
- If the user does not exist yet, creates it (it also checks if it is the default admin).
- **Authenticates the given user without any prompt, assuming it's valid (so it does NOT prompt the login page)**.
1. Your reverse proxy authenticates the user and send the username through a HTTP header.
2. Kanboard retreive the username from the request
- The user is created automatically if necessary
- Open a new Kanboard session without any prompt assuming it's valid
Installation instructions
-------------------------
### Setting up your reverse proxy
This is not in the scope of this documentation. You should check that the user login is sent by the reverse proxy using a HTTP header, and find which one.
This is not in the scope of this documentation.
You should check the user login is sent by the reverse proxy using a HTTP header, and find which one.
### Setting up Kanboard
@@ -46,5 +53,12 @@ define('REVERSE_PROXY_DEFAULT_ADMIN', 'myadmin');
// In case the username is not an email address, it
// will be updated automatically as USER@mydomain.com
define('REVERSE_PROXY_DEFAULT_DOMAIN', 'mydomain.com');
```
Notes:
- If the proxy is the same web server that runs Kanboard, according the [CGI protocol](http://www.ietf.org/rfc/rfc3875) the header name will be `REMOTE_USER`. By example, Apache add `REMOTE_USER` by default if `Require valid-user` is set.
- If Apache is a reverse proxy to another Apache running Kanboard, the header `REMOTE_USER` is not set (same behaviour with IIS and Nginx).
- If you have a real reverse proxy, the [HTTP ICAP draft](http://tools.ietf.org/html/draft-stecher-icap-subid-00#section-3.4) proposes the header to be `X-Authenticated-User`. This de-facto standart has been adopted by a number of tools.