Generic Signature Validation

Motivation

We need a HMAC based signature authentication plugin. There are lots of HMAC based protocols out there (i.e. AWS). But having a protocol-agnostic HMAC based authentication plugin, we can effectively support any HMAC based protocols by having a protocol specific middleware (i.e. EC2, S3, etc).

The design described below is based on the following objectives:

    Simplify the configuration of Openstack services to use signature based authentication.
    We do not need new APIs in order to support new HMAC-based protocols.

Problem Description

Currently keystone provides separate api's (/ec2tokens and /s3tokens) for validating ec2 and s3 signatures. In future if there is plan to support new signature, we need to expose a new keystone api for validating the new signature. As a consequence we will be adding new keystone api's for different signature implementation which is not efficient.

Proposed Solution

Authenticating signatures should be made as a auth plugin (similar to password auth plugin) to V3 authentication API and issues a token as the result of successful verification. All we have to do is to define the new authentication payload for signature authentication. Payload should also optionally include the parameters for authenticating the client/service who is trying to authenticate on user/resource behalf. If the keystone is front ended by two way 2 mutual ssl the authentication payload do not need to include the client signature. Client signature can be obtained by signing the combination of access_key_id, signature_method, data_to_sign and signature. For example, say middleware wants to validate the signature on behalf of the resource owner, it needs to establish trust with Keystone first, perhaps via out-of-band method. When trust is established, there will be a shared secret between Keystone and the individual services where middleware is running. When middleware is validating the signature on behalf of the resource owner, it needs to add its own signature onto the request, using the pre-established shared secret. Generic signature plugin will need to validate two signatures. One from the trusted client (middleware), the other from the originating signer (resource owner).

We introduce a new plugin called signature for validating generic signatures besides the default authentication plugins token and password. On successful authentication, the signature plugin must provide a valid user_id in user authentication context.

For example ,

{“auth”: {“identity”: {
“methods”: [“signature”],
“signature”: {
    "user": {
        “access_key_id”: access_key_id,
        “signature_method”: signature_alrogithm,
        “data_to_sign”: to_be_signed_data,
        “signature”: signature
    },
    "client": {
        "date": client timestamp,
        "algorithm" signature_algorithm,
        "client_signature": client_signature,
        "client_access_key_id": client_access_key_id
    }
 }
}

Public API Changes

After implementing the proposed signature validation as a authentication plugin we do not have to expose the public api /v2.0/ec2token and /v2.0/s3token.

Admin API Changes

No admin api changes.

Backend Schema Changes

This plugin will make use of credential table, ec2_credential table, or both, based on a configurable option.