Open Stack

Hi again,

Because was no answer to my questions then I have decided to choose and
implement first scenario.

So now I need to review my patchsets by community:
1) https://review.openstack.org/#/c/211933/
This is patchset for swift3 with new unit tests. It implements checking of
headers of signature v4 auth and preparation string to pass it to keystone.
2) https://review.openstack.org/#/c/215481/
This is patchset for keystone. It implements signature v4 calculation and
comparison with provided one.
3) https://review.openstack.org/#/c/215325/
This is patchset for devstack. It implements setting of region for checking
in swift3.

All new code is written in previous architecture style.
So please review these patchsets.

On Mon, Aug 17, 2015 at 3:52 PM, Andrey Pavlov <andrey.mp at gmail.com> wrote:

> Hi,
>
> I'm trying to support AWS signature version 4 for S3 requests.
> Related bugs:[1] for keystonemiddleware and [2] for swift3:
>
> Also keystone doesn't have support for V4 signature verification for S3
> (but it supports V4 for EC2 requests).
>
> Differences between V1 and V4 can be found here - V1: [3] and V4: [4].
> (Signature verification has several differences for EC2 and S3 requests)
>
> My question is - how to implement V4 signature verification?
> I have several scenarios:
> 1) Leave current architecture. Swift3 will parse authorization info, will
> calculate StringToSign, will place it in 'X-Auth-Token'
> and place some additional header with signature version info. s3token will
> provide these values to keystone. keystone will
> calculate signature with V4 algorithm and check it.
> 2) Same as first but without s3token - swift3 will send all info to
> keystone itself.
> 3) Same as first but most authorization headers will be parsed by s3token
> and s3token will send to keystone.
>
> I prefer first scenario.
> But what think keystone team?
>
>
> Current implementation of S3 signature V1 verificatoin has several
> oddities for me:
>
> First oddity for me is in implementation of EC2 and S3 verification in
> keystone -
> ec2tokens (in keystone) takes all request parameters, calculates all that
> it needs, and checks
> calculated signature with user provided (Because only keystone can
> securely access secret_key
> by provided access_key). But signature calculation code is placed in
> keystoneclient...
> But s3tokens takes strange 'token' attribute (that calculated outside of
> keystone), access_key and signature.
> Then keystone hash token with secret_key (that was obtained from DB by
> access_key) and checks this result
> with provided signature.
> Oddity for me is in different algorithms for similar essences.
>
> Next oddity is in swift pipeline for S3 requests -
> at 'first' request with S3 params recognized by swift3 plugin. It checks
> authorization information,
> validates S3 parameters, calculates StringToSign as it described in [3]
> and places it in 'X-Auth-Token' header.
> at next step s3token from keystonemiddleware takes X-Auth-Token (that is a
> StringToSign) from header,
> sends it to keystone to check authorization.
> Oddity for me is in s3token that doesn't parse authorization information
> unlike ec2token from keystonemiddleware.
>
> [1] https://bugs.launchpad.net/keystonemiddleware/+bug/1473042
> [2] https://bugs.launchpad.net/swift3/+bug/1411078
> [3] http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html
>
> [4]
> http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html
>
> --
> Kind regards,
> Andrey Pavlov.
>



-- 
Kind regards,
Andrey Pavlov.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150827/6a30ded6/attachment.html>