google credentials backend (dev)

[Nathan Grunzweig]

Hi,

I'm beginning work on something and wish to sync with you or hear any comments you might have before i begin.

we want to support login via google.
for this purpose i'm going to implement an oauth2/google credential backend.

the idea is:
* mount the "google" backend
* use the config path to set the google application id and secret (where to store the secret in the meanwhile? chicken-egg.. nevermind)
* path-help of mount will show a link to google that you can open in the browser and will give you a token, as specified in oauth2 for installed apps: https://developers.google.com/identity/protocols/OAuth2InstalledApp#overview
* login path will take this token and behave similarly to github backend (which is my case study in order to implement this feature)

any thoughts/comments you might have are most welcome.

cheers,
Nathan

[Jeff Mitchell]

Hi Nathan,

We've shied away from OAuth2 in the past for a few reasons. One of
them is that right now there isn't a way in Vault to handle a non-JSON
request, and the output from most OAuth2 services when they round-trip
(I've worked with FB, Google, Twitter, and a couple of others) is raw
urlencoded form data. So that's an immediate, although probably
solvable, blocker.

The workflow is also not entirely clear. The user makes a call to
Vault and gets a URL. The user then authorizes Vault via Google, and
this gives Vault a Google API token that it can use to act on behalf
of the user. At this point the user is redirected by Google to
<something>, which depending on the chosen workflow flow might be a
port on localhost, but in most cases would need to use some non
localhost address. What happens next? Vault returns a normal secret
JSON response in the user's web browser? How do we map the user to
policies?

A separate concern is that we have some plans to consolidate some of
the backends, and I think if we were comfortable merging this kind of
provider, we'd want to have it designed in a way that makes it easy to
add support for other providers by implementing interfaces rather than
separate backends.

Best,
Jeff

> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/hashicorp/vault/issues
> IRC: #vault-tool on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Vault" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vault-tool+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vault-tool/e8eaaceb-dc51-4890-96b6-feed63e6a59e%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Nathan Grunzweig]

Hi Jeff,

thanks for the reply,
just to make sure we're on the same page - i don't mean 3 legged oauth2 authentication, i meant google's specific oauth 2 for installed applications.
so there is no redirect from google servers to a vault server, the code is returned to the user and he gives it manually to vault, in the same way that a token is generated in github and the user manually gives it to vault.

so vault shows you a url, you access it, login and get a "code" which you paste into the login path similarly to github.
then the vault backend uses the code with a google api to generate a token and access the google api, retrieving user information.
i need to learn more about what information google stores but i'm pretty sure they have domain/org (at least for the email).
from here, i imagine, it should be the same as github.

[Jeff Mitchell]

Hi Nathan,

Thanks for pointing that out -- in my initial look I saw the redirect
to localhost and missed the other possibilities, figuring it was
basically the same thing but redirecting to a local web server. This
does look doable. :-)

--Jeff

> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/hashicorp/vault/issues
> IRC: #vault-tool on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Vault" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vault-tool+...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/vault-tool/8aa3ff64-c95b-4869-b2ab-6bbd99aa5058%40googlegroups.com.

[Nathan Grunzweig]

glad to hear it.
so, one final issue that comes to mind is automation: running the google/auth2 test in CI to validate that the contract isn't broken.

in github, you could have a static token that you use for your tests on a permanent basis, and when running your CI you could use that token via environment variable.
that approach probably won't work with google, because the code returned by google will be different each time and probably expires after a while.

in github you could have  a local "enterprise" github to test against that your CI could run for the duration of the test, but i'm not aware of any such local google oauth2 installation.

the best i can come up with is running an html-client in an init phase of the test to use against an ad-hoc test app.
it does the whole get code process (including authentication against google), and passes the code to vault to use in the test.

so while the input to vault is a google code, the input for the test is an ad-hoc test oriented google account, with its login details.

there are other alternatives.
what do you think?

cheers,
N

[Jeff Mitchell]

On Sun, Mar 13, 2016 at 1:55 AM, 'Nathan Grunzweig' via Vault
<vault...@googlegroups.com> wrote:
> glad to hear it.
> so, one final issue that comes to mind is automation: running the
> google/auth2 test in CI to validate that the contract isn't broken.
>
> in github, you could have a static token that you use for your tests on a
> permanent basis, and when running your CI you could use that token via
> environment variable.
> that approach probably won't work with google, because the code returned by
> google will be different each time and probably expires after a while.
>
> in github you could have a local "enterprise" github to test against that
> your CI could run for the duration of the test, but i'm not aware of any
> such local google oauth2 installation.
>
> the best i can come up with is running an html-client in an init phase of
> the test to use against an ad-hoc test app.
> it does the whole get code process (including authentication against
> google), and passes the code to vault to use in the test.
>
> so while the input to vault is a google code, the input for the test is an
> ad-hoc test oriented google account, with its login details.
>
> there are other alternatives.
> what do you think?

Hi Nathan,

I'm not sure how we'd automate something like that within Vault's test
framework, but from an outside CI perspective this seems doable. If
you don't mind listing the other alternatives you thought of, that
would be interesting too.

Best,
Jeff

[Nathan Grunzweig]

Hi Jeff,

unfortunately implementing that as a CI step does not solve the problem: the first test passes but the remaining tests fail.
an environment variable from CI provides the google auth code, the first test tries to login in with it and does so successfully, but the second test tries to use the same auth-code and gets an error message from google saying the code is already redeemed.

i'm on it now to see how to generate a different auth code for each test, i think it'll be ok.

anyway, another issue is the teams logic.
since google has no concept of teams like github, i'll probably do something similar to local team management which i believe you have in the local userpass backend.

this does raise a nice feature question: perhaps team management should also be a backend. for example, maybe i want to login via google, but i want team management to be done via github, ldap or some other mechanism. i realize there might sometimes be an issue mapping users from google into git users, but i suspect there are some valid heuristics for this case specifically and that other cases are simpler. just a thought...

cheers,
N

[Jeff Mitchell]

On Tue, Mar 15, 2016 at 4:10 AM, 'Nathan Grunzweig' via Vault
<vault...@googlegroups.com> wrote:
> i'm on it now to see how to generate a different auth code for each test, i
> think it'll be ok.

That would be my suggestion.

> anyway, another issue is the teams logic.
> since google has no concept of teams like github, i'll probably do something
> similar to local team management which i believe you have in the local
> userpass backend.

There is no concept of teams in the userpass backend.

> this does raise a nice feature question: perhaps team management should also
> be a backend. for example, maybe i want to login via google, but i want team
> management to be done via github, ldap or some other mechanism. i realize
> there might sometimes be an issue mapping users from google into git users,
> but i suspect there are some valid heuristics for this case specifically and
> that other cases are simpler. just a thought...

Team management can't be a backend because backends are kept separate
from each other -- there's no cross-talk. At the moment (although we
do have some ideas kicking around for the future) we prefer teams to
be handled natively by the authentication mechanism. I figured you
were simply planning to map individual users to policies...

Best,
Jeff

[Nathan Grunzweig]

also good! :D

[Nathan Grunzweig]

looks good.

issue:
https://github.com/hashicorp/vault/issues/646

pull request:
https://github.com/hashicorp/vault/pull/1219

[Nathan Grunzweig]

looks good.

issue:
https://github.com/hashicorp/vault/issues/646

pull request:
https://github.com/hashicorp/vault/pull/1219