{"thread":{"id":"52039","subject":"git smart http + apache mod_auth_openidc","startedAt":"2019-10-15T15:59:11Z","lastAt":"2019-10-18T01:18:18Z","messageCount":8,"participants":["Ralph Ewig","brian m. carlson","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"384104","messageId":"4eb22ffc-77a1-4cd7-2277-bdc57d31186b@protonmail.com","threadId":"52039","inReplyTo":null,"subject":"git smart http + apache mod_auth_openidc","fromName":"Ralph Ewig","fromEmail":"ralph.phd@protonmail.com","sentAt":"2019-10-15T15:59:03Z","receivedAt":"2019-10-15T15:59:11Z","isPatch":false,"sender":{"key":"ralph.phd@protonmail.com","avatar":null},"body":"Hi Everyone, hoping you might have a solution for \nthis problem:\n\nCONTEXT\n\n  * I'm serving git repos using \"smart https\" via \napache and basic authentication; everything works \nfine.\n  * We're moving to SSO via Azure AD and apache \nmod_auth_openidc; this works fine for gitweb (on \nthe same server as git).\n\nPROBLEM\n\nWhen trying to clone a repo with the OIDC setup, \ngit breaks on the redirect for user authentication \nwith the following error message (replaced server \nids etc with xxx):\n\n     C:\\Users\\void>git clone --progress -v \n\"https://git.xxx.xxx/WebApps.git\"\n     Cloning into 'WebApps'...\n     fatal: unable to update url base from \nredirection:\n       asked for: \nhttps://git.xxx.xxx/WebApps.git/info/refs?service=git-upload-pack\n        redirect: \nhttps://login.microsoftonline.com/xxx/oauth2/authorize?response_type=code&scope=openid&client_id=xxx&state=xxx&redirect_uri=https%3A%2F%2Fgit.xxx.xxx%2Fredirect&nonce=xxx\n\n\nCan the git client just not handle a web based \nredirect for login, or is this a configuration \nissue? Any ideas would be greatly appreciated. Thanks!\n\nRalph\n\n\n"},{"id":"384217","messageId":"20191016233319.3rhmekasi5csytyl@camp.crustytoothpaste.net","threadId":"52039","inReplyTo":"4eb22ffc-77a1-4cd7-2277-bdc57d31186b@protonmail.com","subject":"Re: git smart http + apache mod_auth_openidc","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2019-10-16T23:33:19Z","receivedAt":"2019-10-16T23:33:30Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2019-10-15 at 15:59:03, Ralph Ewig wrote:\n> Hi Everyone, hoping you might have a solution for \n> this problem:\n> \n> CONTEXT\n> \n>   * I'm serving git repos using \"smart https\" via \n> apache and basic authentication; everything works \n> fine.\n>   * We're moving to SSO via Azure AD and apache \n> mod_auth_openidc; this works fine for gitweb (on \n> the same server as git).\n> \n> PROBLEM\n> \n> When trying to clone a repo with the OIDC setup, \n> git breaks on the redirect for user authentication \n> with the following error message (replaced server \n> ids etc with xxx):\n> \n>      C:\\Users\\void>git clone --progress -v \n> \"https://git.xxx.xxx/WebApps.git\"\n>      Cloning into 'WebApps'...\n>      fatal: unable to update url base from \n> redirection:\n>        asked for: \n> https://git.xxx.xxx/WebApps.git/info/refs?service=git-upload-pack\n>         redirect: \n> https://login.microsoftonline.com/xxx/oauth2/authorize?response_type=code&scope=openid&client_id=xxx&state=xxx&redirect_uri=https%3A%2F%2Fgit.xxx.xxx%2Fredirect&nonce=xxx\n> \n> \n> Can the git client just not handle a web based \n> redirect for login, or is this a configuration \n> issue? Any ideas would be greatly appreciated. Thanks!\n\nThe Git client doesn't handle any sort of web-based login.  In general,\nin order to do web-based login, you have to provide a fully functional\ngraphical web browser, and Git operates in many environments that don't\nhave one (such as servers, containers, and headless systems).\n\nYou should treat your Git server like you would treat any API you may\naccess, since essentially it is one.  That means that you would need to\nprovide a way to use some sort of external credential.\n\nI know next to nothing about Azure AD, but it claims to support\nKerberos, so you may be able to use that in conjunction with libcurl's\nGSS-Negotiate support and Apache's mod_auth_kerb (which is shipped in\nDebian).  I use Kerberos-based authentication for my personal server\n(which is Linux, not AD) and it does work, so it is possible to set up.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"384225","messageId":"1320f616-ddcc-0eed-22f2-e28eb0abf039@protonmail.com","threadId":"52039","inReplyTo":"20191016233319.3rhmekasi5csytyl@camp.crustytoothpaste.net","subject":"Re: git smart http + apache mod_auth_openidc","fromName":"Ralph Ewig","fromEmail":"ralph.phd@protonmail.com","sentAt":"2019-10-17T03:00:58Z","receivedAt":"2019-10-17T03:01:12Z","isPatch":false,"sender":{"key":"ralph.phd@protonmail.com","avatar":null},"body":"Thanks for the reply. I was hoping the Git GUI \nmight be able to handle the OpenID authentication \nflow, but it makes sense that it would be \ninconsistent with other git clients.\n\nAzure AD does support both LDAP and Kerberos, but \nunfortunately only as an extra cost add-on called \n\"Domain Services\". I might try to hack up a script \nto just sync the Azure AD password hashes to the \nhtpassword file. Otherwise I guess I'll have to \nbite the bullet and pay the extra bill.\n\nNonetheless, thank you for the suggestion!\nRalph\n\n\nOn 10/16/2019 4:33 PM, brian m. carlson wrote:\n> On 2019-10-15 at 15:59:03, Ralph Ewig wrote:\n>> Hi Everyone, hoping you might have a solution for\n>> this problem:\n>>\n>> CONTEXT\n>>\n>>    * I'm serving git repos using \"smart https\" via\n>> apache and basic authentication; everything works\n>> fine.\n>>    * We're moving to SSO via Azure AD and apache\n>> mod_auth_openidc; this works fine for gitweb (on\n>> the same server as git).\n>>\n>> PROBLEM\n>>\n>> When trying to clone a repo with the OIDC setup,\n>> git breaks on the redirect for user authentication\n>> with the following error message (replaced server\n>> ids etc with xxx):\n>>\n>>       C:\\Users\\void>git clone --progress -v\n>> \"https://git.xxx.xxx/WebApps.git\"\n>>       Cloning into 'WebApps'...\n>>       fatal: unable to update url base from\n>> redirection:\n>>         asked for:\n>> https://git.xxx.xxx/WebApps.git/info/refs?service=git-upload-pack\n>>          redirect:\n>> https://login.microsoftonline.com/xxx/oauth2/authorize?response_type=code&scope=openid&client_id=xxx&state=xxx&redirect_uri=https%3A%2F%2Fgit.xxx.xxx%2Fredirect&nonce=xxx\n>>\n>>\n>> Can the git client just not handle a web based\n>> redirect for login, or is this a configuration\n>> issue? Any ideas would be greatly appreciated. Thanks!\n> The Git client doesn't handle any sort of web-based login.  In general,\n> in order to do web-based login, you have to provide a fully functional\n> graphical web browser, and Git operates in many environments that don't\n> have one (such as servers, containers, and headless systems).\n>\n> You should treat your Git server like you would treat any API you may\n> access, since essentially it is one.  That means that you would need to\n> provide a way to use some sort of external credential.\n>\n> I know next to nothing about Azure AD, but it claims to support\n> Kerberos, so you may be able to use that in conjunction with libcurl's\n> GSS-Negotiate support and Apache's mod_auth_kerb (which is shipped in\n> Debian).  I use Kerberos-based authentication for my personal server\n> (which is Linux, not AD) and it does work, so it is possible to set up.\n\n"},{"id":"384232","messageId":"20191017060322.GA10373@sigill.intra.peff.net","threadId":"52039","inReplyTo":"1320f616-ddcc-0eed-22f2-e28eb0abf039@protonmail.com","subject":"Re: git smart http + apache mod_auth_openidc","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-10-17T06:03:23Z","receivedAt":"2019-10-17T06:03:25Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 17, 2019 at 03:00:58AM +0000, Ralph Ewig wrote:\n\n> Thanks for the reply. I was hoping the Git GUI \n> might be able to handle the OpenID authentication \n> flow, but it makes sense that it would be \n> inconsistent with other git clients.\n\nI don't think we'd ever do the full flow, but it might be that it's\npossible to use a token generated by the flow in a separate browser\nsession. This is easy to do if you can provide the token to the server\nin place of a password. E.g., if you use 2FA on GitHub, you can generate\na limited token that allows you to connect for Git operations.\n\nYou can also use time-limited tokens and feed them from a custom\ncredential helper, which does the full authentication flow from a web\nbrowser. I think Google does (or did) have such a thing internally, but\nI don't think any part of it was made public (it was discussed on the\nlist a couple times in the early days of credential helpers).\n\nThat would still have to end up with a token \"password\" to send over\nbasic auth, I think. There was some discussion a while back of letting\ncredential helpers pass back content for HTTP \"Authorization\" headers,\nbut I don't think anything was ever merged.\n\n> >>       C:\\Users\\void>git clone --progress -v\n> >> \"https://git.xxx.xxx/WebApps.git\"\n> >>       Cloning into 'WebApps'...\n> >>       fatal: unable to update url base from\n> >> redirection:\n> >>         asked for:\n> >> https://git.xxx.xxx/WebApps.git/info/refs?service=git-upload-pack\n> >>          redirect:\n> >> https://login.microsoftonline.com/xxx/oauth2/authorize?response_type=code&scope=openid&client_id=xxx&state=xxx&redirect_uri=https%3A%2F%2Fgit.xxx.xxx%2Fredirect&nonce=xxx\n\nYou're running into one other complexity here, which is that we don't\nallow cross-server redirects during the initial conversation. So even if\nyou did have an auth flow where we could somehow provide all the\ninformation via Git, we'd still be unhappy about bouncing between\nmultiple servers.\n\nMostly that's there to avoid leaking credentials. We only have one\nnotion of \"the username and password we're using\" for a given fetch, so\nwe want to avoid leaking it if we're redirected to another server. But\nobviously Git _could_ be smarter there, if this was the only blocker\nremaining (but from my understanding of OpenID, it's not).\n\n-Peff\n"},{"id":"384263","messageId":"8d06b57a-8d02-1d05-fb12-00a01d776200@protonmail.com","threadId":"52039","inReplyTo":"20191017060322.GA10373@sigill.intra.peff.net","subject":"Re: git smart http + apache mod_auth_openidc","fromName":"Ralph Ewig","fromEmail":"ralph.phd@protonmail.com","sentAt":"2019-10-17T14:21:17Z","receivedAt":"2019-10-17T14:21:27Z","isPatch":false,"sender":{"key":"ralph.phd@protonmail.com","avatar":null},"body":"Interesting ... I have not looked at access tokens \nbefore, but did find some documentation online \nthat describes how Azure AD Jason Web Tokens can \nbe used to authenticate a headless API \n(https://docs.microsoft.com/en-us/azure/active-directory/develop/id-tokens), \n\n\nThis seems to be a fit in this scenario, but  is \nadmittedly a bit deeper into the weeds than I'm \nfamiliar with. I'll keep digging in to see if I \ncan find a solution along that route. Really \nappreciate the pointer!\n\nRalph\n\n\nOn 10/16/2019 11:03 PM, Jeff King wrote:\n> On Thu, Oct 17, 2019 at 03:00:58AM +0000, Ralph Ewig wrote:\n>\n>> Thanks for the reply. I was hoping the Git GUI\n>> might be able to handle the OpenID authentication\n>> flow, but it makes sense that it would be\n>> inconsistent with other git clients.\n> I don't think we'd ever do the full flow, but it might be that it's\n> possible to use a token generated by the flow in a separate browser\n> session. This is easy to do if you can provide the token to the server\n> in place of a password. E.g., if you use 2FA on GitHub, you can generate\n> a limited token that allows you to connect for Git operations.\n>\n> You can also use time-limited tokens and feed them from a custom\n> credential helper, which does the full authentication flow from a web\n> browser. I think Google does (or did) have such a thing internally, but\n> I don't think any part of it was made public (it was discussed on the\n> list a couple times in the early days of credential helpers).\n>\n> That would still have to end up with a token \"password\" to send over\n> basic auth, I think. There was some discussion a while back of letting\n> credential helpers pass back content for HTTP \"Authorization\" headers,\n> but I don't think anything was ever merged.\n>\n>>>>        C:\\Users\\void>git clone --progress -v\n>>>> \"https://git.xxx.xxx/WebApps.git\"\n>>>>        Cloning into 'WebApps'...\n>>>>        fatal: unable to update url base from\n>>>> redirection:\n>>>>          asked for:\n>>>> https://git.xxx.xxx/WebApps.git/info/refs?service=git-upload-pack\n>>>>           redirect:\n>>>> https://login.microsoftonline.com/xxx/oauth2/authorize?response_type=code&scope=openid&client_id=xxx&state=xxx&redirect_uri=https%3A%2F%2Fgit.xxx.xxx%2Fredirect&nonce=xxx\n> You're running into one other complexity here, which is that we don't\n> allow cross-server redirects during the initial conversation. So even if\n> you did have an auth flow where we could somehow provide all the\n> information via Git, we'd still be unhappy about bouncing between\n> multiple servers.\n>\n> Mostly that's there to avoid leaking credentials. We only have one\n> notion of \"the username and password we're using\" for a given fetch, so\n> we want to avoid leaking it if we're redirected to another server. But\n> obviously Git _could_ be smarter there, if this was the only blocker\n> remaining (but from my understanding of OpenID, it's not).\n>\n> -Peff\n\n"},{"id":"384264","messageId":"5a2cc6f5-a8d0-356b-ff4e-a716aa5675b1@protonmail.com","threadId":"52039","inReplyTo":"20191017060322.GA10373@sigill.intra.peff.net","subject":"Re: git smart http + apache mod_auth_openidc","fromName":"Ralph Ewig","fromEmail":"ralph.phd@protonmail.com","sentAt":"2019-10-17T14:33:38Z","receivedAt":"2019-10-17T14:33:47Z","isPatch":false,"sender":{"key":"ralph.phd@protonmail.com","avatar":null},"body":"Quick follow up question: can the git client pass \na token read from a cookie with a request? That \nwould enable users to sign-in via a browser, store \nthe cookie, and then use that as the access token \nto authenticate a git request.\n\n\nOn 10/16/2019 11:03 PM, Jeff King wrote:\n> On Thu, Oct 17, 2019 at 03:00:58AM +0000, Ralph Ewig wrote:\n>\n>> Thanks for the reply. I was hoping the Git GUI\n>> might be able to handle the OpenID authentication\n>> flow, but it makes sense that it would be\n>> inconsistent with other git clients.\n> I don't think we'd ever do the full flow, but it might be that it's\n> possible to use a token generated by the flow in a separate browser\n> session. This is easy to do if you can provide the token to the server\n> in place of a password. E.g., if you use 2FA on GitHub, you can generate\n> a limited token that allows you to connect for Git operations.\n>\n> You can also use time-limited tokens and feed them from a custom\n> credential helper, which does the full authentication flow from a web\n> browser. I think Google does (or did) have such a thing internally, but\n> I don't think any part of it was made public (it was discussed on the\n> list a couple times in the early days of credential helpers).\n>\n> That would still have to end up with a token \"password\" to send over\n> basic auth, I think. There was some discussion a while back of letting\n> credential helpers pass back content for HTTP \"Authorization\" headers,\n> but I don't think anything was ever merged.\n>\n>>>>        C:\\Users\\void>git clone --progress -v\n>>>> \"https://git.xxx.xxx/WebApps.git\"\n>>>>        Cloning into 'WebApps'...\n>>>>        fatal: unable to update url base from\n>>>> redirection:\n>>>>          asked for:\n>>>> https://git.xxx.xxx/WebApps.git/info/refs?service=git-upload-pack\n>>>>           redirect:\n>>>> https://login.microsoftonline.com/xxx/oauth2/authorize?response_type=code&scope=openid&client_id=xxx&state=xxx&redirect_uri=https%3A%2F%2Fgit.xxx.xxx%2Fredirect&nonce=xxx\n> You're running into one other complexity here, which is that we don't\n> allow cross-server redirects during the initial conversation. So even if\n> you did have an auth flow where we could somehow provide all the\n> information via Git, we'd still be unhappy about bouncing between\n> multiple servers.\n>\n> Mostly that's there to avoid leaking credentials. We only have one\n> notion of \"the username and password we're using\" for a given fetch, so\n> we want to avoid leaking it if we're redirected to another server. But\n> obviously Git _could_ be smarter there, if this was the only blocker\n> remaining (but from my understanding of OpenID, it's not).\n>\n> -Peff\n\n"},{"id":"384302","messageId":"20191017225529.sg37cxvyssbaitfw@camp.crustytoothpaste.net","threadId":"52039","inReplyTo":"5a2cc6f5-a8d0-356b-ff4e-a716aa5675b1@protonmail.com","subject":"Re: git smart http + apache mod_auth_openidc","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2019-10-17T22:55:29Z","receivedAt":"2019-10-17T22:55:36Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2019-10-17 at 14:33:38, Ralph Ewig wrote:\n> Quick follow up question: can the git client pass\n> a token read from a cookie with a request? That\n> would enable users to sign-in via a browser, store\n> the cookie, and then use that as the access token\n> to authenticate a git request.\n\nGit has an option, http.cookieFile, that can read a cookie from a file,\nyes.  That does, of course, require that you're able to put the cookie\nin a file from a web browser.  I'm not aware of any web browsers that\neasily provide an option to dump cookies into a file.\n\nAlso, just as a note, this approach definitely won't work for automated\nsystems you have, such as CI systems.  That's why I suggested Kerberos:\nbecause you can have services that have principals and you can use those\ncredentials in your CI systems to access code and run jobs.\n\nClearly you know your infrastructure and users better than I do, but I\ndon't recommend having a web-based sign-on as your only form of\nauthentication for a Git server.  It's going to cause a lot of pain and\ninconvenience on all sides.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"384331","messageId":"20b6729f-a05e-b658-2cd4-70cb7a9d17b7@protonmail.com","threadId":"52039","inReplyTo":"20191017225529.sg37cxvyssbaitfw@camp.crustytoothpaste.net","subject":"Re: git smart http + apache mod_auth_openidc","fromName":"Ralph Ewig","fromEmail":"ralph.phd@protonmail.com","sentAt":"2019-10-18T01:18:04Z","receivedAt":"2019-10-18T01:18:18Z","isPatch":false,"sender":{"key":"ralph.phd@protonmail.com","avatar":null},"body":"Understood (and agree).\n\nWe do use git for source code (where we use SSH \nand key authentication for CI/CD), but also for \nconfiguration control of other files like \nfinancial reports, engineering drawings, etc. \nwhere access is via HTTPS.  In that 2nd group the \nchallenge is to make it as \"not coding like\" as \npossible so the non-developer crowd isn't scared off.\n\nSince we use trac for project management company \nwide (all verticals), my latest idea is to \nintercept the git http request on the server side \nto authenticate against the trac session info \nstored in the db (using a custom php script),  and \nthen pass it on to git-http-backend or throw an \nerror prompting the user to sign into trac first. \nMost users are signed into trac 24/7 anyway since \nits central to our workflow.\n\nin the end paying the extra fee for MS Domain \nServices to get SSO via LDAP or Kerberos might be \nthe right answer though - just trying to be \nscrappy if I can since it's an early stage \nstartup. Nonetheless really appreciate the \nexchange of ideas!\n\nRalph\n\n\nOn 10/17/2019 3:55 PM, brian m. carlson wrote:\n> On 2019-10-17 at 14:33:38, Ralph Ewig wrote:\n>> Quick follow up question: can the git client pass\n>> a token read from a cookie with a request? That\n>> would enable users to sign-in via a browser, store\n>> the cookie, and then use that as the access token\n>> to authenticate a git request.\n> Git has an option, http.cookieFile, that can read a cookie from a file,\n> yes.  That does, of course, require that you're able to put the cookie\n> in a file from a web browser.  I'm not aware of any web browsers that\n> easily provide an option to dump cookies into a file.\n>\n> Also, just as a note, this approach definitely won't work for automated\n> systems you have, such as CI systems.  That's why I suggested Kerberos:\n> because you can have services that have principals and you can use those\n> credentials in your CI systems to access code and run jobs.\n>\n> Clearly you know your infrastructure and users better than I do, but I\n> don't recommend having a web-based sign-on as your only form of\n> authentication for a Git server.  It's going to cause a lot of pain and\n> inconvenience on all sides.\n\n"}]}