Bug 1041616

Summary: [RFE][swift]: tempURL middleware change
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: RFEsAssignee: RHOS Maint <rhos-maint>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: markmc, yeylon
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/swift/+spec/tempurl-middleware-change
Whiteboard: upstream_milestone_none upstream_status_unknown upstream_definition_new
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-19 17:34:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description RHOS Integration 2013-12-12 18:16:42 UTC 
Cloned from launchpad blueprint https://blueprints.launchpad.net/swift/+spec/tempurl-middleware-change.

Description:

The existing swift middleware has a tempURL filter for authenticating signature specified in a temporary URL. The signature algorithm used is fixed to HMAC-SHA1 (RFC 2104). In other words, the tempURL filter can handle only HMAC-SHA1 signed URLs. This is limiting if the client wants to use a different signature alogrithm. Also, should swift decide to support multiple algorithms, the tempURL filter code has to change. This calls for a signature algorithm agnostic way to validate the signature. Further, validating the signature in the middleware itself requires storing the user specified secretKey with each Swift account. As the strength of the key depends on what the customer chooses, this increases the chances of compromising the secretKey. Its desirable to de-couple security from storage and delegate validation to keystone, which offers a reliable algorithm using accessKey/secretKey pair. This also provides flexibility in supporting more signature algorithms and efficiency as keystone is stood up by its own servers. Users could have a separate key pair for the tempURL for extra security.

Specification URL (additional information):

None