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.
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 file (.conf or .properties).
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.userService=com.gitblit.LdapUserService in your gitblit.properties
file or your web.xml
file and then configure the realm.ldap settings appropriately for your LDAP environment.
Please see ldapUserServiceSampleData.ldif to see the data in LDAP that reflects the above picture.
The following are the settings required to configure Gitblit to authenticate against the example LDAP server with LDAP-controlled team memberships.
parameter | value | description |
---|---|---|
realm.ldap.server | ldap://localhost:389 | 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). |
realm.ldap.username | cn=Directory Manager | The credentials that will log into the LDAP server |
realm.ldap.password | password | The credentials that will log into the LDAP server |
realm.ldap.backingUserService | users.conf | Where to store all information that is used by Gitblit. All information will be synced here upon user login. |
realm.ldap.maintainTeams | true | Are team memberships maintained in LDAP (true) or manually in Gitblit (false). |
realm.ldap.accountBase | OU=Users,OU=UserControl,OU=MyOrganization,DC=MyDomain | What is the root node for all users in this LDAP system. Subtree searches will start from this node. |
realm.ldap.accountPattern | (&(objectClass=person)(sAMAccountName=${username})) | 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. |
realm.ldap.groupBase | OU=Groups,OU=UserControl,OU=MyOrganization,DC=MyDomain | What is the root node for all teams in this LDAP system. Subtree searches will start from this node. |
realm.ldap.groupMemberPattern | (&(objectClass=group)(member=${dn})) | 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. |
realm.ldap.admins | @Git_Admins | A space-delimited list of usernames and/or teams that indicate admin status in Gitblit. Teams are referenced with a leading @ character. |
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.
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 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.
Your subclass must be on Gitblit's classpath and must have a public default constructor.
Instead of maintaining a users.conf
or users.properties
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.