The provided security credentials are not valid. #277

Closed
rusher81572 opened this Issue Oct 4, 2014 · 5 comments

Comments

Projects
None yet
2 participants
@rusher81572

Hello,

My Java program uses 1.8.5. I decided to update the Java API to 1.8.11. I can connect to Amazon S3 but I am unable to connect to a third-party S3 provider any more. Has anything changed with authentication since 1.8.5? I downgraded my Java program to 1.8.5 and everything works normal.

The error message the S3 client reports:

The provided security credentials are not valid. (Service: Amazon S3; Status Code: 403; Error Code: InvalidSecurity; Request ID: EF8C16704B8011E4)

I know my credentials are correct and I tried multiple third-party S3 compatible services and have the same problem.

My credentials code;

    AWSCredentials credentials = new BasicAWSCredentials(access_key, secret_key);
    AmazonS3 s3Client = new AmazonS3Client(credentials);
    s3Client.setEndpoint(endpoint);

Thank you,

Phillip.

@rusher81572 rusher81572 closed this Oct 4, 2014

@rusher81572 rusher81572 reopened this Oct 4, 2014

@rusher81572

This comment has been minimized.

Show comment
Hide comment
@rusher81572

rusher81572 Oct 5, 2014

I compiled a few versions prior to 1.8.11. Here are the results:
1.8.6 - works.
1.8.7 - works.
1.8.8 - works
1.8.9 - works.
1.8.10.2 - Does not work
1.8.11 - Does not work.

I compiled a few versions prior to 1.8.11. Here are the results:
1.8.6 - works.
1.8.7 - works.
1.8.8 - works
1.8.9 - works.
1.8.10.2 - Does not work
1.8.11 - Does not work.

@hanshuo-aws

This comment has been minimized.

Show comment
Hide comment
@hanshuo-aws

hanshuo-aws Oct 7, 2014

Contributor

Hi,

What's the endpoint you were using to talk to your S3 bucket?
And in which AWS region is your bucket located?

Contributor

hanshuo-aws commented Oct 7, 2014

Hi,

What's the endpoint you were using to talk to your S3 bucket?
And in which AWS region is your bucket located?

@rusher81572

This comment has been minimized.

Show comment
Hide comment
@rusher81572

rusher81572 Oct 7, 2014

Thank you for the reply. My program works fine for Amazon S3 using any API. The problem I am having is with S3 compatible services. Downgrading the API to < 1.8.10.2 resolved the issue.

Thank you for the reply. My program works fine for Amazon S3 using any API. The problem I am having is with S3 compatible services. Downgrading the API to < 1.8.10.2 resolved the issue.

@hanshuo-aws

This comment has been minimized.

Show comment
Hide comment
@hanshuo-aws

hanshuo-aws Oct 7, 2014

Contributor

Gotcha.

What's happening is that in our 1.8.10 release, we switched the default signing protocol from V2 signing to V4 signing. The purpose of this change is to make sure the SDK is forward-compatible with new AWS regions where only V4 signing will be supported (e.g. the "cn-north-1" region that was recently launched).

Meanwhile, to ensure backwards-compatibility, the SDK is by default configured to keep using the old signing protocol for all the existing v2-supported regions. But... unfortunately this would only work if the SDK could recognize the endpoint, and in your case since the SDK doesn't understand the endpoint of non-AWS services, it will simply assume it's talking to a new AWS region, and then choose to use V4 protocol to sign the request. Apparently, the "s3-compatible" services you were working with don't understand this protocol yet, and as a result your request was rejected with 403 error.

Assuming these service vendors won't implement V4-signing support soon, a workaround for you is to manually override the signer via ClientConfiguration#setSignerOverride.

    AWSCredentials credentials = new BasicAWSCredentials(access_key, secret_key);
    // Use ClientConfiguration to force V2 signing
    AmazonS3 s3Client = new AmazonS3Client(credentials,
            new ClientConfiguration().withSignerOverride("S3SignerType"));
    s3Client.setEndpoint(endpoint);

This is indeed a very hacky solution, but there's not much we can do about it before these service providers are truly "s3-compatible".

Contributor

hanshuo-aws commented Oct 7, 2014

Gotcha.

What's happening is that in our 1.8.10 release, we switched the default signing protocol from V2 signing to V4 signing. The purpose of this change is to make sure the SDK is forward-compatible with new AWS regions where only V4 signing will be supported (e.g. the "cn-north-1" region that was recently launched).

Meanwhile, to ensure backwards-compatibility, the SDK is by default configured to keep using the old signing protocol for all the existing v2-supported regions. But... unfortunately this would only work if the SDK could recognize the endpoint, and in your case since the SDK doesn't understand the endpoint of non-AWS services, it will simply assume it's talking to a new AWS region, and then choose to use V4 protocol to sign the request. Apparently, the "s3-compatible" services you were working with don't understand this protocol yet, and as a result your request was rejected with 403 error.

Assuming these service vendors won't implement V4-signing support soon, a workaround for you is to manually override the signer via ClientConfiguration#setSignerOverride.

    AWSCredentials credentials = new BasicAWSCredentials(access_key, secret_key);
    // Use ClientConfiguration to force V2 signing
    AmazonS3 s3Client = new AmazonS3Client(credentials,
            new ClientConfiguration().withSignerOverride("S3SignerType"));
    s3Client.setEndpoint(endpoint);

This is indeed a very hacky solution, but there's not much we can do about it before these service providers are truly "s3-compatible".

@rusher81572

This comment has been minimized.

Show comment
Hide comment
@rusher81572

rusher81572 Oct 7, 2014

That worked, thank you

That worked, thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment