Refactor Auth API

[ghost]

We need to refactor the auth API so as to:

1. Provide a simple, synchronous API
2. Avoid using closures/callbacks for simple computations
3. Avoid depending on any HTTP framework (remove any reference to http.request, keep only required bits of data)
4. Provide an 'AwsServiceName' to the signing requests, as this may be included depending on the service.

The planned API is as follows:

auth: {
    client: {
        generateV4Headers: function (query, method, uri, payload, secretKey) -> { headersDict, errorObject },
    },
    server: {
        prepareV2: function (QueryString, Headers) -> { authParamsObject, errorObject },
        prepareV4: function (QueryString, Headers) -> { authParamsObject, errorObject },
        checkV2Signature: function(authParamsObject, secretKeyValue) -> bool,
        checkV4Signature: function(authParamsObject, secretKeyValue) -> bool,
    },
}

This is the general feeling. The Client would use the client API, and the server could use the server API in two steps:

1. prepare auth params for actual auth
2. retrieve auth information from whatever storage is used
3. compute and check signature using results from step 1+2

Admitedly, the current API is missing a potential options object, or at least an AWSServiceName to use.

[jmunoznaranjo]

Looks good 👍 . Maybe you want to consider a different name for prepareVX as it suggests (to me at least) that a signature is being created instead of verified. I suggest extractVX or extractVXParams.

[ghost]

Actually, in my current work, I actually defined only two functions in the server API:
extractParams and checkSignature, and those functions use the params.version to switch on the right version.

I could possibly also export checkSignatureV4 and checkSignatureV2, as well as the associated extractParams, but not in the first step. I hope to be able to put out the first set of PRs tuesday :)

[LaurenSpiegel]

As noted in https://github.com/scality/Arsenal/pull/119/files/3267fd091deac5d00f951bacf278362fca28f86d#r72753763 ,
if the generate4Headers function is really going to be multi-purpose we can't hard code the signedHeaders. Instead the host header and any x-amz- or x-scal- should be included in the signedheaders and the signature.

[rahulreddy]

Piggybacking on @LaurenSpiegel 's comment we should make it generic in the sense it should not set any headers to the request object, it should just return a generic object with the headers that can be set.

[LaurenSpiegel]

To be clear, there are 2 issues that are separate:

1. My original issue: The signed headers should not be a defined string. It should be created by concatenating host with all of the x-amz and x-scal headers from the request headers.
2. Rahul's issue -- don't mess with the request object directly.

[ghost]

@rahulreddy @LaurenSpiegel Should we create a dedicated issue for the generateV4Headers's signed header topic ? Not modifying the request object is already part of my aim for this task.

[LaurenSpiegel]

@DavidPineauScality, I already fixed the signed headers issue so that the encrypted bucket creation tool would work. 18d657b

[ghost]

Ok perfect, thanks. I guess a huge rebase is waiting for me again...

On Wed, Aug 24, 2016 at 6:22 PM, Lauren Spiegel [email protected]
wrote:

@DavidPineauScality https://github.com/DavidPineauScality, I already
fixed the signed headers issue so that the encrypted bucket creation tool
would work. 18d657b
18d657b

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#102 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANpZZ6UU6s8p33E7nsN7_jCeKfmEb41Yks5qjG_XgaJpZM4I85rs
.

David Pineau
Scality R&D Engineer

http://bit.ly/2aKbaTu

[ghost]

Following the work done in the associated PR, Only one thing is left remaining to completely wrap up this rework:

Use the new API to remove slowly the doAuth from the relevant components, and then remove the doAuth utility function altogether.