Search Proxy Design

The Search Proxy’s purpose is to enforce multi-tenancy on ElasticSearch. The Search Proxy will utilize either OpenStack Keystone or Rackspace’s Global Auth systems to validate auth tokens and enforce access to the ElasticSearch API via role based security.

All requests to the Search Proxy must contain a scoped token in the header as well as the tenant name.

X-Auth-Token: {token}
X-Tenant-Name: {tenant name}

###Token Authentication###

Upon receiving a request for a new tenant the following will happen:

• The scoped token will be checked if it already exists in the cache and is not expired.
• If the token already exists in the local cache and is not expired then the request will pass through without any calls to Keystone.
• If the scoped token does not exist it will be authenticated through Keystone/Global Auth.
• If the scoped token exists in the local cache but has expired it will be authenticated through Keystone.
• Anytime the scoped token has been successfully authenticated the token value (not the token id) will be stored in a local cache along with the tenant id and token expiration

###Keystone & Global Auth###

The Search Proxy will authenticate tokens to the appropriate identity server. The following call will be used to validate a scoped token:

GET /tokens/{token}

With a valid scoped token, the tenant id and token expiration will be retrieved from the response body. This data will then be stored in the Search Proxy’s local cache. The JSON format used for storing this data is as follows:

[scoped_token]: {
    tenant: tenant_id
}

If the token is invalid, the request is rejected.

If the token is valid the Search Proxy will then carry out the following actions:

1. Modify the request by removing the X-Auth-Token and X-Tenant-Id headers
2. Re-write the request URI by injecting the tenant id assigned to the requesting user
3. Send the request forward to ElasticSearch
4. Return the response from ElasticSearch back to the request origin

###Re-writing the URI###

There are two types of HTTP requests from Kibana to ElasticSearch that need to be intercepted by the Search Proxy.

Search requests from Kibana:

/_all/_search/
/_all/_mapping/

Passing through the Search Proxy the request will be transformed into:

/{tenant_id}/_search/
/{tenant_id}/_mapping/

Search requests made directly to the Search API:

/{tenant_id}/_search/
/{tenant_id}/_mapping/

The Search Proxy will validate that the X-AUTH-TOKEN correlates to the tenant id supplied in the request.