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
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to