Change GET decrypted secrets to unique URI

Include the URL of your launchpad blueprint:

Currently retrieving the metadata and actual decrypted data for a secret stored in Barbican uses the same URI, with only the Accept header used to determine which response to return. This complicates deployments with RBAC systems in front of Barbican (such as Repose - or as middleware (such as EOM - It also requires adding logic like this to the Barbican app when it is used to enforce RBAC:

This blueprint proposes using a unique URI to access decrypted secrets, such as this: <host>/v1/secrets/<secret-UUID>/payload

Problem Description

Currently to retrieve a secret’s metadata and its decrypted data, the same URI is used, such as this:

GET <host>/v1/secrets/<secret-UUID>

It would be easier to configure RBAC systems that operate in front of a Barbican deployment if these two retrieval types were distinguished by URI.

Proposed Change

This blueprint calls for adding a new URI structure to retrieve decrypted secrets as follows:

GET <host>/v1/secrets/<secret-UUID>/payload

So this would include adding a new Pecan sub-controller to handle the ‘payload’ requests, adding unit and functional tests for the new ‘payload’ resource, and updating API documentation.

The existing Accept-based decryption approach would not be removed in the current ‘v1’ API version to avoid breaking the current API contract, but could be removed in the next version (‘v2’) of the API (not part of this blueprint).


Another option is to use a URI such as this to retrieve decrypted secrets:

GET <host>/v1/secrets/<secret-UUID>.payload

This approach would require parsing within the Pecan controller logic however.

Data model impact


REST API impact

This blueprint would add a new URI to retrieve decrypted secrets:

GET <host>/v1/secrets/<secret-UUID>/payload

The Accept header would still be used as now to specify the desired format to return decrypted secrets in, but the ‘application/json’ format would no longer be needed/used.

The current URI to retrieve secrets would still function as it does now, but the decryption options could be removed in the next API version (‘v2’) by a future blueprint.

Security impact

None, as the same policy rule (‘secret:decrypt’) for the new decrypt action will be used as for the current header-based decryption mechanism.

Notifications & Audit Impact

None, though auditing might actually be easier due to the unique-URI per action approach taken by this blueprint.

Other end user impact

The Python Barbican client will also need to be updated to work with this change.

Performance Impact


Other deployer impact


Developer impact

The proposed change would clean up the Pecan controllers code a bit, segregating secret metadata and decrypted payload concerns from each other.



Primary assignee:


Other contributors:


Work Items

  1. Add new ‘payload’ sub-resource controller off the ‘secrets’ resource, using the ‘secret:decrypt’ policy action

  2. Add associated unit and functional tests per below

  3. Update API documentation per below (currently located here:

  4. Update the Python Barbican Client to utilize this new resource. If it is not available (due to older Barbican deployments), it should fail over to using the current decrypt mode




Add unit and functional tests to test decrypted secret retrievals using the new ‘payload’ resource off of the ‘secrets’ resource. These new tests should function properly in the Devstack gate job.

Documentation Impact

API documentation will need to be updated to reflect these new secret decryption API call, and to mark as ‘deprecated’ the current Accept header based approach.