Currently, the API does not support LDAP authentication when trying to make a POST request to the /sessions endpoint for example. As a result, because our gitlab installation is solely using LDAP, we cannot authenticate users in automated scripts.
The RESTful API should support LDAP authentication as well as the standard authentication when requests are made.
Micah
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
The API expects you to use the private token every user is assigned. (see on account info on demo server). For more info how to use it in the API see the API Help page.
By Administrator on 2013-01-14T21:10:40 (imported from GitLab)
I understand that the API in general uses the private_token value for each and every request. The ONE exception to this is this signature: "POST /session" which is meant to "authenticate" a user. Currently, the only authentication that is performed is with the call to "User.find_for_database_authentication". I would propose that instead of returning unauthorized solely after checking this call, we would also check to see if a) if ldap is enabled and b) if it is enabled, does the value for email exist in ldap as well as the password match in ldap.
The problem we are facing is that all of our users are configured as ldap users but when we try to allow them to authenticate via command-line scripts that we are using, they cannot because the api does not allow us to authenticate them in using their LDAP credentials. Our goal is for them to authenticate in so that our script can get their private_token value and make all subsequent requests using that token rather than some hard-coded value.
It may not be a bad idea either to include an optional parameter in the POST request that would indicate whether or not we should fall back to LDAP authentication (ldap_authenticate for example).
I am opening this issue here but I would be happy to make this feature enhancement and open a pull request for it.
Thank you,
Micah
By Administrator on 2013-01-15T04:37:36 (imported from GitLab)
Glad to see this was re-opened :) I'm hoping to get this working in our environment sooner than you will probably get 4.2 released. If we get there before you do, I'll open a pull request with the changes for you to get.
Thank you!
Micah
By Administrator on 2013-01-15T16:48:52 (imported from GitLab)
Please keep in mind that there might and will be other authentication schemes like LDAP in future. There is shibboleth fork and my pam fork. So when implementing things for ldap, could you pick up more generalized names for functions and variables?
By Administrator on 2013-02-02T15:48:33 (imported from GitLab)