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