James Moger
2013-07-13 cc04772888848c754880ed181fcf13c0a658e7ed
src/site/setup_authentication.mkd
@@ -8,6 +8,7 @@
* Windows authentication
* Redmine auhentication
* Salesforce.com authentication
* Servlet container authentication
### LDAP Authentication
*SINCE 1.0.0*
@@ -77,14 +78,36 @@
### 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.userService = com.gitblit.WindowsUserService
    realm.windows.defaultDomain =
### 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.userService = com.gitblit.RedmineUserService
    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.userService = com.gitblit.SalesforceUserService
    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.GitblitUserService](https://github.com/gitblit/gitblit/blob/master/src/com/gitblit/GitblitUserService.java) and override the *setup()* and *authenticate()* methods.
Please subclass [com.gitblit.GitblitUserService](https://github.com/gitblit/gitblit/blob/master/src/main/java/com/gitblit/GitblitUserService.java) and override the *setup()* and *authenticate()* methods.
Make sure to set the *serviceImpl* field in your *setup()* method.
You may use your subclass by specifying its fully qualified classname in the *realm.userService* setting.
@@ -92,10 +115,11 @@
Your subclass must be on Gitblit's classpath and must have a public default constructor.  
### Custom Everything
Instead of maintaining a `users.conf` or `users.properties` file, you may want to integrate Gitblit into an existing environment.
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/com/gitblit/IUserService.java).
Please see the following interface definition [com.gitblit.IUserService](https://github.com/gitblit/gitblit/blob/master/src/main/java/com/gitblit/IUserService.java).