openstack/barbican
Code Issues Proposed changes

Added Certificate API Docs and Quick Start Guides

Browse Source 
Change-Id: I36e8eb3e210597a2f8aa6b57f126f7fe8e99797a
This commit is contained in:
Ade Lee 2015-05-29 10:22:12 -04:00
parent 3a0ec0e8a2
commit 84d1d0b595
5 changed files with 695 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/source/api/index.rst
View File

@ -12,7 +12,8 @@ Quick Start
./quickstart/containers ./quickstart/containers
./quickstart/acls ./quickstart/acls
./quickstart/pkcs11keygeneration ./quickstart/pkcs11keygeneration
./quickstart/certificates
./quickstart/dogtag_setup
API Reference API Reference
############# #############
@ -23,3 +24,4 @@ API Reference
./reference/secrets ./reference/secrets
./reference/containers ./reference/containers
./reference/acls ./reference/acls
./reference/certificates

329
doc/source/api/quickstart/certificates.rst Normal file
View File

@ -0,0 +1,329 @@
******************************
Certificates API - Quick Start
******************************
Barbican will be used to manage the lifecycle of x509 certificates covering
operations such as initial certificate issuance, certificate re-issuance,
certificate renewal and certificate revocation. At present, only the issuance of
certificates is implemented.
This guide will provide some examples on how to use each of the supported operations.
It assumes that you will be using a local running development environment of Barbican.
If you need assistance with getting set up, please reference the :doc:`development guide </setup/dev>`.
Barbican can be used to request certificate issuance from a number of private and
public Certificate Authorities (CAs). This is done through the Orders interface.
There are several types of certificate orders available:
* :ref:`Simple CMC<simple_cmc_order>`
* :ref:`Full CMC<full_cmc_order>`
* :ref:`Stored Key<stored_key_order>`
* :ref:`Custom<custom_certificate_order>`
An example of each kind of certificate request will be provided below.
When the certificate order is received, a certificate order is generated and the client
will be provided an order reference. This order will be in PENDING state. Once the
certificate order has been fulfilled and the certificate is issued, the
order state will be updated to ACTIVE, and the order will be updated to include
a reference to a Certificate Container.
.. _what_is_a_cert_container:
What is a Certificate Container?
################################
A completed certificate order contains a reference to certificate container
as shown below:
.. code-block:: bash
curl -H 'content-type:application/json' -H 'X-Project-Id: 12345' \
http://localhost:9311/v1/orders/df1d1a0f-8454-46ca-9287-c57ced0418e7
.. code-block:: javascript
{
"status": "ACTIVE",
"sub_status": "cert_generated",
"updated": "2015-05-09T22:40:05.007512",
"created": "2015-05-09T22:40:01.556689",
"container_ref": "http://localhost:9311/v1/containers/1e71dc2b-cf63-4aa4-91f7-41ea1a9e5493",
"order_ref": "http://localhost:9311/v1/orders/df1d1a0f-8454-46ca-9287-c57ced0418e7",
"meta": {
"profile": "caServerCert",
"request_data": "LS0tLS1CRUdJ...VC0tLS0tCg==",
"request_type": "simple-cmc",
"ca_id": "422e6ad3-24ae-45e3-b165-4e9487cd0ded"
},
"sub_status_message": "Certificate has been generated",
"type": "certificate"
}
Getting the container provides references to secrets for the certificate,
any intermediate certificate chain in PKCS7 format, and potentially references
to the private and any passphrase used to encrypt the private key (if it is stored in
Barbican).
.. code-block:: bash
curl -H 'content-type:application/json' -H 'X-Project-Id: 12345' \
http://localhost:9311/v1/containers/1e71dc2b-cf63-4aa4-91f7-41ea1a9e5493
.. code-block:: javascript
{
"status": "ACTIVE",
"updated": "2015-05-09T22:40:05.003296",
"name": null,
"consumers": [],
"created": "2015-05-09T22:40:05.003296",
"container_ref": "http://localhost:9311/v1/containers/1e71dc2b-cf63-4aa4-91f7-41ea1a9e5493",
"creator_id": null,
"secret_refs": [
{
"secret_ref": "http://localhost:9311/v1/secrets/acd47891-9e72-4542-b9de-be66cc343610",
"name": "certificate"
},
{
"secret_ref": "http://localhost:9311/v1/secrets/a871baa4-6ef2-42db-ba01-13414ab60d9e",
"name": "intermediates"
}
],
"type": "certificate"
}
You can get the certificate itself by extracting the payload of the secret_ref pointed to by the label "certificate".
.. code-block:: bash
curl -H 'content-type:application/json' -H 'X-Project-Id: 12345' \
-H 'Accept:application/pkix-cert' \
http://localhost:9311/v1/secrets/acd47891-9e72-4542-b9de-be66cc343610/payload
.. code-block:: bash
-----BEGIN CERTIFICATE-----
MIIDcTCCAlmgAwIBAgIBWDANBgkqhkiG9w0BAQsFADA/MRwwGgYDVQQKDBNwa2kt
dG9tY2F0MjYgZG9tYWluMR8wHQYDVQQDDBZDQSBTaWduaW5nIENlcnRpZmljYXRl
MB4XDTE1MDUwOTIyNDAwMVoXDTE3MDQyODIyNDAwMVowIDEeMBwGA1UEAwwVc2Vy
....
HIG28XVygTC93uQmk1mAUTsIpFsk
-----END CERTIFICATE-----
.. _finding_the_cas:
What CAs are Available?
#######################
Barbican communicates with public and private CAs through CA plugins that are
configured to communicate with one or more CAs. CA plugins are configured and
enabled in **barbican-api.conf**.
To see the list of CA's that are currently configured, you can query the cas
resource:
.. code-block:: bash
curl -H 'content-type:application/json' -H 'X-Project-Id:12345' \
http://localhost:9311/v1/cas
This should provide a response like the following:
.. code-block:: bash
{"cas": ["http://localhost:9311/v1/cas/3a2a533d-ed4d-4c68-a418-2ee79f4c9581"], "total": 1}
More details on each CA can be obtained by querying the specific CA:
.. code-block:: bash
curl -H 'content-type:application/json' -H 'X-Project-Id:12345' \
http://localhost:9311/v1/cas/3a2a533d-ed4d-4c68-a418-2ee79f4c9581
The output shows the status of the CA and the plugin used to communicate with it:
.. code-block:: javascript
{
"status": "ACTIVE",
"updated": "2015-05-09T05:55:37.745132",
"created": "2015-05-09T05:55:37.745132",
"plugin_name": "barbican.plugin.dogtag.DogtagCAPlugin",
"meta": [
{"name": "Dogtag CA"},
{"description": "Certificate Authority - Dogtag CA"}
],
"ca_id": "3a2a533d-ed4d-4c68-a418-2ee79f4c9581",
"plugin_ca_id": "Dogtag CA",
"expiration": "2015-05-10T05:55:37.740211"
}
A snake-oil CA plugin is included with the Barbican source code for basic testing.
In addition, a robust, enterprise-ready CA plugin is provided for the Dogtag CA.
Instructions for setting up the CA are provided at :doc:`Dogtag Setup Instructions <./dogtag_setup>`.
More details can be found in the :doc:`certificate reference <../reference/certificates>`.
.. _order_certificate:
How to Order a Certificate
##########################
As mentioned above, several types of certificate orders are available. This
section details each one.
.. _simple_cmc_order:
Simple CMC Certificate Order
****************************
The easiest way to obtain a certificate is to provide a simple CMC request to the
server using a Simple CMC Order type. In the example below, we will use openssl
commands to generate an RSA key pair and use that key pair to create a CSR.
.. code-block:: bash
openssl genrsa -out private.pem 2048
openssl req -new -key private.pem -out csr.pem -subj '/CN=server1,o=example.com'
base64 ./csr.pem |tr -d '\r\n'
The output of the last command will be a base64 encoded string that can be pasted
into a JSON request for a Simple CMC Certificate order.
.. code-block:: bash
curl -X POST -H 'content-type:application/json' -H 'X-Project-Id: 12345' -d '{
"type": "certificate",
"meta": {
"request_data": "LS0tLS1CRUdJT..... oK2Fkh6dXBTVC0tLS0tCg==",
"request_type": "simple-cmc",
"ca_id": "422e6ad3-24ae-45e3-b165-4e9487cd0ded",
"profile": "caServerCert"
}
}' http://localhost:9311/v1/orders
The ca_id and profile parameters are not required. The profile represents a specific
kind of certificate product (a three year server cert, for instance) as defined by the
CA and CA plugin. For a Dogtag CA, "caServerCert" is usually a profile that corresponds
to a server cert and which is automatically approved and issued. More details can be
found in :doc:`Dogtag Setup Instructions <./dogtag_setup>`.
The result of this JSON request will be an order reference, which, when fulfilled
will contain a reference to a certificate container. The certificate can be extracted
as shown above.
.. code-block:: bash
{"order_ref": "http://localhost:9311/v1/orders/df1d1a0f-8454-46ca-9287-c57ced0418e7"}
.. _full_cmc_order:
Full CMC Certificate Order
**************************
This type has not yet been implemented.
.. _stored_key_order:
Stored Key Certificate Order
****************************
Stored Key certificate orders take advantage of the fact that Barbican is also
a repository for secrets. RSA private keys can be either generated on the client
and stored in Barbican beforehand using the secrets interface, or generated in
Barbican directly using the orders interface.
All that is required for the certificate order is the reference to the secret container
for the RSA key pair and any parameters needed to generate a CSR. Barbican will
retrieve the RSA key pair (assuming the user has permission to access it) and will generate
the CSR on the user's behalf. The CSR will then be submitted to a back-end CA. This
may be particularly useful for provisioning flows.
In the example below, we will generate a RSA key pair using the Orders interface, and
use this generated secret to create a Stored Key Order.
.. code-block:: bash
curl -X POST -H 'content-type:application/json' -H 'X-Project-Id: 12345' -d '{
"type": "asymmetric",
"meta": {
"algorithm": "rsa",
"bit_length": "2048"
}
}' http://localhost:9311/v1/orders
This should provide a response as follows:
.. code-block:: bash
{"order_ref": "http://localhost:9311/v1/orders/cb3c43d6-e30c-40c0-b28c-b0dd58a6209d"}
We can retrieve the reference to the container containing the RSA key pair from the order.
.. code-block:: bash
curl -H 'content-type:application/json' -H 'X-Project-Id: 12345' \
http://localhost:9311/v1/orders/cb3c43d6-e30c-40c0-b28c-b0dd58a6209d
.. code-block:: javascript
{
"status": "ACTIVE",
"updated": "2015-05-09T22:40:05.007512",
"created": "2015-05-09T22:40:01.556689",
"container_ref": "http://localhost:9311/v1/containers/1e71dc2b-cf63-4aa4-91f7-41ea1a9e5493",
"order_ref": "http://localhost:9311/v1/orders/cb3c43d6-e30c-40c0-b28c-b0dd58a6209d",
"meta": {
"algorithm": "rsa",
"bit_length": "2048"
},
"type": "asymmetric"
}
Now that we have a reference to the container, we can create a stored-key request.
.. code-block:: bash
curl -X POST -H 'content-type:application/json' -H 'X-Project-Id: 12345' -d '{
"type": "certificate",
"meta": {
"source_container_ref": "http://localhost:9311/v1/containers/1e71dc2b-cf63-4aa4-91f7-41ea1a9e5493",
"subject_dn": "cn=server1, o=example.com",
"request_type": "stored-key",
"ca_id": "422e6ad3-24ae-45e3-b165-4e9487cd0ded",
"profile": "caServerCert"
}
}' http://localhost:9311/v1/orders
As noted in the previous section, ca_id and profile are optional. The response will be a reference to the
created order.
.. _custom_certificate_order:
Custom Certificate Order
########################
A custom certificate order (which is also the order type assumed when no certificate
order type is provided) is an order in which any request attributes are submitted to
the back-end CA unchanged. This is useful if you wish to communicate with a specific CA
and wish to provide parameters that are specific to that CA. Because this request
contains parameters that are CA specific, the ca_id is required.
The example below is a custom request for a server cert from a Dogtag CA. As usual,
the response is an order reference.
.. code-block:: bash
curl -X POST -H 'content-type:application/json' -H 'X-Project-Id: 12345' -d '{
"type": "certificate",
"meta": {
"request_data": "LS0tLS1CRUdJT..... oK2Fkh6dXBTVC0tLS0tCg==",
"request_type": "custom",
"ca_id": "422e6ad3-24ae-45e3-b165-4e9487cd0ded",
"profile": "caServerCert"
}
}' http://localhost:9311/v1/orders

6
doc/source/api/quickstart/containers.rst
View File

@ -99,6 +99,12 @@ certificates:
"updated": "2015-03-30T21:10:45.417835" "updated": "2015-03-30T21:10:45.417835"
} }
The payload for the secret referenced as the "certificate" is expected to be a
PEM formatted x509 certificate.
The payload for the secret referenced as the "intermediates" is expected to be a
PEM formatted PKCS7 certificate chain.
For more information on creating a certificate container, reference the For more information on creating a certificate container, reference the
:ref:`Creating a Certificate Container <create_certificate_container>` section. :ref:`Creating a Certificate Container <create_certificate_container>` section.

210
doc/source/api/quickstart/dogtag_setup.rst Normal file
View File

@ -0,0 +1,210 @@
**************************
Dogtag Setup - Quick Start
**************************
Dogtag is the Open Source upstream community version of the Red Hat Certificate
System, an enterprise certificate management system that has been deployed in some
of the largest PKI deployments worldwide. RHCS is FIPS 140-2 and Common Criteria certified.
The Dogtag Certificate Authority (CA) subsystem issues, renews and revokes many different
kinds of certificates. It can be used as a private CA back-end to Barbican, and interacts
with Barbican through the Dogtag CA plugin.
The Dogtag KRA subsystem is used to securely store secrets after being encrypted by
storage keys that are stored either in a software NSS database or in an HSM. It
can serve as a secret store for Barbican, and interacts with Barbican core through
the Dogtag KRA plugin.
In this guide, we will provide instructions on how to set up a basic Dogtag instance
containing a CA and a KRA, and how to configure Barbican to use this instance for a
secret store and a certificate plugin. Much more detail about Dogtag, its deployment
options and its administration are available in the `RHCS documentation
<https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System>`_.
**Note:** The code below is taken from the devstack Barbican-Dogtag gate job. You can
extract this code by looking at the Dogtag functions in contrib/devstack/lib/barbican.
Installing the Dogtag Packages
******************************
Dogtag packages are available in Fedora/RHEL/Centos and on Ubuntu/Debian distributions.
This guide will include instructions applicable to Fedora/RHEL/Centos.
If installing on a Fedora platform, use at least Fedora 21.
To install the required packages:
.. code-block:: bash
yum install -y pki-ca pki-kra 389-ds-base
Creating the Directory Server Instance for the Dogtag Internal DB
*****************************************************************
The Dogtag CA and KRA subsystems use a 389 directory server as an internal database.
Configure one as follows:
.. code-block:: bash
mkdir -p /etc/389-ds
cat > /etc/389-ds/setup.inf <<EOF
[General]
FullMachineName= localhost.localdomain
SuiteSpotUserID= nobody
SuiteSpotGroup= nobody
[slapd]
ServerPort= 389
ServerIdentifier= pki-tomcat
Suffix= dc=example,dc=com
RootDN= cn=Directory Manager
RootDNPwd= PASSWORD
EOF
setup-ds.pl --silent --file=/etc/389-ds/setup.inf
Creating the Dogtag CA
**********************
The following bash code sets up a Dogtag CA using some reasonable defaults to run in
an Apache Tomcat instance on ports 8373 and 8370. Detailed version-specific documentation
is packaged and installed with the Dogtag packages as Linux man pages. For more
details on how to customize a Dogtag instance, see the man pages for *pkispawn* or
consult the `RHCS documentation <https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System>`_.
.. code-block:: bash
mkdir -p /etc/dogtag
cat > /etc/dogtag/ca.cfg <<EOF
[CA]
pki_admin_email=caadmin@example.com
pki_admin_name=caadmin
pki_admin_nickname=caadmin
pki_admin_password=PASSWORD
pki_admin_uid=caadmin
pki_backup_password=PASSWORD
pki_client_database_password=PASSWORD
pki_client_database_purge=False
pki_client_pkcs12_password=PASSWORD
pki_clone_pkcs12_password=PASSWORD
pki_ds_base_dn=dc=ca,dc=example,dc=com
pki_ds_database=ca
pki_ds_password=PASSWORD
pki_security_domain_name=EXAMPLE
pki_token_password=PASSWORD
pki_https_port=8373
pki_http_port=8370
pki_ajp_port=8379
pki_tomcat_server_port=8375
EOF
pkispawn -v -f /etc/dogtag/ca.cfg -s CA
Creating the Dogtag KRA
***********************
The following bash code sets up the Dogtag KRA in the same Apache Tomcat instance
as above. In this simple example, it is required to set up the CA even if only
the KRA is being used for a secret store.
Note that the actual hostname of the machine should be used in the script (rather
than localhost) because the hostname is used in the subject name for the SSL
server certificate for the KRA.
.. code-block:: bash
mkdir -p /etc/dogtag
hostname=$(hostname)
cat > /etc/dogtag/kra.cfg <<EOF
[KRA]
pki_admin_cert_file=/root/.dogtag/pki-tomcat/ca_admin.cert
pki_admin_email=kraadmin@example.com
pki_admin_name=kraadmin
pki_admin_nickname=kraadmin
pki_admin_password=PASSWORD
pki_admin_uid=kraadmin
pki_backup_password=PASSWORD
pki_client_database_password=PASSWORD
pki_client_database_purge=False
pki_client_pkcs12_password=PASSWORD
pki_clone_pkcs12_password=PASSWORD
pki_ds_base_dn=dc=kra,dc=example,dc=com
pki_ds_database=kra
pki_ds_password=PASSWORD
pki_security_domain_name=EXAMPLE
pki_security_domain_user=caadmin
pki_security_domain_password=PASSWORD
pki_token_password=PASSWORD
pki_https_port=8373
pki_http_port=8370
pki_ajp_port=8379
pki_tomcat_server_port=8375
pki_security_domain_hostname=$hostname
pki_security_domain_https_port=8373
EOF
pkispawn -v -f /etc/dogtag/kra.cfg -s KRA
Configuring Barbican to Communicate with the Dogtag CA and KRA
**************************************************************
In order for Barbican to interact with the Dogtag CA and KRA, a PEM file must be
created with trusted agent credentials.
.. code-block:: bash
PASSWORD=password
USER=barbican
BARBICAN_CONF_DIR=/etc/barbican
openssl pkcs12 -in /root/.dogtag/pki-tomcat/ca_admin_cert.p12 -passin pass:PASSWORD \
-out $BARBICAN_CONF_DIR/kra_admin_cert.pem -nodes
chown $USER $BARBICAN_CONF_DIR/kra_admin_cert.pem
The Barbican config file (/etc/barbican/barbican-api.conf) needs to be modified.
The modifications below set the Dogtag plugins as the only enabled secret store and
certificate plugins. Be sure to restart Barbican once these changes are made.
Note that the actual hostname of the machine should be used in the script (rather
than localhost) because the hostname is used in the subject name for the SSL
server certificate for the CA.
.. code-block:: bash
[dogtag_plugin]
pem_path = '/etc/barbican/kra_admin_cert.pem'
dogtag_host = $(hostname)
dogtag_port = 8373
nss_db_path = '/etc/barbican/alias'
nss_db_path_ca = '/etc/barbican/alias-ca'
nss_password = 'password'
simple_cmc_profile = 'caOtherCert'
approved_profile_list = 'caServerCert'
[secretstore]
namespace = barbican.secretstore.plugin
enabled_secretstore_plugins = dogtag_crypto
[certificate]
namespace = barbican.certificate.plugin
enabled_certificate_plugins = dogtag
Testing the Setup
*****************
Once all the above is set up, you can test the CA and KRA plugins by making a
request for a certificate using a pre-approved profile. As the issued certs are
stored in the secret_store, this indirectly tests the KRA plugin as well.
First, follow the instructions in :ref:`finding_the_cas` to find the ca_id of
the Dogtag CA.
Second, submit a simple CMC request as detailed in :ref:`simple_cmc_order`.
The request should be automatically approved, and you should be able to extract
the certificate from the certificate container in the order.

147
doc/source/api/reference/certificates.rst Normal file
View File

@ -0,0 +1,147 @@
****************************
Certificates API - Reference
****************************
.. _reference_post_certificate_orders:
POST /v1/orders
################
Certificates are requested using the Orders interface. Detailed description of this interface
is deferred to the Orders API reference. This reference identifies the parameters that are specific
to each of the certificate order types i.e. those orders for which the parameter *type*
is "certificate".
All orders contain a required parameter *meta*, which is a dictionary containing key-value
parameters which specify the details of an order request. All the parameters below are passed
in the *meta* dictionary.
The result of this operation is an order for a certificate, returned to the client as an order
reference. Upon completion, the order will contain a reference to a Certificate Container,
see :ref:`certificate_containers`.
Common Attributes
*****************
Certificate orders have the same attributes that are common to all orders. The table below lists
those parameters that are specific to certificate orders in particular.
+----------------------------+---------+----------------------------------------------+------------+
| Attribute Name | Type | Description | Default |
+============================+=========+==============================================+============+
| request_type | string | (optional) The type of certificate order | custom |
| | | Possible values are stored-key, simple-cmc, | |
| | | full-cmc and custom | |
+----------------------------+---------+----------------------------------------------+------------+
| ca_id | string | (optional) The UUID of the CA to which this | None |
| | | certificate order should be sent. This | |
| | | UUID can be obtained from the cas interface. | |
+----------------------------+---------+----------------------------------------------+------------+
| profile | string | (optional) Identifier indicating the | None |
| | | certificate product being requested. | |
| | | eg. a 3 year server certificate with certain | |
| | | extensions. This identifier is CA specific. | |
| | | Therefore, ca_id is required if the profile | |
| | | is provided. | |
+----------------------------+---------+----------------------------------------------+------------+
| requestor_name | string | (optional) Requestor name | None |
+----------------------------+---------+----------------------------------------------+------------+
| requestor_email | string | (optional) Requestor email | None |
+----------------------------+---------+----------------------------------------------+------------+
| requestor_phone | string | (optional) Requestor phone | None |
+----------------------------+---------+----------------------------------------------+------------+
Attributes for Simple CMC Orders
********************************
+----------------------------+---------+----------------------------------------------+------------+
| Attribute Name | Type | Description | Default |
+============================+=========+==============================================+============+
| request_data | string | The base64 encoded simple CMC request with | None |
| | | no line breaks. Simple CMC is the same as | |
| | | a PKCS10 CSR. (RFC 5272) | |
+----------------------------+---------+----------------------------------------------+------------+
Attributes for Stored Key Requests
**********************************
+----------------------------+---------+----------------------------------------------+------------+
| Attribute Name | Type | Description | Default |
+============================+=========+==============================================+============+
| source_container_ref | string | Reference to the RSA container already | None |
| | | stored in Barbican containing the private | |
| | | and public keys. | |
+----------------------------+---------+----------------------------------------------+------------+
| subject_dn | string | Subject DN for the certificate. This | None |
| | | value must comply with RFC 1485. | |
+----------------------------+---------+----------------------------------------------+------------+
| extensions | string | (optional) Base 64 DER encoded ASN.1 values | None |
| | | for requested certificate extensions, | |
| | | Currently, this value is not parsed. | |
+----------------------------+---------+----------------------------------------------+------------+
Attributes for Custom Orders
****************************
+----------------------------+---------+----------------------------------------------+------------+
| Attribute Name | Type | Description | Default |
+============================+=========+==============================================+============+
| (Varies - depends on CA) | (Varies)| Custom certificate orders pass arbitrary | None |
| | | parameters through the CA unchanged. It is | |
| | | up to the CA to interpret the parameters. | |
| | | Note that as the request parameters are CA | |
| | | specific, *ca_id* is required for this | |
| | | request type. | |
+----------------------------+---------+----------------------------------------------+------------+
Request:
********
The request below shows a simple CMC request. For examples of each type,
see the :doc:`Certificate Quick Start Guide <../quickstart/certificates>`.
.. code-block:: javascript
POST /v1/orders
Headers:
Content-Type: application/json
X-Project-Id: {project_id}
Content:
{
"type": "certificate",
"meta": {
"request_data": "... base 64 encoded simple CMC ...",
"request_type": "simple-cmc",
"ca_id": "422e6ad3-24ae-45e3-b165-4e9487cd0ded",
"profile": "caServerCert"
}
}
Response:
*********
.. code-block:: none
201 Created
{
"order_ref": "https://{barbican_host}/v1/orders/{order_uuid}"
}
HTTP Status Codes
*****************
+------+-----------------------------------------------------------------------------+
| Code | Description |
+======+=============================================================================+
| 201 | Successfully created an Order |
+------+-----------------------------------------------------------------------------+
| 400 | Bad Request |
+------+-----------------------------------------------------------------------------+
| 401 | Invalid X-Auth-Token or the token doesn't have permissions to this resource |
+------+-----------------------------------------------------------------------------+
| 415 | Unsupported media type |
+------+-----------------------------------------------------------------------------+