Pulling this back onto the original thread. On Thu, Sep 9, 2010 at 1:23 PM, Brian Smith <br...@linuxfood.net> wrote: > On Thu, Sep 9, 2010 at 12:54 PM, Michael Schlenker > <schl...@uni-oldenburg.de> wrote: >> >> Am 09.09.2010 um 16:03 schrieb Richard Hipp: >> >>> >>> >>> On Thu, Sep 9, 2010 at 9:48 AM, James Peverill <arsenix.accou...@gmail.com> >>> wrote: >>> On 09/09/2010 09:26 AM, fossil-users-requ...@lists.fossil-scm.org wrote: >>> > Fossil never generates a 401 error. The "401 Authorization Required" >>> > message is coming from someplace else. Are you sure your webserver is >>> > configured correctly? >>> > >>> >>> Well... it is configured correctly for the browser, but maybe not for >>> the fossil client. The 401 is probably coming from the mod_ldap plugin. >>> >>> The way our mod-ldap stuff works it prompts the user for a login/pass >>> upon connection, authenticates the user, and then allows the user to >>> access the page and sets the REMOTE_USER environment variable for >>> fossil. This all works great through a browser. When using the fossil >>> client to do a clone though it doesn't get past the authentication. >>> >>> I see. Right - "fossil sync" does not have any idea how to do LDAP >>> authentication. >>> >>> I guess LDAP credentials are stored in the browser somehow. But "fossil >>> sync" bypasses the browser completely. So I guess it will somehow need to >>> understand some kind of LDAP authentication protocol and reauthenticate? >>> Can anybody explain to me how that works, or perhaps give a link to a >>> reasonable tutorial? Does anybody have an LDAP implementation that I can >>> test against? >> >> There would be two ways to implement this. >> >> 1. Trust a front end webserver like apache and what it sets in the >> REMOTE_USER cgi variable (you could use Kerberos/SPNEGO Auth that way too, >> same principle if you used mod_kerb). >> >> 2. If you directly handle the HTTP request it is just http Basic Auth, but >> you check the credentials not against the sqlite database in fossil but try >> a BIND Operation on an >> ldap server. >> >> Doing some ldap auth is pretty simple if you can call an external program to >> check username/password. If you have openldap client package installed its >> basically just some call >> to ldapsearch and checking if the BIND succeeded. The main complexity is how >> to map the usernames entered to LDAP Distinguished Names. >> > > If you're going to go to the trouble of calling an external program, > you might as well make a generic "external authentication" interface > for fossil. Businesses certainly like that sort of thing. Then you > could do LDAP, text file, manual approval, or whatever you want. > > Mapping usernames to LDAP DNs isn't a huge problem, in the general > case, you probably don't need to support users from different common > names, or organization units (iirc) authenticating to the same repo. > > New settings 'Use External Authentication' (true/false), > 'Authentication Command' (string), and 'Authentication Timeout' (int), > should be sufficient. 'Authentication Command' would take the path to > a program to execute plus arguments, which should return 0 on success > and anything else on failure. Fossil could do parameter substitution > like so: > > Authentication Command: '/usr/local/bin/my_authenticator USERNAME REMOTE_IP' > > Where USERNAME and REMOTE_IP are replaced with their obvious values. > And the password (if one was supplied), could be passed in on STDIN. > > Care would need to be taken so that the external authentication > settings were Not propagated to cloned repositories. > > Off the top of my head, the following parameters might be interesting > for external authenticators: > - USERNAME > - REMOTE_IP > - X509_CERTIFICATE (to handle SSL client certificate authentication > externally, for some reason) > > If there's interest in such an interface, I might be inclined to see > if I couldn't hack it together over the weekend. > > The other alternative is that the storage for usernames is pretty > straightforward for fossil. > Having a 'usersync' tool available for separate download with > out-of-the-box support for pulling in LDAP users > might be an idea better in keeping with fossil philosophy. > > -B >
Pulling this back onto thread after a subject change. On Fri, Sep 10, 2010 at 6:33 AM, James Peverill <arsenix.accou...@gmail.com> wrote: > On 09/10/2010 08:00 AM, fossil-users-requ...@lists.fossil-scm.org wrote: >> The other alternative is that the storage for usernames is pretty >> straightforward for fossil. >> Having a 'usersync' tool available for separate download with >> out-of-the-box support for pulling in LDAP users >> might be an idea better in keeping with fossil philosophy. >> > I have the http basic authentication working now. It just prompts the > user for u/p if the server responds with a 401. That works fine. > > The only issue with this setup is that once you have cloned the > repository there is no synchronization of username/passwords with our > ldap, since when fossil lives on our webserver we aren't really even > using the fossil password database. Once the repository is local, > fossil uses the internal password database. If the ldap passwords were > somehow externally synced as you propose... then after a clone the local > passwords would match the ldap ones. This would be cool. > Not sure that really makes sense. That would be trying to make fossil a centralized vcs. And, while fossil has some qualities of a centralized vcs, it's important to remember that it isn't. Not to mention that it's not good practice to just "give away" a copy of your password database, hashed or not. The role that a usersync utility would fill is to make the master repository/ies for the project have some form of unified authentication. Once someone clones, that's their personal copy, and the passwords don't matter much, save for syncing, and those would generally be set on clone anyway. I might experiment with something like this over the weekend. -B _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
