src/site/setup_authentication.mkd - gitblit - Git at Google

 ## Built-in Authentication

 By default, Gitblit stores and authenticates all users against `users.conf`.  However, you may wish to integrate Gitblit into an existing user account infrastructure.

 Gitblit supports additional authentication mechanisms aside from it's internal one.

 * LDAP authentication
 * Windows authentication
 * PAM authentication
 * Htpasswd authentication
 * HTTP header authentication
 * Redmine auhentication
 * Salesforce.com authentication
 * Servlet container authentication

 ### LDAP Authentication
 *SINCE 1.0.0*

 LDAP can be used to authenticate Users and optionally control Team memberships.  When properly configured, Gitblit will delegate authentication to your LDAP server and will cache some user information in the usual users.conf file.

 When using the LDAP User Service, new user accounts can not be manually created from Gitblit.  Gitblit user accounts are automatically created for new users on their first succesful authentication through Gitblit against the LDAP server.  It is also important to note that the LDAP User Service does not retrieve or store user passwords nor does it implement any LDAP-write functionality.

 To use the *LdapUserService* set *realm.authenticationProviders=ldap* in your `gitblit.properties` file and then configure the *realm.ldap* settings appropriately for your LDAP environment.

 #### Example LDAP Layout
 ![block diagram](ldapSample.png "LDAP Sample")

 Please see [ldapUserServiceSampleData.ldif](https://github.com/gitblit/gitblit/blob/master/tests/com/gitblit/tests/resources/ldapUserServiceSampleData.ldif) to see the data in LDAP that reflects the above picture.

 #### Gitblit Settings for Example LDAP Layout
 The following are the settings required to configure Gitblit to authenticate against the example LDAP server with LDAP-controlled team memberships.

 <table class="table">
 <thead>
 <tr><th>parameter</th><th>value</th><th>description</th></tr>
 </thead>
 <tbody>
 <tr>
   <th>realm.ldap.server</th><td>ldap://localhost:389</td>
   <td>Tells Gitblit to connect to the LDAP server on localhost port 389.  The URL Must be of form ldap(s)://&lt;server&gt;:&lt;port&gt; with port being optional (389 for ldap, 636 for ldaps).</td>
 </tr>
 <tr>
   <th>realm.ldap.username</th><td>cn=Directory Manager</td>
   <td>The credentials that will log into the LDAP server</td>
 </tr>
 <tr>
   <th>realm.ldap.password</th><td>password</td>
   <td>The credentials that will log into the LDAP server</td>
 </tr>
 <tr>
   <th>realm.ldap.maintainTeams</th><td>true</td>
   <td>Are team memberships maintained in LDAP (<em>true</em>) or manually in Gitblit (<em>false</em>).</td>
 </tr>
 <tr>
   <th>realm.ldap.accountBase</th><td>OU=Users,OU=UserControl,OU=MyOrganization,DC=MyDomain</td>
   <td>What is the root node for all users in this LDAP system.  Subtree searches will start from this node.</td>
 </tr>
 <tr>
   <th>realm.ldap.accountPattern</th><td>(&(objectClass=person)(sAMAccountName=${username}))</td><td>The LDAP search filter that will match a particular user in LDAP.  ${username} will be replaced with whatever the user enters as their username in the Gitblit login panel.</td>
 </tr>
 <tr>
   <th>realm.ldap.groupBase</th><td>OU=Groups,OU=UserControl,OU=MyOrganization,DC=MyDomain</td>
   <td>What is the root node for all teams in this LDAP system.  Subtree searches will start from this node.</td>
 </tr>
 <tr>
   <th>realm.ldap.groupMemberPattern</th><td>(&(objectClass=group)(member=${dn}))</td><td>The LDAP search filter that will match all teams for the authenticating user.  ${username} will be replaced with whatever the user enters as their username in the Gitblit login panel.  Anything else in ${} will be replaced by Attributes from the User node.</td>
 </tr>
 <tr>
   <th>realm.ldap.admins</th><td>@Git_Admins</td><td>A space-delimited list of usernames and/or teams that indicate admin status in Gitblit.  Teams are referenced with a leading <em>@</em> character.</td>
 </tr>
 </tbody>
 </table>

 #### LDAP In-Memory Server

 You can start Gitblit GO with an in-memory LDAP server by specifying the *--ldapLdifFile* command-line argument.  The LDAP server will listen on localhost of the port specified in *realm.ldap.url* of `gitblit.properties`.  Additionally, a root user record is automatically created for *realm.ldap.username* and *realm.ldap.password*.  Please note that the ldaps:// protocol is not supported for the in-memory server.

 ### Windows Authentication

 Windows authentication is based on the use of Waffle and JNA.  It is known to work properly for authenticating against the local Windows machine, but it is unclear if it works properly with a domain controller and Active Directory.  To use this service, your Gitblit server must be installed on a Windows machine.

     realm.authenticationProviders = windows
     realm.windows.defaultDomain =

 ### PAM Authentication

 PAM authentication is based on the use of libpam4j and JNA.  To use this service, your Gitblit server must be installed on a Linux/Unix/MacOSX machine.

     realm.authenticationProviders = pam
     realm.pam.serviceName = gitblit

 Then define a gitblit authentication policy in `/etc/pam.d/gitblit`

     # PAM configuration for the gitblit service
     # Standard Un*x authentication.
     @include common-auth

 ### Htpasswd Authentication

 Htpasswd authentication allows you to maintain your user credentials in an Apache htpasswd file thay may be shared with other htpasswd-capable servers.

     realm.authenticationProviders = htpasswd
     realm.htpasswd.userFile = /path/to/htpasswd

 ### HTTP Header Authentication

 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.

 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.

     realm.httpheader.userheader = REMOTE_USER
     realm.httpheader.teamheader = X-GitblitExample-GroupNames
     realm.httpheader.teamseparator = ,
     realm.httpheader.autoCreateAccounts = false

 ### Redmine Authentication

 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.

     realm.authenticationProviders = redmine
     realm.redmine.url = http://example.com/redmine

 ### Salesforce.com Authentication

 You may authenticate your users against Salesforce.com.  You can require that user's belong to a particular organization by specifying a non-zero organization id.

     realm.authenticationProviders = salesforce
     realm.salesforce.orgId = 0

 ### Container Authentication

 If you are using the WAR variant and deploying into your own servlet container which has a pre-defined authentication mechanism protecting the Gitblit webapp, then you may instruct Gitblit to automatically create Gitblit accounts for container-authenticated user principals.

     realm.container.autoCreateAccounts = true

 ## Custom Authentication

 This is the simplest choice where you implement custom authentication and delegate all other standard user and team operations to one of Gitblit's user service implementations.  This choice insulates your customization from changes in User and Team model classes and additional API that may be added to IUserService.

 Please subclass [com.gitblit.auth.AuthenticationProvider.UsernamePasswordAuthenticationProvider](https://github.com/gitblit/gitblit/blob/master/src/main/java/com/gitblit/auth/AuthenticationProvider.java).

 You may use your subclass by specifying its fully qualified classname in the *realm.authenticationProviders* setting.

 Your subclass must be on Gitblit's classpath and must have a public default constructor.

 ### Custom Everything

 Instead of maintaining a `users.conf` file, you may want to integrate Gitblit into an existing environment.

 You may use your own custom *com.gitblit.IUserService* implementation by specifying its fully qualified classname in the *realm.userService* setting.

 Your user service class must be on Gitblit's classpath and must have a public default constructor.
 Please see the following interface definition [com.gitblit.IUserService](https://github.com/gitblit/gitblit/blob/master/src/main/java/com/gitblit/IUserService.java).
	## Built-in Authentication

	By default, Gitblit stores and authenticates all users against `users.conf`. However, you may wish to integrate Gitblit into an existing user account infrastructure.

	Gitblit supports additional authentication mechanisms aside from it's internal one.

	* LDAP authentication
	* Windows authentication
	* PAM authentication
	* Htpasswd authentication
	* HTTP header authentication
	* Redmine auhentication
	* Salesforce.com authentication
	* Servlet container authentication

	### LDAP Authentication
	SINCE 1.0.0

	LDAP can be used to authenticate Users and optionally control Team memberships. When properly configured, Gitblit will delegate authentication to your LDAP server and will cache some user information in the usual users.conf file.

	When using the LDAP User Service, new user accounts can not be manually created from Gitblit. Gitblit user accounts are automatically created for new users on their first succesful authentication through Gitblit against the LDAP server. It is also important to note that the LDAP User Service does not retrieve or store user passwords nor does it implement any LDAP-write functionality.

	To use the LdapUserService set realm.authenticationProviders=ldap in your `gitblit.properties` file and then configure the realm.ldap settings appropriately for your LDAP environment.

	#### Example LDAP Layout
	![block diagram](ldapSample.png "LDAP Sample")

	Please see [ldapUserServiceSampleData.ldif](https://github.com/gitblit/gitblit/blob/master/tests/com/gitblit/tests/resources/ldapUserServiceSampleData.ldif) to see the data in LDAP that reflects the above picture.

	#### Gitblit Settings for Example LDAP Layout
	The following are the settings required to configure Gitblit to authenticate against the example LDAP server with LDAP-controlled team memberships.

	<table class="table">
	<thead>
	<tr><th>parameter</th><th>value</th><th>description</th></tr>
	</thead>
	<tbody>
	<tr>
	<th>realm.ldap.server</th><td>ldap://localhost:389</td>
	<td>Tells Gitblit to connect to the LDAP server on localhost port 389. The URL Must be of form ldap(s)://<server>:<port> with port being optional (389 for ldap, 636 for ldaps).</td>
	</tr>
	<tr>
	<th>realm.ldap.username</th><td>cn=Directory Manager</td>
	<td>The credentials that will log into the LDAP server</td>
	</tr>
	<tr>
	<th>realm.ldap.password</th><td>password</td>
	<td>The credentials that will log into the LDAP server</td>
	</tr>
	<tr>
	<th>realm.ldap.maintainTeams</th><td>true</td>
	<td>Are team memberships maintained in LDAP (<em>true</em>) or manually in Gitblit (<em>false</em>).</td>
	</tr>
	<tr>
	<th>realm.ldap.accountBase</th><td>OU=Users,OU=UserControl,OU=MyOrganization,DC=MyDomain</td>
	<td>What is the root node for all users in this LDAP system. Subtree searches will start from this node.</td>
	</tr>
	<tr>
	<th>realm.ldap.accountPattern</th><td>(&(objectClass=person)(sAMAccountName=${username}))</td><td>The LDAP search filter that will match a particular user in LDAP. ${username} will be replaced with whatever the user enters as their username in the Gitblit login panel.</td>
	</tr>
	<tr>
	<th>realm.ldap.groupBase</th><td>OU=Groups,OU=UserControl,OU=MyOrganization,DC=MyDomain</td>
	<td>What is the root node for all teams in this LDAP system. Subtree searches will start from this node.</td>
	</tr>
	<tr>
	<th>realm.ldap.groupMemberPattern</th><td>(&(objectClass=group)(member=${dn}))</td><td>The LDAP search filter that will match all teams for the authenticating user. ${username} will be replaced with whatever the user enters as their username in the Gitblit login panel. Anything else in ${} will be replaced by Attributes from the User node.</td>
	</tr>
	<tr>
	<th>realm.ldap.admins</th><td>@Git_Admins</td><td>A space-delimited list of usernames and/or teams that indicate admin status in Gitblit. Teams are referenced with a leading <em>@</em> character.</td>
	</tr>
	</tbody>
	</table>

	#### LDAP In-Memory Server

	You can start Gitblit GO with an in-memory LDAP server by specifying the --ldapLdifFile command-line argument. The LDAP server will listen on localhost of the port specified in realm.ldap.url of `gitblit.properties`. Additionally, a root user record is automatically created for realm.ldap.username and realm.ldap.password. Please note that the ldaps:// protocol is not supported for the in-memory server.

	### Windows Authentication

	Windows authentication is based on the use of Waffle and JNA. It is known to work properly for authenticating against the local Windows machine, but it is unclear if it works properly with a domain controller and Active Directory. To use this service, your Gitblit server must be installed on a Windows machine.

	realm.authenticationProviders = windows
	realm.windows.defaultDomain =

	### PAM Authentication

	PAM authentication is based on the use of libpam4j and JNA. To use this service, your Gitblit server must be installed on a Linux/Unix/MacOSX machine.

	realm.authenticationProviders = pam
	realm.pam.serviceName = gitblit

	Then define a gitblit authentication policy in `/etc/pam.d/gitblit`

	# PAM configuration for the gitblit service
	# Standard Un*x authentication.
	@include common-auth

	### Htpasswd Authentication

	Htpasswd authentication allows you to maintain your user credentials in an Apache htpasswd file thay may be shared with other htpasswd-capable servers.

	realm.authenticationProviders = htpasswd
	realm.htpasswd.userFile = /path/to/htpasswd

	### HTTP Header Authentication

	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.

	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.

	realm.httpheader.userheader = REMOTE_USER
	realm.httpheader.teamheader = X-GitblitExample-GroupNames
	realm.httpheader.teamseparator = ,
	realm.httpheader.autoCreateAccounts = false

	### Redmine Authentication

	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.

	realm.authenticationProviders = redmine
	realm.redmine.url = http://example.com/redmine

	### Salesforce.com Authentication

	You may authenticate your users against Salesforce.com. You can require that user's belong to a particular organization by specifying a non-zero organization id.

	realm.authenticationProviders = salesforce
	realm.salesforce.orgId = 0

	### Container Authentication

	If you are using the WAR variant and deploying into your own servlet container which has a pre-defined authentication mechanism protecting the Gitblit webapp, then you may instruct Gitblit to automatically create Gitblit accounts for container-authenticated user principals.

	realm.container.autoCreateAccounts = true

	## Custom Authentication

	This is the simplest choice where you implement custom authentication and delegate all other standard user and team operations to one of Gitblit's user service implementations. This choice insulates your customization from changes in User and Team model classes and additional API that may be added to IUserService.

	Please subclass [com.gitblit.auth.AuthenticationProvider.UsernamePasswordAuthenticationProvider](https://github.com/gitblit/gitblit/blob/master/src/main/java/com/gitblit/auth/AuthenticationProvider.java).

	You may use your subclass by specifying its fully qualified classname in the realm.authenticationProviders setting.

	Your subclass must be on Gitblit's classpath and must have a public default constructor.

	### Custom Everything

	Instead of maintaining a `users.conf` file, you may want to integrate Gitblit into an existing environment.

	You may use your own custom com.gitblit.IUserService implementation by specifying its fully qualified classname in the realm.userService setting.

	Your user service class must be on Gitblit's classpath and must have a public default constructor.
	Please see the following interface definition [com.gitblit.IUserService](https://github.com/gitblit/gitblit/blob/master/src/main/java/com/gitblit/IUserService.java).