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

Please confirm AUTH behavior findings (and add them to documentation) #7841

Closed
WernerMairl opened this issue Mar 1, 2019 · 1 comment
Closed
Assignees
Labels
Area:Authentication Resolution:Question This issues appears to be a question, not a product defect

Comments

@WernerMairl
Copy link

Hi
i'm working on a token based Authentication for a NuGet Server (BaGet)
I know all the concepts of CredentialProviders and i have up and running VS+Debugger for Nuget.exe and "artifacts-credprovider" (the Azure Artifact Credential Provider)

Basically Nuget Authentication is implemented here

basically the following 2 lines are doing the work:

clientHandler.Credentials = _credentials;
clientHandler.UseDefaultCredentials = false;

that means the entire process of building and appending a AUTH-Header is delegated to the corefx implementation of HTTPClientHandler (also debugged for this investigations)

basically HTTPClienHandler has no implementation for a AuthType like "Bearer".
It has implementations for "Basic", "NTLM" "Negotiate" and "Digest"..

Reading the sourcecode of artifacts-credprovider, (the NuGet CredentialProvider for Azure Artifacts) i find out, that they are using/implementing Token based security (vsts services) BUT

  • the used Authenticationtype is "Basic" (see VstsBuildTaskCredentialProvider)
  • credential.username is ignored/random/virtual
  • credential.password contains the token.

It make sense to do the same if we implement token based security in our own NuGet Server ?
what is the plan for the future here ?

I see that the current CredentialProvider interface does not allows the transfer of information about the authtype...(or i overlooked something) ?

Summary:

For Token based NuGet Authentication

  1. implement "Basic" Authentication on the server side and assume that the password contains the token
  2. use Config/CredentialProvider Settings on the client side that sends the token as ICredential.Password

TRUE ?
i must assume that Azure Artifacts and others does exactly this "hack" at the moment....

regards
Werner

@rrelyea rrelyea added this to the 5.1 milestone Mar 5, 2019
@rrelyea rrelyea added the Resolution:Question This issues appears to be a question, not a product defect label Mar 5, 2019
@rrelyea rrelyea modified the milestones: 5.1, 5.2 Apr 30, 2019
@nkolev92 nkolev92 modified the milestones: 5.2, 5.3 Jul 1, 2019
@nkolev92 nkolev92 modified the milestones: 5.3, Backlog Aug 21, 2019
@nkolev92
Copy link
Member

Apologies for the late reply, but this analysis is spot on.

Trick is that the PATs passed around are actually scoped, and in order to acquire a PAT you might need to go through 2FA first.

As far as documentation goes, while I'd love for us to have documentation like, this is certainly not high on our priority list right now.

As such I'm gonna close it.
We'd be open to a contribution but at this point I'm not sure where this belongs.

Instructions for building a plugin can be found here: https://docs.microsoft.com/en-us/nuget/reference/extensibility/nuget-cross-platform-authentication-plugin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area:Authentication Resolution:Question This issues appears to be a question, not a product defect
Projects
None yet
Development

No branches or pull requests

4 participants