replace the old auth code from our MinIO fork

[amwolff]

Because of #89, there was work encompassing #90, #91, and #92, which was a side project that I've put into a package here. I've done my best to have the API surface be as succinct as possible and for the potential project of plowing through the old auth code in our MinIO fork to go as smoothly as possible, so I believe that it should be possible to go handler by handler, replacing the auth code.

There are instructions on how to use the library in the linked README.md file.

I think it should be possible to:

1. implement CredentialsProvider in such a way that the MinIO fork receives it from the calling code
       1. in Gateway-ST, CredentialsProvider can be very simple
       2. in Gateway-MT, authclient should implement CredentialsProvider or an implementation should call it
2. have the old auth code work alongside the new auth code
3. after going through each bucket/object handler, run the entire CI suite, verifying nothing broke
4. once every important handler has been adjusted, we can fully get rid of the legacy auth code

This is a significant amount of work, so we might want to partition this issue into subissues that resemble the list above, and we could even partition the work for (4) into an issue per handler.

I don't think we should make support for all available integrity options a requirement for this issue to be completed. I believe it should be another (hopefully small) project.

[amwolff]

@jewharton asked:

Could you explain what "have the old auth code work alongside the new auth code" entails?

@amwolff's response:

Yes, I was hoping that we could wire up the new auth code alongside the old auth system in a way that would allow us to pass credentials from both to the specific action implementations in the gateway's object layer. For now, I was hoping we could create a proof-of-concept with just one action, like PutObject or GetObject. I think we should make sure we aren't constraining ourselves to the current object layer interface and that we think of everything as moldable.

[amwolff]

@jewharton Let's make this issue a 1-2 (number of tasks) that encompasses only points 1 & 2 from the list in the issue description. Then we will go ahead and make an issue per handler to be adjusted. Does this seem like a good idea for now?

[jewharton]

@amwolff Yes, that sounds good to me.

[jewharton]

@amwolff Most MinIO handlers perform signature verification the same way: by calling a common method dedicated to this purpose and returning the verification error, if it exists, to the client. It should be possible to handle the adjustment of these many handlers all at once by adjusting the signature verification method they invoke. So far, the only handlers I've encountered that require complicated adjustment are PutObject, PutObjectExtract, and PutObjectPart. With this in mind, do you still think we should make an issue per handler? What do you think about one issue for the basic handlers and an issue for all (or for each, depending on their complexity) of the PutObject handlers?

[amwolff]

@jewharton sounds perfect! would you like to create these issues while you're on it?