Recently I have been investigating the Trusts feature of Keystone version 3.
During this exploration I have walked through many permutations of acquiring
and using the trust based authentication tokens. What follows is an example of
using the ReST API to delegate a trust from one user to another, and then use
that trust to generate an authentication token for the purposes of accessing
a Swift container owned by the first user.
I am using a freshly updated Devstack on my
Fedora 20 installation. I have a very simple
local.conf file that sets all the passwords to openstack. This allows me
some flexibility when using the command line tools. I am also using the
httpie tool for making the ReST calls.
I have created a container for the demo user named job1, and set
the environment variables OS_PASSWORD=openstack and
OS_AUTH_URL=http://10.0.1.62:5000/v2.0. For reference the IP address of my
machine is currently 10.0.1.62.
####Collect IDs for the Trustor and Trustee
I start nice and simple by recording the IDs that will be needed for the
trust delegation. In this case user demo will be the trustor and alt_demo
####Collect Project ID
Next we will need the ID of the project that alt_demo should have
access to based on the trust.
####Create a JSON File for the Trust Delegation
In this case I would like to delegate a trust that allows impersonation and
gives the trustee the role of Member. This access should allow the trustee
to read and write the container while keeping the trustor’s identity. I’m
allowing impersonation so that if the trustee writes to the container the
ownership will remain with the trustor.
####Get a Token for the Trustor
We need a token scoped to the project for the trustor to authenticate the
####Create the Trust
Using the JSON file we created earlier, we now create the trust. We will want
note the id of the trust created, in this case
####Get a Token for Trustee
Now we will need a token for the trustee to consume the trust. I have
specifically created a token that is not scoped to a project to show that
there is no connection between the trustee and the trusted project.
####Create a JSON File for Trust Consumption
A simple file containing the trustee token we just acquired and the trust ID
we wish to consume.
####Consume the Trust
This operation is the same as acquiring any other authentication token with
the exception that the token will be scoped to the newly created trust. I
have cut out the catalog contents as they are quite long.
####Acquire a Trust Based Authentication Token
After consuming the trust we can use the trust_consume.json file again to
acquire an authentication token based solely on the trustee’s identity. We
will get back a structure that is, more or less, the same as the result of the
trust consumption. In this case though we are concerned with the value of
X-Subject-Token as it contains our authentication token.
####Determine the Storage URL
We need to use the storageURL as provided by Swift if we want to authenticate
with the trust based token. This is important to note as this is the only
root URL we will be able to use in conjuction with token based authentication.
####Confirm that it Works
With our freshly minted trust based authentication token, we will now attempt
to access the contents of Swift scoped to the demo user. We are not actually
accessing an object, but merely reading the contents of Swift to show us the
available containers. To access a container or object, append them to the
storageURL (i.e. http://storageURL/container/object).
####Revoke the Trust
Now we will revoke the trust using the trustor’s authentication token. This
will invalidate the trust based token acquired by the trustee.
####Confirm that Trust has been Revoked
Finally we confirm that the trust has indeed been revoked by attempting to
access the Swift storageURL using the trust based token generated earlier.
This is a very simple example but it shows how trusts can be used to share
Swift resources between users in different projects. I like the idea of
trusts because it allows a developer to provide limited access control without
having to get into the business of credential management. There is much more
depth to the trust mechanism than what is shown here but as I have learned,
Keystone is a deep well.
In my next installment I’ll get into
using the python client interfaces to perform the same operation.