* Windows authentication\r
* PAM authentication\r
* Htpasswd authentication\r
+* HTTP header authentication\r
* Redmine auhentication\r
* Salesforce.com authentication\r
* Servlet container authentication\r
realm.authenticationProviders = htpasswd\r
realm.htpasswd.userFile = /path/to/htpasswd\r
\r
+### HTTP Header Authentication\r
+\r
+HTTP header authentication allows you to use existing authentication performed by a trusted frontend, such as a reverse proxy. Ensure that when used, gitblit is ONLY availabe via the trusted frontend, otherwise it is vulnerable to a user adding the header explicitly.\r
+\r
+By default, no user or team header is defined, which results in all authentication failing this mechanism. The user header can also be defined while leaving the team header undefined, which causes users to be authenticated from the headers, but team memberships to be maintained locally.\r
+\r
+ realm.httpheader.userheader = REMOTE_USER\r
+ realm.httpheader.teamheader = X-GitblitExample-GroupNames\r
+ realm.httpheader.teamseparator = ,\r
+ realm.httpheader.autoCreateAccounts = false\r
+\r
### Redmine Authentication\r
\r
You may authenticate your users against a Redmine installation as long as your Redmine install has properly enabled [API authentication](http://www.redmine.org/projects/redmine/wiki/Rest_Api#Authentication). This user service only supports user authentication; it does not support team creation based on Redmine groups. Redmine administrators will also be Gitblit administrators.\r