Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement Authentication Propagation #1649

Closed
marwan-at-work opened this issue Jul 20, 2020 · 0 comments · Fixed by #1650
Closed

Implement Authentication Propagation #1649

marwan-at-work opened this issue Jul 20, 2020 · 0 comments · Fixed by #1650
Labels
proposal A proposal for discussion and possibly a vote

Comments

@marwan-at-work
Copy link
Contributor

Athens currently supports a couple of types of authentication:

  1. Basic Authentication: authenticates clients to the Athens server itself. If the user has the basic auth, then he/she can access the Athens server.

  2. .netrc file: authenticates Athens with upstream modules. This is so that Athens can download and store private modules.

I propose implementing a third option:

Propagated Authentication: This will allow Athens to accept an Authorization header. However, it will not check it against a static username/password. Instead, it will dynamically create a .netrc file with the given authentication and with machine set to the requested module hostname.

This will allow Go developers to provide their own identity for Athens which will then allow them access to their own private modules.

There are a few things to be aware of:

  1. go mod download can only implicitly authenticate with git-clones through the .netrc file in the HOME directory. So we'd have to dynamically create/destroy home dirs for every go mod download that carries an Auth header. If there is enough demand, we can provide a feature in the future that copies certain files from HOME to TempHome (i.e. .gitconfig)

  2. Once a Module is retrieved and stored, Athens won't know if the next user who requests it is actually authorized to access it or not. This can be solved by providing a ValidationHook or putting Athens behind an auth proxy that can authorize a auth header against the requested module. Note that a ValidationHook at the moment does not include list/latest, so a proxy is likely more appropriate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal A proposal for discussion and possibly a vote
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant