Cannot create a secret when working on a unauthenticated context

[John Vrbanac]

Steps to Reproduce:
* Pull down trunk or 8b983b1645a05dd7c333ca0cca1cbef30ec1ccde
* Start up a development instance of barbican (No authentication)
* Attempt to create a secret:
curl -X POST -H "Content-Type: application/json" -H "X-Project-Id: bam" -d '{
    "name": "AES key",
    "expiration": "2015-12-28T19:14:44.180394",
    "algorithm": "aes",
    "bit_length": 256,
    "mode": "cbc",
    "payload": "YmVlcg==",
    "payload_content_type": "application/octet-stream",
    "payload_content_encoding": "base64"
}' http://localhost:9311/v1/secrets

Actual Response:
{
    "code": 403,
    "description": "Secret creation attempt not allowed - please review your user/project privileges",
    "title": "Forbidden"
}

Expected Response:
{
    "secret_ref": "http://localhost:9311/v1/secrets/486a7ce3-0c46-4d7f-b8b1-c767cb1d7adf"
}

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/183391

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/183391
Committed: https://git.openstack.org/cgit/openstack/barbican/commit/?id=4e9cbe27ce9b22a88ed14da19ceee2cd2d639c96
Submitter: Jenkins
Branch: master

commit 4e9cbe27ce9b22a88ed14da19ceee2cd2d639c96
Author: John Vrbanac <email address hidden>
Date: Thu May 14 23:10:10 2015 -0500

    Fixing unauthenticated middleware role bug

    We regressed a few days to where the unauthenticated middleware
    context is completely broken. This patch attempts to resolve the
    regression through two ways. The first is to provides a way to specify
    the roles through the X-Roles header. It is assumed that a deployer
    using their own middleware should be providing this header. The second
    is that if the X-Roles header isn't specified then the admin role is
    assumed; normally this is when using barbican in dev mode.

    Change-Id: Ic19270f0381b4aec2e0c8a4ce466900bc91e1597
    Closes-Bug: 1455247