Re: git smart http + apache mod_auth_openidc

[Ralph Ewig <ralph.phd@protonmail.com>]

Understood (and agree).

We do use git for source code (where we use SSH 
and key authentication for CI/CD), but also for 
configuration control of other files like 
financial reports, engineering drawings, etc. 
where access is via HTTPS.  In that 2nd group the 
challenge is to make it as "not coding like" as 
possible so the non-developer crowd isn't scared off.

Since we use trac for project management company 
wide (all verticals), my latest idea is to 
intercept the git http request on the server side 
to authenticate against the trac session info 
stored in the db (using a custom php script),  and 
then pass it on to git-http-backend or throw an 
error prompting the user to sign into trac first. 
Most users are signed into trac 24/7 anyway since 
its central to our workflow.

in the end paying the extra fee for MS Domain 
Services to get SSO via LDAP or Kerberos might be 
the right answer though - just trying to be 
scrappy if I can since it's an early stage 
startup. Nonetheless really appreciate the 
exchange of ideas!

Ralph


On 10/17/2019 3:55 PM, brian m. carlson wrote:
> On 2019-10-17 at 14:33:38, Ralph Ewig wrote:
>> Quick follow up question: can the git client pass
>> a token read from a cookie with a request? That
>> would enable users to sign-in via a browser, store
>> the cookie, and then use that as the access token
>> to authenticate a git request.
> Git has an option, http.cookieFile, that can read a cookie from a file,
> yes.  That does, of course, require that you're able to put the cookie
> in a file from a web browser.  I'm not aware of any web browsers that
> easily provide an option to dump cookies into a file.
>
> Also, just as a note, this approach definitely won't work for automated
> systems you have, such as CI systems.  That's why I suggested Kerberos:
> because you can have services that have principals and you can use those
> credentials in your CI systems to access code and run jobs.
>
> Clearly you know your infrastructure and users better than I do, but I
> don't recommend having a web-based sign-on as your only form of
> authentication for a Git server.  It's going to cause a lot of pain and
> inconvenience on all sides.