tempURL middleware change
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.
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- Venkat Sundaram
- Direction:
- Needs approval
- Assignee:
- Venkat Sundaram
- Definition:
- New
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
Assumptions
the swift account id may or may not be the same as the default project id in keystone
should not break existing customers of tempURL - should be backward compatible
Proposal
The tempURL filter should change to re-construct data and leverage the generic signature validation filter. Thus, making it pluggable for future signing algorithms and implementations.
Pre-requisites:
generic signature validation filter should be setup to be used after this filter - this filter only re-constructs data for it
keystone account - the owner of the tempURL should have an a/c with keystone with valid accessKey(s)
keystone tenant - the owner should pass their project ID and accessKey along with the tempURL... For project scoped access keys, only the access key needs to be passed along with the tempURL
High Level Design
The middleware components provides support for the following operations:
Parsing and processing information from the original REST request to form a generic signature validation request. Processing includes validating the signature expiry time.
Signature validation using the Keystone backend
Detailed Design
The tempURL filter should leverage the generic signature validation filter in the middleware filter chain. To achieve this, modify the existing Keystone client middleware tempURL filter as follows:
retain existing logic that parses the input and perform validation
extra parsing logic to get the signature algorithm used
detect tempURL style and use existing code to be backward compatible
construct data from the original tempURL signature in a way that is expected by the generic signature validation filter
set headers as required by the generic signature validation filter
pass the request down the filter chain bypassing the existing validation logic - as the filter down would do that
The fields that would be used for re-constructing data for the generic signature validation data:
Key Identifier
Data to sign
Algorithm
Signature value
Existing tempURL request received by swift middleware:
https:/
temp_
*Example:*
https:/
temp_
temp_
Proposed tempURL request received by swift middleware:
https:/
*Example:*
https:/
Payload to be re-constructed by tempURL filter:
{“auth”: {“identity”: {
“methods”: [“signature”],
“signature”: {
“access_
“signature_
“data_to_sign”: to_be_signed_data,
“signature”: signature
},
“scope”: scope_info
}
The Signature Validator then parses the signature validation response from the Keystone generic Signature Validation Service to builds the user headers that needs to be passed along to the next filter (Service Context Builder) in the pipeline
Classification:
To figure if the request is of old type or new, the following convention would be used:
tempURL-swift => this is the existing tempURL structure
tempURL-keystone => this would be the new tempURL as per keystone generic signature validation specifications
Identify tempURL type:
From the request query params, figure if the request is tempURL-swift or tempURL-keystone
Classify as tempURL-swift if query params has only these fields:
temp_url_sig
temp_url_expires
Classify as tempURL-keystone, if the "temp_url_sig" query param has following parts:
signature type
tenant id
access key
Migrating existing tempURL customers:
update API documentation with details about the new tempURL structure and signing logic change
email customers about the new style of tempURL along with a list of keystone supported signature algorithms
specify a timeframe when tempURL-swift will be decommissioned
customer should find from their keystone a/c the following details
the project ID of the container
the accessKey/secretKey they wish to use
customer no longer need to set the X-Account-
customer would user their preferred signature algorithm and sign the tempURL fields
customer would specify the tempURL-keystone fields specified above
should the customer need to invalidate the tempURL before the expiry time, they just need to revoke their accessKey using keystone
Gerrit topic: https:/
Addressed by: https:/
formpost and tempurl validation with keystone.
Addressed by: https:/
formpost and tempurl validation with keystone.
Work Items
Dependency tree
* Blueprints in grey have been implemented.
